The Cathedral and the Bazaar
The Cathedral and the Bazaar
Version 3.0 Copyright (c) 2000 Eric S. Raymond. Permission is granted to copy, distribute and/or modify this document under the terms of the Open Publication License, version 2.0.The Cathedral and the BazaarThe Mail Must Get ThroughThe Importance of Having UsersRelease Early, Release OftenHow Many Eyeballs Tame ComplexityWhen Is a Rose Not a Rose?Popclient becomes FetchmailFetchmail Grows UpA Few More Lessons from FetchmailNecessary Preconditions for the Bazaar StyleThe Social Context of Open-Source SoftwareOn Management and the Maginot LineEpilog: Netscape Embraces the BazaarNotesBibliographyAcknowledgements
Book Excerpt
neral commitment to a cathedral-building style of development. If the overriding objective was for users to see as few bugs as possible, why then you'd only release a version every six months (or less often), and work like a dog on debugging between releases. The Emacs C core was developed this way. The Lisp library, in effect, was not-because there were active Lisp archives outside the FSF's control, where you could go to find new and development code versions independently of Emacs's release cycle [QR].
The most important of these, the Ohio State Emacs Lisp archive, anticipated the spirit and many of the features of today's big Linux archives. But few of us really thought very hard about what we were doing, or about what the very existence of that archive suggested about problems in the FSF's cathedral-building development model. I made one serious attempt around 1992 to get a lot of the Ohio code formally merged into the official Emacs Lisp library. I ran into political trouble and was largely unsucces
Editor's choice
(view all)Popular books in Computers, Post-1930, Philosophy
Readers reviews
0.0
LoginSign up
Be the first to review this book