do not stand alone, pointing instead to many other articles. Similarly, OSS projects make it easier to create software by composition, as they are “ nonrival” (in the economic sense^{3, 28})—that is, the consumption of software by one person or project does not make it less available for consumption by another, unlike, say, apples or gasoline, which, once consumed, require additional resources so an equivalent resource may be consumed by another consumer. For example, Linux is a mashup, beginning as an operating system kernel, and owes much of its implementation to a composition with another OSS project—the GNU operating system. This practice of composing OSS is so widespread that the Apache project has created a tool— Maven—for understanding and managing the many transitive dependencies that arise in such projects. ¹⁷

Conflicting, unknowable requirements. While iterative life cycles accept that requirements change, they still operate under the assumption that, in any given iteration, a team might still want to collect and analyze these requirements. However, requirements in a crowdsourced system emerge from its participants operating independently. For example, the requirements for the redesigned server architecture and APIs in Apache came from a single core team developer. ² Requirements for Wikipedia articles and Facebook applications come from individual authors and application developers. As a consequence, requirements in a crowdsourced system are never globally “knowable” and therefore inevitably overlap or even conflict, just as the requirements of a city’s inhabitants often conflict; for example, some are pro-development, some want more green space, some want public money for public transit, and some want more highways. Many OSS projects use a voting or moderator process to mediate conflicts, ¹⁶ but in some crowdsourced systems conflicts (such as similar but competing periphery-created add-ons within Firefox) are simply tolerated.

Continuous evolution. As a consequence of having constantly changing requirements and distributed resources, a crowdsourced system is never “done” and hence never stable. The term “perpetual beta” ²¹ describes this new phenomenon. One cannot

conceive of a crowdsourced system’s functionality in terms of “releases” any more than a city has a release. Parts are being created, modified, and torn down at all times. We must accept change as a constant. For example, OSS projects employ a continuous build process, ¹⁸ producing a steady stream of incremental releases and relying on the community of users to be part of the quality-assurance process. For example, the Linux mantra is “release early and often.” ²³ Iterative and, more recently, agile processes similarly advocate small, frequent releases and tight integration with users. Likewise, on the CBSS side, there is no notion of a release of Wikipedia or Facebook; though the underlying platform for both Web sites has traditional releases, the content is constantly changing.

Focus on operations. Historically, system-development life-cycle models have focused on development and maintenance as the activities of interest. However, much of the value of crowdsourced systems is that they must be as reliable and accessible as a public utility. Many existing crowdsourced systems focus on operations as a core competency, ²¹ as in Amazon, eBay, Facebook, Google, Yahoo, and Wikipedia. Downtime for any reason is unacceptable.

Sufficient correctness. Completeness, consistency, and correctness are goals that are, to varying degrees, anathema to crowdsourced systems. The notion of “perpetual beta,” described earlier, is an admission and acceptance of ongoing incompleteness in software. ²¹ We are accustomed to a steady stream of releases of our most basic computing infrastructure (such as operating systems, Web browsers, Web servers, and email clients) to address evolving needs, incorporate new features, and correct bugs. Likewise, sufficient correctness is the norm for crowdsourced content. For example, collaborative tagging—enormously valuable for the semantic Web—does not depend on widespread agreement among taggers. Wikipedia never claimed to be complete or even fully correct, though its accuracy has been assessed and found to be similar to the Encyclopedia Britannica. ¹²

Unstable resources. Peer-produced applications are subject to the whims

of the peers. Resources, including people, computation, information, and connectivity, come and go. ¹⁶ Describing OSS development, Mockus et al., ¹⁸ said these systems “are built by potentially large numbers of volunteers…Work is not assigned; people undertake the work they choose to undertake.” However, large numbers tend to ameliorate the whims of any individual or individual resource, while portabilitly of resources has several manifestations:

˲ In the CBSS arena, large numbers of prosumers (producers who are also consumers of content) make it possible for Wikipedia to be authoritative and users to efficiently download digital content they want through Bit Torrent;

˲ In the computational arena, large numbers of unstable resources result in overall stability and impressive computational power. For example Skype is a threat to traditional phone companies, even though almost all its resources are “contributed” by the masses. Similarly the University of California, Berkeley’s SETI@home project ( http://setiath-ome.ssl.berkeley.edu/) has, at times, been rated the most powerful super-computer in the world, even though it’s powered by “spare” computation from independent contributors; and

˲ In the OSS arena, large numbers of independent developers working in parallel tend to provide multiple, often overlapping, solutions to a single problem, reducing the importance of the success of any particular solution or individual. The emerging trend is that unstable resources are increasingly accommodated and even embraced as part of the philosophy of building and running crowdsourced systems, even though unstable resources are viewed as anathema to successful projects.

Emergent behaviors. Large-scale systems—computational and biological—exhibit emergent behaviors, a characteristic noted in traffic patterns, epidemics, computer viruses, and systems of systems. ¹⁰ Large-scale Web-based applications (such as Second Life, eBay, and MySpace) have certainly seen complex behaviors emerge that are beyond the vision and intent of their creators (such as the “tax revolt” in Second Life and a seller boycott on eBay). Super-linear growth in OSS projects—previously assumed to be im-