The Cathedral and the Bazaar

Eric Steven Raymond

cf text and copyright at: www.tuxedo.org/~esr/writings

Abstract

I anatomize a successful open-source project, fetchmail, thatwas run as a deliberate test of some surprising theories aboutso=ware engineering suggested by the history of Linux. I dis-cuss these theories in terms of two fundamentally di:erentdevelopment styles, the “cathedral” model of most of the com-mercial world versus the “bazaar” model of the Linux world.I show that these models derive from opposing assumptionsabout the nature of the so=ware-debugging task. I thenmake asustained argument from the Linux experience for the proposi-tion that “Given enough eyeballs, all bugs are shallow”, suggestproductive analogies with other self-correcting systems of self-ish agents, and conclude with some exploration of the implica-tions of this insight for the future of so=ware.

1 The Cathedral and the Bazaar

Linux is subversive. Who would have thought even five years ago(1991) that a world-class operating system could coalesce as if bymagic out of part-time hacking by several thousand developers scat-tered all over the planet, connected only by the tenuous strands ofthe Internet?

Certainly not I. By the time Linux swam onto my radar screenin early 1993, I had already been involved in Unix and open-sourcedevelopment for ten years. I was one of the first gnu contributorsin the mid-1980s. I had released a good deal of open-source so=-ware onto the net, developing or co-developing several programs(nethack, Emacs’s vc and gud modes, xlife, and others) that are stillin wide use today. I thought I knew how it was done.

Linux overturned much of what I thought I knew. I had beenpreaching the Unix gospel of small tools, rapid prototyping and evo-

1

2 2 THE MAIL MUST GET THROUGH

lutionary programming for years. But I also believed there was acertain critical complexity above which a more centralized, a prioriapproach was required. I believed that themost important so=ware(operating systems and really large tools like the Emacs program-ming editor) needed to be built like cathedrals, carefully cra=ed byindividual wizards or small bands of mages working in splendidisolation, with no beta to be released before its time.

Linus Torvalds’s style of development – release early and o=en,delegate everything you can, be open to the point of promiscuity– came as a surprise. No quiet, reverent cathedral-building here –rather, the Linux community seemed to resemble a great babblingbazaar of di:ering agendas and approaches (aptly symbolized bythe Linux archive sites, who’d take submissions from anyone) out ofwhich a coherent and stable system could seemingly emerge only bya succession of miracles.

The fact that this bazaar style seemed to work, and work well,came as a distinct shock. As I learned my way around, I workedhard not just at individual projects, but also at trying to under-stand why the Linux world not only didn’t fly apart in confusionbut seemed to go from strength to strength at a speed barely imag-inable to cathedral-builders.

By mid-1996 I thought I was beginning to understand. Chancehanded me a perfect way to test my theory, in the form of an open-source project that I could consciously try to run in the bazaar style.So I did – and it was a significant success.

This is the story of that project. I’ll use it to propose some apho-risms about e:ective open-source development. Not all of these arethings I first learned in the Linux world, but we’ll see how the Linuxworld gives themparticular point. If I’m correct, they’ll help you un-derstand exactly what it is that makes the Linux community such afountain of good so=ware – and, perhaps, theywill help you becomemore productive yourself.

2 The Mail Must Get Through

Since 1993 I’d been running the technical side of a small free-accessInternet service provider called Chester County InterLink (ccil) inWest Chester, Pennsylvania. I co-founded ccil andwrote our uniquemultiuser bulletin-board so=ware – you can check it out by telnetting

3

to locke.ccil.org. Today it supports almost three thousand userson thirty lines. The job allowed me 24-hour-a-day access to the netthrough ccil’s 56K line – in fact, the job practically demanded it!

I had gotten quite used to instant Internet email. I found havingto periodically telnet over to locke to checkmymail annoying.WhatI wantedwas formymail to be delivered on snark (my home system)so that I would be notifiedwhen it arrived and could handle it usingall my local tools.

The Internet’snativemail forwardingprotocol, smtp (SimpleMailTransfer Protocol), wouldn’t suit, because it works best when ma-chines are connected full-time, while my personal machine isn’t al-ways on the net, and doesn’t have a static ip address. What I neededwasaprogramthatwould reachoutovermy intermittentdialupcon-nection and pull across my mail to be delivered locally. I knew suchthings existed, and that most of them used a simple application pro-tocol called pop (Post O?ce Protocol). pop is now widely supportedby most common mail clients, but at the time, it wasn’t built-in tothe mail reader I was using.

I needed a pop3 client. So I went out on the net and found one.Actually, I found three or four. I used one of them for a while, but itwasmissing what seemed an obvious feature, the ability to hack theaddresses on fetched mail so replies would work properly.

The problem was this: suppose someone named ‘joe’ on locke

sent memail. If I fetched the mail to snark and then tried to reply toit, my mailer would cheerfully try to ship it to a nonexistent ‘joe’ onsnark. Hand-editing reply addresses to tack on ‘@ccil.org’ quickly gotto be a serious pain.

This was clearly something the computer ought to be doing forme. But none of the existing pop clients knew how! And this bringsus to the first lesson:

# 1 Every good work of so=ware starts by scratching a developer’spersonal itch.

Perhaps this should have been obvious (it’s long been proverbialthat “Necessity is the mother of invention”) but too o=en so=waredevelopers spend their days grinding away for pay at programs theyneither need nor love. But not in the Linux world – which may ex-plain why the average quality of so=ware originated in the Linuxcommunity is so high.

4 2 THE MAIL MUST GET THROUGH

So, did I immediately launch into a furious whirl of coding upa brand-new pop3 client to compete with the existing ones? Not onyour life! I looked carefully at the pop utilities I had in hand, askingmyself “which one is closest to what I want?” Because

# 2 Good programmers know what to write. Great ones know whatto rewrite (and reuse).

While I don’t claim to be a great programmer, I try to imitate one.An important trait of the great ones is constructive laziness. Theyknow that you get an A not for e:ort but for results, and that it’salmost always easier to start from a good partial solution than fromnothing at all.

Linus Torvalds, for example, didn’t actually try to write Linuxfrom scratch. Instead, he started by reusing code and ideas fromMinix, a tiny Unix-like operating system for pc clones. Eventuallyall the Minix code went away or was completely rewritten – butwhile it was there, it provided sca:olding for the infant that wouldeventually become Linux.

In the same spirit, I went looking for an existing pop utility thatwas reasonably well coded, to use as a development base.

The source-sharing tradition of the Unix world has always beenfriendly to code reuse (this is why the gnu project chose Unix asa base os, in spite of serious reservations about the os itself). TheLinuxworld has taken this tradition nearly to its technological limit;it has terabytes of open sources generally available. So spending timelooking for someelse’s almost-good-enough ismore likely to give yougood results in the Linux world than anywhere else.

And it did for me. With those I’d found earlier, my second searchmade up a total of nine candidates – fetchpop, PopTart, get-mail, gw-pop, pimp, pop-perl, popc, popmail and upop. The one I first settledon was ‘fetchpop’ by Seung-Hong Oh. I put my header-rewrite fea-ture in it, and made various other improvements which the authoraccepted into his 1.9 release.

A few weeks later, though, I stumbled across the code for ‘pop-client’ by Carl Harris, and found I had a problem. Though fetch-pop had some good original ideas in it (such as its background-daemon mode), it could only handle pop3 and was rather amateur-ishly coded (Seung-Hongwas at that time a bright but inexperiencedprogrammer, and both traits showed). Carl’s code was better, quite

5

professional and solid, but his program lacked several importantand rather tricky-to-implement fetchpop features (including thoseI’d coded myself).

Stay or switch? If I switched, I’d be throwing away the coding I’dalready done in exchange for a better development base.

Apracticalmotive to switchwas thepresenceofmultiple-protocolsupport. pop3 is the most commonly used of the post-o?ce serverprotocols, but not the only one. Fetchpop and the other competi-tion didn’t do pop2, rpop, or apop, and I was already having vaguethoughts of perhaps adding imap (Internet Message Access Protocol,the most recently designed and most powerful post-o?ce protocol)just for fun.

But I had a more theoretical reason to think switching might beas good an idea as well, something I learned long before Linux.

# 3 “Plan to throw one away; you will, anyhow.” (Fred Brooks, “TheMythical Man-Month”, Chapter 11)

Or, to put it another way, you o=en don’t really understand theproblem until a=er the first time you implement a solution. Thesecond time, maybe you know enough to do it right. So if you wantto get it right, be ready to start over at least once [jb].

Well (I toldmyself) the changes to fetchpop had beenmy first try.So I switched.

A=er I sent my first set of popclient patches to Carl Harris on 25June 1996, I found out that he had basically lost interest in popclientsome timebefore. The codewas abit dusty,withminorbugshangingout. I had many changes to make, and we quickly agreed that thelogical thing for me to do was take over the program.

Withoutmyactuallynoticing, theprojecthadescalated.No longerwas I just contemplating minor patches to an existing pop client. Itook on maintaining an entire one, and there were ideas bubblingin my head that I knew would probably lead to major changes.

In a so=ware culture that encourages code-sharing, this is a nat-ural way for a project to evolve. I was acting out this principle:

# 4 If you have the right attitude, interesting problems will find you.

But Carl Harris’s attitude was even more important. He under-stood that

6 3 THE IMPORTANCE OF HAVING USERS

# 5 When you lose interest in a program, your last duty to it is tohand it o: to a competent successor.

Without ever having to discuss it, Carl and I knewwe had a com-mon goal of having the best solution out there. The only questionfor either of us was whether I could establish that I was a safe pairof hands. Once I did that, he acted with grace and dispatch. I hope Iwill do as well when it comes my turn.

