Despite the fact that it's been around since 1991, Linux remains a work in progress. It's not perfect, nor does anyone pretend it is. The places where it needs the most immediate improvement are also a matter of debate: what's crucially important to some is only marginally important to others.
Still, there's no question that there are key areas where Linux is lacking -- not just missing individual features, but things that are actively dysfunctional and which need immediate attention. I'm going to run down several major areas where Linux, as an operating system and as a platform, needs work.
The software that goes into a Linux distribution is dealt with in chunks called "packages" -- whole applications, support libraries for apps, programmer's tools, and so on. Firefox and OpenOffice.org, for instance, are present in most every Linux distribution's software repository as package sets.
Package Management
The way packages are managed within any individual distribution is entirely up to the maintainers of that distribution. Red Hat (NYSE: RHT) uses its own RPM system, the Debian distributions have their own .DEB format; and so on. Within the context of any one distribution, this isn't a problem: if you're using only Red Hat or Debian, odds are you obtain the software you need from that distribution's repository and are done with it.
This is one of the many fragmentation problems that makes it difficult for commercial software vendors to offer their products for Linux. No one package format will do the trick across distributions -- not without hassle, anyway.
To that end, potential program vendors have three choices: 1) devote time and effort -- and money -- to ensuring that their program installs, runs, and stays cohesive on a variety of distributions (maybe just Red Hat, Ubuntu, and SUSE to keep things simple); 2) make their programs available in a given distro's repositories; or 3) provide source-code packages so that the user can compile the code on any target platform.
Option #3 is pretty much out of the question for any proprietary software vendor. #1 multiplies the amount of work involved to get any given program out the door -- not to a degree that makes it wholly unfeasible, but it does add more work. That leaves #2, which has the advantage of making applications immediately available to the user of any given distribution, and cuts down on the amount of work needed by an end user to get something installed.
Because the demand for commercial apps on Linux is relatively slender right now, the problem isn't as pronounced: most people just get their offerings from their local repository. In the long run, though, if commercial apps take root on Linux, it will become that much bigger an obstacle to making Linux a platform for same, especially where downloading apps freely from the Web is concerned.
