Book Review #2: Raymond – The Cathedral & The Bazaar


The Cathedral and the Bazaar by Eric Raymond is an examination of the culture behind the Open Source (OS) movement. In the 1970’s Brooks Law was developed, which stated that adding more developers to a late project only makes the project later. Before Linux was proven successful, it was unfathomable to most software industry insiders that such a large number of volunteer developers could produce a complex, reliable piece of software like an operating system. From his position inside the OS movement, Raymond set out to identify the specific reasons that the OS community was able to organize itself well enough to develop software that was more reliable than that of tightly-controlled corporate software development divisions.

Raymond describes the OS community as a “gift culture” (p. 80). In a gift culture, status is earned not by accumulation of wealth or strength, but by how much is given away. How much a programmer is able to give away also depends on the skills they have developed, their ability to solve problems creatively, and their ability to work collaboratively with others.

The difficulty of expressing emotions accurately over the internet has led to a respect for humility within the OS community. Boasting is frowned upon, in favor of allowing individuals’ work to speak for itself. A programmer who works steadily at mundane but necessary tasks, while occasionally throwing in a flash of creativity, earns more respect than the originator of a significant project who then brags about it.

There are a number of specific concepts that make the OS community effective. One adage is “Given enough eyeballs, all bugs are shallow” (p. 30). Bugs in complex applications can be subtle and nondeterministic. The OS community has attracted a large number of users who are also able to describe bugs in a way that is helpful to the core developers. A user may report “The program closed unexpectedly when I opened a jpeg file, and it seems to relate to a file type declaration at line x in source file y”. A developer can fix this much more quickly than a developer on a closed source project who only hears from a user, “The program closed unexpectedly when I opened a jpeg file.” Also, a difficult bug might be easy for 3 in 1000 developers; having a large number of developers makes it more likely that someone on the development team will know how to fix each bug that comes along. It might not always be the same developer who fixes all the difficult bugs, but these bugs will likely match someone’s skill set.

Raymond lists five conditions for deciding whether an open source solution may be developed for a given situation:

  1. Reliability/ stability/ scalability are critical.
  2. Correctness of design and implementation cannot readily be verified by means other than independent peer review.
  3. The software is critical to the user’s control of his/ her business.
  4. The software establishes or enables a common computing and communications infrastructure.
  5. Key methods (or functional equivalents of them) are part of common engineering knowledge. (p. 146)

These criteria provide a solid framework for evaluating whether to keep a piece of software closed or make it open, and for deciding whether it is reasonable to pay for a piece of closed source software or whether funding an OS solution might be better.

Educational Relevance

First of all, reading The Cathedral and the Bazaar makes me want to program again! As a competent programmer who will never work full-time as a developer, the OS community is perfect for me. I can contribute meaningfully to an existing project based on my skill set, or I can develop a project and let others more proficient in certain aspects of programming polish the project. This is a great context in which to apply my strengths, a deep understanding of educational issues and a competent understanding of software development.

While enjoying the cultural and historical parts of the book, the list of criteria mentioned above is one of the most significant pieces I will take away from this reading. Let’s apply this reasoning to the problem of managing student data at the class, school, and district level. What we want is a reliable, customizable, secure database program that will allow us to track student learning. In Sitka, this is currently handled by Schoolmaster. Schoolmaster is a proprietary program, and districts pay for software licenses and support contracts to use it. The educational problem that Schoolmaster addresses, how to handle student data, meets all the criteria for an OS solution. The reliability, stability, and security of a program that handles sensitive student data is critical. With such a large program and a large number of users, it seems difficult for a small development team to iron out all bugs before a major release. The proper handling of data is critical for day-to-day educational functioning. New York City famously sent thousands of students to summer school unnecessarily one year due to an incorrect electronic scoring system on a city-wide benchmark exam. A common communication structure in the handling of student data would ease the transitions of students between school districts, even between vastly different parts of the country. Finally, it is doubtful that the ways SchoolMaster addresses the problem of managing student data is so profound that they are the only ones able to engineer an effective solution to the problem.

How do we make an OS solution to the problem of managing student data at various levels? This is a perfect situation for Richard Stallman’s proposed ‘software tax’. A federally-sponsored development project would allow schools to spend their money on tech support people rather than on a Schoolmaster contract. These people would be able to handle the administration of an OS student data management system in much the same way that server technicians administer Apache. But rather than be limited to supporting just Schoolmaster-related tasks, they would also be able to contribute to supporting other technical solutions in the district as well. None of this would necessarily put SchoolMaster out of business. If they accept the open solution, their people are in a position to develop expertise in the new system quickly. If Schoolmaster fights the OS solution, they run the serious risk of serving a dwindling user base. At some point, Raymond argues, it becomes quite feasible that the MIS person for a publicly traded company becomes liable when their company becomes overly dependent on a proprietary solution that is critical to fundamental operations. In a similar manner, district decision makers will not be looked upon favorably if their choice of a proprietary data management causes the district to become overly dependent on one company’s solution. Raymond also points out that it is critical for businesses to realize when it is right to open up their own software solutions. Open up too early, and competitive advantage is given away before a strong market position can be established. Open up too late, and your market position is taken over by an OS solution provider.

The OS community thrived in early academic computing. It sputtered when software companies threw gobs of money at star developers in the university labs in the 70s and 80s. The community regrouped in spectacular form in the 90s to develop Linux. This success has not yet been realized in education. Open source educational technology is a field ripe for fresh thinking, thinking that applies the ideas that led to the success of Linux to technological solutions in education.

One Response to “Book Review #2: Raymond – The Cathedral & The Bazaar”

  1. Skip Says:

    One issue with education (and many others) adopting OS software is the arcane way in which it is often delivered and the need to understand a fair amount of jargon in order to even know what to download. Sourceforge is a wonderful resource, but “This project provides pre-build GIMP application bundles for Intel and PPC Macs and tools for building GIMP on Mac OS X easily.” Easily? Really?

    Ubuntu (and I suppose EdUbuntu, which I have not investigated yet) is a wonderful step in the right direction. Still, even the automatic updates are filled with jargon that make the whole process intimidating. It’s likely (and supported in your review) that this is because the folks that are looking at and working in OS are programmers. They communicate with each other as programmers and sometimes forget that they need to communicate with a public that doesn’t care (or doesn’t know) whether or not their software is OS as long at it installs easily and does what it says it does. Apple figured this out long ago, and a great example of this is the typical installer–drag an icon to your Apps folder. All of the complicated stuff happens out of sight. Plus, they’ve figured out how to take OS resources (BSD, Apache, etc.) and make a usable system. Again, people don’t know (or care) if the underpinnings of Mac OS are open source–it just works consistently.

    I hope the some of the fresh thinking that you mentioned will be directed toward the end user experience in education. They’re often the least technologically literate group of all, and the group that could most benefit from a thoughtful application of OS tools.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: