[NEC] #3.6: Group as User

[nec at shirky.com]

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

           Published periodically / #3.6 / November 5, 2004 
               Subscribe at http://shirky.com/nec.html
			       Archived at http://shirky.com
          Social Software weblog at http://corante.com/many/

In this issue:

 - Introduction
 - Essay: Group as User: Flaming and the Design of Social Software
     Also at http://www.shirky.com/writings/group_user.html
 - Other notes:
   Fred Wilson's Open Source Conversion
   Gordon Bell Explains Linux   

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

A year and a half ago I suggested, in A Group Is Its Own Worst Enemy,
[http://shirky.com/writings/group_enemy.html] that 

  It has to be hard to do at least some things on the system for some
  users, or the core group will not have the tools that they need to
  defend themselves [against rogue users].

  Now, this pulls against the cardinal virtue of ease of use. But ease
  of use is wrong. Ease of use is the wrong way to look at the
  situation, because youve got the Necker cube [of individual and
  group effects] flipped in the wrong direction. The user of social
  software is the group, not the individual."

The current essay continues the Group-as-User line of thought,
examining the latent social experiment we've seen in flaming and
attempts to control it, and suggesting some possible experiments in
social forms as a result of those observations.

-clay

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

Group as User: Flaming and the Design of Social Software
  http://shirky.com/writings/group_user.html

When we hear the word "software," most of us think of things like
Word, Powerpoint, or Photoshop, tools for individual users. These
tools treat the computer as a box, a self-contained environment in
which the user does things. Much of the current literature and
practice of software design -- feature requirements, UI design,
usability testing -- targets the individual user, functioning in
isolation.

And yet, when we poll users about what they actually do with their
computers, some form of social interaction always tops the list --
conversation, collaboration, playing games, and so on. The practice of
software design is shot through with computer-as-box assumptions,
while our actual behavior is closer to computer-as-door, treating the
device as an entrance to a social space.

We have grown quite adept at designing interfaces and interactions
between computers and machines, but our social tools -- the software
the users actually use most often -- remain badly misfit to their
task. Social interactions are far more complex and unpredictable than
human/computer interaction, and that unpredictability defeats classic
user-centric design. As a result, tools used daily by tens of millions
are either ignored as design challenges, or treated as if the only
possible site of improvement is the user-to-tool interface.
 
The design gap between computer-as-box and computer-as-door persists
because of a diminished conception of the user. The user of a piece of
social software is not just a collection of individuals, but a
group. Individual users take on roles that only make sense in groups:
leader, follower, peacemaker, process nazi, and so on. There are also
behaviors that can only occur in groups, from consensus building to
social climbing. And yet, despite these obvious differences between
personal and social behaviors, we have very little design practice
that treats the group as an entity to be designed for.
 
There is enormous value to be gotten in closing that gap, and it
doesn't require complicated new tools. It just requires new ways of
looking at old problems. Indeed, much of the most important work in
social software has been technically simple but socially complex.

- Learning From Flame Wars
 
Mailing lists were the first widely available piece of social
software. (The PLATO system beat mailing lists by a decade, but had a
limited user base.) Mailing lists were also the first widely analyzed
virtual communities. And for roughly thirty years, almost any
description of mailing lists of any length has mentioned flaming, the
tendency of list members to forgo standards of public decorum when
attempting to communicate with some ignorant moron whose to stupid to
know how too spell and deserves to DIE, die a PAINFUL DEATH, you PINKO
SCUMBAG!!!
 
Yet despite three decades of descriptions of flaming, it is often
treated by designers as a mere side-effect, as if each eruption of a
caps-lock-on argument was surprising or inexplicable.

Flame wars are not surprising; they are one of the most reliable
features of mailing list practice. If you assume a piece of software
is for what it does, rather than what its designer's stated goals
were, then mailing list software is, among other things, a tool for
creating and sustaining heated argument. (This is true of other
conversational software as well -- the WELL, usenet, Web BBSes, and so
on.)

This tension in outlook, between 'flame war as unexpected side-effect'
and 'flame war as historical inevitability,' has two main causes.  The
first is that although the environment in which a mailing list runs is
computers, the environment in which a flame war runs is people. You
couldn't go through the code of the Mailman mailing list tool, say,
and find the comment that reads "The next subroutine ensures that
misunderstandings between users will be amplified, leading to
name-calling and vitriol." Yet the software, when adopted, will
frequently produce just that outcome.
 
The user's mental model of a word processor is of limited importance
-- if a word processor supports multiple columns, users can create
multiple columns; if not, then not. The users' mental model of social
software, on the other hand, matters enormously. For example,
'personal home pages' and weblogs are very similar technically -- both
involve local editing and global hosting. The difference between them
was mainly in the user's conception of the activity. The pattern of
weblogging appeared before the name weblog was invented, and the name
appeared before any of the current weblogging tools were
designed. Here the shift was in the user's mental model of publishing,
and the tools followed the change in social practice.
 
In addition, when software designers do regard the users of social
software, it is usually in isolation. There are many sources of this
habit: ubiquitous network access is relatively recent, it is
conceptually simpler to treat users as isolated individuals than as
social actors, and so on. The cumulative effect is to make maximizing
individual flexibility a priority, even when that may produce conflict
with the group goals.

Flaming, an un-designed-for but reliable product of mailing list
software, was our first clue to the conflict between the individual
and the group in mediated spaces, and the initial responses to it were
likewise an early clue about the weakness of the single-user design
center.

- Netiquette and Kill Files

The first general response to flaming was netiquette. Netiquette was a
proposed set of behaviors that assumed that flaming was caused by (who
else?) individual users. If you could explain to _each_ user what
was wrong with flaming, _all_ users would stop.

This mostly didn't work. The problem was simple -- the people who
didn't know netiquette needed it most. They were also the people least
likely to care about the opinion of others, and thus couldn't be
easily convinced to adhere to its tenets.
 
Interestingly, netiquette came tantalizingly close to addressing group
phenomena. Most versions advised, among other techniques, contacting
flamers directly, rather than replying to them on the list. Anyone who
has tried this technique knows it can be surprisingly effective. Even
here, though, the collective drafters of netiquette misinterpreted
this technique. Addressing the flamer directly works not because he
realizes the error of his ways, but because it deprives him of an
audience. Flaming is not just personal expression, it is a kind of
performance, brought on in a social context.

This is where the 'direct contact' strategy falls down. Netiquette
docs typically regarded direct contact as a way to engage the flamer's
rational self, and convince him to forgo further flaming. In practice,
though, the recidivism rate for flamers is high. People behave
differently in groups, and while momentarily engaging them one-on-one
can have a calming effect, that is a change in social context, rather
than some kind of personal conversion. Once the conversation returns
to a group setting, the temptation to return to performative outbursts
also returns.
 
Another standard answer to flaming has been the kill file, sometimes
called a bozo filter, which is a list of posters whose comments you
want filtered by the software before you see them. (In the lore of
usenet, there is even a sound effect -- *plonk* -- that the
kill-file-ee is said to make when dropped in the kill file.)

Kill files are also generally ineffective, because merely removing one
voice from a flame war doesn't do much to improve the signal to noise
ratio -- if the flamer in question succeeds in exciting a response,
removing his posts alone won't stem the tide of pointless replies. And
although people have continually observed (for thirty years now) that
"if everyone just ignores user X, he will go away," the logic of
collective action makes that outcome almost impossible to orchestrate
-- it only takes a couple of people rising to bait to trigger a flame
war, and the larger the group, the more difficult it is to enforce the
discipline required of all members.

- The Tragedy of the Conversational Commons

Flaming is one of a class of economic problems known as <a
href="http://dieoff.org/page95.htm">The Tragedy of the
Commons</a>. Briefly stated, the tragedy of the commons occurs when a
group holds a resource, but each of the individual members has an
incentive to overuse it. (The original essay used the illustration of
shepherds with common pasture. The group as a whole has an incentive
to maintain the long-term viability of the commons, but with each
individual having an incentive to overgraze, to maximize the value
they can extract from the communal resource.)

In the case of mailing lists (and, again, other shared conversational
spaces), the commonly held resource is communal attention. The group
as a whole has an incentive to keep the signal-to-noise ratio low and
the conversation informative, even when contentious. Individual users,
though, have an incentive to maximize expression of their point of
view, as well as maximizing the amount of communal attention they
receive. It is a deep curiosity of the human condition that people
often find negative attention more satisfying than inattention, and
the larger the group, the likelier someone is to act out to get that
sort of attention.

However, proposed responses to flaming have consistently steered away
from group-oriented solutions and towards personal ones.  The logic of
collective action, alluded to above, rendered these personal solutions
largely ineffective.  Meanwhile attempts at encoding social bargains
weren't attempted because of the twin forces of door culture (a
resistance to regarding social features as first-order effects) and a
horror of censorship (maximizing individual freedom, even when it
conflicts with group goals.)

