Reflection: "The Cathedral and the Bazaar"

Our assignment for the first of February was the read The Cathedral and the Bazaar by Eric Steven Raymond.  For those of you who have never heard of this essay, it's about closed versus open-source software and Raymond's journey through the creation of an open-source project called Fetchmail.


First off, I would like to say that I really enjoyed reading this essay.  The way it was written seems quite similar to what Dr. Bowring is asking us to do for this class, which is to write this blog and use it to publish our experiences during the semester.  If you read it online as I did, you can see a revision history for the essay (the last revision was done 11 years ago).  I liked being able to see that because it shows that Raymond really did go through the development process.  He didn't simply publish an essay and leave it alone.  He went back, maybe cleaned it up a bit, added to it--not unlike what programmers do with coding in open-source projects.


In the essay, Raymond gives 19 rules or lessons that he learned along the way about developing open-source projects.  Since there are so many, I'm only going to share the ones that struck me the most (although you should go read the essay to find out about the rest).


1.  "Every good work of software starts by scratching a developer's personal itch."
Think about it.  Every little program, piece of software, application--all the popular ones anyway--are the result of a developer's personal itch.  Why are they so popular?  It's simple: the good works of software shows in the effort put into the coding.  When the program is something that you know will be beneficial to your needs (and then possibly the needs of others) you put more time and effort into what you're doing, and it shows.


5.  "When you lose interest in a program, your last duty is to hand it off to a competent successor."
This one seems like a no-brainer to me.  As a developer, even if you lose interest in a program you will still want to see it succeed.  After all, you helped bring it to life.  It's only natural to want to find someone capable of carrying on in your place.  If the next developer isn't competent the program dies.  Simple as that.


8.  "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone."
This rule was one Raymond dubbed "Linus's Law" after Linus Torvald, the software engineer who initiated the development of the open-source Linux kernel.  The author described it as follows:
"In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect. In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena—or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door."
Basically, Raymond says it has the Delphi Effect--"the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than the opinion of a single randomly-chosen one of the observers". This is also the principle behind Wikipedia and why it has thrived and grown in popularity.