reading 07: the bazaar
The bazaar model of software development is certainly superior to the cathedral model. If we liken programming to music, then the bazaar model would be a band that creates their own music and the cathedral model would be musicians who are asked to play pieces that someone else wrote. There is, of course, beautiful music in both cases, but the bazaar-style band is where it all starts: the members all build off of each other and pour their heart and time into creating something new and worthy of praise. And, if it’s good enough, then maybe some other musicians will learn it and be inspired to use it as a starting point for something new.
I believe that the most crucial principle that ESR enumerates is the first: “Every good work of software starts by scratching a developer’s personal itch.” We’ve all been a part of that project where the interest isn’t there, and we’ve all seen (or been lucky to be a part of) the project that goes above and beyond simply because there is passion. Ultimately, the cathedral model works because people have their job on the line, but the bazaar style lets the creative juices flow and paves the way for great software to be written.
I also found ESR’s second point very interesting: “Good programmers know what to write. Great ones know what to rewrite (and reuse).” There’s no need to start from scratch on every project when there are a lot of good starting points that exist. In fact, in many of my classes we will work an example in class that has many things in common with the homework. To ignore such parallels might even be a disgrace to the professor. The one problem with such an approach, however, is potentially lacking a complete understanding of the code so that more time is wasted down the road when one runs into problems.
One thing that seemed strange to me at first was ESR’s claim that “one cannot code from the ground up in bazaar style.” In other words, “your nascent developer community needs to have something runnable and testable to play with.” People need to see a program that can eventually be developed into something great. (And, as ESR describes, Mozilla suffered by lacking this at first.) I think that the underlying assumption here is that the bazaar style isn’t meant to accomodate huge changes at once. Rather, it fosters an environment where lots of lots of small changes amount to something tremendous over time. This is even seen in the development of Fetchmail that ESR describes.
As we go into the second half of the semester, I will be thinking in particular about a personal itch that I want to scratch, or at least an interesting problem to solve. I don’t want to be in a position where I want to pass off my third project to a competent successor. I think the coolest thing might be to contribute to an open-source project that I like. It’d be nice to have maintain a PKGBUILD on the AUR one day, or to join the band of contributors to Mozilla. I feel as though there’s a lot to learn in the broad and growing field of computer science, but it’s always fun to surprise myself to see what I can learn and contribute with a little interest and inspiration.