It has become something of a cliché that Linux has reached a critical point in its development and adoption. However, this is especially true now when we look at what events are lined up to occur in the near future, and particularly in the desktop area.

Perhaps the most visible event is the impending launch of Microsoft's Vista. Try as they might, this new OS shows every sign of needing hardware replacement, some user training, and considerable support staff training to be truly effective in deployment. Particularly note the last two, often cited as reasons why moving to Linux is expensive and fraught with danger. Of course, Linux doesn't have the added disadvantage of needing a hardware upgrade.

The second event on the horizon is the move to 64 bit hardware on the desktop. 64 bit hardware is commonplace in the datacenter and on Unix/Linux workstations, but not so common sitting on the average end user's desktop. Some may argue that 64 bit hardware just isn't needed on an average desktop. Quite probably, the same people said the same of the move from 16 bit to 32 bit desktops, and their children probably argued against the need to move from 8 to 16 bit machines.

Both of these events are natural places for people to pause and reconsider their whole environments, and any conscientious CIO is going to give the non-Microsoft alternatives a really long, hard look.

So, can we expect a sudden and dramatic shift to Linux on the desktop? Unfortunately, the answer is probably no. Unless some changes take place.

There are several significant roadblocks to widespread adoption on the desktop. These are not technical in nature, and perhaps surprisingly to some people, they do not revolve around licensing (GNU or otherwise). The wars over licensing (open vs. proprietary) have been fought and in the aftermath, the most sensible people have come to the conclusion that both may have their place and that co-existence of both is not impossible. Which form is better for the end-user in the long run is yet to be determined, even if logic does tend to lead one in a specific direction.

The biggest problem is the lack of application software available and the difficulty in making some of it work. This problem has been recognized for some time, and some effort has been put into determining why this is. A few conversations with independent software vendors (ISVs) quickly reveals the problems that they face when they consider creating applications for Linux, or attempting to move existing products to Linux. Some of the most frequently mentioned ones are listed below.

Lack of development tools
This is surprising given the huge amount of development taking place daily on Linux. Closer investigation reveals that what is really meant is a lack of the sort of development environment in which relatively junior developers can be productive without having to completely understand the technologies they are working with. Think IDE (integrated development environment) in the form that it exists in the Microsoft world. Fortunately, the rapid development of Eclipse and its widespread adoption seems to have muted most of these complaints.

A Need for Compromise
Compromise is needed on the Linux side in recognizing that developers will not all be as skilled as we might all expect in a perfect world, and that good documentation, and development environments oriented towards less skilled developers is going to be needed. On the ISV side, some compromise is needed in recognizing that it is neither possible, nor desirable to be able to create development environments that totally mimic those available in the Windows world. Linux is a very different system. Some re-training will be required for developers to become productive. Insulating developers from the differences is not completely possible. This is the price of admission to this new and expanding market.

Vendor lock-in
A surprising one for a free and open system. What they refer to are the differences between the various distributions which, deliberately or not, make writing cross-distribution applications difficult. The differences that they face include different system management interfaces, different package management, different desktop environments, different levels of software (kernel, libraries, utilities) and of course, the inevitable pseudo-proprietary extensions to the systems. This is highly reminiscent of the Unix world, and many of these companies have bad memories of that period.

Compromise is really required on the part of the Linux vendors. Rather than differentiating their product in ways that make it incompatible with other distributions they should be concentrating on ensuring that the user and ISV experience becomes much more uniform across the distributions. There is plenty of scope to differentiate the distributions in the support that they offer as well as the add-on components and services offered, without compromising uniformity at the basic levels of the system.

KDE vs. Gnome
These desktop systems are both competent. They are also different enough that writing an application to be equally at home in both is close to impossible. Neither has the functionality (from the ISV perspective) of the Windows platform. Fortunately, these problems have been recognized by both groups and there are collaborative efforts underway to deal with these problems, with the first release of the Portland project (piloted by OSDL) setting a very hopeful path for the resolution of this problem.

Compromise between the two development groups appears to have begun here, and is leading to some very much appreciated results.

Binary Drivers
The Linux kernel is relatively unfriendly to drivers supplied in binary form, with interfaces which mutate and evolve rapidly. The standard answer to anyone wanting to use their own drivers is that they should provide them in source form. Unfortunately, this produces some real conflicts with the world of proprietary hardware. In many cases vendors argue that the driver source would expose just too much about how their product worked, allowing unscrupulous third parties to clone the hardware and undercut them on price since these clones would not have R&D costs to recoup. There is some truth to this, although many devices could easily be supported by open sourced drivers. Efforts by the Open Source Community to educate ISVs on the process of open sourcing and supporting their drivers have had some limited success, but this remains a very problematic area from all perspectives

Compromise on this requires some fairly fundamental changes in attitude on both sides. ISVs requiring that their drivers need to remain in binary form need to understand the philosophical and practical difficulties that the Linux development community have with this approach, and perhaps review their strategies for keeping their trade secrets through obfuscation, which is all that binary drivers really are. A determined person or group can always decompile and analyze a binary file.

Compromise on the Linux development side needs to recognize that for commercial success, supporting binary drivers is probably inescapable. The changing kernel interfaces argument really doesn't hold much water. At the top level, there are a set of fixed interfaces (POSIX) which the kernel developers are not free to change as they wish. They have to live with that interface as a constraint. The feasibility of providing a fixed set of interfaces for drivers has already been mostly proven by the NdisWrapper project, which provides the standard set of Windows APIs enabling Windows drivers to successfully run within the Linux kernel. It is far from unreasonable to ask that Linux provides its own stable set of interfaces and specification.

What these issues mean to an ISV is that they look at the number of Linux systems in use, and see a critical mass, enough for them to make it worthwhile investing in creating/moving products to Linux. But, on closer examination they find that the base is fragmented. There isn't just Linux, but RedHat Linux, Novell Linux, Linspire Linux, Lycoris Linux, Debian Linux, Mandrake Linux ...

For an impressive list of Linux distributions available take a look at:

http://www.linux.org/dist/list.html

The fragmentation means more work for ISVs, work in development, work in creating potentially multiple distributions, and work in supporting the product across a range of different Linux variants, each evolving at a different pace.

Many ISVs decide that Linux is not yet a platform of interest. The day they decide otherwise is probably the day Linux hits the tipping point and becomes a mainstream reality on the desktop as well as in the datacenter.