Each of Eric Raymond's three essays describes a different facet of the open source movement. In "The Cathedral and the Bazaar", Raymond describes the method of starting and running open source projects and the technical advantages of the bazaar style of software development. In "Homesteading the Noosphere", Raymond describes the values and culture of the society out of which the open source movement has risen. Finally, in "The Magic Cauldron", Raymond details the ways in open source software can be made economically viable.

"The Cathedral and the Bazaar" is the most straightforward of Raymond's essays. It's a combination of rules to follow when starting and maintaining an open source project, some advice on software engineering, and reasons why open source is a good idea from a technical standpoint. Several of the major points include: good software fills a need for the software's developer; reuse code if possible, as it is much easier to start with an initial code base to use as a scaffolding rather than starting from scratch; treat your customers as developers, release early and often, and listen to your customers, all of which relate to the simple point that the more people looking at the code, the faster bugs will be found and fixed; and finally, recognize when someone else has a good idea. These, I think, were the most important to his argument for the open source approach to building software, because they all either describe a rule for maintaining a project, describe a benefit of the open source approach, or describe a software engineering rule which the open source approach makes easier to follow. My only criticism of this particular essay was that I don't think some of his rules were necessary to include. For instance, the idea of creating a throw-away piece of code just to get a feel for the problem. This is a very good point, and one very central to software engineering, but this applies just as well to the closed source approach as to the open source approach, and open source approach is no more conducive to this method than is the closed source approach.

"Homesteading the Noosphere" is an ethnography of the open source community. It details the various ideologies of hackers; the contrast between the open source licenses and the actual practices of the members of the open source community, in particular the reluctance to fork projects; and the idea of ownership in the open source community. The central argument of this essay, however, is the idea of the open source community as a gift culture. The argument is that because there is an overabundance of processing time, memory, disk space, etc., hackers cannot form a society around scarcity economics, in which the people in power are those who control the resources. Instead, a hacker in the open source community gains reputation through "gift giving", i.e., writing open source code, debugging open source code, and writing documentation for open source code. How much a hacker's reputation improves depends on the "value" of the gift. Creating an open source project, particularly a what Raymond calls a "category killer", which is a piece of software so useful for a particular purpose that it becomes the only software used for that purpose, is worth a lot. Creating a new and innovative project is better than imitating an already existing closed source project, although both are worth quite a bit. Extending, debugging, and writing documentation for a project are worth less than starting a project of one's own, but are still valuable contributions to the open source community. Debugging, particularly, can become worth quite a bit if one manages to fix a great deal of bugs. While this particular essay has some very interesting observations about hacker culture, and in particular the open source community, Raymond also makes some very serious mistakes. One which struck me in particular was his misuse of Maslow's hierarchy of values to support his claim that it is a chance to gain reputation, and not the "joy of hacking", which is what drives the open source community. The "joy of hacking" is not, as Raymond claims, a transcendence need. When a person reaches this level of Maslow's hierarchy, that person becomes so selfless that he or she is willing to give up even his or her most basic needs in order to help humankind. Gandhi and Martin Luther King, Jr. are examples of people who reached this level; a hacker who enjoys writing code has not. In fact, the "joy of hacking" is just that, it's something a person does for fun and excitement. This need, in fact, falls lower in Maslow's hierarchy than does the need for esteem. Thus, if we are to follow Maslow's theory, it would in fact be the "joy of hacking" which would be the primary drive for members of the open source community, and not the need for esteem! It is mistakes such as these which lead me to question the validity of some of Raymond's analysis of the open source community. Still, overall, I do think he makes some valuable points, and this essay is particularly important because it is the first attempt to describe the culture of the open source community.

Finally, "The Magic Cauldron", which asserts that software should be a service industry, not a manufacturing industry, and then goes on to describe ways to make money from software under this assertion. He makes several good points about why software should be a service industry; I was particularly impressed by the fact that only 5% of programmers actually work on software which is meant to be sold. He also does a fairly good job of giving examples of when it is a good idea for source to be closed, and when it is a good time to open up source that was closed. Some of his ideas for making money are also good. Some of his ideas for profit-making, such as giving away the software but selling support, and giving away client software for a particular service and then selling subscriptions to that service, seem like very good ideas. Others, such as selling t-shirts and mugs, or selling a brand, seemed much less viable, in the first case simply because I doubt it would generate enough revenue (although it would work well in addition to selling support or selling subscriptions), and in the second simply because I don't believe many companies would buy a brand just to prove they are compliant (take Microsoft, which does its best to be non-compliant to standards whenever possible; its court battle with Sun over extending Java is a perfect example of the problem with this idea). Overall, however, I think Raymond does an effective job of showing that a successful economic model can be built around open source software.