The Metropolis Model: A New Logic For Development of Crowdsourced Systems

Two trends in business and society are reshaping the world: the rise of the socio-technical network and an emerging service orientation. Benkler⁴ offered a provocative argument about the networked information economy: that we are in the midst of a radical transformation in how we create our information environment. This change is at the heart of the open-source software movement, but OSS is only one example of how society is restructuring around new models of production and consumption of services. The aspect of the restructuring that is most startling "is the rise of effective, large-scale cooperative efforts—peer production of information, knowledge, and culture… We are beginning to see the expansion of this model not only to our core software platforms, but beyond them into every domain of information and cultural production"⁴ Benkler calls this phenomenon "commons-based peer production," attributing its rise to the rise of "the network." The networked information environment has dramatically transformed the marketplace, creating new modes and opportunities for how we produce and consume information. Crowd-sourcing—the popular term for commons-based peer production—is used to create value in information technology, the arts, basic research, and retail business.¹³

A "commons" is the opposite of property, referring rather to a set of shared, accessible community resources. Peer production harnesses the creative energies of many self-selecting participants with little or no financial compensation or formal managerial structure. The importance of this form of production is undeniable; as of May 2009 five of the 10 most popular Web sites—MySpace.com, YouTube.com, Facebook.com, Wikipedia.org, and Blogger.com—were produced this way, according to Alexa.com¹; with the exception of Wikipedia, all are for-profit enterprises.

