[NEC] 1.4 - Broadcast Institutions, Community Values

[list-replies@shirky.com]

NEC @ Shirky.com, a mailing list about Networks, Economics, and Culture 

           Published periodically / # 1.4 / September 8, 2002 
              Subscribe at http://shirky.com/nec.html

In this issue:

 - Introduction
 - Quote of Note: Scott Bradner
 - Essay: Broadcast Institutions, Community Values
   (Also at http://www.shirky.com/writings/broadcast_and_community.html)
 - Worth Reading
     - David Isenberg on the telecom bubble
 - Literature Request: Social Software and Social Weather

* Introduction ========================================================

After an August hiatus, this month's essay is an extension of a speech
I gave at the BBC in mid-July about online community, and in
particular, about the ways in which assumptions made by media
organizations can actually hamper efforts to foster online community. 

I have also shamelessly stolen David Isenberg's "Quote of Note" feature
from his SMART newsletter. (http://isen.com/announce.html) 

-clay
clay@shirky.com

* Quote of Note =======================================================

"The internet makes it possible to do something without having to prove
in advance that it's a good idea."

  Scott Bradner of Harvard, from a talk on 10 good decisions that
  shaped the internet. (Dan Gillmor covered the talk in his SJ Mercury
  News column, 
  http://www.siliconvalley.com/mld/siliconvalley/business/columnists/dan_gillmor/4029770.htm)

* Essay ===============================================================

Broadcast Institutions, Community Values
(http://www.shirky.com/writings/broadcast_and_community.html)

[Note: This essay is an extension of a speech I gave at the BBC about
the prospects for online community building by broadcast media.]

There is a long history of businesses trying to harness the power of
online communities for commercial ends.  Most of these attempts have
failed, for the obvious reasons.  There are few products or services
people care about in a way that would make them want to join a
community, and when people are moved to speak out about a commercial
offering, it is usually to complain.

Media organizations, however, would seem to be immune to these
difficulties, because online media and online communities have the
same output: words and images.  Even here, though, there are
significant obstacles to hosting community, obstacles peculiar to the
nature of media.  Much of the discipline a broadcast organization must
internalize to do its job well are not merely irrelevant to community
building, but actively harmful.

If you were a broadcast media outlet thinking about community
building, here are five things you would think about:

1. Audiences are built. Communities grow.
2. Communities face a tradeoff between size and focus.
3. Participation matters more than quality.
4. You may own the software, but the community owns itself.
5. The community will want to build. Help it, or at least let it.

#1. Audiences are built. Communities grow.

Audiences are connected through broadcast.  Everyone in the MSNBC
audience sees MSNBC content broadcast outwards from the center.  You
can't build a community this way, because the things that make a
community worthwhile are provided by the members for one another, and
cannot be replaced by things the hosting organization can
offer.  Communities are connected through what Greg Elin calls
intercast -- the communications that pass among and between
interconnected members of a community.

Broadcast connections can be created by a central organization, but
intercast connections are created by the members for one another.
Communities grow, rather than being built. New members of an audience
are simply added to the existing pool, but new members of a community
must be integrated.  Matt Jones uses the word "loam" to describe the
kind of environment conducive to community formation.  One of the most
important things you can do to attract community is to give it a
fertile environment in which to grow, and one of the most damaging
things you can do is to try to force it to grow at a rapid pace or in
a preset direction.

#2. Communities face a tradeoff between size and focus.

Communities are held together through intercast communications, but,
to restate Metcalfe's Law, the complexity of intercast grows faster
than group size.  This means that in an intercast world, uniformly
dense interconnectedness becomes first hard and then impossible to
support as a group grows large.  The typical response for a growing
community is to sub-divide, in either "soft" ways (overlapping social
clusters) or "hard" ways (a church that splits into two congregations.)

Small groups can be highly focused on some particular issue or
identity, but such groups can't simply be inflated like a balloon,
because a large group is a different _kind_ of thing than a small
one.  Online groups that grow from small to large tend to lose their
focus, as topic drift or factionalization appears.

Most broadcast organizations assume that reaching a large group is an
unqualified good, so they push for size at any cost, and eventually
bump into the attendant tradeoffs:  you can have large community, but
not a highly focused one; you can have a focused community, but not a
large one; or you can reach a large number of people focused on a
particular issue, but it won't be a community.

With these options, broadcast organizations will (often unconsciously)
opt for the last one, simply building an audience and calling it a
community, as in "The community of our readers."  Though this may make
for good press release material, calling your audience a community
doesn't actually make it one.

#3. Participation matters more than quality.

The order of things in broadcast is "filter, then publish." The order
in communities is "publish, then filter."  If you go to a dinner
party, you don't submit your potential comments to the hosts, so that
they can tell you which ones are good enough to air before the group,
but this is how broadcast works every day.  Writers submit their
stories in advance, to be edited or rejected before the public ever
sees them.  Participants in a community, by contrast, say what they
have to say, and the good is sorted from the mediocre after the fact.

Media people often criticize the content on the internet for being
unedited, because everywhere one looks, there is low quality -- bad
writing, ugly images, poor design.  What they fail to understand is
that the internet is strongly edited, but the editorial judgment is
applied at the edges, not the center, and it is applied after the
fact, not in advance.  Google edits web pages by aggregating user
judgment about them, Slashdot edits posts by letting readers rate
them, and of course users edit all the time, by choosing what (and
who) to read.

Anyone who has ever subscribed to a high-volume mailing list knows
there are people who are always worth reading, and people who are
usually worth ignoring.  This is a way of raising the quality of what
gets read, without needing to control what gets written.  Media
outlets that try to set minimum standards of quality in community
writing often end up squeezing the life out of the discussion, because
they are so accustomed to filtering before publishing that they can't
imagine that filtering after the fact can be effective.

#4. You may own the software, but the community owns itself.

The relationship between the owner of community software and the
community itself is like the relationship between a landlord and his
or her tenants.  The landlord owns the building, and the tenants take
on certain responsibilities by living there.  However, the landlord
does not own the tenants themselves, nor their relations to one
another.  If you told tenants of yours that you expected to sit in on
their dinner table conversation, they would revolt, and, as many
organizations have found, the same reaction occurs in online
communities.

Community is made possible by software, but the value is created by
its participants.  If you think of yourself as owning a community when
you merely own the infrastructure, you will be astonished at the
vitriol you will face if you try to force that community into or out
of certain behaviors.

#5. The community will want to build. Help it, or at least let it.

Healthy communities modify their environment.  One of the surprises in
the design of software that supports community is that successful
innovations are often quite shallow.  We have had the necessary
technology to build weblogs since 1994, but weblogs themselves didn't
take off until 5 years later, not because the deep technology wasn't
there, but because the shallow technology wasn't.  Weblogs are
primarily innovations in interface, and, as importantly, innovations
in the attitudes of the users.

Because communal innovation often hinges as much on agreements among
users as protocols among machines, communities can alter their
environments without altering the underlying technology.  If you spend
any time looking at LiveJournal (one of the best overall examples of
good community engineering) you will see periodic epidemics of the
"Which type of pasta are you"-style quizzes. ("You're fusilli -- short
and twisted.")  The quizzes are not hosted on LiveJournal servers, but
they have become part of the LiveJournal community.

If LiveJournal had decided to create a complete, closed experience,
they could have easily blocked those quizzes.  However, they didn't
mistake owning the database for owning the users (see #4 above), so
they let the users import capabilities from elsewhere. The result is
that the community's connection to LiveJournal is strengthened, not
weakened, because over time the environment becomes fitted to the
community that uses it, even though nothing in the software itself
changes.
 
- Hard Work

If you want to host a community online, don't kid yourself into
believing that giving reporters weblogs and calling the reader
comments "community" is the same as the real thing.  Weblogs operate
on a spectrum from media outlet (e.g. InstaPundit) to communal
conversation (e.g. LiveJournal), but most weblogs are much more
broadcast than intercast.  Likewise, most comments are write-only
replies to the original post in the manner of Letters to the Editor,
rather than real conversations among the users.  This doesn't mean
that broadcast weblogs or user comments are bad; they just don't add
up to a community.

Real community is a self-creating thing, with some magic spark, easy
to recognize after the fact but impossible to produce on demand, that
draws people together.  Once those people have formed a community,
however, they will act in the interests of the community, even if
those aren't your interests. You need to be prepared for this.

The hallmark of a successful community is that it achieves some sort
of homeostasis, the ability to maintain an internal equilibrium in the
face of external perturbations.  One surprise is that if a community
forms on a site you host, they may well treat you, the owner of the
site, as an external perturbation.  Another surprise is that they will
treat growth as a perturbation as well, and they will spontaneously
erect barriers to that growth if they feel threatened by it.  They
will flame and troll and otherwise make it difficult for potential new
members to join, and they will invent in-jokes and jargon that makes
the conversation unintelligible to outsiders, as a way of raising the
bar for membership.

This does not mean that hosting community is never worthwhile -- the
communal aspects of sites like Slashdot and Kuro5hin are a critical
source of their value.  It just means that it is hard work, and will
require different skills and attitudes than those necessary to run a
good broadcast site.  Many of the expectations you make about the
size, composition, and behavior of audiences when you are in a
broadcast mode are actually damaging to community growth.  To create
an environment conducive to real community, you will have to operate
more like a gardener than an architect.

* Literature Request: Social Software and Social Weather ==============

My class at NYU this fall is called "Social Weather," and concerns the
way we can read group dynamics in real space with far greater ease and
refinement than we can online.  If you walk into a bar, you understand
the social weather immediately -- people are sitting alone, or in
couples, or groups, they're whispering or laughing or shouting, and so
on. Online spaces created by social software (such as mailing lists, or
chat rooms) have social weather as well, but as participants, we get
many fewer clues about the social weather than we do in the real
world. 

There are several obvious reasons for this, including limited
interfaces, separation of the participants in space and time, and a
lack of evolved familiarity with social software, but as we are living
in a golden age of social software, we have an opportunity to improve
this situtation.

This is part of my larger interest in social software generally, a
topic I am now pursuing on several fronts. I would appreciate any
pointers to interesting experiments or literature in the area of
understanding or improving the ability of groups to interact online.

* Worth Reading  ======================================================

David Isenberg's keynote at the World Technology Congress, given over
the summer, and reprinted at http://www.isen.com/archives/020723.html

A sample:

  The telephone company business model used to be based on vertical
  integration.  The network was a voice network.  The wires were voice
  wires.  The switches were voice switches.  You can say the same for
  cable TV.  The cable system was specialized for broadcasting video
  entertainment.  These were special-purpose networks.

  The Internet, in sharp contrast, is a general-purpose network.  It
  will carry anything.  The Internet does not care whether it is
  carrying voice or video or financial data or email or pictures.

  The Internet pushes the decision "What to carry," to its edges.  It
  pushes the decision "How to use the network," right into the lap of
  the end user.  This is a direct consequence of the Internet's
  architecture.

* End =================================================================

Copyright 2002, Clay Shirky
Feel free to reprint, quote, or forward, so long as you credit me.