uring the recent LinuxWorld conference, Linux proponents loudly celebrated Linux’ increasing importance in the world of software. It’s true that Linux has made great strides in becoming a standard part of the computing landscape, but it has made far more inroads into the Unix space than into the Windows desktop space. Despite that, there’s simply no doubt that the desktop?and Microsoft?are the current target of many open source software projects. These projects are conceived, executed, and extended to compete with Microsoft’s desktop applications.
They’re making progress, too, particularly with early-adopters and in IT-mandated vertical application environments, but as these projects mature, they’re going to have to compete head-on with their far better funded and user-tested Microsoft counterparts on average users’ desktops. To compete successfully, Linux needs a standardized platform and robust installation mechanisms so that users can choose software on its merits, without worrying about whether the software they want works on their particular Linux flavor or GUI choice.
A GUI Decision
Linux is a kernel, an operating system?not a complete operating environment in the sense that Windows is a complete operating environment. The tradeoff is one of choice. Windows has a single interface (true, there are variations between versions, but those are largely transparent to users). In contrast, Linux has no built-in GUI interface. Users are free to choose among many commercially available or free GUI X-Window interfaces, such as Gnome, KDE, and Motif, each of which provides a different look and feel.
Unfortunately, to some degree differences in GUI X-Window interfaces extend to the programming interfaces as well, meaning that software developers must either support multiple GUIs or choose which GUI(s) they plan to support. Because the interfaces are slightly different, application developers generally target one or two primary GUI programming models. Supporting many GUIs isn’t just a simple process of including one set of libraries or another; it’s often a frustrating and error-prone exercise in writing GUI-specific code. While these applications may run on non-targeted GUI interfaces, vendors often guarantee support for only one or two.
The multiple-GUI problem illustrates a basic difference in Windows and Linux. Windows has one general GUI interface which has served many millions of people and works for many millions of different applications. The Mac (another successful consumer OS) is similar; one general GUI works across all Mac applications. Why is Linux different?
Freedom to Choose?Or Not to Choose
According to most open-source advocates, having multiple available GUIs translates into a desirable user choice. For example, http://www.uselinuxathome.com/ENgui.htm says that the “choice of GUI has been made possible by the open source nature of Linux,” and that “The idea is…to find the one that’s right for you…”
|
The average user doesn’t know?or care?about the underlying operating system, the idea of GUI interfaces, the various types of file systems, or about any other “technical” aspect of using a computer. (Jono Bacon tells an interesting story about how users perceive GUIs.) Many?perhaps most?home and small business users never alter their Windows system defaults, other than to perhaps download a different screen saver, add a peripheral, or install their preferred applications. Giving them choices isn’t going to make them happy?they want something that works out of the box! And they want that single setup to work for all their programs.
Most of the major distributions aren’t addressing this problem directly. For example, Mandrake ships with three different X-Window GUIs: KDE, Gnome, and IceWM. How much time should users spend exploring these different GUIs before they find the one that’s “right”?and works with all their applications? One month? Five months? Are there more productive ways for users to spend their time than trying different GUIs? Developers, hobbyists, and large IT shops gain value from the ability to try and test a multiplicity of interface choices, but the average home or business user will not.
Even the act of trying different GUIs is fraught with pitfalls for average users. For example, here’s a short excerpt from the IceWM site’s FAQ, titled “How to make IceWM my default window manager.” From the outset, the average Windows user will be lost. What’s a window manager? Why would I need one? That question will arise quickly?as soon as their new Linux installation boots to a shell (a command prompt). I suspect most Windows users will stop there, thinking that the machine is broken. But let’s take a look at an excerpt from the instructions in the FAQ:
“In order to run IceWM, you must assure that the executable (called icewm) is in your path. You should then add IceWM to your X start-up script (which could be .xinitrc, .xsession or .Xclients).
Note: Supplying the full path to IceWM isn’t sufficient – if IceWM isn’t in your path, restarting it will fail (even if you don’t this by hand it is done automatically on changing the theme).
Which of the scripts mentioned above is the right one mainly depends on whether you manually start X (using startx) or have X running all the time.
First I explain what you need to do if you manually start X. Then I address the case “X is running all the time” (which means that you log in via xdm or something like that). Finally I describe what both cases have in common.
Running IceWM at X startup
If you use startx to start up X then you run your window manager from the .xinitrc file.Running IceWM after graphical login
If your system has a graphical login (X is already running while you log in) you are using a display manager such as xdm, kdm or gdm. In this case .xinitrc has no effect (it is not read in by xdm). You must instead use a .xsession file.Hint: It is absolutely no problem to have a .xsession and a .xinitrc file (which is especially useful for inhomogeneous networks).
Mandrake users repeatedly reported that their .xsession wasn’t read and no applications started. To work around that in the kdm login interface choose Default and add IceWM as the last entry to your .xsession.
These directions may be crystal clear to experienced Linux or Unix users, but they’re going to be incomprehensible to most Windows users. The problem doesn’t lie in poor word choice or sentence structure: it’s the authors’ assumptions about users’ knowledge and experience that makes the instructions virtually worthless. What’s an executable? What’s an X start-up script? What does it do? Where is it? What’s involved in adding IceWM to a startup script? What’s startx? What’s a display manager? What’s .xinitrc? What does it do? What’s a .xsession file? I’m sure you get the point.
In fact, I suspect that many users wouldn’t even know what a path is. If you tell them, they may not understand why it’s important, and they won’t know how to edit it. The fact is that average users don’t know and don’t want to know how to solve problems with their computers?that’s why businesses hire IT and support staff, so that average users can concentrate on their work, not on their computers.
If the problem were limited to setting up just one specific GUI, it would be relatively easy to solve it by creating a robust installation, but it isn’t. There are many GUIs, each with its own FAQ, its own procedure, and its own quirks.
Price, Quality, Availability, Security, Simplicity, and Interoperability
The idea of choice is part of the bedrock of open source. But open source also wants to replace Microsoft on the desktop, or at least make a serious dent in Microsoft’s hegemony. To do that, the open source community must recognize that its primary goals: freedom of choice, freedom of source code, and freedom to alter applications, are not the goals of the average user.
Choice, to most users, is the ability to choose any program they wish, and have it install and run seamlessly, without affecting any other application already installed; without requiring them to know which GUI they’re running (or even that they’re running a GUI); without altering path statements; without editing configuration files; without facing a command prompt; and without having to compile any source code; create any makefiles, or any other programming task that only developers are fond of.
|
So far, the open source community has been highly sensitive to the needs of power users, hobbyists, and centralized IT departments, but highly insensitive to the needs of average, technically (and sometimes literally) illiterate users. Many people will argue that the public should be educated to value software choice and to see Microsoft’s impositions and removal of choice for what it is. But it is a grave mistake to stake Linux’ future on the hope that millions of people will be inspired to software activism, that they will take the ideological high road when all they want is to buy a piece of software that works with a piece of electronics.
Don’t shoot the messenger. I’m trying to ease the transition of Linux into a Microsoft-centric world. Instead, go ask average users what they want. Microsoft does. They perform extensive user testing with every major application. Microsoft’s choices weren’t made by fiat?at least, not in recent history. Open source software must begin to address these users’ needs if Linux is to become a real competitor to Windows.
Start with a Standard GUI
The tradeoffs made by the open source community between usability vs. choice will become increasingly important as various distributions and organizations (such as SuSe and Lindows) try to move Linux into the general desktop market space. It’s extremely important for the open source community to be responsive not only to users’ freedom to choose, but also to users’ freedom not to have to choose.
As a first step, open source proponents should band together to create a standardized Linux/GUI combination as a single platform for application development targeted toward average users with the goal of removing barriers to generalized adoption. Doing so would not remove or limit choice for more advanced Linux users. Vendors and open source projects would be free to choose to support the standard or not, just as they please. Freedom of choice is not incompatible with the concept of providing a standard platform. Applications that meet the standard would:
- be guaranteed to work on the defined standard platform
- have an install program that automated all modifications to the target machine and provided reasonable and intelligent default settings
- have an uninstall program that removed the software but would not affect any data produced with the software
- would interoperate (where appropriate) with other standard applications
- would include the ability for users to manually or automatically upgrade their applications to the latest stable release version
Any such group should immediately implement comprehensive end-user testing and make the results available to the open source community. A project that builds on and augments the existing Free Standards Group recommendation, the Linux Standard Base (LSB) project, might be a good first step. The LSB provides tests and documentation so that organizations can certify their Linux application binaries as compatible with a specified binary standard.
The LSB project doesn’t address GUI concerns, and perhaps it shouldn’t. After all, not all applications require a GUI. But those that do need some way to provide assurance to users that the software will run on their systems. Until that happens, average users aren’t likely to get very excited about either Linux or open source.
