This is a condensation of the book The Cathedral & The Bazaar by Eric S. Raymond. The book starts by using the metaphors of a cathedral and a bazaar for contrasting styles of software development, moving to preach the bazaar method, and delineating what exactly it involves.

Frequently it seemed to me as if this book was an attempt to concretise and systematise something which has happened quite naturally and perhaps even by accident in the pursuance of open source development. I am wary of thinking it as a ‘software development methodology,’ in a strict sense, but I think the book still provides some interesting points and reflections, as well as some fun history of open source projects. Of all the thoughts, the quote “given enough eyeballs, all bugs are shallow” has stuck with me particularly.

Cathedral:

  • Few developers, source available only to those between releases.
  • Bugs and development problems are tricky, insidious, deep phenomena.
  • Months of scrutiny by a few to develop confidence that it’s fixed.
  • Inevitable disappointment when the release is not perfect.

Bazaar:

  • Source available to all between release, anyone can make a submission
  • Release early and often
  • Speed
  • Different agendas
  • Assume bugs are generally shallow,

Project Management Tenets

Software project management has five functions:

  1. Define goals and keep everyone pointed in the right direction.
  2. Monitor and make sure crucial details don’t get skipped.
  3. Motivate people to do boring but necessary drudgework.
  4. Organise deployment of people for best productivity.
  5. Marshall resources needed to sustain the project.

Tenets for Bazaar-style Development

  1. Every good work of software starts by scratching a developer’s personal itch. - “Necessity is the mother of invention”
  2. Good programmers know what to write. Great ones know what to rewrite (and reuse)
  3. Plan to throw one away; you will, anyhow. - Often don’t understand the problem until you’ve first implemented the solution
  4. If you have the right attitude, interesting problems will find you.
    • When you lose interest in a program, your last duty is to hand it off to competent successor.
    • Treating your users are co-developers is your least-hassle route to rapid code improvement and debugging.
    • Relase early, release often. And listen to your customers.
    • Given a large enough beta-tester and co-developer base, almost every problem will be characterised quickly and the fix obvious to someone.
      • “Given enough eyeballs, all bugs are shallow”
      • The person who finds the problem isn’t usually the person who fixes it
      • Delphi effect: opinion of a mass of equal observers is more reliable than a single observer. Bazaar contributors are self-selected.
      • More users find more bugs.
  5. Smart data structures and dumb code works a lot better than the other way round.
  6. If you treat your beta testers as if they are your most valuable resource, they will be.
  7. The next best thing to having good ideas is recognising good ideas.
  8. Often, the most striking and innovative solutions come from realising that your concept of the problem was wrong
  9. Perfection is not achieved when there is nothing more to add, but rather when there is nothing more to take away.
  10. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
  11. When writing gateway software, take pains to disturb the data stream as little as possible. And never throw away data unless forced.
  12. When your language is not Turing-complete, syntactic sugar can be your friend.
  13. A security system is only as secure as its secret. Beware of psuedo-secrets.
  14. To solve an interesting problem, start by finding a problem that is interesting to you.
  15. Provided the coordinator has a medium as good as the Internet, and knows how to lead without coercion, many heads are better than one.

Example case

Eric Raymond ran a project in this spirit with the following process:

  1. Wanting a feature in a POP client
  2. Looking for the client which most closely resembled the one he wanted
  3. Implemented features.
  4. fetch-pop inferior base, found pop-client which was better (more professional but missing some difficult features). Throw away already completed work for better base?

Additional Comments

  • Release early and often
  • Add everyone who contacted him to beta list
  • Chatty announcements to beta list encouraging people to participate
  • Poll beta testers about design decisions
  • Egoless programming: “when developers are not territorial about their code, and encourage other people to look for bugs and potential improvements in it, improvements happen faster than anywhere else.”
  • Use the example of Linux VS Hurd
  • egoboo, free market in
  • Open source communities can put more skilled time into a problem
  • Future service value is key to the economics of software production
  • More effective to recruit self-selected volunteers from the Internet than it is to manage buildings full of people who would rather be doing something else.
  • Joy is an asset. Enjoyment predicts efficiency.