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

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

possible, be tolerant of incompatibili-ties 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.

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.

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

5 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 pro-