Week 2: Reaction to "The Cathedral and the Bazaar"

In the article, "The Cathedral and the Bazaar" by Eric Raymond, the author discusses how he used his own open-source project, fetchmail, in an attempt to parallel Linux's development history and to test some theories about software engineering. He discusses these theories from two distinct perspectives, one that he calls the "cathedral" model, which represents the commercial world of software development, and a dichotomous view that he refers to as the "bazaar" model, representing the Linux world of software development. Raymond argues that these opposing models come from two very different assumptions about the software debugging process.

I agree that these two models approach software debugging from different perspectives. The bazaar model views software bugs as "shallow" and software problems to be transparent, whereas the cathedral-building model views bugs as "deep" and difficult to trace. There appears to be a number of socio-economic forces that influence the reasons for these two opposing perspectives.

The cathedral-building style of commercial software development is typically characterized by small to medium sized teams working on a large project in terms of a structured software development process, e.g., analysis, design, development, testing, debugging, documentation, and deployment. Often in large scale projects, these tasks are separated among different work units. In this model, the leadership style of the project manager is usually authoritative and tasks are delegated to subordinates. Software developers often work on projects where they have little or no interest in the end result. In a cathedral-building scenario, software is released infrequently with the goal being "perfect" software. This stems from the broader business goals of profit maximization and customer satisfaction through "bug-free" software.

In contrast, the mantra of the bazaar model is "release early, release often". This strategy serves two important purposes. Firstly, it reduces the duplication of debugging work because bug "fixes" are quickly propagated back into the next release. Secondly, it perpetuates interest and developer motivation in the project because code contributors are able to see the results of their efforts and they receive recognition from their peers within the community through feedback. Within this model, developers tend to be motivated and committed to the project because they have a vested interest in the outcome; the software serves an important functional and practical purpose to them. In many instances, hackers are also users of the software too.

The bazaar model loosely adopts a sociological approach known as the Delphi Method and incorporates it in its approach to debugging. Raymond refers to this as Linus' Law and says that "Given enough eyeballs, all bugs are shallow." In effect, the bazaar model harnesses the expertise of a software project's large community to fix bugs and resolve software issues.

The leadership style in the bazaar model is that of a project coordinator. Rather than delegate tasks and set time-lines for project targets, the project coordinator attracts the interest of software users and developers by effectively communicating the project's potential and by fostering a sense of community around a project.

Each model appears to be sound given the appropriate context. I think that a software development process, such as an Agile Software Development framework for software engineering is a better model for commercial software development in instances when requirements are newly emerging and rapidly changing rather than the cathedral-building model described by Raymond. Some of the principles of agile software development include customer satisfaction through rapid, continuous delivery of useful software, close cooperation between business people and developers, projects built around motivated individuals, the existence of self-organizing teams, and regular adaptation to changing circumstances.

The bazaar model appears to require certain preconditions to exist to be successful in an open source software development context. One precondition is a large pool of software users and developers with the desire to collectively solve software problems that are of interest to them. Another important precondition is the existence of a coordinator who can form a sustainable community by rewarding the egos of developers and by capturing and maintaining interest in the project through the effective communication of their vision.