The Cathedral and the Bazaar takes its title from an essay Raymond read at the 1997 Linux Kongress. The essay documents Raymond's acquisition, re-creation, and numerous revisions of an e-mail utility known as fetchmail. Raymond engagingly narrates the fetchmail development process while elaborating on the ongoing bazaar development method he uses with the help of volunteer programmers. The essay smartly spares the reader from the technical morass that could easily detract from the text's goal of demonstrating the efficacy of the open-source, or bazaar, method in creating robust, usable software.
Once Raymond has established the components and players necessary for an optimally running open-source model, he sets out to counter the conventional wisdom of private, closed-source software development. Like superbly written code, the author's arguments systematically anticipate their rebuttals. For programmers who "worry that the transition to open source will abolish or devalue their jobs," Raymond adeptly and factually counters that "most developer's salaries don't depend on software sale value." Raymond's uncanny ability to convince is as unrestrained as his capacity for extrapolating upon the promise of open-source development.
In addition to outlining the open-source methodology and its benefits, Raymond also sets out to salvage the hacker moniker from the nefarious connotations typically associated with it in his essay, "A Brief History of Hackerdom" (not surprisingly, he is also the compiler of The New Hacker's Dictionary). Recasting hackerdom in a more positive light may be a heroic undertaking in itself, but considering the Herculean efforts and perfectionist motivations of Raymond and his fellow open-source developers, that light will shine brightly. --Ryan Kuykendall --This text refers to the Hardcover edition.
From the Publisher
About the Author
Eric Raymond is an Open Source evangelist and author of the highly influential paper "The Cathedral and the Bazaar".
Excerpt. © Reprinted by permission. All rights reserved.
Indistinguishable From Magic
Beyond Geeks Bearing Gifts
The Manufacturing Delusion
The "Information Wants to be Free" Myth
The Inverse Commons
Reasons for Closing Source
Use-Value Funding Models
Why Sale Value is Problematic
Indirect Sale-Value Models
When to be Open, When to be Closed
Open Source as a Strategic Weapon
Open Source and Strategic Business Risk
The Business Ecology of Open Source
Coping with Success
Open R&D and the Reinvention of Patronage
Getting There From Here
Conclusion: Life after the Revolution
Afterword: Why Closing a Drivers Loses Its Vendor Money
Indistinguishable From Magic
In Welsh myth, the goddess Ceridwen owned a great cauldron that would magically produce nourishing food--when commanded by a spell known only to the goddess. In modern science, Buckminster Fuller gave us the concept of "ephemeralization", technology becoming both more effective and less expensive as the physical resources invested in early designs are replaced by more and more information content. Arthur C. Clarke connected the two by observing that "Any sufficiently advanced technology is indistinguishable from magic".
To many people, the successes of the open-source community seem like an implausible form of magic. High-quality software materializes "for free", which is nice while it lasts but hardly seems sustainable in the real world of competition and scarce resources. What's the catch? Is Ceridwen's cauldron just a conjuring trick? And if not, how does ephemeralization work in this context--what spell is the goddess speaking?
Beyond Geeks Bearing Gifts
The experience of the open-source culture has certainly confounded many of the assumptions of people who learned about software development outside it. Chapter 3, The Cathedral and the Bazaar described the ways in which decentralized cooperative software development effectively overturns Brooks's Law, leading to unprecedented levels of reliability and quality on individual projects. Chapter 4, Homesteading the Noosphere examined the social dynamics within which this "bazaar" style of development is situated, arguing that it is most effectively understood not in conventional exchange-economy terms but as what anthropologists call a "gift culture" in which members compete for status by giving things away. In this essay I begin by exploding some common myths about software production economics; then continue the line of analysis of these essays into the realm of economics, game theory and business models, developing new conceptual tools needed to understand the way that the gift culture of open-source developers can sustain itself in an exchange economy.
In order to pursue this line of analysis without distraction, we'll need to abandon (or at least agree to temporarily ignore) the "gift culture" level of explanation. Chapter 4 posited that gift culture behavior arises in situations where survival goods are abundant enough to make the exchange game no longer very interesting; but while this appears sufficiently powerful as a psychological explanation of behavior, it lacks suffiency as an explanation of the mixed economic context in which most open-source developers actually operate. For most, the exchange game has lost its appeal but not its power to constrain. Their behavior has to make sufficient material-scarcity-economics sense to keep them in a gift-culture-xsupporting zone of surplus.
Therefore, this essay will consider (from entirely within the realm of scarcity economics) the modes of cooperation and exchange that sustain open-source development. While doing so it will answer the pragmatic question "How do I make money at this?", in detail and with examples. First, though, I will show that much of the tension behind that question derives from prevailing folk models of software-production economics that are false to fact.
(A final note before the exposition: the discussion and advocacy of open-source development in this essay should not be construed as a case that closed-source development is intrinsically wrong, nor as a brief against intellectual-property rights in software, nor as an altruistic appeal to "share". While these arguments are still beloved of a vocal minority in the open-source development community, experience since Chapter 3 was published has made it clear that they are unnecessary. An entirely sufficient case for open-source development rests on its engineering and economic outcomes--better quality, higher reliability, lower costs, and increased choice.)
The Manufacturing Delusion
We need to begin by noticing that computer programs like all other kinds of tools or capital goods, have two distinct kinds of economic value. They have use value and sale value.
The use value of a program is its economic value as a tool. a productivity multiplier. The sale value of a program is its value as a salable commodity. (In professional economist-speak, sale value is value as a final good, and use value is value as an intermediate good.)
When most people try to reason about software-production economics, they tend to assume a "factory model" which is founded on the following fundamental premises:
Most developer time is paid for by sale value.
The sale value of software is proportional to its development cost (i.e., the cost of the resources required to functionally replicate it) and to its use value.
In other words, people have a strong tendency to assume that software has the value characteristics of a typical manufactured good. But both of these assumptions are demonstrably false.
First, code written for sale is only the tip of the programming iceberg. In the pre-microcomputer era it used to be a commonplace that 90% of all the code in the world was written in-house at banks and insurance companies. This is probably no longer the case--other industries are much more software-intensive now, and the finance industry's share of the total must have accordingly dropped--but we'll see shortly that there is empirical evidence that approximately 95% of code is still written in-house.