Reading 06: The Cathedral and the Bazaar
Since I’ve never really worked on an open source project before, I can’t say for sure that I’ve gotten the full experience of the bazaar. But also I feel like since my internships so far have had a very startup-y feel to them, with producing working products being just as if not more important than the typical corporate hierarchical structure, I also haven’t really gotten the full cathedral experience either. I mean, I know that I, as a person, usually prefer to have more structure, but that’s mostly because I feel like most of the code I write is garbage, and the thought of it having little to no review before being implemented is terrifying.
If I think in terms of group projects I have had in my college career so far, then the bazaar is the kind of project where each group member has a vague idea what we are doing, our parts kind of depend on each other but not really, and it takes a lot of effort at the end to make sure all of our work lines up to make a decent project. On the other side, a cathedral would be a project where we have usually picked a leader to make the big decisions, and we have to spend a ridiculous amount of time planning beforehand before we even start coding to make sure we all know for sure what we’re doing. Now, since we’re college students the planning is never as rigorous as it should be, but I can definitely say that I’ve worked with both kinds of groups so far. And, as working in a group tends to go, both methods seem to be equally stressful. In a bazaar-style group, we all start out with completely different visions of what the end product will be, and as we get down to the wire, it’s difficult to resolve these visions into a completed project. On the other hand, the cathedral style often feels limiting, and not only is it hard to suggest a new feature once the planning has been done, if you forget to add something necessary to the project, usually no one catches it until, like, the night it’s due. So again, I can’t say for sure which one is superior because just working with other people in any context can be extremely infuriating, even though it’s a necessary part of creating anything, not just usable code.
Ultimately, I don’t know if the superiority of development comes down to “cathedral vs. bazaar” as must as it depends on communication. Cathedrals have a more rigid structure where the plan of action is fully communicated to everyone, but if it doesn’t allow for the moving parts to communicate to each other to allow for course-correction and improvements, then it’s just going to consist of bland coders churning out bland code. The bazaar allows for more voices to be heard on a semi-equal level, but if those voices aren’t also listening to each other, then nothing significant is going to get accomplished and the project won’t be cohesive. So I think each model has its merits and pitfalls, and it’s the implementation of each that affects the successful execution of a product.
