Attracting newbies (Was Booting Debian/testing fails)
If GNU-Linux is going to make any serious inroads in the BDU market
(BDU=brain dead user) which Microsoft dominates faute de mieux, there
has to be documentation which the average BDU can understand. In the
distros about which I have had personal experience (Red Hat 8 -- before
RH abandoned the BDUs -- Debian Sarge and now Etch) such documentation
seems to be an afterthought.
For example, Debian made much of the fact that the Sarge distribution
had an installer application, which is being improved for Etch. However,
the installation guide for Sarge and the draft guide for Etch breaks
virtually every recommended practice for writing technical manuals for
Most documentation reads like text books for computer science majors.
The installation guide starts out with long-winded explanations about
Debian, the Social Contract, Free Software Guidelines, etc. This
information is of no interest to the BDU who -- faced with the task of
installation -- wants to know only how to install the O/S and what to in
any conceivable situation where the installation may go wrong. Even when
the guide gets around to doing so, there is still too much information
-- badly presented for the most part -- which is not relevant to the
immediate task, and -- in my experience -- not enough essential
The problem is that the lead manual writers are the software developers,
rather than potential users not familiar with the ins-and-outs of the
software. Indeed, for the lead writers to have such familiarity is a
positive disadvantage: they need to think like BDUs, not developers.
On page 47 of Martin Krafft's book "The Debian System" there is a
diagram of the Debian organization. While the word documentation is
mentioned once in the diagram, the text which the diagram illustrates --
2.4.1 from pages 46 to 50 -- makes no reference to documentation; it is
all about perfecting the software.
There are basically two audiences for GNU/Linux documentation:
developers and BDUs. The developers can write the text books, the
documentation intended for the developer audience.
If however the people involved in the Debian project are serious about
having BDUs use GNU/Linux on their desktops, then the project needs
effective editors to serve the BDU audience who must have a status in
the organization equal to that of the developers.
Effective BDU documentation will require a approval process parallel to
but separate from the development approval process. No package to be
used by BDUs should reach the testing and stable versions of each Debian
release until approved by both the developers *and* the editors. Each
should have a veto over the other.
Good developers do not make good editors, and vice-versa. Good editors
will not be attracted to the project if they must meet the developer
requirements listed on pages 63-64 of Mr. Krafft's book. There needs to
be a separate set of requirements for editors, at very least for the
documentation destined for BDUs.
Once this organization is in place, I would envisage the following
process for BDU documentation. First, developers would still write the
text books, although even for these good editors are essential. It would
be the responsibility of editors to extract from the text books what is
essential for BDUs and draft manuals and guides from it. At this stage
the consultation between developers and editors would be close, because
the former would have to help the latter understand what they meant --
as opposed to what they said -- in their text books.
The editors would then test the draft BDU documentation on actual BDUs.
The process works something like this. Go to the nearest Starbucks or
sports bar and recruit somebody willing to be the guinea pig. Sit her
down in front of a computer with the installation disk and the
installation guide, and ask her to install the O/S on the computer using
only the materials you have given her. Do not prompt her when she gets
stuck; only record at what point she got stuck and why.
For the editor observing this process it will be a vary chastening
experience. She will discover that even she -- non-developer that she
is -- will discover that in editing the manual she will have
unconsciously made assumptions that seemed obvious to her but not to her
One should always be reminded of the result of one instruction dating
from the days of dedicated word processors. "Install the floppy disk
(10" disks then) into the drive." After reading that instruction the
poor operator trying to get the machine to work wondered why the drive
would not work after she took the disk out of its black cardboard case
and tried to insert the naked vinyl into the drive.
Only after repeated revision and testing of this nature would
documentation be ready for editorial approval. The real question Linux
developers should ask themselves is whether they are serious about
increasing the market share of Linux on desktops beyond the 3% or so it
now has. If so, there must be a fundamental change in how the BDU
documentation is created, tested, and distributed, and when, how and by
whom newbie questions are answered. If the documentation editors are to
be volunteers, good ones will not be attracted to the project unless
they are given status in the organization.
I have had no personal experience with the distributions *based* on
Debian, like the various *buntus. If those who develop them are aiming
for the BDU market, then all the more power to them. It does appear
however that the marketing could be improved. (Are these Debian based
distributions created by volunteers, by paid staff or a mix of the two?)
In my case, out of frustration with Windows 98, in July 2003 I switched
to Linux. My major mistake was to start with RH8 just when RH abandoned
the individual user and concentrated on the "enterprise" market. I
moved to Sarge when it was first released rather than Fedora, because of
my annoyance with RH. I am now moving to Etch.
If in October 2005 when Sarge was released there were reliable Debian
based distributions aimed at the BDU market, I did not know about them,
or how or where to find out about them. At the time I certainly could
not find anything about them on the standard Linux user group lists
So I had a baptism of fire, but only learned as much as I needed to know
in order to use the applications I needed for my work. In particular I
learned enough to be able to use full blown Debian and know what
questions to ask and how to ask them if I run into a problem. I have
not regretted the experience, and get a vicarious pleasure of telling my
friends, when they are attacked by viruses, worms, Trojan horses, etc.,
that they could reduce their propensity for such attacks by 70% if they
did not contaminate their computers with *any* Microsoft product.