possible—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.
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.
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 metropo-
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.
lis 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.
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, as discussed
16, 18
earlier. Even though many for-profit
companies contribute to OSS projects, the contributions do not change
the inherent nature of management
in the projects. 3 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
