Reading 06: Illusive Bazaars

Before addressing the superiority of either the cathedral or bazaar models of software development, I think it is important to state up front that my experience in the bazaar model is limited at best. I think this lack of exposure is an inherent part of an academic computer science curriculum for two reasons. First, an education is (at least in some early stage) instructional. ESR himself admits on page 58 that the bazaar development model works because the top 5% of programmers have selected themselves into the activity. An early undergraduate classroom is not where those 5% are sitting. Additionally, there’s an element of discernment and investigation that has to happen in a young hacker’s journey, where they come to find what aspect of computing truly interests them. By the knowledge curve alone, a hacker might not progress to the material that invigorates them until the later part of their education where upper-level, challenging classes become available. As ESR points out, a hacker won’t contribute to a project they find boring, and it is probably the case that most students early on are bored, so why would they hack? Second, the academic model is not particularly well-suited to the sustained, collaborative work that characterizes the bazaar. There is material to teach and modules to get through, so really the only way work can be done is by building mini cathedrals in short blitzes. The structure and vision imposed by a professor on a project is what ensures that a student is exposed to and learns to use new tools. Additionally, the bazaar model is the absolute antithesis of anything resembling an academic honor code. All this to say, I really haven’t experienced the bazaar model. If at all, the closest I have come was the research office I worked at over the summer.

One of the things I loved about this office, and a big reason I am going back, is that the structural hierarchy was low to minimal. There was me, a manager, a manager, and then the organization’s director. This meant that I got to interact with employees on other teams, and while I wasn’t necessarily involved (just trying to keep my head above water on the project I had joined) I found that many people contributed to projects across teams through shared git repos. It was awesome! People could scratch down new ideas or obsess over optimizations however much they wanted, even though they were technically tied to a single project they were responsible for delivering. What made this even better was that some of the developers had experience as or were currently doing the roles of the customers we were developing products for. As ESR explains, a big part of open-source success is that users are co-developers and so optimizations and additional features are more or less obvious to the developer pool. And in our conversation in class about how open-source is bad about developing user applications, I reflected on my experience over the summer and realized why. Hackers don’t care about putting features in word processors or social media photo sharing apps. Generally, these products’ user bases are the layman, and so they will never be good for open-source because they won’t have the dedicated, expansive dev pool that the bazaar model requires; there’s not enough interest. I saw this first hand at my internship. We served technical customers really well because we understood each-other and they could come test and give reasonable feedback and suggestions. General users often talked right by us and vice versa.

So as for the ‘superior’ model, I would say it depends. It’s a lot like the problem of underproduced public goods in the free market in economic analysis. When there’s a public good that isn’t necessarily profitable, but which society needs (like power) the government has step in to subsidize or provide the service. Open-source is the future of software development for the things that open-source communities find interesting and want to supply. The other stuff, which non-technical audiences might want, will become cathedral projects because they have to be completed by generally uninterested or less productive programmers working on projects the open-source community deemed boring and therefore would not supply themselves.