Editor: Nick Stoughton <nick@usenix.org >

As I enter my fourth year as editor of this column, and as I reflect on the progress and changes that have happened in that time, I find myself wondering if the battle is over, or the wheel is simply turning, and soon well be right back where we started.

Then, we in the midst of the battle over Language Independent Specifications and Test Methods, now we are trying to understand the very future of the POSIX work. At the same time, we are considering sponsorship of a Project to build a Language Independent version of POSIX.1 (including Realtime and Threads), and the lack of anyone interested in test methods is actually having an adverse effect on the usefulness of the work we are producing.

Some years ago, before I was truly involved in standards, it was common for military and government groups to produce their own standards, MIL-SPECS in the US, and STANAGs in NATO. The realization that this was expensive, not just to the producers of the standard, but to the vendors who had to meet them to make sales into those government bodies, led to the move towards open, industry wide specifications. POSIX has had much help from the US Government over its life. While the process has been open, and effectively free for all interested parties to participate, there are more and more cases arising where the only interested party is the Government, or to be more specific, the military.

This production of MIL-SPECS by another name, or by another route, is not helpful to the industry as a whole. Sure, the Government is a big buyer of computer systems; they promise to spend hundreds of millions of dollars on computer systems over a relatively short period. But divide that between the vendors who have to implement those standards that the military have built alone, and the investment required simply does not match the return.

And so there is a move afoot to try and stop the standards bodies producing standards in particular, to stop PASC (the IEEE Portable Application Standards Committee) from producing POSIX standards. "If you donÕt let the military build these standards, then we wonÕt have to lose money implementing them", or so the argument goes. Trouble is, this is a broken argument. Broken in so many places it will never fly. PASC is simply one sponsor body for IEEE computer portability standards. If it went away, and someone, even the military, wanted to produce a standard in that space, they could simply approach the IEEE Standards Advisory Board and produce it, as a full scale IEEE and ISO standard, independently of PASC.

Standards have been useful, so far. OK, we have one or two that some may argue about, especially when we consider the effect on UNIX of standards such as the realtime set. These are standards that do have historical precedent, which exist in many forms today, but rarely in mainstream UNIX implementations. The major vendors have had to spend millions of dollars adding these interfaces to their products, because X/Open was forced to follow POSIX here. This is an investment that, despite government money, will take many years to recoup. Do all vendors have to implement all interfaces? Clearly this is good for the government, who want to feel that there is open competition for all tenders (if only that were true!).

Some have commented that in spite of the huge cost, it has been worthwhile, since it was much easier to add these interfaces to UNIX than it will be to add them to Window NT. Anything that makes it harder to sell NT must be good! I remember this argument ten years or more ago, when UNIX was emerging as a major player in the Operating Systems market, and the mainframe vendors were valiantly refusing to believe that their end was nigh.

The whole point of standards, though, is to make these arguments futile; if we do produce useful, general-purpose standards, that everyone, and not just the military, want, then who cares what platform they are implemented on? I build applications today that I know will run on NT as well as UNIX, without testing them to destruction, without spending a huge time and effort porting them; they will just work there (thanks to Softway's OpenNT POSIX extensions). And since I don't (currently) write applications to guide Cruise Missiles, I can safely ignore those standards that are intended to make that job easier.

And so we come full circle; the need for standards is greater today than it ever has been. As we diversify away from good old UNIX to other emergent operating systems (and I am using that term advisedly), the benefits from standards are even greater than when I was simply worried about porting between UNIX implementations. The details we are arguing about have returned to the same that we were worried about three years ago. The lesson we must learn is that while standards are useful, and worthwhile, not everyone need implement all standards that exist; let market forces drive that.