should be based. We call them the Metropolis Model; metropolis is the Greek word for “city.” The analogy is deliberate; this new form of producing systems is more like constructing a city than a single building, a perspective called ultra-large-scale (ULS). ²⁰ ULS systems are like cities in that they are not conceived or built by a single organization, have no centralized control, and are continuously evolving.

The Metropolis Model is our attempt to describe and prescribe the principles surrounding how such systems might be created and sustained. It offers a unified logic for reasoning about and managing system development for the two major forms of crowdsourced systems: OSS development and community-based service systems (see the figure here). A CBSS, which involves creation of content but typically not of software, includes social networking and commercial service systems. The crowds utilized by the two types of systems are also different, as we discuss later. These systems are not new, though their rapid growth and importance is unprecedented. For example, OSS has become an increasingly important sector of the software market; according to a 2008 European Union study of Free/Libre Open Source Software, or FLOSS, the “notional value of Europe’s investment in FLOSS software [represented] 20.5% of total software investment” in 2006.¹¹ This model does not apply to all forms of software creation or system development; some systems are too business-critical, security-critical, or safety-critical to be entrusted to the crowds so will never be produced by a group of peers. But the Metropolis Model clearly applies to a large and fast-growing set of software-centric systems.

Software architects and project managers find it worthwhile to embrace the principles of the Metropolis Model for developing this broad class of systems, taking advantage of the collective wisdom, creativity, and productivity of the crowds. The Model’s principles inevitably lead businesses and project managers to reason differently about virtually every aspect of system development, including project management, requirements elicitation, architecture, implementation, testing, delivery, maintenance, and operations.

one cannot
conceive of a
crowdsourced
system’s
functionality in
terms of “releases”
any more than
a city has a release.
Characteristics

The Metropolis Model is built on the characteristics of crowdsourced systems, eight of which have been identified (in the ULS report²⁰ and in our own surveys of CBSS and OSS projects) that challenge existing models of system development. They provide the Model’s intellectual motivation. Software and system engineering have long embraced a centralized production model in which requirements are collected and negotiated, projects managed, architectures created, and correctness determined through a controlled, planned process. It is hierarchical and rule-oriented, not commons-based or egalitarian. Even agile methods are centralized, stressing the importance of face-to-face communication and the advantages of the “bullpen,” or open– office environment where workers interact freely.

However, future crowdsourced systems will be community-driven and decentralized, with little overall control, as is the case with CBSS and OSS. ¹⁶ Consequently, we can no longer design and implement such systems through older models. Here are the eight characteristics of crowdsourced systems:

Open teams. Assumptions of a closed team of dedicated developers should be abandoned. “Based on our usual assumptions about volunteer projects and decentralized production processes that have no managers, [Linux] was a model that could not succeed. But it did.” ⁴ Similarly, the Apache project was not “organized around a single person or primary contributor” ⁹ but resulted from a number of Web masters working together, primarily via email. Jimmy Wales, founder of Wikipedia, an example of a CBSS, exercises virtually no control over the community or the ranks of its volunteers.

Mashability. Enormous effort goes into making systems that are difficult to tear apart for historical, intellectual-property, and security reasons. However, “mashability” is a core characteristic of crowdsourced systems. Web browsers make it simple to view any page’s source, and it is accepted practice to use parts of existing Web sites in new creations. For example, Google Maps, prior to making its APIs public, was used in mashups. In Wikipedia, it is accepted and encouraged that articles