- Weblog and Wiki Responses

When considering social engineering for flame-proofed-ness, it's
useful to contemplate both weblogs and wikis, neither of which suffer
from flaming in anything like the degree mailing lists and other
conversational spaces do. Weblogs are relatively flame-free because
they provide little communal space. In economic parlance, weblogs
solve the tragedy of the commons through enclosure, the subdividing
and privatizing of common space.
 
Every bit of the weblog world is operated by a particular blogger or
group of bloggers, who can set their own policy for accepting
comments, including having no comments at all, deleting comments from
anonymous or unfriendly visitors, and so on. Furthermore, comments are
almost universally displayed away from the main page, greatly limiting
their readership. Weblog readers are also spared the need for a bozo
filter. Because the mailing list pattern of 'everyone sees everything'
has never been in effect in the weblog world, there is no way for
anyone to hijack existing audiences to gain attention.
 
Like weblogs, wikis also avoid the tragedy of the commons, but they do
so by going to the other extreme. Instead of everything being owned,
nothing is. Whereas a mailing list has individual and inviolable posts
but communal conversational space, in wikis, even the writing is
communal. If someone acts out on a wiki, the offending material can be
subsequently edited or removed. Indeed, the history of the Wikipedia ,
host to communal entries on a variety of contentious topics ranging
from Islam to Microsoft, has seen numerous and largely failed attempts
to pervert or delete entire entries. And because older versions of
wiki pages are always archived, it is actually easier to restore
damage than cause it. (As an analogy, imagine what cities would look
like if it were easier to clean graffiti than to create it.)

