The Cathedral and the Bazaar | Page 4

is easy to underestimate. In fact, pretty well all of us in the
open-source world drastically underestimated how well it would scale up with number of
users and against system complexity, until Linus Torvalds showed us differently.
In fact, I think Linus's cleverest and most consequential hack was not the construction of
the Linux kernel itself, but rather his invention of the Linux development model. When I
expressed this opinion in his presence once, he smiled and quietly repeated something he
has often said: ``I'm basically a very lazy person who likes to get credit for things other
people actually do.'' Lazy like a fox. Or, as Robert Heinlein famously wrote of one of his
characters, too lazy to fail.
In retrospect, one precedent for the methods and success of Linux can be seen in the
development of the GNU Emacs Lisp library and Lisp code archives. In contrast to the
cathedral-building style of the Emacs C core and most other GNU tools, the evolution of
the Lisp code pool was fluid and very user-driven. Ideas and prototype modes were often
rewritten three or four times before reaching a stable final form. And loosely-coupled
collaborations enabled by the Internet, a la Linux, were frequent.
Indeed, my own most successful single hack previous to fetchmail was probably Emacs
VC (version control) mode, a Linux-like collaboration by email with three other people,
only one of whom (Richard Stallman, the author of Emacs and founder of the Free
Software Foundation) I have met to this day. It was a front-end for SCCS, RCS and later
CVS from within Emacs that offered ``one-touch'' version control operations. It evolved
from a tiny, crude sccs.el mode somebody else had written. And the development of VC
succeeded because, unlike Emacs itself, Emacs Lisp code could go through
release/test/improve generations very quickly.
The Emacs story is not unique. There have been other software products with a two-level
architecture and a two-tier user community that combined a cathedral-mode core and a
bazaar-mode toolbox. One such is MATLAB, a commercial data-analysis and
visualization tool. Users of MATLAB and other products with a similar structure
invariably report that the action, the ferment, the innovation mostly takes place in the
open part of the tool where a large and varied community can tinker with it.
Release Early, Release Often
Early and frequent releases are a critical part of the Linux development model. Most
developers (including me) used to believe this was bad policy for larger than trivial
projects, because early versions are almost by definition buggy versions and you don't
want to wear out the patience of your users.
This belief reinforced the general commitment to a cathedral-building style of
development. If the overriding objective was for users to see as few bugs as possible,

why then you'd only release a version every six months (or less often), and work like a
dog on debugging between releases. The Emacs C core was developed this way. The Lisp
library, in effect, was not-because there were active Lisp archives outside the FSF's
control, where you could go to find new and development code versions independently of
Emacs's release cycle [QR].
The most important of these, the Ohio State Emacs Lisp archive, anticipated the spirit and
many of the features of today's big Linux archives. But few of us really thought very hard
about what we were doing, or about what the very existence of that archive suggested
about problems in the FSF's cathedral-building development model. I made one serious
attempt around 1992 to get a lot of the Ohio code formally merged into the official Emacs
Lisp library. I ran into political trouble and was largely unsuccessful.
But by a year later, as Linux became widely visible, it was clear that something different
and much healthier was going on there. Linus's open development policy was the very
opposite of cathedral-building. Linux's Internet archives were burgeoning, multiple
distributions were being floated. And all of this was driven by an unheard-of frequency of
core system releases.
Linus was treating his users as co-developers in the most effective possible way:
7. Release early. Release often. And listen to your customers.
Linus's innovation wasn't so much in doing quick-turnaround releases incorporating lots
of user feedback (something like this had been Unix-world tradition for a long time), but
in scaling it up to a level of intensity that matched the complexity of what he was
developing. In those early times (around 1991) it wasn't unknown for him to release a
new kernel more than once a day! Because he cultivated his base of co-developers and
leveraged the Internet for collaboration harder than anyone else, this worked.
But how did it work? And was it something I could duplicate, or did it rely on some
unique genius of Linus Torvalds?
I