Day 8 Reading Summary and Reflections

Today's readings for the Open Source Usability course discuss the software practices and methodologies used in the open source community and include:

1. The Cathedral and the Bazaar
2. A Case Study of Open Source Software : The Apache Project
3. Two Case Studies of Open Source Software : Apache and Mozilla

The Cathedral and the Bazaar is an essay written by Eric Raymond which chronicles his efforts in developing Fetchmail which is a mail client that retrieves mail from a mail sever and delivers it to your local workstation. It discusses some of the principles which guide open source development, and his experience running this open source project. More importantly it contrasts two starkly different development models : The Cathedral Model (popularized by Fred Brooks in the Mythical Man Month), which can be seen in many closed source
development efforts, as well as the Bazaar Model, which is seen in many open source projects, most notably the Free operating system Linux.

Raymond argues that fundamentally there are two ways of thinking about building software. One method called the Cathedral method,is the idea that you begin with one carefully planned design for the software system and slowly but surely build the software to meet the design specifications (similar to the careful designand building of a gothic Cathedral). The Bazaar model, which Eric Raymond mentions is more fluid, model, where ideas and prototypes rule, and constant iteration and rework can make up for the lack of careful design and planning at the beginning of the project. This model encourages people to tinker with the ideas and its transparency encourages people to spot errors in code, faster than with a traditional design,build,test, release software lifecycle model.

If you implement a solution for the first time you typically don't have enough information to design and develop the solution as well as it ideally should be. However, once you've developed the solution once and have an understanding of the underpinnings, it's best to throw away the rough and unnuanced solution for one more nuanced. The Bazaar model takes advantage of this fact.

