When the project started it was easier to get involved because the code base was smaller and most people were contributing in their spare time, a few hours here and there on the weekend, while they did their real jobs that brought in money for them to live. Anybody with coding experience will tell you it's much easier to join a project where the code base is fresh rather than work on something that 2 decades worth of ideas implemented by someone who holds all the decisions leading up to why a certain subsystem is written the way it is in their head. It's that knowledge about why a certain piece of code is written the way it is, that you only glean by actually writing the code, making the mistake and learning from it. Expecting a younger person to be able to automagically have this same knowledge when they join the project is short-sighted. The other issue is that Linux may not have started as a commercially driven project, but it is a commercially driven one now. Someone in their spare time wanting to contribute to the kernel can't compete with someone being paid by Oracle to write a file system. They've got better things to do. The solution is to make it worthwhile for younger people to start working on the kernel, because at the moment the barrier for entry is high because commercial interests make it hard for young ones to learn the kernel when all the low hanging fruit is reaped by those paid to work on it, and knowledge required now is higher than it was 20 years ago.

Tends to be a waste of time in my experience. Your novice spare time patches are competing with those from people who are 1) paid to work full time on the code base 2) that they had a significant hand in writing themselves. Note that I have contributed a meagre patch to gcc, so my name's in the changelog in 2004, but it didn't result in me taking off with the gcc project. Maybe I shouldn't have focused on fixing bugs in gcc and added a new feature, since adding new features is easier to do. The most prolific contributors to open source projects are involved in famous open source projects because they are paid to be or their project is not famous and they control it and are the sole contributor.

All of them, or close enough. I play far too many games that having a single one running on Linux isn't enough for me to warrant ditching Windows. 10% running on Linux wouldn't be enough, it would have to be closer to 95%. And for that to happen, there would have to be some sort of miraculous movement of concious thought within the game industry to start developing games for Linux instead of Windows. Lone developers can't shift the industry. Games are the sole reason I use Windows.

He's doing this to raise money for research. I don't think he expects to solve it 'live on TV infront of a studio audience'. It's more like an opportunity for others to be educated about the Riemann hypothesis.

Now all Java devs will be able to afford a yacht like Larry's after customers fork out for the non-crippleware version of the jvm.

Oh and Dragon Age from Bioware has heaps of content for single player. It's the best single player experience I've had in ages.

Duke Nukem Forver will have loads of content after 12 years in development.

"If I have seen a little further it is by standing on the shoulders of Giants." - Isaac Newton. The corollary is there is no such thing as a self-made man.

Yeah I've been working on with open source dev tools in the network appliance domain for several years now but I've come to think that .NET is one of the things that MS did right. Thankfully I haven't been working with Java but c/c++ and python and bash. Java wasn't originally open source and was a poorly designed language that got lots of marketing impetus from Sun, hence it's widespread adoption. You end up with code the calls the AbstractObjectFactory that calls the AbstractAbstractObjectFactory etc and a whole lot of objects that you don't need. At least with C++ you can choose not to use objects and simplify. Same with Python.

Management that requires me print out a timesheet in from excel and then get it printed and signed then I scan the signed document and email it to the appropriate people.

Evidence based estimating is what I'd like to see more of and less of the abracadabra 'story points' rubbish that SCRUM practitioners advocated. At a previous organization we went down the SCRUM road and were told to use story points where a story point is a unit of effort (not time) required to do the task. Naturally all the devs were confused and eventually resorted to equating a story point with a unit of time (like an hour) and not a unit of effort as we were supposed to. There's also the problem were one dev's estimate of say 4 story points is not the same as another dev's estimate of 4 story points. There was never a consensus as to what a 'unit of effort' meant unless it was taken to be equivalent to a unit of time. Evidence based estimating seems to provide a better solution since it tracks the history of an individual dev's estimates, recognising the fact that an individuals estimate will differ from another. So for example if someone has a habit of underestimating a task, because of the feedback that goes into the system after the task is done, the system caters for this when that person makes another estimate.

Yay ... now all I need is a farting cow, a playground for the kids and a swamp in my backyard and I'll have enough juice to run my linux desktop. Seriously this kids going to turn into one of those bosses with all the fancy ideas of how things should work, then try and convince other people to do the work for him, and no skills to make anything.

Except it has this ability to leave trailing whitespace on the end of lines, can't do buffer local settings (i.e. can't set different a different value for tabstops depending on the file), and the last time I saw someone use it he would tap the space bar several times to indent because Geany's tabs to space conversion was broken and I don't even think it's configurable via some sort of script language. I don't really understand why people don't use one of the more established editors like emacs or vim. If you learn how to use one of those well then you're not going to regret it, but with something like Geany you'll eventually run into problems that these serious editors would already have encountered and solved.