Loved the article of Joel on Picking a Ship Date. As usual, he has various entertaining stories to make his point.
Both Red Hat and SUSE have their Linux distributions shipping every six months (Fedora Core and SUSE Professional) which in my opinion burns too many developer cycles on testing, quality assurance and documentation. Except for a few fairly obscure developer features each distribution is hardly distinguishable from the previous version.
Maybe its a good thing that these features are released on a six-month based schedule, but in my opinion they are not as important as they used to be. In the early days of Linux the the a.out to ELF migration or the libc5 to glibc migration would have every Linux user running to download the latest distribution.
A few interesting quotes:
If you have a lot of validation and unit tests, and if you write your software carefully, you may get to the point where any daily build is almost high enough quality to ship.
On reasons why you might have to change your release date, I found this painfully funny:
Or maybe a new version of the Linux kernel is coming out soon with yet another all-new system to implement packe filtering;
On new software releases that are not worth upgrading to:
Corel PhotoPaint and Intuit Quickbooks are particularly egregious examples of this; they have a new "major" verson every year which is rarely worth buying
I have a similar feeling with my Linux distros; I tend to stay with my current distribution for very long periods of time. Literally, only when forced to upgrade through dependencies I consider an upgrade. Maybe am no longer a sophisticated user.
On teaching and hackers:
But mostly because I'm a pedantic windbag who can't resist the opportunity to teach a little lesson to the younguns who think that a compiler has to generate machine code.
Based on your age you will either call this an evil hack (if you're young) or an elegant hack (if you're old);
Interesting read on blogs, IM, presence, wikis and our humanity on Adam's blog.
Microsoft and Open Source
Mitch Kapor comments on the recent Groove acquisition from Microsoft, Mitch said something interesting:
The challenge now is whether Ray and Groove, which represent forces of architectural innovation, can have a successful impact at Microsoft, which after all, is a large (58,000 person), middle-aged (30 year-old) company. It's hard to know whether the loss of nimbleness due to size and age is a greater challenge to Microsoft than is open source.
I have finally started looking at Microsoft's Indigo, and am disappointed at it for various reasons, maybe I will write something about it later. In the meantime, I started to learn about ZeroC's ICE which seems more useful as a basic RPC framework.