Linux Standard Base Is Doomed to Irrelevance

I was honored to give a keynote address at Linux Business Expo (as part of NetWorld+Interop) this year in Atlanta. Unfortunately, due to an administrative mix-up, no one posted signs for the event, so only a handful of people showed up. Red Hat Inc.'s Bob Young had the same problem for his keynote, which took place the day before. Nevertheless, I tried to drill home my message to the few who attended.

My goal is simple: I'm out to drum up some support for Linux Standard Base (LSB), and I'm out to give LSB a serious kick in the keester. (It is also my goal to chew some bubblegum, but I'm all out of bubblegum.)My first message was to encourage others to support LSB. But by support I don't just mean to contribute to the project, although that is very important. I am also calling for the Linux community to shame the mother organization Free Standards Group into either hiring a solid leader to get LSB moving, or for the existing leadership to get off its bum and produce a comprehensive specification and a self-hosting sample implementation in our lifetime. And by comprehensive I mean encompassing enough to build sophisticated graphical applications. What I most certainly do not mean is the pathetic minimal standard that seems to be slated for the LSB 1.0 specification. That way lies irrelevance.

After almost three years, the most significant visible achievement of LSB is a beta specification called the Linux Development Platform Specification (LDPS). LDPS is a paltry 1,800 words describing an inadequate set of building blocks for Linux applications. The specification itself is so simplistic that I was able to duplicate almost the entire list of requirements, version for version, in less than two minutes by asking the audience common-sense questions. Now consider the fact that there were only two or three Linux programmers in the audience!

Even more embarrassing is the fact that LDPS is not honest about achieving its goal. For example, the specification lists several distributions that comply with LDPS. But these distributions do not fully comply with even the tiny list of requirements LDPS covers. None of the distributions listed that I have used completely adhere to the File system Hierarchy Standard 2.1.

And in areas of the specification where they do comply, that compliance does not always solve the problem of compatibility. For instance, LDPS makes the meaningless requirement that a distribution must include either ncurses version 4 or ncurses version 5. But those that include version 4 will have incompatibilities with programs compiled for version 5, and vice versa.

In short, both LDPS and the general LSB specification should identify many more pieces of the system than they do. These specifications should not pander to existing distributions but require only those versions that most benefit users and administrators. And then LSB should be aggressive about forcing distributions to update their products to conform.

And therein lies the problem: a total lack of aggression and willingness to be proactive. In fact, all of the LSB problems seem to stem from passive and inactive leadership, which is why I suggested a few weeks ago that LSB participant Scott McNeil should take over this project. LSB has more than enough talent and technical heroes. But it also takes testosterone (or estrogen as the case may be) to push a specification forward, and it takes more of the same to establish a clear and comprehensive definition and demand that distributions come into line. Scott has that to offer. And that's what LSB currently lacks.

The passive approach LSB is now taking may please the distributions and members of the Linux community who are sensitive to being told which standards they should use.

But Linux deserves better. And LSB no longer has any legitimate reason not to deliver better. Until recently, LSB defended its passive approach by stating that there aren't enough resources to lead Linux forward, only to document what exists. The Open Source Development Labs, which vendors are ready to pour millions of dollars into, should solve this problem, leaving LSB without any more excuses. So as of now, LSB, you are on notice. Get a leader, or get out of the way.

Nicholas Petreley is the founding editor of LinuxWorld (www.linuxworld.com). Reach him at nicholas.petreley@linuxworld.com.

Join the newsletter!

Error: Please check your email address.

More about Free Standards GroupInteropLSBRed Hat

Show Comments

Market Place