3 The Importance of Having Users

And so I inherited popclient. Just as importantly, I inherited pop-client’s user base. Users are wonderful things to have, and not justbecause they demonstrate that you’re serving a need, that you’vedone something right. Properly cultivated, they can become co-de-velopers.

Another strength of the Unix tradition, one that Linux pushesto a happy extreme, is that a lot of users are hackers too. Becausesource code is available, they can be e:ective hackers. This can betremendously useful for shortening debugging time. Given a bitof encouragement, your users will diagnose problems, suggest fixes,andhelp improve the code farmore quickly than you could unaided.

# 6 Treating your users as co-developers is your least-hassle route torapid code improvement and e:ective debugging.

The power of this e:ect is easy to underestimate. In fact, prettywell all of us in the open-source world drastically underestimatedhowwell it would scale upwith number of users and against systemcomplexity, until Linus Torvalds showed us di:erently.

In fact, I think Linus’s cleverest and most consequential hackwas not the construction of the Linux kernel itself, but rather hisinvention of the Linux development model. When I expressed thisopinion in his presence once, he smiled and quietly repeated some-thing he has o=en said: “I’m basically a very lazy person who likesto get credit for things other people actually do.” Lazy like a fox. Or,as Robert Heinlein famously wrote of one of his characters, too lazyto fail.

In retrospect, oneprecedent for themethods and success of Linuxcan be seen in the development of the gnu Emacs Lisp library and

7

Lisp code archives. In contrast to the cathedral-building style of theEmacs C core and most other gnu tools, the evolution of the Lispcodepoolwasfluid andveryuser-driven. Ideas andprototypemodeswereo=en rewritten threeor four timesbefore reachinga stablefinalform. And loosely-coupled collaborations enabled by the Internet, ala Linux, were frequent.

Indeed, my own most successful single hack previous to fetch-mail was probably Emacs vc (version control) mode, a Linux-likecollaboration by email with three other people, only one of whom(Richard Stallman, the author of Emacs and founder of the Free So=-ware Foundation) I have met to this day. It was a front- end for sccs,rcs and later cvs from within Emacs that o:ered “one-touch” ver-sion control operations. It evolved from a tiny, crude sccs.el modesomebody else had written. And the development of vc succeededbecause, unlike Emacs itself, Emacs Lisp code could go through re-lease/test/improve generations very quickly.

4 Release Early, Release O=en

Early and frequent releases are a critical part of the Linux develop-ment model. Most developers (including me) used to believe thiswas bad policy for larger than trivial projects, because early versionsare almost by definition buggy versions and you don’t want to wearout the patience of your users.

This belief reinforced the general commitment to a cathedral-building style of development. If the overriding objective was forusers to see as few bugs as possible, why then you’d only release aversion every six months (or less o=en), and work like a dog on de-buggingbetween releases. TheEmacsC corewasdeveloped thisway.The Lisp library, in e:ect, was not – because there were active Lisparchives outside the fsf’s control, where you could go to find newand development code versions independently of Emacs’s releasecycle [qr].

The most important of these, the Ohio State elisp archive, an-ticipated the spirit and many of the features of today’s big Linuxarchives. But few of us really thought very hard about what we weredoing, or about what the very existence of that archive suggestedabout problems in the fsf’s cathedral- building developmentmodel.I made one serious attempt around 1992 to get a lot of the Ohio code

8 4 RELEASE EARLY, RELEASE OFTEN

formally merged into the o?cial Emacs Lisp library. I ran into polit-ical trouble and was largely unsuccessful.

But by a year later, as Linux became widely visible, it was clearthat something di:erent and much healthier was going on there.Linus’s open development policywas the very opposite of cathedral-building. Linux’s Internet archiveswereburgeoning,multipledistri-butionswere beingfloated. And all of thiswas driven by anunheard-of frequency of core system releases.

Linuswas treating his users as co-developers in themost e:ectivepossible way:

# 7 Release early. Release o=en. And listen to your customers.

Linus’s innovation wasn’t so much in doing quick-turnaroundreleases incorporating lots of user feedback (something like this hadbeen Unix-world tradition for a long time), but in scaling it up toa level of intensity that matched the complexity of what he wasdeveloping. In those early times (around 1991) it wasn’t unknownfor him to release a new kernel more than once a day! Because hecultivated his base of co-developers and leveraged the Internet forcollaboration harder than anyone else, this worked.

But how did it work? And was it something I could duplicate, ordid it rely on some unique genius of Linus Torvalds?

I didn’t think so. Granted, Linus is a damn fine hacker. Howmany of us could engineer an entire production-quality operatingsystem kernel from scratch? But Linux didn’t represent any awe-some conceptual leap forward. Linus is not (or at least, not yet) aninnovative genius of design in theway that, say, Richard Stallman orJames Gosling (of NeWS and Java) are. Rather, Linus seems to me tobe a genius of engineering and implementation, with a sixth sensefor avoiding bugs and development dead-ends and a true knack forfinding the minimum-e:ort path from point A to point B. Indeed,the whole design of Linux breathes this quality andmirrors Linus’sessentially conservative and simplifying design approach.

So, if rapid releases and leveraging the Internet medium to thehilt were not accidents but integral parts of Linus’s engineering-genius insight into theminimum-e:ort path, what was hemaximiz-ing? What was he cranking out of the machinery?

Put that way, the question answers itself. Linus was keeping hishacker/users constantly stimulated and rewarded – stimulated by

9

theprospect ofhavinganego-satisfyingpieceof the action, rewardedby the sight of constant (even daily) improvement in their work.

Linus was directly aiming to maximize the number of person-hours thrown at debugging and development, even at the possiblecost of instability in the code and user-base burnout if any seriousbug proved intractable. Linus was behaving as though he believedsomething like this:

# 8 Given a large enough beta-tester and co-developer base, almostevery problem will be characterized quickly and the fix obvious tosomeone.

Or, less formally, “Given enough eyeballs, all bugs are shallow.” Idub this: “Linus’s Law”.

My original formulation was that every problem “will be trans-parent to somebody”. Linus demurred that the person who under-stands and fixes the problem is not necessarily or even usually theperson who first characterizes it. “Somebody finds the problem,” hesays, “and somebody else understands it. And I’ll go on record assaying that finding it is the bigger challenge.” But the point is thatboth things tend to happen rapidly.

Here, I think, is the core di:erence underlying the cathedral-builder and bazaar styles. In the cathedral-builder view of program-ming, bugs and development problems are tricky, insidious, deepphenomena. It takes months of scrutiny by a dedicated few to de-velop confidence that you’ve winkled them all out. Thus the longrelease intervals, and the inevitable disappointment when long-awaited releases are not perfect.

In the bazaar view, on the other hand, you assume that bugsare generally shallow phenomena – or, at least, that they turn shal-low pretty quickly when exposed to a thousand eager co-developerspounding on every single new release. Accordingly you release o=enin order to get more corrections, and as a beneficial side e:ect youhave less to lose if an occasional botch gets out the door.

And that’s it. That’s enough. If “Linus’s Law” is false, then anysystem as complex as the Linux kernel, being hacked over by asmanyhandsas theLinuxkernel, shouldat somepointhave collapsedunder the weight of unforseen bad interactions and undiscovered“deep” bugs. If it’s true, on the other hand, it is su?cient to explainLinux’s relative lack of bugginess and its continuous uptimes span-ning months or even years.

10 4 RELEASE EARLY, RELEASE OFTEN

Maybe it shouldn’t have been such a surprise, at that. Sociologistsyears ago discovered that the averaged opinion of a mass of equallyexpert (or equally ignorant) observers is quite a bit more reliable apredictor than that of a single randomly-chosenoneof the observers.They called this the “Delphi e:ect”. It appears that what Linus hasshown is that this applies even to debugging an operating system –that the Delphi e:ect can tame development complexity even at thecomplexity level of an os kernel.

One special feature of the Linux situation that clearly helps alongtheDelphi e:ect is the fact that the contributors for any givenprojectare self- selected. An early respondent pointed out that contributionsare received not from a random sample, but from people who areinterested enough to use the so=ware, learn about how it works,attempt to find solutions to problems they encounter, and actuallyproduce an apparently reasonable fix. Anyone who passes all thesefilters is highly likely to have something useful to contribute.

I am indebted to my friend Je: Dutky <dutky@wam.umd.edu>for pointing out that Linus’s Law can be rephrased as “Debuggingis parallelizable”. Je: observes that although debugging requiresdebuggers to communicate with some coordinating developer, itdoesn’t require significant coordination between debuggers. Thus itdoesn’t fall prey to the same quadratic complexity andmanagementcosts that make adding developers problematic.

In practice, the theoretical loss of e?ciency due to duplication ofwork by debuggers almost never seems to be an issue in the Linuxworld. One e:ect of a “release early and o=en policy” is tominimizesuch duplication by propagating fed-back fixes quickly [jh].

Brooks (the author of “TheMythical Man-Month”) evenmade ano:-hand observation related to Je:’s : “The total cost of maintaininga widely used program is typically 40 percent or more of the costof developing it. Surprisingly this cost is strongly a:ected by thenumber of users. More users find more bugs.” (my emphasis).

Moreusers findmorebugs because addingmoreusers addsmoredi:erentwaysof stressing theprogram.This e:ect is amplifiedwhenthe users are co- developers. Each one approaches the task of bugcharacterization with a slightly di:erent perceptual set and analyt-ical toolkit, a di:erent angle on the problem. The “Delphi e:ect”seems towork precisely because of this variation. In the specific con-text of debugging, the variation also tends to reduce duplication ofe:ort.

