Part 1 – The cathedral vs. bazaar models of software development

In the Cathedral and the Bazaar, so and so outlines two different frameworks in which software can be developed. The cathedral model he presents is more conventional, and represents a closed process where a smaller, insular group of developers work in isolation to create some large potentially splendid project. The author originally held the conventional wisdom that more complex and intricate software projects could only be reliably developed in this cathedral-esque manner. Releases only happen after a long amount of heavily directed development has taken place, typically without the release of a beta.

The bazaar model, in contrast, corresponds to projects are open-sourced, where the code base is available to a large audience holding “many different agendas and approaches”. With such a large and diverse set of eyes looking at and working on the code, bugs are found fast and development can take place at a rate much greater than projects that lack the same transparency, such as cathedrals.

I think that as a beginner, the idea of working in a cathedral environment sounds initially more appealing. I feel that, given my relatively limited knowledge, I would benefit greatly from the direction that inevitably comes from such a structured project. However, although it would be more uncomfortable from the outset, I’m sure that working in a bazaar environment would provide a more diverse set of voices upon which there are lessons to be drawn.

Part 2 – 2 Lessons from the Cathedral and the Bazaar

“Smart data structures and dumb code works a lot better than the other way around.”

-(http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s06.html)

I think this “lesson” struck me more than some of the others because it felt like advice that I will have occasion to follow pretty frequently and is a lesson I’ve learned by experience in some of my past programming experiences. It was also interesting because it seemed a little counterintuitive given some of the larger themes in which the author was writing. I could be taking some of what was being said out of context, having smart data structures seems to require some degree of forward planning.

Obviously an open-source project, in spite of featuring a more flexible and dynamic development process, depends on considerable amount of forethought to be done effectively. Still, the fact that the author was explicit in emphasizing the importance of this specific kind of planning indicates that there might be some tendencies that naturally arise in an open-source setting might not be the most productive to the end goal and need to be consciously avoided.

“The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.”

-(http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s07.html)

This quote also struck me as something I learned first-hand in my coding experience. Although not a completely analogous situation, I’ve found that when at a loss as to where to take a project or how to deal with a development hurdle, it’s always been better to talk over project requirements with the eventual end-user and see if their input can lead you from the weeds.

Even more generally, it’s an effective mindset in that it helps to demystify the process of having novel and good ideas. If you outsource not just development, but also broader ideas, to the userbase, there’s nothing to lose because at worst you just end up with some ideas you can easily ignore.