The first release of Linux in September 1991 was initially downloaded by ten people. Five sent back bug fixes. By 1993, there were an estimated 20,000 Linux users worldwide, with about 100 contributing to the code.¹⁹

Eric Raymond points to the “massively-parallel peer review” as one of the key components to successful open-source projects.²⁰ And Linus Torvalds is credited with the maxim explaining, “Many eyes make all bugs shallow.”²¹

And those eyes include not just programmers, but an entire community of varying interests, skill levels, and backgrounds. Developer and author Forrest Cavalier identified the following three types of participants in open-source communities.²²

• The need-driven consumer: The largest part of any active open-source community is users who participate because the software solves a problem or fulfills a need. Users may report bugs, but they may not be be programmers and they may not be able to or interested in fixing them.
• The user-developer: User-developers—Raymond describes them as co-developers—may contribute code or documentation, as well as participate in discussion and advocacy. Their motivation, according to Cavalier, “may be to have fun, learn, make a contribution, or even get something that fulfills a need of use.”²³
• The core developer: A small corps of participants will be actively developing and advancing a project. The Linux kernel is managed by a group of six core developers (Torvalds + 5); Mullenweg credits a team of fewer than ten people with leading WordPress development. Core developers may change over time, but they shoulder the bulk of the work of advancing the project and fixing bugs identified elsewhere in the community.

Licensing a project under the GPL will make it open source, but a project needs a community to use and support it for it to be successful. Like financial markets, open-source communities are most efficient when there are large numbers of participants.²⁴ Cavalier, responding to Raymond's “Bazaar,” was particularly interested in the “effective size” of the community or bazaar:

The “effective size” of a bazaar: The total of the number of participants motivated and able to contribute the results of individual effort (modifications, enhancements) or provide feedback to the bazaar for a specific activity.

“Specific activity” is very important to effective size. Bazaars may have very large effective sizes for some activities and not others. For example, a bazaar with a size of 5000 may only have an effective size of 5 (or even less than 1) for an unpopular activity such as documentation or regression testing. This may be due to lack of motivation or inability to contribute. (Many bazaar efforts are volunteer efforts.)²⁵

In offering an academic explanation of the open-source development model, Joseph Feller and Brian Fitzgerald agreed:

Users are a critical feature, serving as coders, testers, documenters, and also providing prompt notification of new requirements.²⁶

Software evolves. Well, software that lasts evolves. SWISH became Swish-e, b2 became WordPress, and Apache continues to be patched and extended to serve new needs.

This evolution is essential to meeting our changing needs, and the GPL promotes evolvability by protecting the right of any participant in the community to solve a problem in a program. Active communities effectively emulate organic evolution in the code they produce, often testing different solutions in parallel and selecting the most fit bits of code for each new release. And if the community can't agree on the most fit solution, communities can split, as happened when a new group of programmers rejected WordPress and began work on the original b2 code with a project called b2evolution.

Still, some software is more amenable to evolution than others. Writer and NYU professor Clay Shirky found that some systems, especially those promised to be the next “industry standard,” are too large and unwieldy to evolve. Writing in 1996 on the evolution of the Web and HTML, Shirky noted:

Evolvable systems—those that proceed not under the sole direction of one centralized design authority but by being adapted and extended in a thousand small ways in a thousand places at once—have three main characteristics that are germane to their eventual victories over strong, centrally designed protocols.

• Only solutions that produce partial results when partially implemented can succeed. The network is littered with ideas that would have worked had everybody adopted them. Evolvable systems begin partially working right away and then grow, rather than needing to be perfected and frozen. Think VMS vs. Unix, cc:Mail vs. RFC-822, Token Ring vs. Ethernet.
• What is, is wrong. Because evolvable systems have always been adapted to earlier conditions and are always being further adapted to present conditions, they are always behind the times. No evolving protocol is ever perfectly in sync with the challenges it faces.
• Finally, Orgel's Rule, named for the evolutionary biologist Leslie Orgel—“Evolution is cleverer than you are.” As with the list of the Web's obvious deficiencies above, it is easy to point out what is wrong with any evolvable system at any point in its life. No one seeing Lotus Notes and the NCSA server side-by-side in 1994 could doubt that Lotus had the superior technology; ditto ActiveX vs. Java or Marimba vs. HTTP. However, the ability to understand what is missing at any given moment does not mean that one person or a small central group can design a better system in the long haul.

Centrally designed protocols start out strong and improve logarithmically. Evolvable protocols start out weak and improve exponentially. It's dinosaurs vs. mammals, and the mammals win every time. The Web is not the perfect hypertext protocol, just the best one that's also currently practical. Infrastructure built on evolvable protocols will always be partially incomplete, partially wrong and ultimately better designed than its competition.²⁷

Software follows many of the same rules. Apache may not be the best Web server for every use, but its flexible architecture and constant evolution continue to attract a large number of developers who would rather live with—and perhaps fix—the limitations than look elsewhere.

WordPress's Matt Mullenweg hardly hesitates before answering. “You have to be the most passionate user—passionate to the point of obsession,” he offers.²⁸

Eric Raymond suggests, “Every good work of software starts by scratching a developer's personal itch,” adding, “To solve an interesting problem, start by finding a problem that is interesting to you.”²⁹

To explain the social context of open-source development, Raymond repeats a quote found in Gerald Weinberg's Psychology of Computer Programming. The quote is from Memoirs of a Revolutionist, the autobiography of Pyotr Alexeyvich Kropotkin, a nineteenth-century Russian anarchist:

Having been brought up in a serf-owner's family, I entered active life, like all young men of my time, with a great deal of confidence in the necessity of commanding, ordering, scolding, punishing and the like. But when, at an early stage, I had to manage serious enterprises and to deal with [free] men, and when each mistake would lead at once to heavy consequences, I began to appreciate the difference between acting on the principle of command and discipline and acting on the principle of common understanding. The former works admirably in a military parade, but it is worth nothing where real life is concerned, and the aim can be achieved only through the severe effort of many converging wills.³⁰

Raymond goes on:

To operate and compete effectively, hackers who want to lead collaborative projects have to learn how to recruit and energize effective communities of interest in the mode vaguely suggested by Kropotkin's “principle of understanding.”³¹

While problems may get solved by people who care enough to solve them, open-source communities build around participants that are passionate about solving a problem. With no means of applying the traditional management techniques or coercion, leaders in the open-source world emerge based on the passion for a project.