The Cathedral and the Bazaar

The Cathedral and the Bazaar

1. Development styles

   • Cathedral Model
     • Most important software
       • Carefully crafted
       • With no beta to be released prematurely
     • Bugs and development problems are
       • Tricky
       • Insidious
       • Deep phenomena
     • Long release intervals
   • Bazaar Model
     • Linux community
       • Differing agendas and approaches
         • Symbolized by the Linux archive sites
     • Bugs are generally shallow phenomena
       • Release often in order to get more corrections
         • Less to lose if an occasional botch gets out the door

2. The Mail Must Get Through

   • Lessons learned
     • #1 Every good work of software starts by scratching a developer’s personal itch
     • #2 Good programmers know what to write. Great ones know what to rewrite (and reuse)
     • #3 Plan to throw one away; you will, anyhow
     • # 4 If you have the right attitude, interesting problems will find you
     • # 5 When you lose interest in a program, your last duty to it is to hand it off to a competent successor

3. The Importance of Having Users

   • Properly cultivated
     • They can become co-developers
   • They can be effective hackers
     • Shortening debugging time
   • Lesson #6
     • Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging

4. Release Early, Release Often

   • Lesson #8
     • Given enough eyeballs, all bugs are shallow
   • Delphi effect
     • Averaged opinion of a mass of equally expert observers
       • Is quite a bit more reliable a predictor
         • Than that of a single randomly-chosen one of the observers
   • More users find more bugs
     • Adding more users adds more different ways of stressing the program
   • Linus
     • Was releasing a new kernel more than once a day
       • Cultivated his base of co-developers
       • Leveraged the Internet for collaboration harder than anyone else
       • Versions are numbered

5. When Is A Rose Not A Rose ?

   • Eric S. Raymond
     • Added imap support
     • Fetchmail
       • Learned how to forward fetched mail to the smtp port
     • Tested his theory about what Linus Torvalds had done right
       • Released early and often
       • Grew his beta list
       • Sent chatty announcements to the beta list whenever he released
       • Listened to his beta testers
   • Lesson #9
     • Smart data structures and dumb code works a lot better than the other way around
   • Lesson #10
     • If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource

Images and files in the map