Danger of fragmentation
So, what exactly is the LSB, and what does it mean for businesses? The project was initiated in 1998 under the chairmanship of Bruce Perens, with the aim of preventing Unix's fragmentation from spilling over into Linux. In 2000, the LSB and LI18NUX projects joined to form the FSG, and efforts over the next four years culminated in the release of the LSB 2.0. One of the primary motivating factors in all this has been the desires of ISVs to have a single unified scheme for porting, testing and certifying applications on Linux. With Unix, ISVs were forced to create a new port for every version, an expensive proposition; it is no surprise that Unix market share is steadily giving way to Windows and Linux.
"There was a big problem with the level of forking in the Unix community," says Red Hat analyst relations manager Nick Carr. "Applications wouldn't move around under any circumstances. It's not that it would take three months to port, it was that it wasn't going to happen."
The LSB builds on earlier efforts that attempted to prevent Unix fragmentation, such as the Portable Operating System Interface (POSIX) and the Single Unix Specification (SUS); it uses some of POSIX's source code standards and SUS' interface definitions. POSIX only defines programming interfaces and doesn't guarantee binary compatibility, while standards such as OSF/1, which aim for binary compatibility, were found to be too restrictive. The LSB aims to strike a balance between the two approaches - it includes a binary compatibility layer, but isn't as restrictive as OSF/1.
The aim of the LSB isn't to create a single, monolithic Linux operating system, but to
allow different LSB-compliant distributions to differentiate from the competition, while still running any LSB-compliant application.
LSB 2.0 was formed largely by ISV feedback, says Zemlin. Vendors wanted the specification to cover more of the libraries used in building applications, such components as additional runtime environments, cryptography, XML, PERL, PHP and Java. Version 2.0 added several significant features, such as support for SUS and an application binary interface for C++.
The standardisation project is necessary if application vendors and end users are to feel comfortable choosing open-source over a proprietary option, says Zemlin. "Without the standard, writing applications to multiple flavours of Linux becomes costly. By supporting the LSB, ISVs will achieve interoperability with a full range of Linux distributions, thereby reducing their costs for development and testing of their applications," he says. "Most significantly, the LSB brings assurance to Linux end users that they will have a broad choice of independent software for Linux."
Talkback
The same problem could happen with Microsoft as they differentiate their products. After all, so far their current version english of MS-Word can't interoperate flawlessly with localized versions of the same software. If you consider slightly different versions, or other platforms than x86 the situation is even worse.
If they can't have their office suite to interoperate with itself how can we expect that various versions of their server software will work together. Not to mention that they simultaneously supports several separate product lines like win2k, win2003 server, XP, and soon Longhorn all slightly different. On top of that we haver various other software such as Exchange, IIS, SQL Server. If you need to upgrade one component, my experience is that you will need to upgrade all the rest, giving lots and lots of headaches.
My guess is that most LInux distros are far more interoperable with themselves and other Linux and unix systems with or without LSB than Microsft manages to be within their own product lines. The GPL factor keepls Linux inline regardless of standards. If one Linux finds some new amazing way of doing things, it will be all over the marketplace as he is required by GPL to share with his competitors.
The only thing that he can keep secret is upgrade and support procedures he runs in his office and it is such difference that makes him competitive, but such differences seldom affects the interoperability of software at the customer location.
At least the licence isn't likely to fork.Once GPLed you are in control of your software. If you go the Microsoft way you can never be sure what licence you end up with. All of a sudden, you download some more or less necessary service pack, and the licence of your entire installation changes.
Now, so far the licence changes applied with service packs have been quite harmless, but the fact that they do change it is worrying.
Would you buy a car, where you all of a sudden find that after your first service, the passenger seats have been removed and you have to buy specil passenger licences to have them added back. I think not.
I remember Linus Torvalds answer to "The forking question" was "so what".
That is, if linux forks there must be some very good and acceptable reason for that to happen.
And there are none, and no demand for that.
In stead there is a strong demand for a standard making life easier for everybody working with linux.
And linux is right now the envolving world standard for supercomputers, embedded devices, consumer electronics,
web-servers, carrier grade, - you name it.
So a standard base for linux is something everybody actively want.
Excuse me?
Quote: "Now, so far the licence changes applied with service packs have been quite harmless, but the fact that they do change it is worrying."
Very wrong, Sir. There already have been security patches from Microsoft that came with an EULA requiring very demanding, one way deal, terms or else no rights to install the patch.
Here's one example:
http://www.theregister.co.uk/2002/06/30/ms_security_patch_eula_gives/
Perhaps people have forgotten how a free market is suppose to work.
In a real free market there are no ways to limit consumer choice other then by providing good quality solutions at competitive prices. Should someone not be able to provide that then somebody else will. Thus enabling the 'better species' (Darwin anyone?) to become dominant until the environment (the needs of the masses) changes and the former 'better species' better adapt to the new environment fast enough or some other 'better species' will become dominant (the innovation need for speed).
Since it stands to reason that good interoperability will be part of the demands required from a 'better species' it's fair to say that in a real free market good interoperability will be no problem at all.
And given the free market nature of Open Source today the mechanics of ensuring good interoperability are already in place today.
Not complying to such Darwinian laws would find any Open Source solution sidetracked and quickly replaced by something else that does. Basicly it's a safety mechanism. Even mistakes are quickly minimized (by means of lesser demand) and thus turned into a thing of the past faster then the PR department of a typical company could change it's PR theme.