11

So adding more beta-testers may not reduce the complexity ofthe current “deepest” bug from the developer’s point of view, but itincreases the probability that someone’s toolkit will be matched tothe problem in such a way that the bug is shallow to that person.

Linus coppers his bets, too. In case there are serious bugs, Linuxkernel version are numbered in such a way that potential users canmake a choice either to run the last version designated “stable” orto ride the cutting edge and risk bugs in order to get new features.This tactic is not yet formally imitated by most Linux hackers, butperhaps it should be; the fact that either choice is available makesboth more attractive. [hbs]

5 When Is A Rose Not A Rose ?

Having studied Linus’s behavior and formed a theory about why itwas successful, I made a conscious decision to test this theory onmynew (admittedly much less complex and ambitious) project.

But the first thing I did was reorganize and simplify popclienta lot. Carl Harris’s implementation was very sound, but exhibited akind of unnecessary complexity common to many C programmers.He treated the code as central and the data structures as support forthe code. As a result, the code was beautiful but the data structuredesign ad-hoc and rather ugly (at least by the high standards of thisold lisp hacker).

I had another purpose for rewriting besides improving the codeand the data structure design, however. That was to evolve it intosomething I understood completely. It’s no fun to be responsible forfixing bugs in a program you don’t understand.

For the first month or so, then, I was simply following out theimplications of Carl’s basic design. The first serious change I madewas to add imap support. I did this by reorganizing the protocolmachines into a generic driver and three method tables (for pop2,pop3, and imap). This and the previous changes illustrate a generalprinciple that’s good for programmers to keep in mind, especiallyin languages like C that don’t naturally do dynamic typing:

# 9 Smart data structures and dumb code works a lot better than theother way around.

12 5 WHEN IS A ROSE NOT A ROSE ?

Brooks, Chapter 9: “Showme your [code] and conceal your [datastructures], and I shall continue to bemystified. Showme your [datastructures], and I won’t usually need your [code]; it’ll be obvious.”

Actually, he said “flowcharts” and “tables”. But allowing for thirtyyears of terminological/cultural shi=, it’s almost the same point.

At this point (early September 1996, about six weeks from zero) Istarted thinking that a name change might be in order – a=er all, itwasn’t just a pop client any more. But I hesitated, because there wasas yet nothing genuinely new in the design. My version of popclienthad yet to develop an identity of its own.

That changed, radically, when fetchmail learned how to forwardfetchedmail to the smtp port. I’ll get to that in a moment. But first: Isaid above that I’d decided to use this project to testmy theory aboutwhat Linus Torvalds had done right. How (you may well ask) did Ido that? In these ways:

– I released early and o=en (almost never less o=en than everyten days; during periods of intense development, once a day).

– I grew my beta list by adding to it everyone who contacted meabout fetchmail.

– I sent chatty announcements to the beta list whenever I re-leased, encouraging people to participate.

– And I listened to my beta testers, polling them about designdecisions and stroking them whenever they sent in patchesand feedback.

Thepayo: from these simplemeasureswas immediate. From thebeginning of the project, I got bug reports of a quality most devel-opers would kill for, o=en with good fixes attached. I got thoughtfulcriticism, I got fan mail, I got intelligent feature suggestions. Whichleads to:

# 10 If you treat your beta-testers as if they’re your most valuableresource, theywill respond by becoming yourmost valuable resource.

One interesting measure of fetchmail’s success is the sheer sizeof the project beta list, fetchmail-friends. At the time of last revision(August 2000) it has 249members and is adding two or three aweek.

Actually, as I revise in late May 1997 the list is beginning to losemembers from its high of close to 300 for an interesting reason.

13

Several people have asked me to unsubscribe them because fetch-mail is working so well for them that they no longer need to see thelist tra?c! Perhaps this is part of the normal life-cycle of a maturebazaar-style project.

6 Popclient becomes Fetchmail

The real turning point in the project was when Harry Hochheisersent me his scratch code for forwardingmail to the client machine’ssmtp port. I realized almost immediately that a reliable implemen-tation of this feature would make all the other mail delivery modesnext to obsolete.

For many weeks I had been tweaking fetchmail rather incre-mentally while feeling like the interface design was serviceable butgrubby – inelegant and with too many exiguous options hangingout all over. The options to dump fetched mail to a mailbox file orstandard output particularly bothered me, but I couldn’t figure outwhy.

(If you don’t care about the technicalia of Internet mail, the nexttwo paragraphs can be safely skipped.)

What I saw when I thought about smtp forwarding was that pop-client had been trying to do toomany things. It had been designed tobe both amail transport agent (mta) and a local delivery agent (mda).With smtp forwarding, it could get out of the mda business and be apure mta, handing o: mail to other programs for local delivery justas sendmail does.

Why mess with all the complexity of configuring a mail deliveryagent or setting up lock-and-append on a mailbox when port 25 isalmost guaranteed to be there on any platform with tcp/ip supportin the first place? Especially when this means retrievedmail is guar-anteed to look like normal sender-initiated smtpmail, which is reallywhat we want anyway.

(Back to a higher level...)Even if youdidn’t follow thepreceding technical jargon, there are

several important lessons here. First, this smtp-forwarding conceptwas the biggest singlepayo: I got fromconsciously trying to emulateLinus’s methods. A user gave me this terrific idea – all I had to dowas understand the implications.

14 6 POPCLIENT BECOMES FETCHMAIL

# 11 The next best thing to having good ideas is recognizing goodideas from your users. Sometimes the latter is better.

Interestingly enough, you will quickly find that if you are com-pletely and self- deprecatingly truthful about how much you oweother people, the world at large will treat you like you did everybit of the invention yourself and are just being becomingly modestabout your innate genius. We can all see how well this worked forLinus!

(When Igavemy talk at thePerl conference inAugust 1997,hackerextraordinaire LarryWallwas in the front row. As I got to the last lineabove he called out, religious-revival style, “Tell it, tell it, brother!”.The whole audience laughed, because they knew this had workedfor the inventor of Perl, too.)

A=er a very few weeks of running the project in the same spirit,I began to get similar praise not just from my users but from otherpeople to whom the word leaked out. I stashed away some of thatemail; I’ll look at it again sometime if I ever startwonderingwhethermy life has been worthwhile :–).

But there are two more fundamental, non-political lessons herethat are general to all kinds of design.

# 12 O=en, the most striking and innovative solutions come fromrealizing that your concept of the problem was wrong.

I had been trying to solve the wrong problem by continuing todevelop popclient as a combined mta/mda with all kinds of funkylocal delivery modes. Fetchmail’s design needed to be rethoughtfromthegroundupasapuremta, apart of thenormal smtp-speakingInternet mail path.

When you hit a wall in development – when you find yourselfhard put to think past the next patch – it’s o=en time to ask notwhether you’ve got the right answer, but whether you’re asking theright question. Perhaps the problem needs to be reframed.

Well, I had reframed my problem. Clearly, the right thing to dowas (1) hack smtp forwarding support into the generic driver, (2)make it the default mode, and (3) eventually throw out all the otherdeliverymodes, especially the deliver-to-file and deliver-to-standard-output options.

I hesitated over step 3 for some time, fearing to upset long-timepopclient users dependent on the alternate delivery mechanisms.

15

In theory, they could immediately switch to .forward files or theirnon-sendmail equivalents to get the same e:ects. In practice thetransition might have been messy.

But when I did it, the benefits proved huge. The cru=iest parts ofthe driver code vanished. Configuration got radically simpler – nomore grovelling around for the system mda and user’s mailbox, nomoreworries aboutwhether theunderlyingos supports file locking.

Also, the only way to losemail vanished. If you specified deliveryto a file and the disk got full, your mail got lost. This can’t happenwith smtp forwarding because your smtp listener won’t return ok

unless the message can be delivered or at least spooled for laterdelivery.

Also, performance improved (though not so you’d notice it in asingle run). Another not insignificant benefit of this changewas thatthe manual page got a lot simpler.

Later, I had to bring delivery via a user-specified local mda backin order to allow handling of some obscure situations involving dy-namic slip. But I found a much simpler way to do it.

Themoral? Don’t hesitate to throw away superannuated featureswhen you can do it without loss of e:ectiveness. Antoine de Saint-Exupéry (who was an aviator and aircra= designer when he wasn’tbeing the author of classic children’s books) said:

# 13 “Perfection (in design) is achieved not when there is nothingmore to add, but rather when there is nothing more to take away.”

When your code is getting both better and simpler, that is whenyou know it’s right. And in the process, the fetchmail design acquiredan identity of its own, di:erent from the ancestral popclient.

It was time for the name change. The new design looked muchmore like a dual of sendmail than the old popclient had; both aremtas, but where sendmail pushes then delivers, the new popclientpulls then delivers. So, twomonths o: the blocks, I renamed it fetch-mail.

There is amore general lesson in this story about how smtp deliv-ery came to fetchmail. It is not only debugging that is parallelizable;development and (to a perhaps surprising extent) exploration of de-sign space is, too.When your developmentmode is rapidly iterative,development and enhancementmay become special cases of debug-ging – fixing ‘bugs of omission’ in the original capabilities or conceptof the so=ware.

16 7 FETCHMAIL GROWS UP

Even at a higher level of design, it can be very valuable to havethe thinking of lots of co-developers random-walking through thedesign space near your product. Consider the way a puddle of waterfinds a drain, or better yet how ants find food: exploration essen-tially by di:usion, followed by exploitation mediated by a scalablecommunication mechanism. This works very well; as with HarryHochheiser andme, one of your outriders may well find a huge winnearby that you were just a little too close-focused to see.

7 Fetchmail Grows Up

There I was with a neat and innovative design, code that I knewworked well because I used it every day, and a burgeoning beta list.It gradually dawned on me that I was no longer engaged in a trivialpersonal hack that might happen to be useful to few other people.I had my hands on a program every hacker with a Unix box and aslip/pppmail connection really needs.

With the smtp forwarding feature, it pulled far enough in frontof the competition to potentially become a “category killer”, one ofthose classic programs that fills its niche so competently that thealternatives are not just discarded but almost forgotten.

I think you can’t really aim or plan for a result like this. You haveto get pulled into it by design ideas so powerful that a=erward theresults just seem inevitable, natural, even foreordained. The onlyway to try for ideas like that is by having lots of ideas – or by havingthe engineering judgment to take other peoples’ good ideas beyondwhere the originators thought they could go.

Andy Tanenbaum had the original idea to build a simple nativeUnix for ibm pcs, for use as a teaching tool (he called it Minix). LinusTorvalds pushed the Minix concept further than Andrew probablythought it could go – and it grew into something wonderful. In thesame way (though on a smaller scale), I took some ideas by CarlHarris and Harry Hochheiser and pushed them hard. Neither of uswas ‘original’ in the romantic way people think is genius. But then,most science and engineering and so=ware development isn’t doneby original genius, hacker mythology to the contrary.

The results were pretty heady stu: all the same – in fact, justthe kind of success every hacker lives for! And they meant I wouldhave to setmy standards even higher. Tomake fetchmail as good as I

17

now saw it could be, I’d have to write not just for my own needs, butalso include and support features necessary to others but outsidemyorbit. And do that while keeping the program simple and robust.

The first and overwhelmingly most important feature I wrotea=er realizing this was multidrop support – the ability to fetch mailfrom mailboxes that had accumulated all mail for a group of users,and then route each piece of mail to its individual recipients.

I decided to add themultidrop support partly because someuserswere clamoring for it, but mostly because I thought it would shakebugs out of the single-drop code by forcing me to deal with address-ing in full generality. And so it proved. Getting rfc 822 address pars-ing right tookmea remarkably long time,notbecause any individualpiece of it is hard but because it involved a pile of interdependentand fussy details.

But multidrop addressing turned out to be an excellent designdecision as well. Here’s how I knew:

# 14 Any tool should be useful in the expected way, but a truly greattool lends itself to uses you never expected.

The unexpected use for multi-drop fetchmail is to run mailinglists with the list kept, and alias expansion done, on the client side ofthe Internet connection. This means someone running a personalmachine through an isp account can manage a mailing list withoutcontinuing access to the isp’s alias files.

Another important changedemandedbymybeta testerswas sup-port for 8-bit mime (Multipurpose Internet Mail Extensions) opera-tion. This was pretty easy to do, because I had been careful to keepthe code 8-bit clean. Not because I anticipated the demand for thisfeature, but rather in obedience to another rule:

# 15 When writing gateway so=ware of any kind, take pains to dis-turb the data stream as little as possible – and *never* throw awayinformation unless the recipient forces you to!

Had I not obeyed this rule, 8-bit mime support would have beendi?cult andbuggy. As itwas, all I had to do is read themime standard(rfc 1652) and add a trivial bit of header-generation logic.

Some European users bugged me into adding an option to limitthe number of messages retrieved per session (so they can controlcosts from their expensive phone networks). I resisted this for a long

18 8 A FEW MORE LESSONS FROM FETCHMAIL

time, and I’m still not entirely happy about it. But if you’re writingfor the world, you have to listen to your customers – this doesn’tchange just because they’re not paying you in money.

8 A FewMore Lessons From Fetchmail

Before we go back to general so=ware-engineering issues, there area couplemore specific lessons from the fetchmail experience to pon-der. Nontechnical readers can safely skip this section.

The rc (control) file syntax includesoptional ‘noise’ keywords thatare entirely ignored by the parser. The English-like syntax they allowis considerably more readable than the traditional terse keyword-value pairs you get when you strip them all out.

These started out as a late-night experiment when I noticed howmuch the rc file declarationswere beginning to resemble an impera-tiveminilanguage. (This is alsowhy I changed the original popclient‘server’ keyword to ‘poll’).

It seemed tomethat trying tomake that imperativeminilanguagemore like English might make it easier to use. Now, although I’m aconvinced partisan of the “make it a language” school of design asexemplified by Emacs and html and many database engines, I amnot normally a big fan of “English-like” syntaxes.

Traditionally programmers have tended to favor control syntaxesthat are very precise and compact and have no redundancy at all.This is a cultural legacy from when computing resources were ex-pensive, so parsing stages had to be as cheap and simple as possible.English, with about 50% redundancy, looked like a very inappropri-ate model then.

This is not my reason for normally avoiding English-like syn-taxes; I mention it here only to demolish it. With cheap cycles andcore, terseness should not be an end in itself. Nowadays it’s moreimportant for a language to be convenient for humans than to becheap for the computer.

There remain, however, good reasons to be wary. One is the com-plexity cost of the parsing stage – you don’t want to raise that tothe point where it’s a significant source of bugs and user confusionin itself. Another is that trying to make a language syntax English-like o=en demands that the “English” it speaks be bent seriouslyout of shape, so much so that the superficial resemblance to natural

19

language is as confusing as a traditional syntax would have been.(You see this bad e:ect in a lot of so-called “fourth generation” andcommercial database-query languages.)

The fetchmail control syntax seems to avoid these problems be-cause the languagedomain is extremely restricted. It’s nowhereneara general-purpose language; the things it says simply are not verycomplicated, so there’s little potential for confusion inmovingmen-tally between a tiny subset of English and the actual control lan-guage. I think there may be a wider lesson here:

# 16 When your language is nowhere near Turing-complete, syntac-tic sugar can be your friend.

Another lesson is about security by obscurity. Some fetchmailusers askedme to change the so=ware to store passwords encryptedin the rc file, so snoopers wouldn’t be able to casually see them.

I didn’t do it, because this doesn’t actually addprotection. Anyonewho’s acquired permissions to read your rc file will be able to runfetchmail as you anyway – and if it’s your password they’re a=er,they’d be able to rip the necessary decoder out of the fetchmail codeitself to get it.

All .fetchmailrc password encryption would have done is givea false sense of security to people who don’t think very hard. Thegeneral rule here is:

# 17 A security system is only as secure as its secret. Beware ofpseudo-secrets.

9 Necessary Preconditions for the Bazaar Style

Early reviewers and test audiences for this paper consistently raisedquestions about the preconditions for successful bazaar-style devel-opment, including both the qualifications of the project leader andthe state of code at the time one goes public and starts to try to builda co-developer community.

It’s fairly clear that one cannot code from the groundup inbazaarstyle [in]. One can test, debug and improve in bazaar style, but itwouldbeveryhard tooriginateaproject inbazaarmode.Linusdidn’ttry it. I didn’t either. Your nascent developer community needs tohave something runnable and testable to play with.

20 9 NECESSARY PRECONDITIONS FOR THE BAZAAR STYLE

When you start community-building, what you need to be ableto present is a plausible promise. Your program doesn’t have to workparticularly well. It can be crude, buggy, incomplete, and poorlydocumented. What it must not fail to do is (a) run, and (b) convincepotential co-developers that it can be evolved into something reallyneat in the foreseeable future.

Linux and fetchmail both went public with strong, attractive ba-sic designs. Many people thinking about the bazaar model as I havepresented it have correctly considered this critical, then jumpedfrom it to the conclusion that a high degree of design intuition andcleverness in the project leader is indispensable.

But Linus got his design from Unix. I got mine initially from theancestral popclient (though it would later change a great deal, muchmore proportionately speaking than has Linux). So does the leader/coordinator for a bazaar-style e:ort really have to have exceptionaldesign talent, or can he get by on leveraging the design talent ofothers?

I think it is not critical that the coordinator be able to originatedesigns of exceptional brilliance, but it is absolutely critical that thecoordinator be able to recognize good design ideas from others.

Both the Linux and fetchmail projects show evidence of this.Linus, while not (as previously discussed) a spectacularly originaldesigner, has displayed a powerful knack for recognizing good de-sign and integrating it into the Linux kernel. And I have alreadydescribed how the single most powerful design idea in fetchmail(smtp forwarding) came from somebody else.

Early audiences of this paper complimented me by suggestingthat I am prone to undervalue design originality in bazaar projectsbecause I have a lot of it myself, and therefore take it for granted.There may be some truth to this; design (as opposed to coding ordebugging) is certainly my strongest skill.

But theproblemwithbeingclever andoriginal in so=waredesignis that it gets to be a habit – you start reflexively making thingscute and complicated when you should be keeping them robust andsimple. I have had projects crash onme because Imade thismistake,but I managed not to with fetchmail.

So I believe the fetchmail project succeeded partly because I re-strained my tendency to be clever; this argues (at least) against de-sign originality being essential for successful bazaar projects. Andconsider Linux. Suppose Linus Torvalds had been trying to pull o:

21

fundamental innovations in operating system design during the de-velopment; does it seem at all likely that the resulting kernel wouldbe as stable and successful as what we have?

A certain base level of design and coding skill is required, ofcourse, but I expect almost anybody seriously thinking of launchingabazaar e:ortwill alreadybeabove thatminimum.Theopen-sourcecommunity’s internalmarket in reputationexerts subtlepressureonpeople not to launch development e:orts they’re not competent tofollow through on. So far this seems to have worked pretty well.

There is another kind of skill not normally associated with so=-waredevelopmentwhich I think is as important as design clevernessto bazaar projects – and it may be more important. A bazaar projectcoordinator or leader must have good people and communicationsskills.

This should be obvious. In order to build a development commu-nity, you need to attract people, interest them in what you’re doing,and keep themhappy about the amount ofwork they’re doing. Tech-nical sizzle will go a long way towards accomplishing this, but it’sfar from the whole story. The personality you project matters, too.

It is not a coincidence that Linus is a nice guy whomakes peoplelike him and want to help him. It’s not a coincidence that I’m anenergetic extrovert who enjoys working a crowd and has some ofthe delivery and instincts of a stand-up comic. To make the bazaarmodel work, it helps enormously if you have at least a little skill atcharming people.

10 The Social Context of Open-Source So=ware

It is truly written: the best hacks start out as personal solutions tothe author’s everyday problems, and spread because the problemturns out to be typical for a large class of users. This takes us back tothe matter of rule 1, restated in a perhaps more useful way:

# 18 To solve an interesting problem, start by finding a problem thatis interesting to you.

So itwaswithCarlHarris and the ancestral popclient, and sowithme and fetchmail. But this has been understood for a long time. Theinteresting point, the point that the histories of Linux and fetchmailseem to demand we focus on, is the next stage – the evolution of

22 10 THE SOCIAL CONTEXT OF OPEN-SOURCE SOFTWARE

so=ware in the presence of a large and active community of usersand co-developers.

In “The Mythical Man-Month”, Fred Brooks observed that pro-grammer time is not fungible; adding developers to a late so=wareproject makes it later. He argued that the complexity and commu-nication costs of a project rise with the square of the number ofdevelopers, while work done only rises linearly. This claim has sincebecome known as “Brooks’s Law” and is widely regarded as a tru-ism. But if Brooks’s Law were the whole picture, Linux would beimpossible.

Gerald Weinberg’s classic “The Psychology Of Computer Pro-gramming” supplied what, in hindsight, we can see as a vital correc-tion to Brooks. In his discussion of “egoless programming”, Wein-berg observed that in shops where developers are not territorialabout their code, and encourage other people to look for bugs andpotential improvements in it, improvement happens dramaticallyfaster than elsewhere.

Weinberg’s choiceof terminologyhasperhapspreventedhis anal-ysis from gaining the acceptance it deserved – one has to smile at thethought of describing Internet hackers as “egoless”. But I think hisargument looks more compelling today than ever.

Thehistory ofUnix shouldhave preparedus forwhatwe’re learn-ing from Linux (and what I’ve verified experimentally on a smallerscale by deliberately copying Linus’s methods [egcs]). That is, thatwhile coding remains an essentially solitary activity, the really greathacks come from harnessing the attention and brainpower of entirecommunities. The developerwho uses only his or her own brain in aclosed project is going to fall behind the developer who knows howto create an open, evolutionary context in which feedback explor-ing the design space, code contributions, bug-spotting, and otherimprovements come back from hundreds (perhaps thousands) ofpeople.

But the traditional Unix world was prevented from pushing thisapproach to the ultimate by several factors. One was the legal con-traints of various licenses, trade secrets, and commercial interests.Another (in hindsight)was that the Internetwasn’t yet good enough.

Before cheap Internet, there were some geographically compactcommunities where the culture encouraged Weinberg’s “egoless”programming, and a developer could easily attract a lot of skilledkibitzers and co-developers. Bell Labs, the mit ai Lab, uc Berkeley –

23

these became the home of innovations that are legendary and stillpotent.

Linux was the first project to make a conscious and successfule:ort to use the entire world as its talent pool. I don’t think it’s acoincidence that the gestation period of Linux coincided with thebirth of the World Wide Web, and that Linux le= its infancy duringthe same period in 1993–1994 that saw the takeo: of the isp indus-try and the explosion of mainstream interest in the Internet. Linuswas the first person who learned how to play by the new rules thatpervasive Internet access made possible.

While cheap Internet was a necessary condition for the Linuxmodel to evolve, I think it was not by itself a su?cient condition.Another vital factor was the development of a leadership style andset of cooperative customs that could allow developers to attract co-developers and get maximum leverage out of the medium.

But what is this leadership style and what are these customs?They cannot be based on power relationships – and even if theycould be, leadership by coercion would not produce the results wesee.Weinberg quotes the autobiography of the 19th-centuryRussiananarchist Pyotr Alexeyvich Kropotkin’s Memoirs of a Revolutionist togood e:ect on this subject:

Having been brought up in a serf-owner’s family, I en-tered active life, like all young men of my time, with agreat deal of confidence in the necessity of commanding,ordering, scolding, punishing and the like. But when, atan early stage, I had to manage serious enterprises and todeal with [free] men, and when each mistake would leadat once to heavy consequences, I began to appreciate thedi:erence between acting on the principle of commandand discipline and acting on the principle of common un-derstanding. The formerworksadmirably inamilitarypa-rade, but it is worth nothing where real life is concerned,and theaimcanbeachievedonly through the severe e:ortof many converging wills.

The “severe e:ort of many converging wills” is precisely whata project like Linux requires – and the “principle of command” ise:ectively impossible to apply among volunteers in the anarchist’sparadise we call the Internet. To operate and compete e:ectively,

24 10 THE SOCIAL CONTEXT OF OPEN-SOURCE SOFTWARE

hackers who want to lead collaborative projects have to learn howto recruit and energize e:ective communities of interest in themode vaguely suggested by Kropotkin’s “principle of understand-ing”. They must learn to use Linus’s Law. [sp]

Earlier I referred to the “Delphi e:ect” as a possible explana-tion for Linus’s Law. But more powerful analogies to adaptive sys-tems in biology and economics also irresistably suggest themselves.The Linux world behaves in many respects like a free market or anecology, a collection of selfish agents attempting to maximize utilitywhich in the process produces a self-correcting spontaneous ordermore elaborate and e?cient than any amount of central planningcould have achieved. Here, then, is the place to seek the “principleof understanding”.

The “utility function” Linux hackers aremaximizing is not classi-cally economic, but is the intangible of their ownego satisfactionandreputation among other hackers. (Onemay call theirmotivation “al-truistic”, but this ignores the fact that altruism is itself a form of egosatisfaction for the altruist). Voluntary cultures that work this wayare not actually uncommon; one other in which I have long partic-ipated is science fiction fandom, which unlike hackerdom has longexplicitly recognized “egoboo” (ego-boosting, or the enhancement ofone’s reputation among other fans) as the basic drive behind volun-teer activity.

Linus, by successfully positioning himself as the gatekeeper ofa project in which the development is mostly done by others, andnurturing interest in the project until it became self-sustaining, hasshown an acute grasp of Kropotkin’s “principle of shared under-standing”. This quasi-economic view of the Linux world enables usto see how that understanding is applied.

We may view Linus’s method as a way to create an e?cient mar-ket in “egoboo” – to connect the selfishness of individual hackersas firmly as possible to di?cult ends that can only be achieved bysustained cooperation. With the fetchmail project I have shown (al-beit on a smaller scale) that his methods can be duplicated withgood results. Perhaps I have even done it a bit more consciously andsystematically than he.

Many people (especially those who politically distrust free mar-kets)would expect a culture of self-directed egoists to be fragmented,territorial, wasteful, secretive, and hostile. But this expectation isclearly falsified by (to give just one example) the stunning variety,

25

quality and depth of Linux documentation. It is a hallowed giventhat programmers hate documenting; how is it, then, that Linuxhackers generate somuch of it? Evidently Linux’s freemarket in ego-boo works better to produce virtuous, other-directed behavior thanthemassively-funded documentation shops of commercial so=wareproducers.

Both the fetchmail and Linux kernel projects show that by prop-erly rewarding the egos of many other hackers, a strong developer/coordinator can use the Internet to capture the benefits of havinglots of co-developers without having a project collapse into a chaoticmess. So to Brooks’s Law I counter-propose the following:

# 19 Provided the development coordinator has amedium at least asgood as the Internet, and knows how to lead without coercion, manyheads are inevitably better than one.

I think the future of open-source so=ware will increasingly be-long to people who know how to play Linus’s game, people wholeave behind the cathedral and embrace the bazaar. This is not to saythat individual vision and brilliance will no longer matter; rather,I think that the cutting edge of open-source so=ware will belongto people who start from individual vision and brilliance, then am-plify it through the e:ective construction of voluntary communitiesof interest.

Perhaps this is not only the future of open-source so=ware. Noclosed-source developer canmatch the pool of talent the Linux com-munity can bring to bear on a problem. Very few could a:ord evento hire the more than two hundred (1999: six hundred, 2000: eighthundred) people who have contributed to fetchmail!

Perhaps in the end the open-source culture will triumph not be-cause cooperation ismorally right or so=ware “hoarding” ismorallywrong (assuming you believe the latter, which neither Linus norI do), but simply because the closed-source world cannot win anevolutionary arms race with open-source communities that can putorders of magnitude more skilled time into a problem.

11 OnManagement and the Maginot Line

The original “Cathedral and Bazaar” paper of 1997 ended with thevision above – that of happy networked hordes of programmer/

26 11 ON MANAGEMENT AND THE MAGINOT LINE

anarchists outcompeting and overwhelming the hierarchical worldof conventional closed so=ware.

A goodmany skeptics weren’t convinced, however; and the ques-tions they raise deserve a fair engagement. Most of the objectionsto the bazaar argument come down to the claim that its proponentshave underestimated the productivity- multiplying e:ect of conven-tional management.

Traditionally-minded so=ware-development managers o=en ob-ject that the casualness with which project groups form and changeand dissolve in the open- source world negates a significant partof the apparent advantage of numbers that the open-source commu-nityhasover any single closed-sourcedeveloper. Theywouldobservethat in so=ware development it is really sustained e:ort over timeand the degree to which customers can expect continuing invest-ment in the product that matters, not just how many people havethrown a bone in the pot and le= it to simmer.

There is something to this argument, to be sure; in fact, I havedeveloped the idea that expected future service value is the key tothe economics of so=ware production in The Magic Cauldron.

But this argument also has a major hidden problem; its implicitassumption that open-source development cannot deliver such sus-tained e:ort. In fact, therehavebeenopen-sourceprojects thatmain-tained a coherent direction and an e:ective maintainer communityover quite long periods of time without the kinds of incentive struc-tures or institutional controls that conventional management findsessential. The development of the gnu Emacs editor is an extremeand instructive example; it has absorbed the e:orts of hundreds ofcontributors over fi=een years into a unified architectural vision,despite high turnover and the fact that only one person (its author)has been continuously active during all that time. No closed-sourceeditor has ever matched this longevity record.

This suggests a reason for questioning the advantages of conven-tionally-managed so=ware development that is independent of therest of the arguments over cathedral vs. bazaar mode. If it’s possibleforgnuEmacs to express a consistent architectural visionoverfi=eenyears, or for an operating system like Linux to do the same over eightyears of rapidly changing hardware and platform technology; andif (as is indeed the case) there have been many well- architectedopen-source projects of more than five years duration – then we are

27

entitled to wonder what, if anything, the tremendous overhead ofconventionally- managed development is actually buying us.

Whatever it is certainly doesn’t include reliable execution bydeadline, or on budget, or to all features of the specification; it’sa rare ‘managed’ project thatmeets even one of these goals, let aloneall three. It also does not appear to be ability to adapt to changes intechnology and economic context during the project lifetime, either;the open-source community has proven far more e:ective on thatscore (as one can readily verify, for example, by comparing the thirty-year history of the Internet with the short half-lives of proprietarynetworking technologies – or the cost of the 16-bit to 32-bit transi-tion in Microso= Windows with the nearly e:ortless up-migrationof Linux during the same period, not only along the Intel line ofdevelopment but to more than a dozen other hardware platformsincluding the 64-bit Alpha as well).

One thing many people think the traditional mode buys you issomebody to hold legally liable and potentially recover compensa-tion from if the project goes wrong. But this is an illusion; most so=-ware licenses arewritten to disclaimevenwarranty ofmerchantabil-ity, let alone performance – and cases of successful recovery forso=ware nonperformance are vanishingly rare. Even if they werecommon, feeling comforted by having somebody to sue would bemissing the point. You didn’t want to be in a lawsuit; you wantedworking so=ware.

So what is all that management overhead buying?Inorder tounderstand that,weneed tounderstandwhat so=ware

developmentmanagers believe theydo. Awoman I knowwho seemsto be very good at this job says so=ware projectmanagement has fivefunctions:

1. To define goals and keep everybody pointed in the same direc-tion.

2. To monitor and make sure crucial details don’t get skipped.

3. To motivate people to do boring but necessary drudgework.

4. To organize the deployment of people for best productivity.

5. To marshal resources needed to sustain the project.

28 11 ON MANAGEMENT AND THE MAGINOT LINE

Apparently worthy goals, all of these; but under the open-sourcemodel, and in its surrounding social context, they can begin to seemstrangely irrelevant. We’ll take them in reverse order.

My friend reports that a lot of resource marshalling is basicallydefensive; once youhaveyourpeople andmachines ando?ce space,you have to defend them from peer managers competing for thesame resources, and higher-ups trying to allocate the most e?cientuse of a limited pool.

But open-source developers are volunteers, self-selected for bothinterest and ability to contribute to the projects they work on (andthis remains generally true even when they are being paid a salaryto hack open source.) The volunteer ethos tends to take care of the ‘at-tack’ side of resource-marshalling automatically; people bring theirown resources to the table. And there is little or no need for a man-ager to ‘play defense’ in the conventional sense.

Anyway, in a world of cheap pcs and fast Internet links, we findpretty consistently that the only really limiting resource is skilled at-tention. Open- source projects, when they founder, essentially neverdo so for want of machines or links or o?ce space; they die onlywhen the developers themselves lose interest.

That being the case, it’s doubly important that open-source hack-ers organize themselves for maximum productivity by self-selection –and the social milieu selects ruthlessly for competence. My friend,familiar with both the open-source world and large closed projects,believes that open source has been successful partly because its cul-ture only accepts the most talented 5% or so of the programmingpopulation. She spendsmost of her time organizing the deploymentof the other 95%, and has thus observed first-hand the well-knownvariance of a factor of onehundred inproductivity between themostable programmers and the merely competent.

The size of that variance has always raised an awkward question:would individual projects, and the field as a whole, be better o:without more than 50% of the least able in it? Thoughtful managershave understood for a long time that if conventional so=ware man-agement’s only function were to convert the least able from a netloss to a marginal win, the gamemight not be worth the candle.

The success of the open-source community sharpens this ques-tion considerably, byprovidinghard evidence that it is o=en cheaperand more e:ective to recruit self-selected volunteers from the Inter-

29

net than it is to manage buildings full of people who would ratherbe doing something else.

Which brings us neatly to the question of motivation. An equiva-lent and o=en- heardway to statemy friend’s point is that traditionaldevelopment management is a necessary compensation for poorlymotivated programmers who would not otherwise turn out goodwork.

This answer usually travels with a claim that the open-sourcecommunity can only be relied on to do work that is ‘sexy’ or techni-cally sweet; anything else will be le= undone (or done only poorly)unless it’s churnedoutbymoney-motivated cubiclepeonswithman-agers cracking whips over them. I address the psychological and so-cial reasons for being skeptical of this claim in “Homesteading theNoosphere”. For present purposes, however, I think it’s more inter-esting to point out the implications of accepting it as true.

If the conventional, closed-source, heavily-managed style of so=-ware development is really defended only by a sort of Maginot lineof problems conducive to boredom, then it’s going to remain viablein each individual application area for only so long as nobody findsthose problems really interesting and nobody else finds any wayto route around them. Because the moment there is open-sourcecompetition for a ‘boring’ piece of so=ware, customers are going toknow that it was finally tackled by someonewho chose that problemto solve because of a fascination with the problem itself – which, inso=ware as in other kinds of creative work, is a far more e:ectivemotivator than money alone.

Having a conventional management structure solely in order tomotivate, then, is probably good tactics but bad strategy; a short-term win, but in the longer term a surer loss.

So far, conventional development management looks like a badbet now against open source on two points (resource marshalling,organization), and like it’s living on borrowed time with respect toa third (motivation). And the poor beleaguered conventional man-ager is not going to get any succour from the monitoring issue; thestrongest argument the open-source community has is that decen-tralized peer review trumps all the conventional methods for tryingto ensure that details don’t get slipped.

Can we save defining goals as a justification for the overhead ofconventional so=ware project management? Perhaps; but to do so,we’ll need good reason to believe thatmanagement committees and

30 11 ON MANAGEMENT AND THE MAGINOT LINE

corporate roadmaps are more successful at defining worthy andwidely-shared goals than the project leaders and tribal elders whofill the analogous role in the open-source world.

That is on the face of it a pretty hard case to make. And it’s not somuch the open-source side of the balance (the longevity of Emacs, orLinus Torvalds’s ability to mobilize hordes of developers with talkof “world domination”) that makes it tough. Rather, it’s the demon-strated awfulness of conventionalmechanisms fordefining the goalsof so=ware projects.

One of the best-known folk theorems of so=ware engineering isthat 60% to 75% of conventional so=ware projects either are nevercompleted or are rejected by their intended users. If that range isanywhere near true (and I’ve nevermet amanager of any experiencewhodisputes it) thenmoreprojects thannot are being aimedat goalsthat are either (a) not realistically attainable, or (b) just plain wrong.

This, more than any other problem, is the reason that in today’sso=ware engineering world the very phrase “management commit-tee” is likely to send chills down the hearer’s spine – even (or perhapsespecially) if the hearer is a manager. The days when only program-mers griped about this pattern are long past; ‘Dilbert’ cartoons hangover executives’ desks now.

Our reply, then, to the traditional so=ware development man-ager, is simple – if the open-source community has really underes-timated the value of conventional management, why do so many ofyou display contempt for your own process?

Onceagain theexistenceof theopen-source community sharpensthis question considerably – because we have fun doing what we do.Our creative play has been racking up technical, market-share, andmind-share successes at an astounding rate. We’re proving not onlythat we can do better so=ware, but that joy is an asset.

Two and a half years a=er the first version of this essay, the mostradical thought I can o:er to close with is no longer a vision of anopen-source- dominated so=ware world; that, a=er all, looks plausi-ble to a lot of sober people in suits these days.

Rather, I want to suggest what may be a wider lesson about so=-ware, (and probably about every kind of creative or professionalwork). Human beings generally take pleasure in a task when it fallsin a sort of optimal-challenge zone;not so easy as tobeboring,not toohard to achieve. A happy programmer is one who is neither under-

31

utilized nor weighed down with ill-formulated goals and stressfulprocess friction. Enjoyment predicts e?ciency.

Relating to your own work process with fear and loathing (evenin the displaced, ironic way suggested by hanging up Dilbert car-toons) should therefore be regarded in itself as a sign that the pro-cess has failed. Joy, humor, and playfulness are indeed assets; it wasnot mainly for the alliteration that I wrote of “happy hordes” above,and it is no mere joke that the Linux mascot is a cuddly, neotenouspenguin.

Itmaywell turnout that oneof themost important e:ects of opensource’s successwill be to teachus that play is themost economicallye?cient mode of creative work.

12 Acknowledgements

This paper was improved by conversations with a large number ofpeoplewho helped debug it. Particular thanks to Je:Dutky <dutky@wam.umd.edu>,whosuggested the“debugging isparallelizable” for-mulation, andhelpeddevelop theanalysis thatproceeds fromit.Alsoto Nancy Lebovitz <nancyl@universe.digex.net> for her suggestionthat I emulateWeinberg by quoting Kropotkin. Perceptive criticismsalso came from Joan Eslinger <wombat@kilimanjaro.engr.sgi.com>and Marty Franz <marty@net-link.net> of the General Technics list.Glen Vandenburg <glv@vanderburg.org> pointeed out the impor-tance of self-selection in contributor populations and suggested thefruitful idea that much development rectifies ‘bugs of omission’;Daniel Upper <upper@peak.org> suggested the natural analogies forthis. I’m grateful to the members of plug, the Philadelphia LinuxUser’s group, for providing the first test audience for the first pub-lic version of this paper. Paula Matuszek <matusp00@mh.us.sbphrd.com> enlightened me about the practice of so=ware management.Phil Hudson <phil.hudson@iname.com> reminded me that the so-cial organization of the hacker culture mirrors the organization ofits so=ware, andvice-versa. Finally, LinusTorvalds’s commentswerehelpful and his early endorsement very encouraging.

32 13 FOR FURTHER READING

13 For Further Reading

I quoted several bits from Frederick P. Brooks’s classic The MythicalMan-Month because, in many respects, his insights have yet to beimprovedupon. I heartily recommend the 25thAnniversary editionfrom Addison-Wesley (isbn 0-201-83595-9), which adds his 1986 “NoSilver Bullet” paper.

The new edition is wrapped up by an invaluable 20-years-laterretrospective in which Brooks forthrightly admits to the few judge-ments in the original textwhich have not stood the test of time. I firstread the retrospective a=er the first public version of this paper wassubstantially complete, and was surprised to discover that Brooksattributes bazaar-like practices to Microso= ! (In fact, however, thisattribution turned out to be mistaken. In 1998 we learned from theHalloween Documents that Microso=’s internal developer commu-nity is heavily balkanized, with the kind of general source accessneeded to support a bazaar not even truly possible.)

Gerald M. Weinberg’s The Psychology Of Computer Programming(New York, Van Nostrand Reinhold 1971) introduced the rather un-fortunately-labeled concept of “egolessprogramming”.Whilehewasnowhere near the first person to realize the futility of the “principleof command”, he was probably the first to recognize and argue thepoint in particular connection with so=ware development.

Richard P. Gabriel, contemplating the Unix culture of the pre-Linux era, reluctantly argued for the superiority of a primitive ba-zaar-like model in his 1989 paper Lisp: Good News, Bad News, andHow To Win Big. Though dated in some respects, this essay is stillrightly celebrated among Lisp fans (includingme). A correspondentremindedme that the section titled “Worse Is Better” reads almost asan anticipation of Linux. The paper is accessible on the World WideWeb at http://www.naggum.no/worse-is-better.html.

De Marco and Lister’s Peopleware: Productive Projects and Teams(New York; Dorset House, 1987; isbn 0-932633-05-6) is an underap-preciated gem which I was delighted to see Fred Brooks cite in hisretrospective. While little of what the authors have to say is directlyapplicable to the Linux or open-source communities, the authors’insight into the conditions necessary for creative work is acute andworthwhile for anyone attempting to import some of the bazaarmodel’s virtues into a commercial context.

33

Finally, I must admit that I very nearly called this paper “TheCathedral and the Agora”, the latter term being the Greek for anopen market or public meeting place. The seminal “agoric systems”papers by Mark Miller and Eric Drexler, by describing the emer-gent properties of market-like computational ecologies, helped pre-pare me to think clearly about analogous phenomena in the open-source culture when Linux rubbedmy nose in them five years later.These papers are available on the Web at http://www.agorics.com/agorpapers.html.

14 Epilog: Netscape Embraces the Bazaar

It’s a strange feeling to realize you’re helping make history... .On January221998, approximately sevenmonths a=er Ifirst pub-

lished “The Cathedral and the Bazaar”, Netscape Communications,Inc. announced plans to give away the source for Netscape Commu-nicator. I had had no clue this was going to happen before the day ofthe announcement.

Eric Hahn, Executive Vice President and Chief Technology Of-ficer at Netscape, emailed me shortly a=erwards as follows: “Onbehalf of everyone at Netscape, I want to thank you for helping usget to this point in the first place. Your thinking and writings werefundamental inspirations to our decision.”

The following week I flew out to Silicon Valley at Netscape’s invi-tation for a day-long strategy conference (on Feb 4 1998) with someof their top executives and technical people. We designed Netscape’ssource-release strategy and license together.

A few days later I wrote the following:

Netscape is about to provide us with a large-scale, real-world test of the bazaar model in the commercial world.The open-source culture now faces a danger; if Netscape’sexecution doesn’t work, the open-source concept may beso discredited that the commercial world won’t touch itagain for another decade.

On the other hand, this is also a spectacular opportu-nity. Initial reaction to the move on Wall Street and else-where has been cautiously positive. We’re being given achance to prove ourselves, too. If Netscape regains sub-

34 14 EPILOG: NETSCAPE EMBRACES THE BAZAAR

stantial market share through this move, it just may seto: a long-overdue revolution in the so=ware industry.

The next year should be a very instructive and interest-ing time.

And indeed it was. As I write in mid-1999, the development ofwhat was later named ‘Mozilla’ has been only a qualified success.It achieved Netscape’s original goal, which was to deny Microso=a monopoly lock on the browser market. It has also achieved somedramatic successes (notably the release of the next-generationGeckorendering engine).

However, it has not yet garnered the massive development ef-fort from outside Netscape that the Mozilla founders had originallyhoped for. The problem here seems to be that for a long time theMozilla distribution actually broke one of the basic rules of thebazaar model; they didn’t ship something potential contributorscould easily run and see working. (Until more than a year a=er re-lease, buildingMozilla from source required a license for the propri-etary Motif library.)

Most negatively (from the point of view of the outside world) theMozilla grouphas yet to ship a production-quality browser – and oneof the project’s principals caused a bit of a sensation by resigning,complaining of poormanagement andmissed opportunities. “Opensource,” he correctly observed, “is not magic pixie dust.”

And indeed it is not. The long-term prognosis for Mozilla looksdramatically better now (in August 2000) than it did at the timeof Jamie Zawinski’s resignation letter – but he was right to pointout that going open will not necessarily save an existing project thatsu:ers from ill-defined goals or spaghetti code or any of the so=wareengineering’s other chronic ills. Mozilla has managed to provide anexample simultaneously of how open source can succeed and how itcould fail.

In the mean time, however, the open-source idea has scored suc-cessesand foundbackers elsewhere.1998and late1999sawa tremen-dous explosion of interest in the open-source development model,a trend both driven by and driving the continuing success of theLinux operating system. The trendMozilla touched o: is continuingat an accelerating rate.

35

15 Endnotes

[jb] In Programing Pearls, the noted computer-science aphoristJon Bentley comments on Brooks’s observation with “If you plan tothrow one away, you will throw away two.”. He is almost certainlyright. The point of Brooks’s observation, and Bentley’s, isn’t merelythatyoushouldexpectfirst attempt tobewrong, it’s that startingoverwith the right idea is usually more e:ective than trying to salvage amess.

[qr] Examples of successful open-source, bazaar developmentpredating the Internet explosion and unrelated to the Unix and In-ternet traditions have existed. The development of the info-Zip com-pression utility during 1990–1992, primarily for dos machines, wasone such. Another was the rbbs bulletin board system (again fordos), which began in 1983 and developed a su?ciently strong com-munity that there have been fairly regular releases up to the present(mid-1999) despite the huge technical advantages of Internet mailand file-sharing over local bbss. While the info-Zip community re-lied to some extent on Internet mail, the rbbs developer culture wasactually able to base a substantial on-line community on rbbs thatwas completely independent of the tcp/ip infrastructure.

[jh] John Hasler has suggested an interesting explanation for thefact that duplication of e:ort doesn’t seem to be a net drag on open-source development. He proposes what I’ll dub “Hasler’s Law”: thecosts of duplicatedwork tend to scale sub-qadraticallywith team size– that is, more slowly than the planning andmanagement overheadthat would be needed to eliminate them.

This claimactuallydoesnot contradictBrooks’sLaw. Itmaybe thecase that total complexity overhead and vulnerability to bugs scaleswith the square of team size, but that the costs from duplicatedworkare nevertheless a special case that scales more slowly. It’s not hardto develop plausible reasons for this, starting with the undoubtedfact that it ismuch easier to agree on functional boundaries betweendi:erentdevelopers’ code thatwill preventduplicationof e:ort thanit is to prevent the kinds of unplanned bad interactions across thewhole system that underly most bugs.

The combination of Linus’s Law and Hasler’s Law suggests thatthere are actually three critical size regimes in so=ware projects. Onsmall projects (I would say one to at most three developers) noman-agement structure more elaborate than picking a lead programmer

36 15 ENDNOTES

is needed. And there is some intermediate range above that inwhichthe cost of traditional management is relatively low, so its benefitsfromavoiding duplication of e:ort, bug-tracking, andpushing to seethat details are not overlooked actually net out positive.

Above that, however, the combinationofLinus’sLawandHasler’sLaw suggests there is a large-project range in which the costs andproblems of traditional management rise much faster than the ex-pected cost from duplication of e:ort. Not the least of these costsis a structural inability to harness the many-eyeballs e:ect, which(as we’ve seen) seems to do a much better job than traditional man-agement at making sure bugs and details are not overlooked. Thus,in the large-project case, the combination of these laws e:ectivelydrives the net payo: of traditional management to zero.

[hbs] The split between Linux’s experimental and stable versionshas another function related to, but distinct from, hedging risk. Thesplit attacks another problem: the deadliness of deadlines. Whenprogrammers are held both to an immutable feature list and a fixeddrop-dead date, quality goes out the window and there is likely acolossal mess in the making. I am indebted to Marco Iansiti andAlan MacCormack of the Harvard Business School for pointing meat evidence that relaxing either one of these constraints can makescheduling workable.

One way to do this is to fix the deadline but leave the feature listflexible, allowing features to drop o: if not completed by deadline.This is essentially the strategy of the “stable” kernel branch; AlanCox (the stable-kernel maintainer) puts out releases at fairly regularintervals, but makes no guarantees about when particular bugs willbe fixed or features back-ported from the experimental branch.

The other way to do this is to set a desired feature list and deliveronly when it is done. This is essentially the strategy of the “experi-mental” kernel branch. De Marco and Lister cited research showingthat this scheduling policy (“wake me up when it’s done”) producesnot only the highest quality but, on average, shorter delivery timesthan either “realistic” or “aggressive” scheduling.

I have come to suspect (as of early 2000) that in earlier versionsof this paper I severely underestimated the importance of the “wakemeupwhen it’sdone”anti-dealinepolicy to theopen-sourcecommu-nity’s productivity and quality. General experience with the rushedgnome 1.0 in 1999 suggests that pressure for a premature release

37

can neutralize many of the quality benefits open source normallyconfers.

It may well turn out to be that the process transparency of opensource is one of three coequal drivers of its quality, alongwith “wakeme up when it’s done” scheduling and developer self-selection.

[in] An issue related to whether one can start projects from zeroin the bazaar style is whether the bazaar style is capable of support-ing truly innovative work. Some claim that, lacking strong leader-ship, the bazaar can only handle the cloning and improvement ofideas already present at the engineering state of the art, but is un-able to push the state of the art. This argument was perhaps mostinfamously made by the Halloween Documents, two embarrassinginternal Microso= memoranda written about the open-source phe-nomenon.Theauthors comparedLinux’sdevelopmentof aUnix-likeoperating system to “chasing taillights”, and opined “(once a projecthas achieved “parity” with the state-of-the-art), the level of manage-ment necessary to push towards new frontiers becomes massive.”

There are serious errors of fact implied in this argument. Oneis exposed when the Halloween authors themseselves later observethat “o=en [...] new research ideas are first implemented and avail-able on Linux before they are available/incorporated into other plat-forms.”

If we read “open source” for “Linux”, we see that this is far froma new phenomenon. Historically, the open-source community didnot invent Emacs or the World Wide Web or the Internet itself bychasing taillights or being massively managed – and in the present,there is somuch innovativework going on in open source that one isspoiled for choice.Thegnomeproject (topickoneofmany) ispushingthe state of the art in guis and object technology hard enough tohave attracted considerable notice in the computer trade press welloutside the Linux community. Other examples are legion, as a visitto Freshmeat on any given day will quickly prove.

But there is amore fundamental error in the implicit assumptionthat the cathedral model (or the bazaar model, or any other kindof management structure) can somehow make innovation happenreliably. This is nonsense. Gangs don’t have breakthrough insights –even volunteer groups of bazaar anarchists are usually incapable ofgenuine originality, let alone corporate committees of people with asurvival stake in some status quoante. Insight comes from individuals.The most their surrounding social machinery can ever hope to do

38 15 ENDNOTES

is to be responsive to breakthrough insights – to nourish and rewardand rigorously test them instead of squashing them.

Some will characterize this as a romantic view, a reversion tooutmoded lone-inventor stereotypes. Not so; I am not asserting thatgroups are incapable of developing breakthrough insights once theyhave been hatched; indeed, we learn from the peer-review processthat such development groups are essential to producing a high-quality result. Rather I am pointing out that every such group de-velopment starts from – is necessarily sparked by – one good ideain one person’s head. Cathedrals and bazaars and other social struc-tures can catch that lightning and refine it, but they cannot make iton demand.

Therefore the root problem of innovation (in so=ware, or any-where else) is indeed how not to squash it – but, even more funda-mentally, it is how to grow lots of people who can have insights in thefirst place.

To suppose that cathedral-style development could manage thistrick but the low entry barriers and process fluidity of the bazaarcannotwould be absurd. If what it takes is one personwith one goodidea, then a socialmilieu inwhich one person can rapidly attract thecooperation of hundreds or thousands of others with that good ideais going inevitably to out-innovate any in which the person has todo a political sales job to a hierarchy before he can work on his ideawithout risk of getting fired.

And, indeed, if we look at the history of so=ware innovation byorganizations using the cathedral model, we quickly find it is ratherrare. Large corporations rely on university research for new ideas(thus the Halloween Documents authors’ unease about Linux’s fa-cility at coopting that research more rapidly). Or they buy out smallcompanies built around some innovator’s brain. In neither case isthe innovation native to the cathedral culture; indeed, many in-novations so imported end up being quietly su:ocated under the"massive level of management" the Halloween Documents’ authorsso extol.

That, however, is a negative point. The reader would be betterserved by a positive one. I suggest, as an experiment, the following:

– Pick a criterion for originality that you believe you can applyconsistently. If your definition is “I know itwhen I see it”, that’snot a problem for purposes of this test.

39

– Pick any closed-source operating systemcompetingwithLinux,and a best source for accounts of current development work onit.

– Watch that source and Freshmeat for one month. Every day,count the number of release announcements on Freshmeatthat you consider ‘original’ work. Apply the same definition of‘original’ to announcements for that other os and count them.

– Thirty days later, total up both figures.

The day I wrote this, Freshmeat carried twenty-two release an-nouncements, of which three appear they might push state of theart in some respect, This was a slow day for Freshmeat, but I will beastonished if any reader reports as many as three likely innovationsa month in any closed-source channel.

[egcs]Wehowhavehistory on aproject that, in severalways,mayprovide amore indicative test of the bazaar premise than fetchmail;egcs, the Experimental gnu Compiler System.

This project was announced inmid-August of 1997 as a consciousattempt to apply the ideas in the early public versions of “The Cathe-dral and the Bazaar”. The project founders felt that the developmentof gcc, the Gnu C Compiler, had been stagnating. For about twentymonths a=erwards, gcc and egcs continued as parallel products –both drawing from the same Internet developer population, bothstarting from the same gcc source base, both using pretty much thesame Unix toolsets and development environment. The projects dif-fered only in that egcs consciously tried to apply the bazaar tactics Ihave previously described, while gcc retained amore cathedral-likeorganizationwith a closed developer group and infrequent releases.

This was about as close to a controlled experiment as one couldask for, and the results were dramatic. Within months, the egcs

versions had pulled substantially ahead in features; better optimiza-tion, better support for fortran and C++. Many people found theegcs development snapshots to be more reliable than the most re-cent stable version of gcc, and major Linux distributions began toswitch to egcs.

In April of 1999, the Free So=ware Foundation (the o?cial spon-sors of gcc) dissolved the original gcc development group and o?-cially handed control of the project to the the egcs steering team.

40 15 ENDNOTES

[sp] Of course, Kropotkin’s critique and Linus’s Law raise somewider issues about the cybernetics of social organizations. Anotherfolk theorem of so=ware engineering suggests one of them; Con-way’s Law – commonly stated as “If you have four groups workingon a compiler, you’ll get a 4-pass compiler”. The original statementwas more general: “Organizations which design systems are con-strained to produce designs which are copies of the communicationstructures of these organizations.” We might put it more succinctlyas “Themeans determine the ends”, or even “Process becomes prod-uct”.

It is accordingly worth noting that in the open-source commu-nity organizational form and function match on many levels. Thenetwork is everything and everywhere: not just the Internet, butthe people doing the work form a distributed, loosely coupled, peer-to-peer network which provides multiple redundancy and degradesvery gracefully. In both networks, each node is important only to theextent that other nodes want to cooperate with it.

The peer-to-peer part is essential to the community’s astonishingproductivity. The point Kropotkin was trying to make about powerrelationships is developed further by the ‘snafu Principle’: “Truecommunication is possible only between equals, because inferiorsare more consistently rewarded for telling their superiors pleasantlies than for telling the truth.” Creative teamwork utterly dependson true communication and is thus very seriously hindered by thepresence of power relationships. The open-source community, ef-fectively free of such power relationships, is teaching us by contrasthowdreadfullymuch they cost in bugs, in lowered productivity, andin lost opportunities.

Further, the snafu principle predicts in authoritarian organiza-tions a progressive disconnect between decision-makers and reality,as more andmore of the input to those who decide tends to becomepleasant lies. The way this plays out in conventional so=ware devel-opment is easy to see; there are strong incentives for the inferiors tohide, ignore, and minimize problems. When this process becomesproduct, so=ware is a disaster.

(c) http://www.tuxedo.org/~esr/writings/cathedral-bazaar/

Set in 11pt urwAntiqua type by TEX.

August 22, 2001