A bit of a FG special here and a slightly different topic for FG, but still very pertinent to open source development.
Today saw the last ever release of the -ck kernel patchset.
Anybody who ever tried ricing their Gentoo in order to attain half-decent audio/visual perforance, or knows much about kernel patchsets, will no doubt be aware of the -ck kernel patchset. It is a patchset for the Linux kernel that is aimed at providing an optimal desktop experience. It made my old machines usable with Gentoo Linux back in 2001-2003 before I switched to Ubuntu and gave up hope of my old machines ever being able to handle more than one sizeable task at a time. Con took a problem, solved it, but because he wasn't well integrated in Linux kernel development his solution never got the proper attention it deserved.
The two main features of Con's patchset are his Staircase Deadline scheduler and Swap Prefetch. The kernel scheduler decides what processes get access to your computer's CPU and when you are low on memory the kernel pushes inactive applications into swap. In real terms this means that your music lags when you load up OpenOffice.org and Firefox takes 20s to respond to your first click if you didn't switch your PC off last night. In real terms the -ck patchset means no lagging music when you use other applications, and your Linux desktop does not take ages to become responsive if you haven't used it for a while. Basically Con took the rather rubbish default Linux scheduling and swapping logic and threw them out the window. And he has been working on these for years - at least since Linux 2.6.1.
So why is today seeing the last release of -ck? Well, Con has been effectively cast aside by the kernel development process. Justifiably feeling offended, and subsequently lost his desire to keep maintaining a bunch of features that could never get merged into mainline.
When somebody close to Linus runs off and implements their own scheduler, it takes less than 3 months to become integrated into mainline. People will debate back and forth the technical merits of CFS (by Ingo Molnar) and SD (by Con Kolivas) but the reality is that both solutions are good but only SD is very well tested and refined. CFS is still new and raw. It came down to "who you know" and Ingo has his hand on the kernel tree so his solution gets way more contact with the right people and hence is now fast-tracked into Linux as the default scheduler. I don't think the technical merits of either had anything to do with choosing between them. SD was not written by a highly-ranked kernel developer, CFS was. It's just ridiculous that it has taken so many years to get to a stage where the default kernel scheduler is Not Crap (tm).
Understandably completely disillusioned that his efforts are now going to be nothing more than a historic catalyst, Con will no longer maintain this patchset. It is almost redundant now anyway since CFS makes the SD pointless as a patch. Logically concluding that the same would happen with his other major kernel patches, Con is issuing calls to "merge or delete" them because why should he put in years of dedication just for his work to be disregarded for a more junior solution. At last some of it looks like it is going in - notably swap prefetch - but it's a shame that sometimes it takes such extreme measures for decent features to be properly considered. Once Linux 2.6.23 ships, by default Linux desktops will no longer be afflicted by applications taking double-digit times to wake up on an idle machine.
Contributing to open source projects has it's benefits and it's downsides. One of the downsides is that significant contributions can be ignored by upstream and with a project the size of the Linux kernel there is no way you can realistically fork it. Indeed, in smaller projects people will put forward valid contributions that are rejected due to fear of the original author having to maintain something they did not write or create. Not every good line of code will become part of the project it is intended for. One of the true arts of open source project management is striking the right balance between accepting contributions and minimizing the problems they may cause, but it will always be a case that some bad stuff gets in whilst some good stuff gets lost. It happens to games - check out all the OpenTTD contributions many of which were great but never got merged.
The most important thing from such a saga is that people learn from it. Will Linux kernel patch inclusion policies change? I doubt it, but open source is open development - other people can look at this and use it as a basis for making their own contribution acceptance policies. Basically you do not want to lose contributors as talented and dedicated as Con Kolivas.
This article is dedicated to you Con. You improved my Linux experience and that of many others. So long, and thanks for all the fish.