Reading: Cathedral and the Bazaar

by Chris F

As I sit here, listening to Daft Punk, I ponder what I too from Eric Steven Raymond’s “The Cathedral and the Bazaar”. It’s a text that I’ve heard about before, while at ITO, and one that both Peter and Rob have recommended I read. Following their advice, I decided to do just that. So, what have I learned after this 40-page read?

First, I’d like to start with a summary. This paper contains 19 of Raymond’s teaching for advocating open-source software development. Here they are:

  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 [version] away; you will, anyhow. (Copied from Frederick Brooks’ The Mythical Man Month)
  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.
  6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
  7. Release early. Release often. And listen to your customers.
  8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
  9. Smart data structures and dumb code works a lot better than the other way around.
  10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
  11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
  12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
  13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. (Attributed to Antoine de Saint-Exupéry)
  14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
  15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
  16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
  17. A security system is only as secure as its secret. Beware of pseudo-secrets.
  18. To solve an interesting problem, start by finding a problem that is interesting to you.
  19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

Most of these apply to computer programming, but there are a few that are of use to employers and business owners in general, and those are the ones that refer to ways of motivating your programmers or opening up the source of your program to the community. There are also a few of them which apply to designers, like the one which urges you to listen to other people as well, because their ideas might be great and you could use them, or discussion with others will trigger something in you which will become a great idea. It’s interesting that this paper mentions this, because without knowing about it, I was talking about the same thing in my 2012 start-of-the-year talk at UCS.

It was an interesting but tedious read for me, because other than the really good teachings that I mention above, it talks about a software development project using Linux. It’s great to see the iterations that his software went through, and understand how development works within the open-source community, but it seemed very familiar and akinto what we do at the Computer Games Design course when we use the AGILE methodology. We iterate and release often, listen to feedback from our users, and reiterate based on it, which makes me think that AGILE is derived from this method of development and delivery.

It’s a great source for understanding why open-source development is great, and the lessons are interesting, but that’s about all that I got from reading it.

Other than the quotes from above, the thing that I found most interesting in this paper was an annex at the end of the paper, a sort of revision, that was made a few years after the original release of the paper, after the guys from Netscape decided to release the source for their browser which ended up to be what we now know as Mozilla (whose Firefox happens to be the browser I am writing this on at the moment). It seems that they had some really big problems at the beginning, because Netscape still clung unto the Cathedral model too much, releasing stuff only when they believed it was done, which Raymond says it’s at the same time a great example of how awesome open-source development can be and how can it fail. Like we all know at the moment, the Mozilla project was highly successful, with their browser being in the top 3 most used browsers in the world, and the Mozilla Foundation working at the moment on the release of their phones and mobile operating system, as well as developing a tablet. The quote that got to me, and that, again, I’m glad I have found because I can now quote it properly instead of saying “I thought of this” (which, as we all know, is not permitted in an academic environment), is that “Open-source is not magic pixie dust” (Mozilla project principal, after resigning). This is what I keep talking about when people tell me that gamification will revolutionize the world. Yes, just like open-source software, the possibility exists and it’s there, but it’s not magical. It requires quite a lot of work and achieving what I call “high gamification” in order to have a successful gamification model. Just like with any other game, it takes time, iterations and testers in order to have it become good.

Hopefully, over the course of the year, I will be able to prove this to be true.

Chris F.

Bibliography
Raymond, E.S. 2010. Cathedral and the bazaar. La Vergne, TN: [SnowBall Publishing].

Advertisements