The educated world, and everything touched by it,
to undergo an alteration of the same order of consequence as the
method, the printing press, the Industrial Revolution, and the
transistor. So I will suggest in this essay. It will be a
revolution in collaboration--just
as, not coincidentally, these previous revolutions made it possible for
work more closely together in various new ways.
To a great extent, as has often been observed, the increasingly evident
of collaboration is really just the fulfillment of the promise of the
Internet. So perhaps a better descriptor
is simply "the Internet Revolution." If so, the Internet
Revolution has parts, and we are only now
entering into the next part--the collaborative part.
I do not claim to be making an original claim in forecasting
this revolution, nor do I really expect to persuade anyone that it is
coming. I hope this essay will at least
evince my own sincerity in avowing a belief in this impending revolution. I hope it will also help explain why I, and a
growing number of people online, believe this revolution is coming. And for those who are not yet convinced, I
hope it will at least clarify and plant the seed of a very, very fruitful idea.
This essay is intended more as a manifesto than as a project
proposal or an academic paper. I plan to
describe an idea, "strong collaboration," and why creativity is needed to make
it work, and then explain the cultural
elements also needed for strong collaboration to work.
One other introductory remark is in order.
Some people will read an inaccurate summary
of this essay, or this introduction, and think that it's old hat--that I
singing the praises of wikis and blogs and folksonomies all over
again. "Power to the cyber-people" and all that: that
was still new about two years ago, but not now.
As an interpretation of this essay, that would be a mistake. My
take on the future of
collaboratively-developed content is importantly different from that
prevails on Wikipedia, Slashdot, Kuro5hin, and most of the Blogosphere
on this stuff--i.e., the websites and Internet projects that most
developments in online collaboration. I
boldly submit that my take is not only different, it is more mature and
than the prevailing view of online collaboration, according to which,
as far as
I can tell, collaboration is best done when anarchy prevails, anonymity
expected, and hard-won expertise is at best ignored and at worst an
sophomoric contempt. Not only do I have
these philosophical or policy disagreements, I think that focus on
tools like wikis, to the exclusion of projects and their special
has led to widespread indifference to whole classes of potential new
kinds or systems of collaboration. At
any rate, I think and hope that those who theorize about online
will find something new and worth thinking about here.
Strong collaboration and its many possibilities
Strong, or radical, collaboration is crucially
different from old-fashioned collaboration. Many people who have
not worked much with
open source software, or with Wikipedia, do not realize this.
Old-fashioned collaboration generally
involves two or more people working serially
on a single work, or each on a different part of a work, and the work
put together by an editor and perhaps approved by committee. This
frequently produces boring,
unadventurous, and confusing work, as everybody knows; the phrase
committee" stands for "stitched together incoherently like a Frankenstein
Strongly collaborative works are not written by committee, in this way. Anyone who tries to replicate the success of
Wikipedia, for example, by using committees
just has not got the concept of strong collaboration.
Instead, strong collaboration involves a constantly changing
roster of interchangeable people, and changing mainly at the whim of the
participants themselves. For the most
part at least, collaborators are not
pre-assigned to play special roles in the project. There is just one main role--that of
collaborator. And anyone who shows up
and fits the requirements (bear in mind that some projects have almost no
requirements at all) can play that role.
Moreover, to the extent to which work is strongly collaborative,
everyone has equal rights over the product.
Everyone feels equal ownership and feels equally emboldened to make
The justification for this odd and perhaps
methodology has nothing to do with egalitarian ideology, as some have
it. At least, it need not have anything to do with egalitarian
ideology. Some have portrayed Wikipedia and open source
software as "communist" because its results are free, and everyone is
participate under roughly equal terms (if they are able, that
is). But this is silly, of course. People of every
political stripe can and do support
strongly collaborative methods. The fact
that the collaborative work is free is not a result of some strictly
desire for "no ownership" and "free stuff for everybody."
Instead, open source and open content stuff is free for the
simple reason that an arbitrarily large
number of people can and do work on it.
So who's going to own it? Nobody can own it, or else you couldn't get
that large number of people to work on it so hard and take personal
responsibility for it. Similarly, you
can't get an arbitrarily large number of people to volunteer to work on something
that a much smaller number of individuals own, or have special authority
over. If a work is said to be "owned" by
John Doe, Jane Roe will think it's up to John Doe to call the shots. She doesn't want to step on Doe's toes, or
she might feel that she has no right to do so.
So she and others just don't have the same incentive to work together on
something when she is told the content has owners. When a work is free and ownerless, everyone enjoys
more or less equal rights to contribute, and motivation to get to work, and to
work together, is much stronger.
It is not anything
magic about wiki software in
particular that makes Wikipedia work as well as it does. Wikipedia's success is more due to the fact
that it is strongly collaborative
than that it is a wiki. Wikis and the
Wikipedia model are one way to enable strong collaboration, but they are not
only one way. I think that the Wikipedia
community made a mistake when it decided that it's the wiki part that explained
Wikipedia's success. They proceeded to apply
the same software and content development system, which happened to work (more
or less) for an encyclopedia, to develop very different kinds of projects: a
dictionary, news articles, editing public domain books, writing new books from
scratch, and several more things. It
seems they found they had a whopping good hammer and suddenly everything looked
like a nail. A lot of other people have
got in on the act, with "wiki farms" sprouting up all over. Even Amazon.com has recently decided to add
wiki pages to their pages about books. I
predict that this experiment, like the Los
Angeles Times Wikitorial experiment, will fail miserably. The revolutionary thing about Wikipedia, the
thing worth replicating, is not the fact
that it's a wiki. It's the fact that
it's strongly collaborative. And
collaborations do not happen just because someone puts up a wiki. As the zillions of dead or stillborn wikis
attest, with wikis, it is not the case that if you build it, they will come.
The fact is that there is no substitute for
carefully thinking through the details
of a collaborative system and how it ought to work in order produce a
particular kind of information. Just appropriating the Wikipedia
not solve all content development problems.
Different kinds of information--different content editing systems.
No one would
have suggested that Second Life, which is a collaboratively-developed
space (like a video game that the participants work on together),
should be a
wiki. A wiki is inappropriate for that
because wikis aren't (strictly speaking) 3D, they're mainly text.
Why should every collaborative text project be a wiki, and share the
model, just because it's text? For a lot of people who love
there seems to be far too much in-the-box thinking going on.
Wikis, and the very specific way that
Wikipedia uses the wiki tool, are just one game. There are many
other games. One only needs to do creative and intelligent
problem-solving to think of many more; and the best "Web 2.0"
realize this very well.
What relatively few seem to realize is what an
absolutely huge assortment of
collaborative text development systems are possible. We haven't
even begun to scratch the surface. The names of tools--"wikis," "blogs,"
"tagging," etc.--seem to define the creative boundaries for too many
people. Often, one has only to change a
single rule, and the whole paradigm associated with a tool
changes. Take the humble mailing list (Internet forum),
which can count as a collaborative content development system (just not
strongly so, because people can't edit each others' posts). The
difference between moderated and
unmoderated lists is well known, and everybody familiar with mailing
an opinion about moderation. But it
seems few people think much about other variants--other ways to get
interact and work together. Think of
mailing lists as games. What are all the
games you could play? What rules could you impose, that everyone
playing could agree to, so that the result would be interestingly
different? Here's just one possibility. Suppose
list moderator posts a general question, about war, free trade, global warming,
or whatever, and invites people to write reasoned answers to the question.
the answers (or maybe the half-dozen the moderator thinks best) are posted at once.
who wants to can write a reply to exactly
one of the respondents.
moderator collates the replies so that all the replies to answer #1 are grouped
in one post, all the replies to answer #2 are grouped in a second, and so
the initial answerers write responses to the replies, and these are posted.
It is trivially easy to imagine a
zillion other "games" one could try with a mailing list. Most of the possibilities have not even been
tried; instead, when people use mailing lists, they tend to use them only in very
specific, simple ways.
Why haven't the possibilities been
explored in practice? I think it's the
same reason that wikis, blogs, and other collaborative software each tend to be
conducted in just a few different ways: not
because there are only a few good ways to use these tools and we have settled
upon the best uses, but because people are generally conformists, and because
games require shared understandings that must be conveyed deliberately and
self-consciously. In other words, for
new social games to be played online, there has to be someone who declares, "This is how I propose that we play the
game," and then enough other people, a quorum, actually have to play it that
way. Since people are such conformists,
it's hard to get people to be the first to play new collaborative content
games, and even harder for people to do what it takes organize new sorts of
My point, then, is that Wikipedia's
content editing system is just one game, and there are a zillion other
games one can imagine using wikis to play.
Out of so many possibilities, it would be astonishing if we hit upon the
best one for creating an encyclopedia collaboratively right out of the gate; it
would be even more astonishing if exactly
that game were also the best one
for other kinds of information, like
books or dictionaries.
When, with practically endless
variations on tool design and rules of operation, there is such a huge space of
possibilities to explore, it becomes abundantly clear that a great deal of
intelligent, careful, and above all creative
thought needs to go into the design of collaborative systems. The requirements of an ideal resource of a
specific type, as well as the needs and culture of the collaborators, need to
be very carefully considered.
In fact, it is best if the
collaborators themselves think through together the requirements of a
project. There must be leadership,
granted--that is, some way of actually
arriving at a decision when one is needed, that the collaborators can view
as legitimate--but a large group of people thinking creatively about many
possibilities can produce more ideas, and more interesting ideas, than just one
or a few people working alone. In fact,
when it comes to deciding on a particular "game" to "play," what collaborative
content system to adopt, considerations of smart, creative design are not the
only reason to engage the collaborators.
In addition, to have maximal
participant buy-in, they must feel that they have a significant role in
designing the system, i.e., that the decisions do not come from the top down.
This brings me to the next major
topic: while collaborative systems should be designed with the needs and values
of participants in mind, I think that a certain culture, or set of values, is
necessary in order to make collaboration work.
The principle that collaborators should participate in system design is
an example, but only one example.
The culture of collaboration
What makes strong collaboration
work? It's a whole set of things. Everyone involved should understand what the project's
aim is and what the rules are for getting there. They should also feel empowered to get to
work, and (if they're qualified) they should be able to work on any part, or almost any, of the project,
whenever the desire arises. Assignments
are not made; participants assign themselves, and choosing one assignment does
not prevent others from choosing the same assignment. There are, of course, variations on these
very general principles, but to the extent to which a project is strongly
collaborative, these principles will hold true.
What is contrary
to these principles are the notions of ownership
and top-down assignment. All this is now very well-understood by the
open source community and Wikipedia and other such projects. Shared ownership and self-direction are
essential to the success of strong collaboration.
So I maintain that, in order to
work, any system of strong collaboration requires something like
egalitarianism; but not necessarily the total absence of leadership and authority. Many people who spend much time on
collaborative projects might well disagree with this, or at least anarchists or
borderline anarchists would. It turns
out that this is culturally very important for understanding collaborative
projects, so I need to spend some time on it.
Political and legal theorists know
very well that, if we put political systems on a line, a continuum
their commitment to equality, anarchy is at one end of the continuum,
every assertion of authority illustrates the difference, after all,
those with authority and those without it.
In a perfectly equal society--strictly impossible, no doubt--everyone
would be equal in authority. And, without often getting quite
explicit about it, theorists about online collaboration frequently
commit themselves to something approaching anarchism.
Intellectually speaking, it's an easy
position to take, because it simply amounts to consistency with an
ideal. If your
most fundamental, baseline principle is egalitarianism, it requires
more complexity, to justify adding authority to social systems,
collaborative systems, precisely because adding authority entails
Why is this position so popular
among collaborative content producers? Actually,
it might seem reasonable in the context of collaboration. If shared ownership and self-direction are
essential to strong collaboration, as I claim, then adding an authority to a
collaborative system is to raise up a person who has
some special right to control content
and direct effort. So it is easy for
someone committed to very strong, or radical, collaboration to claim that a
critic of collaboration does not "get it" if he suggests that there needs to be
minimal oversight or control of some sort.
In this way, the culture of collaboration naturally lends itself to a
relatively radical position on the question of authority.
Still, the most radical position
is, of course, only one policy position, and not necessarily the one that will
actually work best--that is, unless
success itself is measured by the degree to which a content creation project is
itself egalitarian. There are some
people who seem to believe that: it is not really
the quality of the software, or the tagging system,
or the encyclopedia, or the dictionary that matters. It could be garbage, and some people really
wouldn't care that much; what matters is simply that the process that produces
these is maximally ownerless and self-directed.
It's the social experiment more than anything else that explains why some
people are drawn to collaborative content production.
The notion that
strong collaboration is valuable mainly or only as a social experiment barely
warrants consideration, much less refutation. Information (software, categorization, etc.)
has its own internal requirements, and it is practically certain that those
requirements cannot be met as well by a radically egalitarian system as it can
by a system that contains some rules and controls and, as a practical necessity,
persons in authority to enforce the rules and controls.
So far, this is only one side of the problem
of making strong collaboration work well.
The other side is that the most radically collaborative system is apt to
strike most traditional information producers--publishers, editors, producers,
journalists, college professors, corporate software engineers, etc.--as an
obvious nonstarter, and the egalitarian or anarchical ideology that appears to
be behind it is bound to seem puzzling and foreign at best. For academics, strong collaboration seems to
have produced bewildering amounts of information more quickly and efficiently
than they have ever seen; but the information is typically of self-evidently
low quality. Traditional information
producers are intrigued by and envious of collaborative content production, but
they cannot see how to make it work to produce information that meets their own
The main puzzlement that academics
and (more generally) traditional information producers cannot get past are the two above-named
essential features of strong collaboration: shared ownership and
self-direction. Shared ownership requires
free information--which is where open source and open content enter the picture--and
thus requires a radical reconsideration of business models, something that
information producers are understandably loath to do. Self-direction, or the rejection of top-down
assignments, is also exactly contrary to the usual corporate methods. For all the talk of flattened corporate
cultures, self-assignment at the level illustrated by Wikipedia is apt to make
managers very nervous.
When it comes to signed content,
including journalistic and academic writing, matters are complicated further by
the fact that academic and professional advancement seems to require clear
authorship. One impediment that keeps
academics from using wikis to develop encyclopedias (notwithstanding the
academics who contribute to Wikipedia) is that they do not see, in the
Wikipedia sort of model, any way to get personal credit for their work. There is a tendency, therefore, to suggest
that wikis be adopted with an apparently
slight variation on the Wikipedia model: that articles be put under the control
of specific authors. But this suggestion
would reject a precise requirement for the Wikipedia model to work. The suggestion is made under the impression,
debunked earlier, that it is wikis
themselves that somehow magically produced all that content. This is not the case: the quantity of content
is a result of the fact that the wiki software was used to pursue strong collaboration, so that everyone felt
equally motivated to take responsibility for and improve content throughout the
project. Wiki software is the tool, but strong
collaboration is the method; praise the method, not the tool.
But the suggestion that academics
(or journalists, or corporate software engineers, etc.) work without assigned
authorship is still, in 2006, apt to be dismissed out of hand. Until they consider it more seriously, traditional
information producers will continue to watch from the sidelines with mixed
amazement and contempt.
I propose, though I will have to
develop this thought elsewhere, that academics and
journalists think about the possibility of distinguishing assignment and credit. It is possible to be granted a byline or
other credit after doing certain
kinds of work. That is the notion behind
a system I have helped to design for the Encyclopedia
of Earth and the Digital Universe encyclopedia: there can still be topic
editors, lead authors, and contributing authors listed, but they are listed
only after they have actually
contributed to or taken responsibility for an article. The assignments do not come from the top
down; people do work where they feel they can help.
So to sum up, there are very
different difficulties on two sides when it comes to making strong
collaboration work. On the one hand, as
we have just seen, traditional information producers must learn to work
together and get credit without ownership or assignment. Onthe other hand, the online public who
are such fans of collaboration must make room for and reconcile themselves to
the notion of at least minimal authority
and control. The best collaborative
projects of the future will walk the line and combine the best of both worlds. But is that possible?
Ever since I articulated the
systems and rules that ran Nupedia and Wikipedia, I have been thinking about
the most difficult problem for the future of strong collaboration, namely, to combine the largely incompatible cultures
of anarchical collaborationists and of traditional information producers. Though many people from both sides will be
reluctant to admit it, the best, most productive culture will combine elements
of both. When it comes to information
that can be jointly authored to good
effect (original scholarship and some artwork might not be in this category), if it is developed using
strong collaboration, the results will be superior in terms
of quantity and efficiency. But the
information needs to be reliable as well, and there is simply no substitute for
the involvement of people with mature and relatively reliable judgment--for
expert involvement. And experts will not
get involved in large numbers, I think, unless they are granted some degree of
control and oversight.
Open source software serves as an
excellent example here. The persons
leading the most successful open source projects are in general, regardless of
what credentials they may or may not have, competent and reliable in making
judgments about what new code should or should not get into a new release of
the software. Still, in a certain way,
software is relatively easy because either it does what it is intended to do,
or it does not. This is simply not the
case with text. An encyclopedia article,
tag, discussion post, dictionary entry, etc., just is, it's not a piece of code that compiles
and does what it's supposed to. So with collaboratively
developed content, it's often difficult to tell whether it's substandard--because
participants do not know or perhaps care about what the standards are, or in
some cases they reject the notion of standards at all. Good anarchists that they are, they are laws
unto themselves. By contrast, code is nice
in that it carries its standards with it, so to speak, in large part anyway.
Sometimes Wikipedia and other such
projects are called "open source," and it is said that, like real open source (software) projects,
they follow the maxims, "publish, then filter" and "publish early and publish
often." After previous essays I have
occasionally been accused of taking a step backward, i.e., of advocating that
strongly collaborative projects "filter, then
publish." That's a step backward because
it's the old content development model.
But this is not what I
recommend. In fact--and I am not the
first to make this observation--as a maxim, "publish, then filter" does not
really get at all relevant aspects of the dynamic. Instead, what is true of open source software
is what I recommend: "post widely, but internally among collaborators; then
filter; then publish." In other words,
code is immediately published internally, among
fellow coders; then the project managers decide what additions are in and
what additions are out; then the result is published externally, i.e., compiled
and released as a new version.
Collaborative open content development projects should work like this,
but they don't. The best of future
projects will, though, or so I maintain.
On this theme I want to convey two
messages. First, speaking to the open
source and open content community: I ask you to imagine if the
Establishment were to use the methods and principles (including shared
ownership and freedom) that you champion. Just imagine
what fantastic results would come of that.
Imagine that, and then ask yourselves what you can do, perhaps what in
your processes and attitudes you can change, to help see to it
information producers adopt the really productive
parts of your culture. And bear in mind
that they love the efficiency collaborative systems display, and they
principle opposed to freedom and openness.
Second, speaking to
traditional information producers (including academics): imagine a world, after
a new collaborative revolution, in which massive amounts of reliable information, nothing like
today's Internet, is available free for all. Isn't that something you would want to use
your influence to get behind, if it were possible? If such incredibly useful information
resources might very well be created with low overhead, then isn't it worth it,
at least as an experiment, to jettison top-down assignment and individual
authorship, and to explore the creative possibilities of modest business models
necessary to support the modest overhead?
It may or may not make you rich; but it might well make the world rich
in a way it has never been before.
There is a second, even longer part, which proposes a number of text projects that are to be creatively designed and run as "open meritocracies." Also of relevance: the Digital Universe has launched seven different initiatives recently.