Open Source -- A Standards Success Story?

This year, the buzz is all about Open Source. The LISA '98 keynote speech, by Eric Allman, was about Open Source. Then, of course, there were the now infamous Hallowe'en documents from Microsoft. The idea has been around for a long time, but Eric Raymond's paper "The Cathedral and the Bazaar" really sparked the most recent formalization of the concept. Those of you who want to know more about the concept should look at <www.opensource.org>.

Open Source software is extremely successful, in general. Without standards, it would probably still succeed, but it would have a far more limited appeal. Just how many successful Open Source applications are there that don't have a POSIX-style system as the base starting point (even if they have been successfully ported to non-POSIX systems)? However, developers of Open Source software still have to riddle their code with #ifdef's to allow for the enormous varieties of systems that are in existence. If the standards community had really achieved everything it wanted to, far less of this conditional compilation would be needed. But at least the majority of systems behave in a largely similar fashion, and that really is thanks to standards. In "The Cathedral and the Bazaar," Eric Raymond points out, "When your code is getting both better and simpler, that is when you know it's right." The fewer the differences between systems, the easier it is to achieve this goal.

The idea that standards such as POSIX make source portability easier is most relevant when the source itself is open. Typical closed or proprietary applications do not worry so much about standards; they are out to use all the proprietary interfaces they can, to squeeze every last drop of performance out of the systems they have targeted. Just how much easier has POSIX made life for a company such as Oracle? (I am not qualified to answer that question personally, but I'd be very interested to hear a response from you if you work for an organization like that.) But how much easier has POSIX made it for the adoption of BIND or Apache?

It is very interesting to look through some of these Open Source applications and see where there is a lack of standardization. Perhaps we in the standards business should take more notice of these. For example, which header files are needed, and in what order; where certain files are located; and how options are handled regularly cause problems. These are the areas we need to consider in the current revision of POSIX and The Open Group's Single UNIX Specification.

And what of that project? Last September, representatives from The Open Group's Base working group, the IEEE Portable Applications Standards Committee (PASC), and ISO/IEC JTC1/SC22/WG15 (POSIX) met in Austin, Texas, to agree that the POSIX standards needed revising and to decide to do the work together. Because of the location, the group has become known as the Austin Group. It has taken six months to settle the basic ground rules for how that group will operate, but finally we appear to be ready to start the real work. Projects will be sponsored in each of the organizations to produce a single common set of specifications ­ initially four, covering what is now in the two POSIX.1 and POSIX.2 standards. The four books planned are: the system APIs (currently POSIX.1 and XSH); Commands and Utilities (POSIX.2 and XCU); a new common definitions book; and a separate guide to using the standards, to which the rationale will be moved. The next meeting is planned for early March, with subsequent meetings in Montreal in July and somewhere in Europe (probably Copenhagen) in the fall. The first drafts of these four books should be ready before the year 2000 rolls around.

All Austin Group meetings are open to anyone; there is no membership requirement. All the drafts are intended to be freely available via the Web for comment. By helping to get these standards correct, useful, and usable, we can ensure a bright future for Open Source developers, our real target audience.