Open source release engineering: a higher standard

Last night I built a bunch of open source software on the Mac OS X system I'm trying out. A partial list: Perl 5.8, expat, XML::Parser, SOAP::Lite, Python 2.1, Zope 2.5.1. Mind you, Perl 5.6 and Python 2.2 come prebuilt with Jaguar. But I've always wanted to see a Perl build happen on a Macintosh. And since Zope 2.5.1 says it doesn't like Python 2.2, I went ahead and built 2.1 as well.

Every time I do this kind of thing, I marvel at the high standard of release engineering that open source sets for itself. If you use open source stuff, you probably take this for granted. If you don't, you're probably don't know or care. But it really is extraordinary. The process was, to be sure, not 100% smooth, and Google was an essential ally. Without it, I wouldn't have found the signposts left by, for example, Jeffrey P Shell and Randal Schwartz .

I know that some people regard scrabbling around in Google for these kinds of clues as evidence that the open source process is haphazard. Sometimes I've been prone to such grumblings myself. But think about it from another perspective. Suppose Microsoft, or any commercial software developer, had to package up not only the end product, but also the entire process for building it from source -- for dozens of slightly-varying platforms. The amazing thing is not that build processes sometimes need to be kicked or cajoled, but that they exist at all. It's a tribute to the power of scripting to automate wildly complex sequences of operations, and to the ingenuity of open source programmers who build and maintain all that automation in addition to the software that it supports.

Former URL: