Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword or section
Like this
0Activity
P. 1
Cath Baz

Cath Baz

Ratings: (0)|Views: 6|Likes:
Published by David_Week_1459

More info:

Published by: David_Week_1459 on Aug 11, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

03/18/2014

pdf

text

original

 
The Cathedral and the Bazaar
Eric Steven Raymond
cf text and copyright at:
 www.tuxedo.org/~esr/writings
 AbstractI anatomize a successful open-source project, fetchmail, that was 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 then make asustainedargumentfromtheLinuxexperiencefortheproposi-tionthat“Givenenougheyeballs,allbugsareshallow”,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 by magic out of part-time hacking by several thousand developers scat-tered all over the planet, connected only by the tenuous strands of the 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 THROUG
lutionary programming for years. But I also believed there was acertain critical complexity above which a more centralized, a prioriapproach wasrequired. I believed that the most important so
=
 ware(operating systems and really large tools like the Emacs program-ming editor) needed to be built like cathedrals, carefully cra
=
ed by individual 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 babbling  bazaar of di
ering agendas and approaches (aptly symbolized by the Linux archive sites, who’d take submissions from
 anyone
) out of  whichacoherentandstablesystemcouldseeminglyemergeonlyby a 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 confusion but 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 arethingsIfirstlearnedintheLinuxworld,butwe’llseehowtheLinux worldgivesthemparticularpoint.IfI’mcorrect,they’llhelpyouun-derstand exactly what it is that makes the Linux community such afountainofgoodso
=
 wareand,perhaps,theywillhelpyoubecomemore 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)
 in WestChester,Pennsylvania.Ico-founded
ccil
andwroteouruniquemultiuserbulletin-boardso
=
 wareyoucancheckitoutbytelnetting 
 
3to
 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 having toperiodicallytelnetoverto
locke
tocheckmymailannoying.WhatIwantedwasformymailtobedeliveredonsnark(myhomesystem)sothatIwouldbenotifiedwhenitarrivedandcouldhandleitusinall my local tools.TheInternet’snativemailforwardingprotocol,
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 needed wasaprogramthatwouldreachoutovermyintermittentdialupcon-nection and pull across my mail to be delivered locally. I knew suchthingsexisted,andthatmost ofthemusedasimpleapplicationpro-tocol called
 pop
 (Post O
?
ce Protocol).
 pop
 is now widely supported by 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 it wasmissingwhatseemedanobviousfeature,theabilitytohacktheaddresses on fetched mail so replies would work properly.The problem was this: suppose someone named ‘joe’ on
 locke
sent me mail. 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-editingreplyaddressestotackon‘@ccil.org’quicklygotto 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
=
 waredevelopersspendtheirdaysgrindingawayforpayatprogramstheneither 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.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->