Linux is hard. No matter how you slice it, there's no avoiding this truth:
the operating system cherished by hackers everywhere is a pain in
the neck to install, configure and use. Forget about the fawning press
accounts, the surging market-share numbers and the tide of Microsoft-hating
corporations paying homage to this jewel in free software's crown. Linux is
a morass of arcane text commands, bewildering options and incomprehensible
Unix concepts. Linux sucks.
I speak, of course, as a "stupid user." If you're a smart user, preferably
one with ample free time, Linux is a breeze. All you have to do, as the
hackers will eagerly hint, is RTFM -- "read the fucking manual." The Linux
world boasts no shortage of frequently-asked-question files, "HowTo"
documents and newsgroups and mailing lists populated by helpful veterans. If
you are motivated, fearless and willing to learn, the secrets of Linux will readily open up for you.
But if you're a stupid user who just wants to get on the Net and surf for
Spice Girls pics, and the words "command-line
interface" send spikes of terror through your bone marrow, then
Linux is gruesome. It is not designed for you.
Linux, in other words, needs help. Sure, there are hundreds, perhaps even thousands, of supersmart programmers hard at work perfecting graphical user interfaces (GUIs) for Linux that look and feel practically identical to your basic Windows or
Macintosh desktop. And yes, there's no question that these programmers are
making astonishing progress -- moving much faster and further than even the
most hard-core Linux evangelist would have predicted two or three years ago.
But there is still little sign that Linux's weakest area -- the provision of
user-friendly "help" -- is anywhere near being shored up.
The problem is that, as one author of Windows-based help systems observes, "Help isn't cool." And in the free software/open-source world, hackers like to do things that are
cool. A whiz-bang graphical user interface that allows you to configure your
desktop to look absolutely any way you please is cool. But plodding through
the grunt work of writing documentation that will hold even the stupidest user's
hand is not.
Linux devotees aren't shy -- they may smile when they say "world domination,"
but it's no joke. Sure, there's a vocal hacker minority who would much rather that stupid users stay in their Windows and Mac
ghettos and not soil the purity of Linux with their clueless
newbie questions. But their voices are increasingly drowned out by those whose
goal is to conquer the software universe.
There's just one problem. Supplying their operating system with usable nongeek support forces Linux's advocates to confront the Achilles heel of their open-source software development model -- the need to get cool people to take on uncool tasks.
"Open-source projects are successful because the people who contribute to
them are interested in the work and find that work fun to do," says David
Mason, a technical writer employed by Red Hat, the leading commercial distributor of Linux, specifically to write help documentation for systems such as the GNOME desktop interface for Linux. "There are few people, including
those who choose the career, who like to write user docs. No one wants to go
home on the weekend and write a user's guide, especially those who don't
think they can write well to begin with. Yes, there have been those who have
done it, and it is a great way to get involved with a project if you are not
a programmer, but it doesn't make it any more fun."
Miguel de Icaza, the coordinator of the GNOME project, heaves a sigh when
asked about "help."
"We have many problems with that," says the 26-year-old Icaza, who splits
his time between hacking on GNOME
and maintaining the computer network at a nuclear science research
institute at the Universidad Nacional Autonoma in Mexico City. "It is being
slowly fixed, very slowly."
Linux has a long history of help problems, going all the way back to the
moment of its creation. Linus Torvalds is quite frank: He is utterly
uninterested in the documentation process. Back in 1991, Torvalds wanted a
version of Unix that he could run on his 386 PC. To use open source
evangelist Eric Raymond's terminology, that was
the "itch" Torvalds needed to "scratch." And scratch it he did, by hacking
together the Linux kernel -- the all-important body of code at the heart of the operating system.
Torvalds made the code available to anyone who wanted it, but saw little
need to hold hands when it came to actually installing the kernel. As a
result, running early versions of Linux required true determination.
Matt Welsh, a graduate student in computer science at the University of
California at Berkeley who specializes in "Internet-scale systems
architecture," remembers his first encounter with Linux, in 1992, all too
clearly.
"This was when Linux fit onto two floppy disks," recalls Welsh. "There was no
networking, there was no X-windows [an essential graphical interface for
Unix systems] -- it was a text-only system that didn't do very much. And it was
impossible to figure out how to install it, given the scant 'readme' files
that were available."
The only help Welsh could find was a document that consisted of little more
than a snapshot of the file and directory structure of a working Linux file
system. Using that snapshot as a guide, Welsh was forced to "manually" place
each file in an appropriate directory, one at a time.
There had to be a better way -- and Welsh provided one, in true hacker
fashion. After taking "copious notes" while installing that early version of
Linux, he ended up with a document that eventually became the "Linux
Installation HowTo." Over the next few years, under Welsh's coordination,
the Linux HowTo archive grew to be an impressive library of helpful documents, each aimed at solving a
specific problem -- such as connecting to the Internet, or setting up a
firewall, or running Quake on a Linux system.
At first glance, Welsh's experience would appear to contradict the theory
that hackers aren't interested in help.
"I pretty much took over most of the documentation and information
management for the Linux project over the next couple of years, because I
was scratching my own personal itch," says Welsh. "It wasn't like I was a
guru and sitting there and going, oh, this is easy stuff and I'm just going to
explain how it works. I would go and figure out how to do something and then
write it up ... Even though it is not seemingly as glamorous, maintaining the
documentation for a project like Linux was actually a lot of fun."
The Linux HowTo archive is a terrific resource, with answers to a great many
questions. Along with the other available sources of information about Linux
and Unix -- the "man" and "info" pages accessible instantly from the
command line prompt, the proliferating online user guides and frequently-asked-question files -- it offers the determined Linux newbie a wealth of useful information.
But it doesn't do a darned thing for the stupid user.
I know, because my own computer skills are such that I am supremely
qualified to impersonate an ignorant Unix/Linux user. Recently, courtesy of Linux hardware vendor
VA Research, I obtained for review purposes a state-of-the-art Linux box with the GNOME desktop preinstalled. I decided that my
first goal would be to see if I could use the GNOME-ppp utility to connect
to the Internet over my home phone line without having to resort to typing in text commands at a
command line prompt. (My review of GNOME's competitor
KDE, as of last June, is here.)
I entered the basic info required -- phone number, user name, password, DNS
number. Then I tried to connect. No go. Next, I clicked on the help menu.
But all that lay under the help menu was an "About this program" option -- no help at all.
After a review of various other sources of information, including the
Linux-PPP HowTo, some actual printed Linux books and even the ppp
"man" pages, it became clear that I would not be able to avoid getting into a
text editor and mucking about with the actual ppp configuration files.
GNOME is an impressive achievement, and by any reasonable standard of software
progress both it and KDE are moving forward at a respectable clip. But they
are both still a long, long way from being stupid-user friendly.
Theories abound as to why Linux still needs help. First,
there's the "all in good time" theory. Jay Painter, author of GNOME-ppp, notes
that he just hasn't had time to get around to the help documentation -- and
he promised that GNOME-ppp wouldn't be released as a full-fledged "1.0"
version until he took care of it. He also says that he isn't all that
worried by the current sad state of help for Linux desktop apps and
utilities.
"It's a problem that will eventually be solved," said Painter, who holds
down a day job at Real Networks.
Fair enough. Linus Torvalds himself has long maintained that the progress
of Linux can best be described as a multi-stage journey, with each stage
building on the last. First, hackers required basic programming tools --
free software compilers, editors and debuggers. Then came the kernel -- the
body of code that together with those tools comprised a full-scale operating
system. In Torvalds' view, the kernel is now stable -- for all practical
purposes, it is done, though there will always be improvements and
advancements.
Now, finally, the time has come to start working on desktop
environments and productivity applications like spreadsheets and word
processors. And maybe once those things are working, programmers will get
around to creating the kind of help browsers and indexing systems necessary
for truly effective help. (David Mason suggests that once Netscape's Mozilla
project releases a complete open source Web browser, portions of that
program will be easy to adapt for use in a state-of-the-art help system.)
Hackers continually migrate to new challenges, says Welsh. "People's interests change as time goes on. A couple of years
ago, if you would have asked any of the major Linux people what is the most
interesting thing happening in Linux today, they would have said, oh, it must
be inside of the kernel or SMP [shared memory multi-processing] support -- all of these complex technical
things that people really liked to work on. If you ask Linus Torvalds today
he will tell you quite clearly that it is GNOME and KDE. He admits that
freely, that one of the most interesting and exciting developments in the
Linux world is these desktop environments ... It is kind of a generational
thing. I think that people who are coming into Linux today are coming at it
where most of the system is very stable, most of the major kernel features
are already there, they're solid, they're dependable, they work. And they're
going, well, what's missing, what can I do, how can I contribute?"
GNOME's Miguel de Icaza provides a perfect illustration of Welsh's
observation. For years, Icaza focused his hacking on the kernel, first
working on a version of Linux for Sun's SPARC computing platform, and then
joining a similar effort to port Linux to SGI hardware. But he eventually
decided that the goal of a Linux desktop was important enough to demand his
full attention.
"Some people work on stuff because it's something that bothers them," says
Icaza, "but I wrote a spreadsheet not because I needed a spreadsheet but
because, one, it was an interesting problem, and two, it was something that
we needed to make open source a reality. I want to have a desktop that is
completely free, so I wrote a desktop -- not because I needed it, but because it
was something that people wanted."
Still, GNOME has a ways to go before it's stupid-user friendly. And some observers suggest that
without outside help -- help from non-hackers -- it may never be. Achieving true
usability, they argue, is fundamentally different from creating a solid operating system -- and a lot more difficult.
Ben Bederson, a specialist in human-computer interaction at the University
of Maryland, suggested that user interfaces are harder to produce because they require greater levels of coordination.
"One of the wonderful things about Unix is that it is highly decoupled," says
Bederson. "Outside of the kernel, which was largely developed by a single
person, much of the hundreds of other pieces of the operating system are
independent of each other. That is, the 'ls' command, and the 'gcc'
compiler, and the 'emacs' text editor, and 'grep', and 'whereis', etc. all
can be built independently from each other (more or less). And, many of
these important pieces are relatively small, and so can be built primarily
by a single individual. A windowing system, on the other hand, is more like
a single complex tightly coupled thing -- and it is more likely to require a
team of highly coordinated developers with a single clear mission. I don't
think the current ... contributors to Linux have the right mind-set for this kind of development.
"The thousands of people that contributed to Linux tend to be hard-core
hackers," Bederson continues. "That is, folks that are technically very good and interested in the low-level details. That is how
they made these efficient and stable pieces. However, these are not the
people that traditionally have been successful at designing and building
user interfaces ... As we now know, it tends to take a very interdisciplinary
team including designers, usability specialists and even psychologists (and
programmers) to build a good user interface. These are not the people
donating their time to open-source software."
"A GUI is to an OS kernel as 'Guernica' is to a crankshaft," says Ben
Shneiderman, the director of the Human-Computer Interaction Library at the
University of Maryland. "A GUI is a human-oriented work, crafted with a
unified vision, attuned to the user's needs, provocative, stimulating,
harmonious, inspiring." And everyone knows that hackers aren't human.
But seriously, says Nathaniel Borenstein, a researcher at the School of
Information at the University of Michigan, "A lifetime of kernel debugging
doesn't make you a usability expert."
"One of the things that I have to beat into the heads of technical
students," says Borenstein, "is that you are really not programming for
people like you."
Borenstein is the principal author of MIME, the standard Internet multimedia
data format. He considers himself a dyed-in-the-wool hacker (his metamail
program is part of several standard Linux distributions) and disdains the
use of a fancy GUI for Linux for his own hacking purposes. But he's
convinced that for Linux to be usable by average computer users, hackers
must listen to the input of people who might never, ever write a single
line of code.
In other words, the open source community needs to expand beyond the
programming world. Borenstein is actively working in pursuit of this goal:
Just last week, he launched a major project at Michigan -- the "Linux/UNIX
Independent Group for Usability Information" -- or LUIGUI.
"The idea of the LUIGUI project is to take the best science we can muster in
the human-computer interaction area, and try and find out what actually
works best for novices," says Borenstein. The students working with
Borenstein intend to conduct a comprehensive review of open-source/free
software programs, rate them on usability and, ultimately, create an
installation of Linux that will be as friendly as possible to the novice
user.
Borenstein argues that the volunteerist, gift-economy ethos underlying the
open-source development model is an outgrowth of the traditional academic
approach to information. It is now time, he says, for the academy to bolster
the open source world with its own contributions -- in the form of
"controlled experimentation" such as user testing. Only then, once the
nonhacker world is making real contributions to the overall open-source
environment, will software projects such as Linux begin to accommodate the
needs of the stupid user.
There's also a third theory of how the help problem will be solved -- the
possibility that the corporate world will see a profitable niche and step
in with proprietary products that fill the need. This is, after all, the
business model employed by such companies as Sendmail Inc., which is paying programmers to write a proprietary GUI for a mail server program that will remain open source.
Such a model is discouraging to true purists, who'd rather see everything
free. The die-hards can take hope in Red Hat's example. David Mason, the
principal author of the GNOME User's Guide, says
that his work has provided the seed for a community-wide explosion.
"Once I got a good first release of the GNOME User's Guide out," says Mason,
"there were quite a few people writing in to help out. Now we have about
nine people working on translations, and about five or six people who edit
or write. I got a substantial section from one fellow and ended up putting
his name as an author for his troubles. Now he not only gets to feel good
about contributing to an open-source project, but he can use it on his
risumi."
"Do I think that there will be as many people writing docs as there are
writing apps?" asks Mason. "No way, and there aren't in closed source
environments either ... I know, I've worked there too. Can docs benefit from
the open-source model? Hell, yes! I have never had this many editors reading
my docs ... and it makes for great proofreading."
A brave new world populated by an infinite number of proofreaders? Useful, accurate help for us stupid users may yet be on the way.
Shares