Articles / Editorial: Make the LSB a c…

Editorial: Make the LSB a community project?

Evan Leibovitch, principal of Sound Software and member of the original LSB committee, takes another step back and compares the efforts the Unix world went through with the ongoing Linux Standard efforts. He proposes to open up the LSB process to the community as a whole, instead of having a tight little group run the show. His editorial also carries a ficton that could become true if a major ISV decides to develop a Linux distribution on its own. The last few weeks (more than a dozen!) have seen the Freshmeat editorial agenda dominated by issues regarding Linux and standards.

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.

Evan Leibovitch

Recent comments

06 Apr 1999 09:30 Avatar farli

The serious flaw that I see with LSB is twofold - its closed nature, to be sure, and its assumption of leadership. Leadership of an OSS project is a matter of respect AND competence. Each OSS project has its Benevolent Dictator. The position is assumed by the individual BD and accepted by the tribe. Why and how the BD assumes the leadership role is not the issue. How he maintains the position is. The BD is respected by the tribe both for his competence and his willingness to hear the voices of the tribe, both of praise and of criticism. He is willing to hear the suggestions for what they are - a good faith effort to contribute. While maintaining ultimate power over the project, he hears the soundness of the ideas and chooses directions based on the value of the ideas, not his own unilateral concepts.

The *ONLY* way that these OSS projects succeed and continue to improve is by using the open communication channels available to both the BD and the tribe members. Without that bi-directional communication, the project flounders and dies. That, unfortunately, will be the result of the LSB project if those involved in it think that they know better than the rest of the community and think that they can impose their will on the tribe. They may succeed in standardizing and marketing whatever they standardize, but where will they go then? Do they seriously think that the OSS community will simply follow like lemmings? They will succeed in causing the very same thing that the *NIX community has seen - fragmentation, animosity, and dissent.


Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.


Project Spotlight


An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.