I'm not here to debate the value of standards, or how deep an impact they may make on the future of Linux. Those issues have been dealt with more than adequately by the many commentaries that have preceded this one, most notable the one Stuart Anderson did last week.
This particular soap-box will instead attempt to take a step back, and look at the way the Linux community has approached the issue. It says much about the Linux community and the way it's preparing to cope with the next wave of FUD and antagonism.
As part of a company that's been selling so-called "open systems" for the better part of 15 years, I've had a chance to see how the Unix community argued and alternately split and join, partner and back-stab. The original community spirit that fostered early BSD development soon took a back-seat to corporate greed.
We jumped at the chance to become involved with Linux, at about the same time that the AT&T Unix legacy got re-dumped, this time by Novell upon SCO. We saw Linux, in some ways, as the real open system that Unix claimed to be but never truly was. Here, after all, was software governed by a license that not only guaranteed source code, but prevented any future user from making closed enhancements!
But free software has been with us for quite some time; there were plans for GNU Hurd long before Linux ever came to be, yet look at how the two have progressed next to each other.
Why? I would suggest that a significant portion of the credit for that rests on Linus' shoulders. He helped steer a personal project into a community one, with a dynamic that saw a widely diverse group of people all pulling in the same direction, all with a voice yet able to achieve consensus.
The community development model is what sets Linux apart from Hurd, from Unix -- and from all its predecessors. Three years ago, this looked to me as if Unix had been re-invented, the right way, where great software was being produced and people were having a good time at it too.
I now look at the Linux standards process as a potential U-turn into the old Unix methods of alliances, mutinies, mistrust, bureaucracy, and politics-by-press-release. As a result, here we are -- many months after the mandate was given by Linux International -- still coming to grips with fundamental principles, such as whether some advocate's scripting-language-du-jour should be part of the standard. Tougher issues, such as packaging systems, appear many months away from resolution -- if ever.
A sense of community -- a trust and appreciation that everyone is working in the same direction -- needs to infect the LSB effort in a way that hasn't happened yet. People who aren't "members" are officially invited not to speak. This is almost the antithesis of the process that begat Linux to begin with; welcome to the LSB cathedral.
The Linux community is at its best when it works informally, quickly, with a broad base of people sharing common trust and purpose. The LSB needs to retrieve some of these qualities if it's going to succeed at its purpose.
What if it doesn't succeed? We've already been given a taste.
The Linux Standards Association, if it hadn't been so ineptly done and driven by emotion, could have been a significant threat to the LSB in coming up with a palatable standard that ISVs could embrace. It's very possible that a future effort similar to the LSA, but implemented better, could succeed -- especially if the LSB continues at its current pace.
I hear persistent rumours -- from too many different sources to have them simply laughed off -- that a major vendor such as IBM is looking to either throw its weight behind a current distribution or make one of its own.
If such a move happens, and no LSB snapshot is yet in place, many ISVs (especially those staying away from Linux now because of perceived instability) would simply flock to supporting that major vendor's distribution. From that point on, current distros wanting to run those applications will find themselves needing to follow the conventions and facilities dictated by someone else.
Is this a bad thing? Not to everyone. Many ISVs won't care less if a standard comes about by committee or decree. If it's reasonable. and stands a chance of lasting and being implemented on enough distros, an arbitrarily imposed standard may be good enough for many ISVs -- regardless of what noises come out of the current standards makers.
It's a reality that Linux, popular as it is, has appeared on the radar of those who succeed by beating competitors into submission. Their tactics, even when legal and legitimate, are usually hardball and frequently effective. The best way to cope with this coming assault is to do what the community does best -- work swiftly, informally, and keep to the same goals that have brought us this far.
The LSB must do what it must to move swiftly, and get back to the basics on which it was founded, rather than dwelling on trivia such as who's allowed to talk to whom (a somewhat strange objection in a supposedly-open process anyway). The original LI mandate, of being the minimum possible standard needed to satisfy the needs of VARs, has the double benefit of being both easier to create, and easier to sell, than the more-complex visions floating around.
Of course, making things happen faster may require the LSB to bring more people into the process than the tight little group running the show now. Perhaps the need for speed may convince the LSB that it'll be better off as a true community project, just like the operating system it's trying to support.
Linux is indeed a better re-invention of Unix because of its community model; its standards effort will only succeed if it follows the same path. I hope this happens; I don't cherish the alternative.