Weblogs and wikis are proof that you can have broadly open discourse
without suffering from hijacking by flamers, by creating a social
structure that encourages or deflects certain behaviors. Indeed, the
basic operation of both weblogs and wiki -- write something locally,
then share it -- is the pattern of mailing lists and BBSes as
well. Seen in this light, the assumptions made by mailing list
software looks less like The One True Way to design a social contract
between users, and more like one strategy among many.

- Reviving Old Tools

This possibility of adding novel social components to old tools
presents an enormous opportunity. To take the most famous example, the
Slashdot moderation system puts the ability to rate comments into the
hands of the users themselves. The designers took the traditional
bulletin board format -- threaded posts, sorted by time -- and added a
quality filter. And instead of assuming that all users are alike, the
Slashdot designers created a karma system, to allow them to
discriminate in favor of users likely to rate comments in ways that
would benefit the community. And, to police _that_ system, they
created a meta-moderation system, to solve the 'Who will guard the
guardians' problem. (All this is documented in the <a
href="http://slashdot.org/faq/com-mod.shtml#cm600">Slashdot FAQ</a>,
our version of <a
href="http://www.yale.edu/lawweb/avalon/federal/fed10.htm">Federalist
Papers #10</a>.)

Rating, karma, meta-moderation -- each of these systems is relatively
simple in technological terms. The effect of the whole, though, has
been to allow Slashdot to support an enormous user base, while
rewarding posters who produce broadly valuable material and
quarantining offensive or off-topic posts.

Likewise, Craigslist took the mailing list, and added a handful of
simple features with profound social effects. First, all of Craigslist
is an enclosure, owned by Craig (whose title is not Founder, Chairman,
and Customer Service Representative for nothing.) Because he has a
business incentive to make his list work, he and his staff remove
posts if enough readers flag them as inappropriate. Like Slashdot, he
violates the assumption that social software should come with no group
limits on individual involvement, and Craigslist works better because
of it.

