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. 18

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. 23 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 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.