If we compare and contrast how debugging, an integral part of the overall lifecycle of software
is done in the Cathedral as well as the Bazaar models of development, we can see differences
that make the finding of bugs easier in one model than in the other. In the Cathedral model of software development a limited number of people are responsible for testing and repairing bugs in a production system. In addition, even though users may notice symptoms of bugs (i.e. that certainly functionality doesn't work as expected), they have limited ability to report and work on finding a resolution of the issue, as source code is not transparent. In the Bazaar model the opposite is true, many users have access to the code, and hence can quickly work to find the issues causing the bugs they experience by simply looking at the code and debugging it. As a result, solid software can be rapidly produced in a Bazaar model of development, as there are more eyeballs not only using the system, but looking at the code and testing the solution,
thanks to the added transparency.

Eric Raymond argues that with the Bazaar model of development, as can be seen in many open source projects, many of the laws and limits that Fred Brooks states in the Mythical Man Month, simply do not exist. The reason he argues is because the assumptions that Fred Brooks,
while it may apply for traditional software development methodologies (i.e. closed source models), such as the need for constant networked communication do not hold true in the open source model where many people can work independently on large projects. I found this argument the most interesting, as the Open Source model seems to be breaking conventinal wisdom in software development. A lot of large scale development projects that were thought difficult if not impossible software engineering feats due to the complexity and the number of people that need to be involved to complete the task are getting done well in the open source model. It seems to me that the open source model of development is breaking fundamental
limits that you see in traditional organizational efforts.

So what are the necessary preconditions to develop software in the Bazaar model? Software can never efficiently begin in the Bazaar model, Raymond argues. Instead there must be some work done by the originator of the project, and this work results in a software project that is released in the open source world. It must not fail to run and it must convince potential contributors that the idea can be evolved into something neat for the foreseeable future. Eric Raymond calls this the plausible promise, and the originator uses this promise to build a strong following, and hopefully a strong community of developers who want to work on the project. Once a critical mass has been built up of co-developers for the project, one can begin to think that there software is entering the Bazaar so to speak. Successful Bazaar projects also require a competent (and only a competent) level of skill of contributors in the area of design, development and debugging. Anymore skill and the project can become overly complex due to the cleverness of the contributor, or alternatively inadequacy due to the incompetency of those making contributions to the project.

I've taken the 19 principles stated in the Cathedral and the Bazaar essay and have categorized them into themes that relate to software management:

The Beginning of FOSS Projects:

• Every good work of software starts by scratching a developer's personal itch.

• To solve an interesting problem, start by finding a problem that is interesting to you.

• If you have the right attitude, interesting problems will find you

Development and Testing:

• Good programmers know what to write. Great ones know what to rewrite (and reuse).

• Release early. Release often. And listen to your customers.

• Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

The Open Source Community:

• If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.

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

• When you lose interest in a program, your last duty to it is to hand it off to a competent successor.

• Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

• Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

Design Related Principles

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

• Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.

• Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.

• Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.

• When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!

• When your language is nowhere near Turing-complete, syntactic sugar can be your friend

• A security system is only as secure as its secret. Beware of pseudo-secrets.

• Plan to throw one away; you will, anyhow

We've compared and contrasted two methodologies used in the development of software, a monolithic model of software development, and a more fluid model of software development. Now that we've looked at the theory, let us take a look at how the theory of open source development works in practice on open source projects, taking the Apache and Mozilla projects as cases of open source development to study as well as some commercial software using traditional development processes and see how they stack up (as discussed in the second and third articles to read for today):

While many proponents of the open source development model make the claim that this model is radically different than traditional development models, in fact there is a lot of similarity between these two models. Successful open source projects, such as Apache, or Mozilla use revision control (i.e. CVS in the case of Apache), bug tracking tools (i.e. Bugzilla in the case of Mozilla), and other tools that traditional development methods also take advantage of.

A major difference between traditional co-located development methods and the open source model is the fact that a lot of open source projects have users geographically distributed around the world. There are advantages and disadvantages to this fact. A major disadvantage is that it can be very difficult to get face to face conversation and discussion that you would find in a co-located work environment. An advantage of this method is that most all communication occurs online which allows conversations to be recorded and used later in decision making and planning processes. Another advantage of the open source model is that it is easier to find open source developers globally who want to work on your project, instead of limiting contributors to one geographical region. It is also important to note that there are typically several methods of communicating with members of a particular open source project, and some methods are more preferred to other methods (for instance typically e-mail mailing lists are preferred to newsgroups and bug databases in the case of Apache).

Another important question to consider is how work is divided up in open source projects, especially seeing as there may be hundreds if not thousands of contributors. While each open source method may have its own method, in the Apache project, a modular architecture allows for development work to be more easily separated out to a particular developer, in that way the developer can mark their territory of the open source project. While contributors are encouraged to contribute their work to the project, the contributor's reputation is considered before the code is accepted and/or committed to code, with founders and contributors with seniority given free reign in committing code to the project. The paper also notes that contributors tend to resolve issues and add new capabilities on areas of the project they have created or contributed to when they began. In addition, maintainers of a particular aspect of the project, typically will hand over control of the project to other contributors when the project no longer interests them. Conflict on an issue in the project, or more precisely how to resolve an issue, is resolved by members of the community voting. This is probably not the best way to resolve issues, as studies from the Harvard Business School have shown that negotiating resolutions yields better results than a simple vote.

The studies also seemed to point that for any open source project there are typically a small number of people (10 to at most 25) who make most of the contributions to the open source project. On the other hand there are a large number of people who issue problem reports. This seems to indicate that not even open source projects can tackle the diseconomies of scale that occur when you have a large number of people working on a project. However, the papers appear to indicate that through modularity and other software engineering techniques the power of a large group of developers can be effectively harvested.

Finally the report also compared three different development platforms, a commercial development platform for telecommunication software, an entirely open source development model (Apache) and a hybrid of commercial and open source development (Mozilla). It would appear that the open source development model was the most effective of the three in terms of measurable data and results, with the hybrid coming in a close second and commercial software falling behind in terms of productivity in last place.