The Architecture of Participation

I've come to use the term "the architecture of participation" to
describe the nature of systems that are designed for user
contribution. Larry Lessig's book, Code and Other Laws of Cyberspace, which he characterizes as an extended meditation on Mitch Kapor's maxim, "architecture is politics", made the
case that we need to pay attention to the architecture of
systems if we want to understand their effects.

I immediately thought of Kernighan and Pike's description of the
Unix software tools philosophy referred to above. I also
recalled an unpublished portion of the interview we did with Linus
Torvalds to create his essay for the 1998 book, Open Sources.
Linus too expressed a sense that architecture may be more important than
source code. "I couldn't do what I did with Linux for Windows,
even if I had the source code. The architecture just wouldn't
support it." Too much of the windows source code consists of
interdependent, tightly coupled layers for a single developer to
drop in a replacement module.

And of course, the Internet and the World Wide Web have this
participatory architecture in spades. As outlined above in the
section on software commoditization, any system designed around
communications protocols is intrinsically designed for
participation. Anyone can create a participating, first-class
component.

In addition, the IETF, the Internet standards process, has a great many
similarities with an open source software project. The only substantial
difference is that the IETF's output is a standards document rather
than a code module. Especially in the early years, anyone could
participate, simply by joining a mailing list and having something
to say, or by showing up to one of the three annual face-to-face
meetings. Standards were decided by participating individuals,
irrespective of their company affiliations. The very name for
proposed Internet standards, RFCs (Request for Comments), reflects
the participatory design of the Net. Though commercial participation
was welcomed and encouraged, companies, like individuals, were
expected to compete on the basis of their ideas and implementations,
not their money or disproportional representation. The IETF approach
is where open source and open standards meet.

And while there are successful open source projects like
Sendmail, which are largely the creation of a single individual,
and have a monolithic architecture,
those that have built large development communities have done
so because they have a modular architecture that allows easy
participation by independent or loosely coordinated developers.
The use of Perl, for example, exploded along with
CPAN, the Comprehensive Perl Archive Network, and Perl's module
system, which allowed anyone to enhance the language with
specialized functions, and make them available to other users.

The web, however, took the idea of participation to a new level,
because it opened that participation not just to software
developers but to all users of the system.

It has always baffled and disappointed me that the open source
community has not claimed the web as one of its greatest success
stories. If you asked most end users, they are most likely to associate the web with proprietary clients such as Microsoft's Internet Explorer than with
the revolutionary open source architecture that made the web possible.
That's a PR failure! Tim Berners-Lee's original web implementation was not
just open source, it was public domain. NCSA's web server and
Mosaic browser were not technically open source, but source was
freely available. While the move of the NCSA team to Netscape
sought to take key parts of the web infrastructure to the proprietary side, and
the Microsoft-Netscape battles made it appear that the web was
primarily a proprietary software battleground, we should know better.
Apache, the phoenix that grew from the NCSA server, kept the open
vision alive, keeping the standards honest, and not succumbing to
proprietary embrace-and-extend strategies.

But even more significantly, HTML, the language of web pages,
opened participation to ordinary users, not just software developers.
The "View Source" menu item migrated from Tim Berners-Lee's original browser,
to Mosaic, and then on to Netscape Navigator and even Microsoft's
Internet Explorer. Though no one thinks of HTML as an open source
technology, its openness was absolutely key to the explosive
spread of the web. Barriers to entry for "amateurs" were low,
because anyone could look "over the shoulder" of anyone else producing
a web page. Dynamic content created with interpreted languages
continued the trend toward transparency.

And more germane to my argument here, the fundamental architecture
of hyperlinking ensures that the value of the web is created by its
users.

In this context, it's worth noting an observation originally made
by Dan Bricklin in his paper, The Cornucopia of the Commons. There are three ways to build
a large database, wrote Dan. The first, demonstrated by Yahoo,
is to pay people to do it. The second, inspired by lessons from
the open source community, is to get volunteers to perform the
same task. The Open Directory Project, an open source Yahoo
competitor, is the result. (Wikipedia provides another example.)
But Napster demonstrates a third way. Because Napster set its
defaults to automatically share any music that was downloaded,
every user automatically helped to build the value of the shared
database.

This architectural insight may actually be more central to the
success of open source than the more frequently cited appeal
to volunteerism. The architecture of Linux, the Internet, and
the World Wide Web are such that users pursuing their own
"selfish" interests build collective value as an automatic
byproduct. In other words, these technologies demonstrate some of
the same network effect as eBay and Napster, simply through the
way that they have been designed.

These projects can be seen to have a natural architecture of
participation. But as Amazon demonstrates, by consistent effort
(as well as economic incentives such as the Associates program),
it is possible to overlay such an architecture on a system
that would not normally seem to possess it.

Note: I had mistakenly attributed the insight about three ways to build a shared database to Clay Shirky when it had originated from Dan Bricklin. Read more in this Radar blog entry.