Raymond distinguishes between two ways of managing a software project: the traditional "Cathedral" way, and the novel "Bazaar" way.
In the Cathedral way, the software is developed by a limited number of developers, released only when being very stable, and maintained without too much help from the outside.
In the Bazaar way, the software is released very often (often in a buggy state), tasks are delegated and contributions from the outside are welcome and often.
ESR attributes the "invention" of the Bazaar way to Linus Torvalds who used it to develop the Linux kernel, a core component of a critical system - the GNU/Linux operating system. (albeit acknowledges that it was used before for other projects)
In "the Cathedral and the Bazaar" he documents his experiences in developing and maintaining his own project Bazaar-style: the fetchmail POP-retrieval system.
2.2. How to start a Bazaar-style Project
"Every good work of software starts by scratching a developer's personal itch." (Necessity is the mother of invention)
ESR recommends looking for previous effort and building from there instead of re-writing your own system from scratch.
Raymond indeed found several tools that achieved part of what he wished to do (fetch E-mail messages using the POP protocol) and eventually settled on contributing to an existing one titled popclient written by Carl Harris.
Harris noted he lost interest in the project and kindly passed the maintainer's baton to Raymond. And so Eric started working on fetchpop.
2.3. The Users and how to Treat them
The standard "I'm not getting paid for doing this and so should not care what my users feel" mode of thinking is not a good one for an open-source developer.
Despite the fact that they don't pay you - you should pay attention to their comments and answer their questions kindly. They are your best asset.
Treating users like they are your co-developers will turn them into co-developers.
Nevertheless, the core developer will have to do a very large portion of the work himself, if he wishes his project to thrive. ("There is no such thing as a free lunch").
2.4. Release Early, Release Often
Make very frequent releases, even if you are not entirely positive that the code is bug-free. (just mark them as development releases)
More users find more bugs. Make sure you have as many of them as possible
2.5. Getting Ideas from Users
It is a good thing to have original ideas.
However, it is equally as good or even better to recognize good ones your users come with.
If you like an idea you came up with or was suggested to you - make sure you implement it in a future release.
"Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away."
2.6. Fetchmail Becomes a Category Killer
Eventually, popclient that was renamed to fetchmail in the course of its evolution became a "category killer".
"one of those classic programs that fills its niche so competently that the alternatives are not just discarded but almost forgotten."
Even after your software has become a category killer, there is still room for improvement, and you should still listen to your users and implement new features.
"The number of items on a project's To-do list always grows or remains constant" (my own invention)
2.7. Overcoming Brooks' Law
The Book "The Mythical Man-Month" by Fred Brooks was written in 1974 and a second edition was released in 1995, which included four new chapters.
The Book is considered a seminal work in the field of software engineering and team management.
It is basically a long list of problems a software project may encounter with solutions proposed for them. (some good, some partial)
Brooks' Law: adding more developers to a project increases the number of interactions that have to exist between them, and so the output does not increase linearly.
As ESR notes, Gerald Weiberg observed that in shops where developers were not territorial about their code, and encouraged others to look for bugs and correct them, output was drastically better.
That's why an open-source Bazaar-style project which is open for public scrutiny can advance much faster than a completely closed Cathedral-style project.
2.8. Final Notes about CatB
The "Cathedral and the Bazaar" was considered a ground-breaking work by the open-source community, and by many other software engineers who have read it.
Many projects switched to the Bazaar style and found an increase in productivity.
Still, some developers have not yet read CatB and use a mixture of Cathedral and Bazaar elements in managing their projects. When I read CatB in 2002 I regretted I had not fully read it earlier, as I was already full-way in developing and maintaining a mature project.
Many software shops, who cannot afford to fully open-source their code (from various reasons), have adopted some of the concepts put forth by CatB and also saw a boost to their productivity.
3. Homesteading the Noosphere
This document discusses the customs of the Open-Source Community and how hackers behave and projects are managed.
Homesteading the noosphere means taking control of uncharted territory in the sphere of ideas.
Due to the fact that computers are very cheap, common and powerful, the open-source hackers culture is essentially a "gift culture", as Anthropologists refer to it.
Such a culture does not have a lack of resources, and its members do not need to struggle to survive.
Instead, they are trying to increase their peer repute (which is by no means fame!), and so are trying to make better impressions on their peers.
This is done by producing or working on important open-source programs, which are distributed without charge.
3.2. The Lack of Project Niches
While there are plenty of projects out there, there is, however, a genuine lack of niches for projects.
Usually, a niche is soon dominated by a small number (sometimes even one) of successful projects which fill it, and no others are needed.
Hackers compete between themselves on these niches, as they are a conserved resource.
This is done in a very similar fashion to how its done in other non-computerized cultures, and the way it was enacted in John Locke's "Theory of Property".
3.3. The Lockean Property Theory
There are three ways to acquire land:
On the frontier, it is possible to acquire land by homesteading it - fencing it, protecting it and proclaiming it is yours.
Normal active real estate is transferred from one person to the other by transfer of title: voluntarily giving it to him.
A land that was abandoned can be claimed by adverse possession: moving in it, fencing it, etc.
3.4. Application to Projects
An active project can be passed on to another maintainer by the permission of its current maintainer.
An abandoned project is there for anyone to take it. (if the old developer lost interest, he is expected to allow anyone to try to take over)
An unfilled niche (the frontier) can be filled out by anyone who wishes to start a project.
The hacker culture thrives by gradually filling more and more unfilled niches.
3.5. Ego-lessness in the Hackers Community
While prestige is important to the Hackers community, prime hackers tend to be humble and self-deprecating.
This is done to give the impression that the maintainer of the project can judge other people's work, and is not too much impressed by his own work.
It is also done to give a sense of imperfection: "my project is perfect? No way! It cannot do x, y, and z". And soon patches that implement them are followed.
Similarly, hackers do not publicly criticize the competency of a peer as a programmer. They do not say: "he is a bad programmer". At most they say: "he writes bad code". (this is as opposed to the Academia where such criticism is common).
Also, no one says he is fixing "Richard Stallman's bugs" but rather "Emacs' bugs". You can say "Project X's code is wonderfully ugly" but you usually don't attribute it to its developers.
3.6. Rewards and Motivation
Raymond points to a study by Theresa Amabile that says that "The more complex the activity, the more it's hurt by extrinsic reward."
While "it may be economically smart to give performance bonuses to people who flip burgers or dug ditches", people who do creative work (like programmers) should be motivated by working on what they would like to do, and will not be effectively motivated by a salary bonus.
There is a big difference between "I'm giving you this reward because I recognize the value of your work" and "You're getting this reward because you've lived up to my standards."
Raymond concludes that programmers who hack on programs out of their own free will will necessary produce better results than those that are paid to do so.
"... it is exactly the recipe with which the open-source culture is now clobbering its competition."
4. The Magic Cauldron
In the Magic Cauldron, ESR "analyses the evolving economic substrate of the open-source phenomenon"
He explains why releasing a software as open-source and keeping the modifications open is a rational thing to do.
He also shows that the open-source world is "stable" (from the game-theoretical sense)
The open-source world creates useful values of good and increasing quality as if by magic.
There seems to be nothing that can stop this phenomenon, and no singular power that finances it.
Furthermore, everything is done voluntarily, and is distributed freely for everyone to use.
How is it possible?
4.2. Use Value and Sale Value
A software's use value is its economic value as a tool, a productivity multiplier.
A software's sale value is its value as a saleable commodity.
The vast majority of code (about %95) has no sale value: in-house software, embedded software, customizations of programs for the organization, hardware device-drivers or other hardware-assisting software.
Only a small amount of the code (which includes most of the open-source code out there) can be sold or distributed in some way.
Making your revenue stream dependant on sale value leads to many complications: you seek the most buyers (to maximize revenue) but the least actual users (to minimize support).
Once a market matures and sales slow down, most vendors will have no choice but to cut expenses by orphaning the product.
That's why commercial software does not correspond to the "Factory Model":
Most developer time is paid for by sale value.
The sale value of software is proportional to its development cost and to its use value.
A green held in common by a village of peasants who graze their cattle there.
Grazing degrades the commons which re-grow their cover only slowly.
Possible Outcomes:
No grass left
An actor using coercive enforcing an allocation policy on behalf of the village
The commons will break up as village members each handle and protect its own part.
The open-source world, on the other hand has an "inverse of the commons" model.
Widespread use of free software tends to increase its value, as users fold in their own fixes and features. (so grass grows taller when grazed upon)
Raymond notes that keeping a patch to oneself, or trying to profit from it does not makes sense economically, and the best way to benefit oneself is to contribute it and integrate it with the existing codebase.
4.4. Case Studies
In "The Magic Cauldron", ESR presents some case studies for real cases where releasing the source code under an open-source license was a rational decision, economically.
Here, I'll present some of them to give a taste of why "open source makes sense" sometimes.
The Apache web-server was started by a group of webmasters who decided to pool their efforts into improving one codebase.
It was more profitable than each maintaining his own version of a web-server , which would have resulted in many web-servers, each one with a limited and distinct functionality.
As a result, the Apache web-server became the most popular in the world, accounting for more domains than all other web-servers combined.
4.4.2. Zope : Give Away a Recipe, Open a Restaurant
Digital Creations, a web-design house had developed for building their sites a complex and powerful system (which is now known as Zope).
A venture capitalist they brought recommended they release it as open-source so it will be a critical advertising for Digital Creations real-asset: its people. I.e: people which will evaluate Zope would find it more efficient to hire the experts than to develop in-house Zope expertise.
It also made more people contribute to the Zope codebase.
As a result, Zope is now a successful, powerful and flourishing application server, with many third-party applications.
4.4.3. Doom : Becoming Open-Source at the Right Time
When the game "Doom" was released, it had ground-breaking technology and superior playability.
Keeping the source code of the engine for itself was an economically sound choice for i.d. software.
As similar engines came up (and i.d. improved upon their engine) the value of the Doom source code became very little.
It was then open-sourced under the GPL, as were subsequent game engines (such as Quake) and now i.d. is better off making money from selling game worlds for players to play in with this engine.
4.5. Business and Open-Source
Depending on open source software is a sounder choice than depending on proprietary one because you have the source and can do with it as you please.
In the ecology of the open source world, no node is indispensable. Developers can drop out, and distributors can fail, without it having a global effect on the ecology as a whole.
We can observe that some firms employ open-source developers (open R&D) for the sake of increasing the total number of units shipped, and by proportion their share of it.