They're right, of course. The nasty flip side of all the diversity is that all the distributions pose a blurred target for Linux developers.
Commercial software vendors have a legitimate beef with the current state of Linux. There are three ways to build an application that runs on multiple distributions of Linux, none of them particularly smooth.
You can write versions specific to each distribution you want to support. But then each version must be tested separately on systems running the target distribution. Marketing and distribution might also vary among distributions. In any case, you're stuck with multiple versions of your product to support. Gee, didn't you already go through this grief with Unix?
You can limit yourself to the one distribution whose target market is closest in demographics to the one you want to reach. But no matter which one you choose, you exclude part of your potential market. Plus, you'll be angrily accused of helping to splinter the community.
Or you can shrug off the differences between distributions and invent your own installation system that works on all of them. Your applications must come with all the libraries and required tools, just in case your purchasers' distributions don't have them.
Developers have tried each of these routes, and none has proven to be particularly appealing. Each has significant pitfalls of both cost and reputation within the community.
There are many reasons you don't see a lot of commercial application software for Linux, but I have to put the lack of a single porting standard near the top. In my view, it even impedes the progress of open source software. The effort spent porting code and packages to multiple distributions is effort that could -- and should -- be spent making the packages themselves better.
Commercial Linux application vendors want what some Linux folk covet, others fear, and others simply ignore -- standards. Those who want standards rarely care where they come from as long as they're well understood and specify what needs to be standardized.
Here are some of the things that application suppliers need to see nailed down.
- File placement Applications shouldn't have to spend much effort looking to see where a specific Linux system keeps its program libraries, configurations, and other important files.
- Software installation method Right now we have three main packaging formats -- RPM, DEB, and TGZ, each of which has its advocates. If you build an RPM package on one distribution and successfully install it on a different RPM-using distribution, consider yourself lucky.
- System versions Especially as key components such as glibc and gcc continue to progress, it's important for a developer to know what facilities are available on the target system. Developers shouldn?t have to guess at what levels of services are available on the platform running the software.
- Menu placement Without needing to get involved in GNOME/KDE disputes, an application vendor should be able to specify once how and where to add programs to users' menus.
In two weeks I'll examine some of the ways the Linux world can balance its valuable diversity with the desired standardization. Why two weeks instead of the usual one? Next time in this space, we'll have a look at what's happening with open source at Germany's huge CeBIT conference, which begins this week.
How important are Linux standards to you? Tell Evan in the TalkBack below.