The second trend, coinciding with and compounding the first, is that organizations are moving toward a service orientation as part of the growing worldwide service economy. Service industries in 2007 accounted for 55% of economic activity in the U.S. (http://www.census.gov/econ/www/servmenu.html). Meanwhile, businesses are shifting from a "goods-dominant" view, in which tangible output and discrete transactions are central, to a service-dominant view, in which intangibility, exchange processes, and relationships are central.²⁷ In the old goods-dominant logic, "services" (usually plural) were viewed as either a type of (intangible) good or an add-on that enhanced the value of a good. In contrast, "service" is now considered "a process of doing something for another party."²⁷ This service-dominant logic requires a shift on the part of businesses to viewing customers not as passive recipients of goods but as co-creators of value. This implies more than just a move from goods to services but a reframing of the purpose of the enterprise and its role in value creation. The service-dominant perspective has profoundly changed how organizations think about their relationships with their customers—"the crowds"—and how they leverage them and their resources. This shift in perspective greatly challenges traditional methods of system development.

Traditionally, system analysts are trained to focus on the "value propositions" of firms, not on "value co-creation." At best, "co-production" with customers has been used in such design methodologies as Joint Product Design, Joint Application Design, Rapid Application Development, and, more recently, agile methods in which customer requirements are solicited and modeled through an iterative process that incorporates immediate customer feedback. But this still reflects a goods-dominant logic. Product-focused and goods-focused design treats customers as isolated entities—recipients of value—neglecting the customers’ own resources and networks for dynamic collaborative value co-creation. Service-dominant design, on the other hand, considers resource integration from various entities, including customers and firms and their suppliers and networks, for value co-creation.⁶ Examples of co-creation have emerged, from OSS to Wikipedia, Facebook, Amazon’s Mechanical Turk, and many other community-based service systems (CBSSs).¹⁵ Each is a complex software-intensive or software-enabled system co-created by its participants—the crowds.⁴

Our existing models of software and system development are of little help in understanding and managing this new form of value co-creation. The older models all contain a "closed world" assumption—that projects have dedicated finite resources, management "manages" these resources, requirements are known, and systems are developed, tested, and released in planned increments. However, these assumptions all break down in a crowdsourced world.

Here, we offer a set of principles on which a new system-development model—more appropriate for the service-dominant, crowdsourced world—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.

---

Back to Top

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 do not stand alone, pointing instead to many other articles. Similarly, OSS projects make it easier to create software by composition, as they are "non-rival" (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 BitTorrent;
• 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://setiathome.ssl.berkeley.edu/) has, at times, been rated the most powerful supercomputer 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 impossible—appears to be an emergent behavior.^14,21 Traditional systems have made deterministic behavior a goal. But systems on the Metropolis scale must abandon this assumption; once the crowds are invited in, determinism is lost.

Back to Top

New Logic

These characteristics mean that traditional life-cycle models are inappropriate for describing or developing crowdsourced systems and thus require a new logic for both development and management. The Metropolis Model captures the characteristics that differentiate crowdsourced systems, offering a unified view of the two major types of crowdsourced systems: CBSS and OSS. Unlike traditional system life-cycle models, the Metropolis Model deliberately focuses on the role and nature of creation by crowds.

Different stakeholders have different roles within crowdsourced systems. For this reason, we distinguish three realms of roles (and associated infrastructure) within a Metropolis Model, as indicated by the "circles"—kernel, periphery, and masses—in the figure. Example roles for people involved in the kernel include architect, business owner, and policy maker; roles at the periphery include developer and prosumer; and roles for the masses include customer and end user.

There are also differences in "permeability" (dashed and solid lines in the figure) between the two major types of crowdsourced systems. For example, in OSS development it is possible to transition from end user to developer to kernel architect by consistently contributing and moving up through the meritocracy. On the CBSS side, it is generally impossible for a prosumer to be part of the kernel, as a distinct organization typically creates, plans, and manages the kernel.

Back to Top

Principles

Given the fundamental constructs of the Metropolis Model and their associated roles and permeability, we now describe its seven key principles, illustrating how they apply to OSS and CBSS. From them we also develop a set of implications for a new life-cycle model:

Crowd engagement and egalitarian management of open teams. A metropolis without residents and visitors is a ghost town. Absent in prior models, the first and foremost principle of the Metropolis Model is crowd management. Crowds must be engaged for value co-creation. How to engage them is not only a system-level issue but a strategic imperative for businesses. A crowd typically consists of volunteers (hence cheap labor) unknown to the business. As when building a city, infrastructure and rules must be in place to create the social and technical mechanisms needed to engage long-term participation, encouraging community custodianship, recognizing merits of individuals, promoting them through a hierarchy of "ranks" or allowing them to move to a different realm, and finally protecting the community by barring malicious or dangerous participants.

---

Most important is that the kernel be highly modular, allowing a project to scale as its community grows, while an original visionary developer or team retains intellectual control.

---

Crowd-management issues overshadow project-management issues (such as cost containment, scheduling, division of labor, and team communication and monitoring) in traditional systems. Focusing on the crowd does not mean that crowdsourced systems lack traditional cost and scheduling concerns and responsibilities; many do. The main impetus for crowdsourcing for many organizations is its potential for cost reduction, increased innovation, and quicker development time for delivering products and services that meet customer needs. However, management requirements are totally different. Most important, the management of open teams in the Metropolis Model is not purely, or even primarily, top-down,^16,18 as discussed earlier. Even though many for-profit companies contribute to OSS projects, the contributions do not change the inherent nature of management in the projects.³ Work is not assigned, and developers largely undertake the work they choose to undertake. Project leaders spend much of their time attracting, motivating, and coordinating a team of talented developers. For example, in OSS projects, there is no project plan, schedule, or list of deliverables.^16,18 What little management structure exists is based on principles of democracy and, frequently, meritocracy. Kernel team members in OSS projects are typically invited in via a consensus of existing kernel members or some kind of voting process, but only after first proving themselves in development, debugging, and design. For example, in the Apache project, "Members are people who have contributed for an extended period of time, usually more than six months and are nominated for membership and then voted on by the existing members."¹⁸ On the CBSS side, Wikipedia contributors are promoted to the rank of "editor" (an unpaid position) only when they receive at least a 75%–80% approval rating from their peers However, their rights, when it comes to articles, are no different from those of other users. A new user is able to update an article, and no one pulls rank. Wikipedia does have specially elected custodians with the authority to track down and remove privileges from rule violators; the crowds thus assume administrative, promotion, measurement, and asset-protection responsibility.

Bifurcated requirements. Requirements must be bifurcated into:

• Kernel service that deliver little or no end-user value, as in the Linux kernel, Apache core, Wikipedia wiki, and Facebook application platform; and
• Periphery contributed by the peer network (the prosumers) that delivers the vast majority of end-user value. Examples include Linux applications and device drivers, Firefox add-ons, Wikipedia articles, and Facebook applications.

The nature of the requirements in these two categories are also different; kernel service requirements concern quality attributes and their trade-offs, while periphery requirements almost exclusively concern end-user perceivable functions. For example, the requirements for Wikipedia’s wiki are totally unrelated to the requirements for Wikipedia’s content. Facebook’s application platform requirements were determined by Facebook (with input from its developers), whereas the requirements for Facebook applications (developed by prosumers) are determined entirely by developers.

Bifurcated architecture. The architecture is divided into a kernel infrastructure and set of peripheral services created by different groups through different processes. Kernel services (such as in Linux, Perl, Apache Core, Wikipedia wiki, and the Facebook application platform) are designed and implemented by a select set of highly experienced and motivated developers who are themselves users of the product.^16,18 These kernel services provide a platform on which subsequent development is based, as in the Linux kernel, along with a set of "zoning rules" (such as the Internet’s communication protocols) or both platform and rules (such as the Facebook application platform). The kernel provides the means for achieving and monitoring quality attributes (such as performance, security, and availability). The architecture of periphery components is enabled and constrained by the kernel through its primitives and compliance with its protocols; the periphery is otherwise unspecified. Each part of the periphery could, in principle, have its own unique architecture. This lack of specification permits unbridled growth and parallel creation at the periphery. Note also that the kernel does not have to be created through a Metropolis life cycle; kernels are created through more conventional means, typically following evolutionary models.

Fragmented implementation. The bifurcation of the kernel and periphery has important consequences for implementation. The vast majority of implementation in the Metropolis Model is crowdsourced, though the crowdsourcing applies only to the periphery. A distinct group implements the kernel, not a crowd but rather a close-knit, highly motivated, coordinated team.¹⁹ As Mockus¹⁸ noted about OSS projects: "Developers are working only on things for which they have a real passion." The periphery develops at its own pace, to its own standards, using its own tools, releasing code as it pleases. Similarly, in a CBSS, Wikipedia contributors and Facebook application developers contribute their own resources and adhere to no deadlines but their own. There is no overarching plan and no coordination of the activities of the periphery, just as there is no plan for the implementation of a city, which consists of the collective decisions and actions of perhaps millions of homeowners, businesses, contractors, and government organizations. This is different from existing development processes, even distributed development, that assume a central plan, allocation of resources, and schedule to which all distributed participants adhere.

Distributed testing. Verification of the kernel differs from verification of the periphery. Though the kernel must be highly reliable, this requirement is tractable because the kernel is typically small—often orders of magnitude smaller than the periphery—highly controlled, and slow to change. The reliability of the most popular OSS products has been reported to be quite high.¹⁶ The reliability of the periphery is indeterminate; sufficient correctness is the norm. But sufficient correctness is tolerable when the kernel is properly architected, because problems in the periphery do not compromise the kernel. Linus Torvalds, creator of Linux, once said, "When someone sends me patches to do a new filesystem, and I don’t necessarily trust the patches per se, I can still trust the fact that if nobody’s using this file system, it’s not going to impact anything else." Similarly the Wikipedia wiki is small, heavily tested, and highly reliable. But Wikipedia relies on its distributed network of contributors and editors to vet the accuracy of its prosumer-contributed entries.

Distributed delivery/maintenance. Delivery and maintenance of the kernel differs dramatically from delivery and maintenance of the periphery. The kernel must be stable and when it does change must be backward compatible (such as in terms of Internet protocols and addressing). At the periphery, perpetual beta is the norm, with a constant stream of independent, uncoordinated "releases." At the periphery, there is no notion of a stable system state. Gradual and fragmented change is typical and expected.⁹

Ubiquitous operations. Metropolis systems are "always on," even when they’re being upgraded. Complicating this mandate is the fact that upgrades are not ubiquitous; parts of the system at different release levels operate (and interoperate) simultaneously. But for systems built through a Metropolis Model, operations must be a focal activity and, in particular, geared toward ultra-high availability. Also, upgrades must be backward compatible, retaining access to at least kernel functionality, since there is no assumption that all parts of the system will be upgraded at any given point in time. Finally, the ubiquitous-operations principle indicates that Metropolis systems must be able to scale with the number of users; scaling is achieved because the periphery provides its own development and execution resources (such as Skype, BitTorrent, Kazaa, and SETI@home).

Back to Top

Implications

A system-development model is built on a particular logic used to structure, plan, and manage the process of developing a system. The model implies a set of expectations on tools, processes, activities, and roles. Many models (such as waterfall, spiral, and agile) have evolved over the years, each with its own characteristics, strengths, and weaknesses. No one model is best for all projects; each is suited to particular development contexts and characteristics. For instance, agile methods are typically best for projects with rapidly evolving requirements and short time-to-market constraints, whereas a waterfall model is best for large projects with well-understood, stable requirements and complex organizational structures. Accordingly, the Metropolis Model describes a new set of principles and prescribes a new set of activities for an increasingly significant segment of the market—crowdsourced systems, both OSS and CBSS—as we’ve explored here. The implications of the Metropolis Model force a new perspective on system development in seven important ways:

Focus on crowd management. The Metropolis Model reflects the metaphor of a bull’s-eye (as in the figure), as opposed to, say, a waterfall, a spiral, a "V," or other representations adopted by other models. The contrast is salient; the "phases" of development disappear in the bull’s-eye. The model focuses managerial attention on the inclusion of customers (the periphery and the masses) for system development, something never previously modeled.

Several challenges arise from the first principle concerning crowd engagement and egalitarian management of open teams for the success of crowdsourced systems. Policies for crowd management must therefore be aligned with an organization’s strategic goals and established early. Crowds are good for certain tasks, not for all. Much of the emergent behavior comes from the activity of the crowd. This connection implies that business models are examined in light of system-development tasks for crowd engagement, performance-management monitoring, and community protection. As crowdsourcing is rooted in the "gift" culture, for-profit organizations must align tasks with volunteers’ values and intentions.²⁹ Project managers must set up a management system that is "lightweight" so responsibility for creation is borne by volunteers and capable and robust enough to drive the ongoing success of the site and protect the system from destruction.⁸

By opening a project to the crowds, management accepts that they consist of unknown people at disparate locations anywhere on the Internet and in time zones, countries, and cultures. This is certainly the case for nontrivial OSS projects. Managing them means the periphery shares in their success and, to a large extent, is self-governing and self-adaptive. Many leaders of important, large-scale open source projects have said they do not "lead" in a traditional sense. For example, Linus Torvalds (creator of Linux) and Larry Wall (creator of Perl) both say they exert no management control and do not command members of the project.³ Jimmy Wales (founder of Wikipedia) does not control Wikipedia; indeed, he does not even control the Wikipedia entry on "Jimmy Wales."³⁰ Periphery members cannot be controlled but must be inspired, persuaded, and motivated. Due to its distributed nature, the project must have a clear task breakdown structure but with a minimum of hierarchy and bureaucracy; there must also be collaboration or mass-collaboration technology—typically email lists, wikis, and discussion forums—for communication and coordination.¹⁶ Even the entrance of many for-profit companies into the OSS movement has not changed the inherent nature of project management in these projects, remaining more consensus-based meritocracies than traditional top-down hierarchies.

This culture means management must focus on communication, negotiation, and leadership to guide developers and content creators, persuading them to share in the vision of the project. The creators of the kernel must also commit resources to create effective tutorials and examples. Finally, kernel creators must pay attention to the usability (simplicity and learnability) of the kernel, making it easy for the periphery to carry on. Wikipedia succeeds, in part, because it is trivial for a prosumer to create or edit an article. Facebook succeeds, in part, because it takes only hours for a developer to create a simple application.

Separate kernel and periphery. The Metropolis Model embeds explicit recognition of separate kernel and periphery in different tools, processes, activities, roles, and expectations for each. The kernel must be small and tightly controlled by a group of developers focusing on modularity, core services, and core quality attributes, enabling unbridled and uncoordinated growth at the periphery.¹⁹ Separation of kernel and periphery is the foundation for the Metropolis Model principles of bifurcated requirements and bifurcated architecture and the foundation for the principles of distributed testing and fragmented implementation.

Change the requirements process. The requirements for Metropolis systems are primarily asserted by the periphery, typically through email, wikis, and discussion forums. These forums must be made available (typically by members of the kernel) and the periphery encouraged to participate in discussions about the requirements to, in effect, create a community. In addition, it must be stressed that these forums are used mainly for discussing the requirements of the core or of significant parts of the periphery. Metropolis projects must, therefore, accept that many requirements for functionality at the periphery may never be discussed. For example, any individual developer may contribute a new device driver to Linux for an obscure device or new Wikipedia entry, and this contribution (and its requirements) might never be discussed in an open forum. This changes the fundamental nature of requirements engineering, which traditionally focuses on collecting requirements, making them complete and consistent, and removing redundancies wherever possible.

Increase attention to architecture. The kernel architecture is the fabric that unites Metropolis systems. As such, it must be designed to accommodate the specific characteristics of CBSSs and OSSs. For this reason, the architecture cannot "emerge," as it often does in traditional life-cycle and agile models. It must be designed up-front by an experienced, motivated team focusing on modularity to enable the parallel activities of the periphery and the kernel’s core quality attributes (such as security, performance, and availability).

A lead architect or small team of leads should be assigned to manage project coordination and have the final say in matters affecting the kernel. For example, Linus Torvalds continues to exert veto rights on matters affecting the Linux kernel. Similarly, members of the team developing Apache’s core control changes to the core’s architecture, Facebook controls its application platform architecture (even though it is OSS), and Wikipedia.org controls the structure and capabilities of its wiki. Most important is that the kernel be highly modular, allowing a project to scale as its community grows, while an original visionary developer or team retains intellectual control.¹⁸

Plan for distributed testing. Bifurcation of the kernel and periphery provides a guiding principle for testing activities. The kernel must be thoroughly tested and validated, since it unites the system. This imperative can, however, be made tractable. When planning a Metropolis project, project leaders must focus on validation of the kernel and put tools, guidelines, and processes in place to facilitate this validation. For this reason alone the kernel should be kept small. The project should have frequent (perhaps nightly) builds and frequent releases. Bug reporting should be built into the system and require little effort on the part of the periphery. The project should focus on explicitly taking advantage of the "many eyes" touted by OSS development to constantly scrutinize and test the kernel.²³ Such scrutiny does not imply that all aspects of a Metropolis project are thoroughly tested, only that the kernel is.

Create flexible automated delivery mechanisms. Delivery mechanisms must work in a distributed, asynchronous manner and be flexible enough to accept incompleteness of the installed base as the norm. Thus, any delivery mechanism must tolerate older versions, multiple coexisting versions, and even incomplete versions. A Metropolis system should also, as far as possible, be tolerant of incompatibilities in itself and among other systems. For example, modern Web browsers still parse old versions of HTML or interact with old versions of Web servers; add-ons and plug-ins in the Firefox browser coexist at different version levels yet do not "break" the browser. This approach to delivery and maintenance is a direct consequence of the characteristic of sufficient correctness.

---

Prior life-cycle models are inadequate—mostly mute—on the concerns of crowdsourcing, super-linear growth, and change as a constant.

---

Plan for ultra-high availability operation. In most system-development projects, operations are not an early focus of developer attention or resources. In a Metropolis project, the principle of ubiquitous operations must be made a focus due to the distributed and uncoordinated nature of contributions. A Metropolis project must design and plan for ultra-high reliability of the kernel and its infrastructure while paradoxically accepting the fact that periphery software often fails. This focus means the project must explicitly create monitoring mechanisms, determine the current state of the system, and control mechanisms so bugs in the periphery do not undermine the kernel. The project must also avoid any form of centralized critical resources or centralized control—people or computation—as they are potential single points of failure and hence anathema to high availability. In addition, the system must transition smoothly, maintaining continuous operations as it evolves.

Back to Top

Conclusion

Life-cycle models are never revolutionary, arising instead in reaction to ambient conditions in the software-development world. The waterfall model was created almost 40 years ago to focus more attention on removing flaws early in a project’s life cycle in reaction to the delays, bugs, and failures of projects of increasing complexity. The spiral model and, later, the Rational Unified Process, were created because projects needed to produce working versions of software more quickly and mitigate risk earlier in the software-development life cycle.⁵ Agile methods grew out of the desire for less bureaucracy, more responsiveness to customer needs, and shorter time to market.

Similarly, the Metropolis Model formally captures a current market response: commons-based peer production and service-dominant logic. Prior life-cycle models are inadequate—mostly mute—on the concerns of crowdsourcing, super-linear growth, and change as a constant. While the Metropolis Model is not a life-cycle model, it does offer new ways to think about how a new breed of system can be developed; its principles help management shift to new project-management styles that take advantage of the "wisdom of crowds." The wrong model or a misaligned model can mean disaster for an organization. The right model—possibly requiring substantial organizational and technological reengineering—provides significant new opportunity. For example, IBM (the most patent-productive company in the world) now makes more money from crowdsourced OSS-related services than from all its patent-protected intellectual property,⁴ even though the shift to OSS was turbulent and controversial within IBM.

The Metropolis Model provides a framework within which organizations are able to reason about all aspects of how they create systems, including tool support, languages, training, resource allocation and management, and personal motivation. The principles of the Metropolis Model are useful as a critical set of questions for examining the alignment of system-development activities with the underlying business model. Business-model questions come first: Who are our customers? What value can be co-created by and for them? What motivation can I offer to engage them for the long term? Answers prompt a new set of system-development questions: How can customer participation be engaged? How can the infrastructure be bifurcated? What technological or system competency must be developed to facilitate engagement and custodianship of the system? What policies must be established to safeguard the community? To answer, organizations must identify the characteristics of their systems and reconsider their business and development models.

Metropolis Model concepts are not appropriate for all forms of development. Smaller systems with limited scope will continue to benefit from the conceptual integrity that accompanies small, cohesive teams. High-security and safety-critical systems and systems built around protected intellectual property will continue to be built in traditional ways for the foreseeable future. But more and more crowdsourcing, mashups, open source, and other forms of nontraditional development are being harnessed for value co-creation. The Metropolis Model speaks to all of them. For example, mashups are beginning to be observed and supported even in the extremely conservative financial sphere.⁶

Embracing the Metropolis Model requires dramatic changes to accepted software-engineering practices. Organizations must be prepared to adopt new organizational structures, processes, and tools to support these changes. Each Metropolis principle is, to some degree, counterintuitive relative to existing software-engineering practices. Management must therefore guard against old habits and foster a new mindset to deal with unknown people in open teams, embrace incomplete requirements, accept sufficient correctness, and anticipate and tolerate emergent behavior.

Much more research is needed to understand and capitalize on the relatively new form of commons-based peer production. We offer the Metropolis Model as a foundation on which subsequent research and life-cycle models can be built.

Back to Top

Back to Top

Back to Top