[NEC] 2.4: Social Software and the Politics of Groups

[list-replies@shirky.com]

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

           Published periodically / # 2.4 / March 9, 2003 
        Licensed under the Creative Commons Attribution License
               Subscribe at http://shirky.com/nec.html

In this issue:

 - Introduction
 - Essay: Social Software and the Politics of Groups
    (Also at http://www.shirky.com/writings/group_politics.html)
 - Reactions to "Power Laws, Weblogs, and Inequality"
 - Microsoft and .NET patents: I'd rather have been wrong 
 - Worth Reading
   - Joi Ito and Socialtext on Happenings
   - Greg Elin's Image Selection Tool
   - Bob Horn on Knowledge Mapping for Complex Social Messes

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

Social software again, this time an essay about the ways in which
group software encodes political bargains between individuals and the
group, and what kinds of questions we should be asking ourselves about
those bargains.

A couple of housekeeping notes.  My ugly home and article pages,
rendered in the "Hey, I know HTML!" style in vogue circa 1997, have
been replaced by much nicer versions, courtesy Mike Essl of essl.com.

I am also launching an RSS feed, enabled by Rael Dornfest's remarkable
blosxom weblog tool (http://www.raelity.org/apps/blosxom/).  The URL
is http://shirky.com/writings/rss.cgi.  I am still trying to figure
out how to make the RSS feed as useful as it can be -- feedback
eagerly accepted.

-clay

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

Social Software and the Politics of Groups
  http://www.shirky.com/writings/group_politics.html

Social software, software that supports group communications, includes
everything from the simple CC: line in email to vast 3D game worlds
like EverQuest, and it can be as undirected as a chat room, or as
task-oriented as a wiki (a collaborative workspace). Because there are
so many patterns of group interaction, social software is a much
larger category than things like groupware or online
communities. Though it includes those things, not all group
communication is business-focused or communal. One of the few
commonalities in this big category is that social software is unique
to the internet in a way that software for broadcast or personal
communications are not.

Prior to the Web, we had hundreds of years of experience with
broadcast media, from printing presses to radio and TV.  Prior to
email, we had hundreds of years experience with personal media -- the
telegraph, the telephone.  But outside the internet, we had almost
nothing that supported conversation among many people at once.
Conference calling was the best it got -- cumbersome, expensive,
real-time only, and useless for large groups.  The social tools of the
internet, lightweight though most of them are, have a kind of fluidity
and ease of use that the conference call never attained: compare the
effortlessness of CC:ing half a dozen friend to decide on a movie,
versus trying to set up a conference call to accomplish the same task.

The radical change was de-coupling groups in space and time.  To get a
conversation going around a conference table or campfire, you need to
gather everyone in the same place at the same moment.  By undoing
those restrictions, the interent has ushered in a host of new social
patterns, from the mailing list to the chat room to the weblog.

The thing that makes social software behave differently other
communications tools is that groups are entities in their own right. A
group of people interacting with one another will exhibit be behaviors
that cannot be predicted by examining the individuals in isolation,
peculiarly social effects like flaming and trolling or concerns about
trust and reputation.  This means that designing software for
group-as-user is a problem that can't be attacked in the same way as
designing a word processor or a graphics tool.

Our centuries of experience with printing presses and telegraphs have
not prepared us for the design problems we face here.  We have had
real social software for less than forty years (dated from the Plato
system), with less than a decade of general availability.  We are
still learning how to build and use the software-defined conference
tables and campfires we're gathering around.

- Old Systems, Old Assumptions

When the internet was strange and new, we concentrated on its strange
new effects.  Earlier generations of social software, from mailing
lists to MUDs, were created when the network's population could be
measured in the tens of thousands, not the hundreds of millions, and
the users were mostly young, male, and technologically savvy.  In
those days, we convinced ourselves that immersive 3D environments and
changing our personalities as often as we changed socks would be the
norm.

That period, which ended with the rise of the Web in the early 1990s,
was the last time the internet was a global village, and the software
built for this environment typically made three assumptions about
groups: they could be of any size; anyone should be able to join them;
and the freedom of the individual is more important than the goals of
the community.

The network is now a global metropolis, vast and heterogeneous, and in
this environment groups need protection from too-rapid growth and from
being hijacked by anything from off-topic conversations to spam.  The
communities that thrive in this metropolitan environment violate most
or all of the earlier assumptions.  Instead of unlimited growth,
membership, and freedom, many of the communities that have done well
have bounded size or strong limits to growth, non-trivial barriers to
joining or becoming a member in good standing, and enforceable
community norms that constrain individual freedoms.  Forums that lack
any mechanism for ejecting or controlling hostile users, especially
those convened around contentious topics, have often broken down under
the weight of user hostile to the conversation (viz usenet groups like
soc.culture.african.american.)

- Social Software Encodes Political Bargains

Social interaction creates a tension between the individual and the
group.  This is true of all social interaction, not just online.
Consider, from your own life, that moment where you become bored with
a dinner party or other gathering.  You lose interest in the event,
and then, having decided it is not for you, a remarkable thing
happens: you don't leave.  For whatever reason, usually having to do
with not wanting to be rude, your dedication to group norms overrides
your particular boredom or frustration.  This kind of tension between
individual goals and group norms arises at some point in most groups.

Any system that supports groups addresses this tension by enacting a
simple constitution -- a set of rules governing the relationship
between individuals and the group.  These constitutions usually work
by encouraging or requiring certain kinds of interaction, and
discouraging or forbidding others.  Even the most anarchic
environments, where "Do as thou wilt" is the whole of the law, are
making a constitutional statement.  Social software is political
science in executable form.

Different constitutions encode different bargains.  Slashdot's core
principle, for example, is "No censorship"; anyone should be able to
comment in any way on any article.  Slashdot's constitution (though it
is not called that) specifies only three mechanisms for handling the
tension between individual freedom to post irrelevant or offensive
material, and the group's desire to be able to find the interesting
comments.  The first is moderation, a way of convening a jury pool of
members in good standing, whose function is to rank those posts by
quality.  The second is meta-moderation, a way of checking those
moderators for bias, as a solution to the "Who will watch the
watchers?" problem.  And the third is karma, a way of defining who is
a member in good standing.  These three political concepts,
lightweight as they are, allow Slashdot to grow without becoming
unusable.

The network abounds with different political bargains, like 
Kuro5hin's distributed editorial function
[http://www.kuro5hin.org/?op=special;page=moderation], 
LiveJournal's invitation codes
[http://www.livejournal.com/support/faqbrowse.bml?faqcat=accounts],
MetaFilter's closing off of user signups during population surges
[http://www.metafilter.com/newuser.mefi], 
Joel Spolsky's design principles for the Joel on Software forum,
[http://www.joelonsoftware.com/articles/BuildingCommunitieswithSo.html]
or the historical reactions of earlier social spaces like LambdaMOO
[http://www.cc.gatech.edu/classes/AY2001/cs6470_fall/LTAND.html] or
Habitat [http://www.scara.com/~ole/literatur/LessonsOfHabitat.html] to
constitutional crises) are all ways of responding to the fantastically
complex behavior of groups.  The variables include different effects
at different scales (imagine the conversation at a dinner for 6, 60,
and 600), the engagement of the users, and the degree to which
participants feel themselves to be members of a group with formal goals.

Further complicating all of this are the feedback loops created when a
group changes its behavior in response to changes in software.
Because of these effects, designers of social software have more in
common with economists or political scientists than they do with
designers of single-user software, and operators of communal resources
have more in common with politicians or landlords than with operators
of ordinary web sites.

- Testing Group Experience

Social software has progressed far less quickly than single-user
software, in part because we have a much better idea of how to improve
user experience than group experience, and a much better idea of how
to design interfaces than constitutions.  While word processors and
graphics editors have gotten significantly better over the years, the
features for mailing lists are not that different from the original
LISTSERV program in 1985.  In fact, most of the work on mailing list
software has been around making it easier to set up and administer,
rather than making it easier for the group using the software to
accomplish anything.

We have lots of interesting examples of social software, from the
original SF-LOVERS mailing list, which ifrst appeared in 1970s and
outlived all the hardware of the network it launched on, to the
Wikipedia, a giant community-created encyclopedia.  Despite a wealth
of examples, however, we don't have many principles derived from those
examples other than "No matter how much the administrators say its
'for work', people will press communications tools to social uses."
[http://tigger.uic.edu/~wplotk1/usia/hist.html] or "It sure is weird
that the Wikipedia works."
[http://www.wikipedia.org/wiki/Wikipedia%3AOur_Replies_to_Our_Critics]
We have historically overestimated the value of network access to
computers, and underestimated the value of network access to other
people, so we have spent much more time on the technical rather than
social problems of software used by groups.

One fruitful question might be "How can we test good group
experience?" Over the last several years, the importance of user
experience, user testing, and user feedback have become obvious, but
we have very little sense of group experience, group testing, or group
feedback.  If a group uses software that encourages constant forking
of topics, so that conversations become endless and any given
conversation peters out rather than being finished, each participant
might enjoy the conversation, but the software may be harming the
group goal by encouraging tangents rather than focus.

If a group has a goal, how can we understand the way the software
supports that goal?  This is a complicated question, not least because
the conditions that foster good group work, such as clear decision-
making process, may well upset some of the individual participants.
Most of our methods for soliciting user feedback assume, usually
implicitly, that the individual's reaction to the software is the
critical factor.  This tilts software and interface design towards
single-user assumptions, even when the software's most important user
is a group.

- Barriers

Another critical question: "What kind of barriers work best?"  Most
groups have some sort of barrier to group membership, which can be
thought of as a membrane separating the group from the rest of the
world.  Sometimes it is as simple as the energy required to join a
mailing list.  Sometimes it is as complicated as getting a sponsor
within the group, or acquiring a password or key.  Sometimes the
membrane is binary and at the edge of the group -- you're on the
mailing list or not.  Sometimes its gradiated and internal, as with
user identity and karma on Slashdot.  Given the rich history we have
with such social membranes, can we draw any general conclusions about
their use by analyzing successes (or failures) in existing social
software?

There are thousands of other questions.   Can we produce diagrams of
social networks in real time, so the participants in a large group can
be aware of conversational clusters as they are forming?  What kind of
feedback loops will this create?  Will software that lets groups form
with a pre-set dissolution date ("This conversation good until
08/01/2003.") help groups focus?  Can we do anything to improve the
online environment for brainstorming?  Negotiation?  Decision making?
Can Paypal be integrated into group software, so that groups can raise
and disperse funds in order to pursue their goals?  (Even Boy Scouts do
this in the real world, but it's almost unheard of online.) And so on.

We are living in a period of incredible ferment for social software.
The last time there was this much foment around the idea of software
to be used by groups was in the late 70s, when usenet, irc and MUDs
were all invented in the space of 18 months.  Now we've got blogs,
wikis, RSS feeds, Trackback, XML-over-IM and all sorts of IM- and
mail-bots.  We've also got a network population that's large,
heterogeneous, and still growing rapidly.  The conversations we can
have about social software can be advanced by asking ourselves the
right questions about both the software and the political bargains
between users and the group that software will encode or enforce.  

-=-

* Reactions to "Power Laws, Weblogs, and Inequality" =================

Last issue's essay, on weblogs and power laws, sparked quite a bit of
interest and controversy -- at one point, Daypop.com showed something
like 150 weblogs pointing to the article. The conversation it started
is far too diverse to summarize, but one thing from the overall
pattern did jump out at me.  A number of people wanted to disbelieve
the essay's premise, because it seemed to suggest that there were
forces at work larger than the will of individual webloggers, and the
weblog world generally favors the idea that the individual is master
of his or her own destiny.

Seeing this reaction, I thought "Ah, the 'Power Law' piece is an
article from 2004 that happened to appear in 2003," because I assumed
that by 2004, the idea of large forces shaping the weblog world would
be commonplace.

I was right about the change, but wrong about the timing. It turns out
that it was an article from March that was published in February.
After Google bought Pyra/Blogger and brought weblogging into the big
time (with the attendant envy from people whose companies were not
bought), and after Dr. Pepper announced that it was wooing alpha
webloggers to recommend its new milk product Raging Cow (it's a good
thing I write non-fiction because I couldn't make this stuff up), it
is now clear to all and sundry that there are things other than the
individual blogger shaping the environment.

I suspect that if I'd published the article today, it would get the
same degree of technical attention from social network geeks that it
got last month, but that its broader claims about structural
inequality would be much less contentious.  I will probably test this
notion later this year, when I put out another piece on social
patterns of weblogging.

One other reaction that particularly sparked my interest: first, David
Sifry, creator of Technorati.com and the notion of a "link cosmos",
added a new category to the Technrati lists called "Interesting
Newcomers," as a way of turning up new weblogs who might be
overshadowed by the weblogs at the left-hand edge of the power law
curve. The forumula is, roughly, what _percentage_ of new links have
you gottne recently, so a weblog with 20 people pointing to that gains
an additional 10 links will do better than a weblog with 50 links that
gains an additional 5.  (It's obviously more complicated than that,
but that's the basic notion.) This does nothing to change the power
law distribution, but it may make it more dynamic, and less likely to
produce homeostasis at the top of the list. Sifry's list is at
http://www.technorati.com/cosmos/interestingnewcomers.html

* Microsoft and .NET patents: I'd rather have been wrong  ================

In May of 2001, in a piece I wrote for O'Reilly about Microsoft's move
into Web Services, I made the following prediction:

  With HailStorm [later folded into .Net], Microsoft is shifting
  from a strategy of controlling software to controlling
  transactions. Instead of selling units of licensed software,
  Hailstorm will allow them to offer services to other developers,
  even those working on non-Microsoft platforms, while owning the
  intellectual property which underlies the authentications and
  transactions, a kind of "describe and defend" strategy.

  "Describe and defend" is a move away from "software as unit" to
  "software as service," and means that their control of the HailStorm
  universe will rely less on software licenses and more on patented or
  copyrighted methods, procedures, and database schema.
    (http://www.openp2p.com/pub/a/p2p/2001/05/30/hailstorm.html)

Not quite two years later, C|Net reported that Microsoft is applying
for a patent that would allow Microsoft to "...dictate how, or
whether, developers of software and devices can link to the .Net
initiative." http://news.com.com/2100-1001-984052.html

This is where open systems will really get tested. To what degree can
the law be used to prevent interoperability of systems based on open
standards like XML?

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

- Happenings

Joi Ito and the folks at Socialtext (full disclosure: I am on the
Socialtext board of advisors) have both posted descriptions of a
Happening, a way of combining conference calls, wikis, and chat rooms
to create focused conversations that are more participatory and more
valuable for the attendees than any of those technologies can produce
alone.

Joi: http://www.openp2p.com/pub/a/p2p/2002/12/26/inroom_chat.html
Socialtext: http://www.socialtext.com/weblog/archives/021903happening.html

The two most important effects of these Happenings are that they allow
the group size to grow to a range of at least two dozen participants,
and that they leave behind a valuable artifact, in the form of written
material contributed by the participants, including especially
pointers to other relevant work (a sort of emergent bibliography.)

- Image Selection Tool

My colleague Greg Elin has launched his Image Selection Tool, at 
http://www.imageselectiontool.com/. Greg's insight is that while every
picture tells a story, it could use a little help. In particular, the
software allows users to embed descriptions of the image in the image,
using JPEG header infor (it only works with JPEG), and also lets you
manage collections of images and stories together as a single package.

- Knowledge Mapping for Complex Social Messes

With a title like that, I don't have to explain it to get you to
click, do I?  It's Bob Horn's work, and worth a read.

http://www.stanford.edu/~rhorn/images/SpchPackard/spchKnwldgPACKARD.pdf

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

This work is licensed under the Creative Commons Attribution License.
The licensor permits others to copy, distribute, display, and perform
the work.  In return, licensees must give the original author credit.

To view a copy of this license, visit
http://creativecommons.org/licenses/by/1.0 

or send a letter to
Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

2003, Clay Shirky