Monday, November 5, 2007

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.

1 comment:

Steven said...

We are a truly global product development firm that partners with software product companies ranging from start-ups to established ISVs to provide software product life cycle solutions. We have worked with more than 50 software product companies in various domains like Education, Healthcare, Retail and Finance. Our wide-ranging experience has enabled us to build a strong product environment within the company that remains unmatched in the industry. If you are looking for any software development services, let us know, click link and just fill up the form. Our experts will get back to you within 1 business day.