The latest news on the Linux front is that the 2.4 kernel won’t be delivered for at least 2 more months.  I guess some people are anxious to get their hands on it, although most of them are probably running the test releases.  Me?  I’m happy with the current kernel (2.2.14) that I’m running, and I’m not about to put a test release on my production box.  I work with enough pre-production software that I don’t want a possibly flaky operating system adding to my troubles.

The interesting thing about the kernel being late is the response in the Linux community.  There are two major camps:  those who think Linus is doing the right thing by holding up the release to ferret out the remaining bugs, and those who think it’s “good enough,” to be released now and follow up quickly with some patch releases.  The former seems to be the larger of the two groups, and the one I’d tend to agree with.

More interesting is the response to detractors who point out that the kernel is late.   “How can it be late,” they point out, “when the kernel team never committed to a release date?  It’ll be released when it’s ready.”  They go on to point out that, unlike Microsoft (or other large companies, but Microsoft is the favorite whipping boy), the Linux community isn’t driven by marketing pressures and competition that requires them to commit to a schedule.  Of course, that doesn’t prevent them from laughing at a company that misses a release date.  

The Open Source crowd needs to learn that not everybody has the luxury of waiting until the coders think things are ready.  Business runs on schedules, and serious people expect developers to commit to a schedule and then stick to it.  As a developer, if you’re not working on a schedule then you’re just goofing off.  If you can’t commit to a schedule, then you shouldn’t be coding because you didn’t spend enough time studying the problem and designing the solution.  Programmers are the reason most software projects are late, buggy, and over budget.  Programmers who are either overconfident in their abilities and fail to take design and testing time into account, or who purposely commit to unrealistic schedules and then point to “unexpected complications” when asking for more time or money to complete the project.  It’s amazing that the business community has allowed this to go on for the last 50 years.  It’s high time that programmers act like the professionals they claim to be and stop shirking their responsibilities like teenagers who don’t like taking out the trash.