And, on the positive side, the addition of a "Nominate for 'Best of
Craigslist'" button in every email creates a social incentive for
users to post amusing or engaging material. The 'Best of' button is a
perfect example of the weakness of a focus on the individual user. In
software optimized for the individual, such a button would be
incoherent -- if you like a particular post, you can just save it to
your hard drive. But users don't merely save those posts to their hard
drives; they click that button. Like flaming, the 'Best of' button
also assumes the user is reacting in relation to an audience, but here
the pattern is harnessed to good effect. The only reason you would
nominate a post for 'Best of' is if you wanted other users to see it
-- if you were acting in a group context, in other words.

- Novel Operations on Social Facts

Jonah Brucker-Cohen's <a href="http://www.bumplist.net">Bumplist</a>
stands out as an experiment in experimenting the social aspect of
mailing lists. Bumplist, whose motto is "an email community for the
determined", is a mailing list for 6 people, which anyone can
join. When the 7th user joins, the first is bumped and, if they want
to be back on, must re-join, bumping the second user, ad
infinitum. (As of this writing, Bumplist is at 87,414 subscribes and
81,796 re-subscribes.) Bumplist's goal is more polemic than practical;
Brucker-Cohen describes it as a re-examination of the culture and
rules of mailing lists.  However, it is a vivid illustration of the
ways simple changes to well-understood software can produce radically
different social effects.

You could easily imagine many such experiments. What would it take,
for example, to design a mailing list that was flame-retardant? Once
you stop regarding the all users as isolated actors, a number of
possibilities appear. You could institute induced lag, where, once a
user contributed 5 posts in the space of an hour, a cumulative 10
minute delay would be added to each subsequent post. Every post would
be delivered eventually, but it would retard the rapid-reply nature of
flame wars, introducing a cooling off period for the most vociferous
participants.

You could institute a kind of thread jail, where every post would
include a 'Worst of' button, in the manner of
Craigslist. Interminable, pointless threads (e.g. Which Operating
System Is Objectively Best?) could be sent to thread jail if enough
users voted them down. (Though users could obviously change subject
headers and evade this restriction, the surprise, first noted by
Julian Dibbell, is how often users respect negative _communal_
judgment, even when they don't respect the negative judgment of
individuals. [<a href="http://www.juliandibbell.com/texts/bungle.html">
Rape in Cyberspace</a> -- search for "aggressively antisocial vibes."])

You could institute a 'Get a room!' feature, where any conversation
that involved two users ping-ponging six or more posts (substitute
other numbers to taste) would be automatically re-directed to a
sub-list, limited to that pair. The material could still be archived,
and so accessible to interested lurkers, but the conversation would
continue without the attraction of an audience.

You could imagine a similar exercise, working on signal/noise ratios
generally, and keying off the fact that there is always a most active
poster on mailing lists, who posts much more often than even the
second most active, and much _much_ more often than the median
poster. Oddly, the most active poster is often not even aware that
they occupy this position (seeing ourselves as others see us is
difficult in mediated spaces as well,) but making them aware of it
often causes them to self-moderate. You can imagine flagging all posts
by the most active poster, whoever that happened to be, or throttling
the maximum number of posts by any user to some multiple of average
posting tempo.

And so on. The number of possible targets for experimentation is large
and combinatorial, and those targets exist in any social context, not
just in conversational spaces.

- Rapid, Iterative Experimentation

Though most of these sorts of experiments won't be of much value,
rapid, iterative experiment is the best way to find those changes that
are positive. The Slashdot FAQ makes it clear that the now-stable
ratings+karma+meta-moderation system could only have evolved with
continued adjustment over time. This was possible because the
engineering challenges were relatively straightforward, and the user
feedback swift.
 
That sort of experimentation, however, has been the exception rather
than the rule. In thirty years, the principal engineering work on
mailing lists has been on the administrative experience -- the Mailman
tool now offers a mailing list administrator nearly a hundred
configurable options, many with multiple choices. However, the
_social_ experience of a mailing list over those three decades
has hardly changed at all.

 This is not because experimenting with social experience is
technologically hard, but because it is conceptually foreign. The
assumption that the computer is a box, used by an individual in
isolation, is so pervasive that it is adhered to even when it leads to
investment of programmer time in improving every aspect of mailing
lists except the interaction that makes them worthwhile in the
first place.

