[FoRK] A Group Is Its Own Worst Enemy

Dr. Ernie Prabhakar < drernie at radicalcentrism.org > on > Tue Dec 12 14:17:53 PST 2006

More about open source than religion, but apropos of both.  I suspect  
many of you have seen this before, but it was new to me.

-- Ernie P.

P.S.  Bonus points for identifying which patterns (if any) best  
characterize FoRK. :-)

Clay Shirky's Writings About the Internet
Economics & Culture, Media & Community, Open Source
http://www.shirky.com/writings/group_enemy.html
Published July 1, 2003 on the "Networks, Economics, and Culture"  
mailing list.

...there are some very specific patterns that they're entering into  
to defeat the ostensible purpose of the group meeting together. And  
he [Bion] detailed three patterns.

The first is sex talk, what he called, in his mid-century prose, "A  
group met for pairing off." And what that means is, the group  
conceives of its purpose as the hosting of flirtatious or salacious  
talk or emotions passing between pairs of members...

The second basic pattern that Bion detailed: The identification and  
vilification of external enemies. This is a very common pattern.  
Anyone who was around the Open Source movement in the mid-Nineties  
could see this all the time. If you cared about Linux on the desktop,  
there was a big list of jobs to do. But you could always instead get  
a conversation going about Microsoft and Bill Gates. And people would  
start bleeding from their ears, they would get so mad....

So even if someone isn't really your enemy, identifying them as an  
enemy can cause a pleasant sense of group cohesion. And groups often  
gravitate towards members who are the most paranoid and make them  
leaders, because those are the people who are best at identifying  
external enemies.

The third pattern Bion identified: Religious veneration. The  
nomination and worship of a religious icon or a set of religious  
tenets. The religious pattern is, essentially, we have nominated  
something that's beyond critique. You can see this pattern on the  
Internet any day you like. Go onto a Tolkein newsgroup or discussion  
forum, and try saying "You know, The Two Towers is a little dull. I  
mean loooong. We didn't need that much description about the forest,  
because it's pretty much the same forest all the way."

...Now, in some places people say "Yes, but it needed to, because it  
had to convey the sense of lassitude," or whatever. But in most  
places you'll simply be flamed to high heaven, because you're  
interfering with the religious text.

So these are human patterns that have shown up on the Internet, not  
because of the software, but because it's being used by humans. Bion  
has identified this possibility of groups sandbagging their  
sophisticated goals with these basic urges. And what he finally came  
to, in analyzing this tension, is that group structure is necessary.  
Robert's Rules of Order are necessary. Constitutions are necessary.  
Norms, rituals, laws, the whole list of ways that we say, out of the  
universe of possible behaviors, we're going to draw a relatively  
small circle around the acceptable ones.

He said the group structure is necessary to defend the group from  
itself. Group structure exists to keep a group on target, on track,  
on message, on charter, whatever. To keep a group focused on its own  
sophisticated goals and to keep a group from sliding into these basic  
patterns. Group structure defends the group from the action of its  
own members...

....

People who work on social software are closer in spirit to economists  
and political scientists than they are to people making compilers.  
They both look like programming, but when you're dealing with groups  
of people as one of your run-time phenomena, that is an incredibly  
different practice. In the political realm, we would call these kinds  
of crises a constitutional crisis. It's what happens when the tension  
between the individual and the group, and the rights and  
responsibilities of individuals and groups, gets so serious that  
something has to be done.

And the worst crisis is the first crisis, because it's not just "We  
need to have some rules." It's also "We need to have some rules for  
making some rules." And this is what we see over and over again in  
large and long-lived social software systems. Constitutions are a  
necessary component of large, long-lived, heterogenous groups.

Geoff Cohen has a great observation about this. He said "The  
likelihood that any unmoderated group will eventually get into a  
flame-war about whether or not to have a moderator approaches one as  
time increases." As a group commits to its existence as a group, and  
begins to think that the group is good or important, the chance that  
they will begin to call for additional structure, in order to defend  
themselves from themselves, gets very, very high.

...

There are, however, I think, about half a dozen things that are  
broadly true of all the groups I've looked at and all the online  
constitutions I've read for software that supports large and long- 
lived groups. And I'd break that list in half. I'd say, if you are  
going to create a piece of social software designed to support large  
groups, you have to accept three things, and design for four things.

1.) Of the things you have to accept, the first is that you cannot  
completely separate technical and social issues...

2.) The second thing you have to accept: Members are different than  
users...

3.) The third thing you need to accept: The core group has rights  
that trump individual rights in some situations...

All groups of any integrity have a constitution. The constitution is  
always partly formal and partly informal. At the very least, the  
formal part is what's substantiated in code -- "the software works  
this way."

The informal part is the sense of "how we do it around here." And no  
matter how is substantiated in code or written in charter, whatever,  
there will always be an informal part as well. You can't separate the  
two.

* Four Things to Design For

The first thing you would design for is handles the user can invest in.

Second, you have to design a way for there to be members in good  
standing.

Three, you need barriers to participation.

finally, you have to find a way to spare the group from scale...

...those four things are of course necessary but not sufficient  
conditions



More information about the FoRK mailing list