Eric Raymond's

A Reflection

Eric
Raymond's essay has a lot of insights, and he presents them convincingly.
I came away from reading it wanting to convert my current project -- indeed
all my software projects -- into his bazaar model. But I don't think that
is likely to happen any time soon. Let me explain why.

Before getting into the main issues here, I would like to comment on
a couple of provocative remarks Raymond makes that are essentially unrelated
to his main thesis.

In one case he marvels at the "stunning variety, quality, and depth
of Linux documentation." Like Microsoft documentation, I assume it exists
somewhere, but I have been stunned only by its inaccessibility and/or irrelevance.
Google can find on the internet many third-party alternatives to the Microsoft
documentation fiasco, but Google is no help at all finding anything useful
for how to make Linux do reasonable things -- like compile itself. That
has been a continuing disappointment.

I have only admiration for Raymond's second notable remark, which he
calls

the 'SNAFU Principle': "True communication is possible only
between equals, because inferiors are more consistently rewarded for telling
their superiors pleasant lies than for telling the truth."

I have long held that honesty is the only reasonable basis for communication
and friendship, but in the circles I frequent I seem to be a lone voice
crying in the wilderness. I really wish Christians could tolerate honesty
as much as the pagans do.

On with the show...

There are two fundamental problems with implementing Raymond's bazaar
software development model in my projects. He is aware of and mentions
both problems, but he does not give them a fair treatment.

Design

The first problem is the matter of design. He admits to the "value [of]
design originality in bazaar projects." This is a refreshing admission,
in stark contrast to the thinking of many other computer professionals
who want to believe only in incremental evolution. Raymond himself likes
to believe in evolution and used the word frequently in his essay, but
the bottom line is, "Insight comes from individuals" [his emphasis].
There is no substitute for design insights.

Raymond mentions the development of the GNU Emacs
editor as an instructive example; it absorbed the efforts of hundreds of
contributors over 15 years, but only one person (its author, Richard Stallman)
was continuously active during all that time. Raymond does not come out
and say so, but that one person preserved the consistent architectural
vision that Raymond did praise in the project. Similarly, it was Linus
Torvalds who did the same thing for Linux, and Eric Raymond himself who
provided the focus and vision driving his featured Fetchmail project.

Open source has many bazaar-like advantages over managed "cathedral"
projects, but design is not one of them. You still need the lead designer
with a vision for where the project needs to go and the control to make
it go there. Furthermore, that designer must do much of the work to get
it there before the bazaar can even work at all. Raymond admits the program
must be running well enough for people to see what it can do before they
will buy into it as an OS project.

Linus Torvalds adapted the idea of Minix, but completely rewrote it
and had it working before Linux took off and acquired a life of its own.
Eric Raymond did the same for Fetchmail. In both cases the software subsequently
grew and "evolved" so that little or none of the original code is left,
but the designer started essentially as a solo project. Linux and Fetchmail
were both small enough that they could be done that way; my
BibleTrans project is much larger -- but I am still stuck with the
one-designer model. Although I can't think of any at the moment, I can
imagine ideas too big and complex to be done alone in a garage on nights
and weekends. Actually, BibleTrans is too big for nights and weekends.
It's a full-time project spanning many years -- and it still isn't good
enough to inspire a community of users, let alone co-developers.

Which brings me to

Marketing

Raymond has another crucial insight that he gives scant attention to: "To
make the bazaar model work, it helps enormously if you have at least a
little skill at charming people." It's worse than that. The project has
to scratch the itch of more than just a couple people -- and these people
must be programmers -- or else open source is irrelevant.

Anybody who has gone through a college computer science curriculum can
be interested in the way operating systems work, so Linux qualifies. Programmers
love text-based editors like Emacs. But Raymond himself notes how hard
it was to get the open-source version of Netscape going. Although it came
after he wrote this essay, it would be interesting to see Raymond's observation
on how it took a single guy's vision (and rewrite) to make Firefox take
off.

Selling an anti-programmer operating
system like my MOSto programmers is a different matter. Linux
may be the the best thing since sliced bread from a programmer's perspective,
but it's really hard for non-programmer types to use. This is a fundamental
problem with the bazaar model. Out of 100 million evangelical Christians
in America we can find only a thousand or so interested enough in Bible
translation to do anything about it; good luck in finding five programmers
among them!

I am not a charismatic extrovert like Raymond, my skills are elsewhere.
It seems to me that the bazaar only works for hucksters. Well, I can't
seem to sell my ideas to the bishop in the cathedral either.