Once you regard the group mind as part of the environment in which the
software runs, though, a universe of un-tried experimentation opens
up. A social inventory of even relatively ancient tools like mailing
lists reveals a wealth of untested models. There is no guarantee that
any given experiment will prove effective, of course. The feedback
loops of social life always produce unpredictable effects. Anyone
seduced by the idea of social perfectibility or total control will be
sorely disappointed, because users regularly reject attempts to affect
or alter their behavior, whether by gaming the system or abandoning
it.

But given the breadth and simplicity of potential experiments, the
ease of collecting user feedback, and most importantly the importance
users place on social software, even a few successful improvements,
simple and iterative though they may be, can create disproportionate
value, as they have done with Craigslist and Slashdot, and as they
doubtless will with other such experiments.

* Other Notes  ===========================================================

- Fred Wilson's Open Source conversion

There was an amazing thread on Fred Wilson's blog, spread out over a
week in early October, related to his outlook on the tech industry
after installing Firefox.

First, tries Firefox, on the recommendation of another VC. 
  http://avc.blogs.com/a_vc/2004/10/firefox.html

Then he says "Interesting, but not such a big deal."
  http://avc.blogs.com/a_vc/2004/10/firefox_continu.html">Interesting,

Then, on getting some clue from a blog reader about tabbed browsing,
he says "Interesting, and maybe a big deal."
  http://avc.blogs.com/a_vc/2004/10/firefox_continu_1.html

Then he groks Open Source as a consumer phenomenon.
  http://avc.blogs.com/a_vc/2004/10/open_source.html
 
Then he sells all his Microsoft stock. 
  http://avc.blogs.com/a_vc/2004/10/open_source_con.html

Then he defends that decision, predicting a tidal wave of community
driven software development.
  http://avc.blogs.com/a_vc/2004/10/open_source_con_1.html

And the remarkable thing about seeing it blog format is that he never
tells the whole story of his conversion in a coherent, retrospective
way. you just see it unfold as he did.

* Gordon Bell Explains Linux to Steve Ballmer

Well, not really, but he explained it for the rest of us, and
Mr. Ballmer could read it as easily wa we can.

Here's Ballmer's take on operating system piracy, from the article
Ballmer calls for $100 PC [Ballmer calls for $100 PC -
http://hardware.silicon.com/desktops/0,39024645,39125161,00.htm] 

  "The biggest problem we have right now is that people who should be
  paying for software aren't," Ballmer told an audience of technology
  executives at an industry conference in Orlando, Florida sponsored
  by market researcher Gartner.

  One way to stem piracy is to offer consumers in emerging countries a
  low-cost PC, Ballmer said. "There has to be... a $100 computer to go
  down-market in some of these countries. We have to engineer [PCs] to
  be lighter and cheaper," he said."

And here's Gordon Bell on the nature of standards, from an ACM article
entitled A Time and Place for Standards
[http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=210&page=3]

  People buy products, not protocols or algorithms. A little more than
  a decade ago, it looked as if the people who developed MPEG coding
  would make a bundle since, at the time, encoding and decoding files
  required a special off-board processor. Before long, however, CPUs
  powerful enough to handle the MPEG processing on their own came to
  market, suddenly extinguishing any demand for special MPEG
  chips. Because this also had the effect of eliminating any place for
  patent royalties to "hide", fantasies of fortunes to be derived from
  MPEG were quickly dispelled.

Not only does Ballmer have it wrong, in other words, he has it
backwards. 

I remember realizing, in the late 90s, that other than the hard drive,
the operating system had become the single most expensive part of a
PC, and this realization came courtesy the wonderful Dell "Design your
own computer" site. For the first time, the price of the OS had
nowhere to hide, in Gordon's phrase.

Since then, of course, the cost of storage has gone through the floor,
making the OS the single most expensive part of many standard-issue
PCs, and a $100 computer will only make it worse. When the hardware
gets that cheap, and it's close now, the choice will become "run
windows XP buy 1 PC; run Linux, and buy a second PC with the savings." 

* 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.

2004, Clay Shirky