Tue, 21 Mar 2006
a historical perspective on Social Software

I was just introduced to Clay Shirky's A Group Is Its Own Worst Enemy (via Jeremy Keith), and it's got me thinking. Go on and give it a read, it's worth it.
From 1/3 through:

Now, this story has been written many times. It's actually frustrating to see how many time it's been written. You'd hope that at some point that someone would write it down, and they often do, but what then doesn't happen is other people don't read it.

This resonates with my personal experiences. I've seen this story play out a few times, including on slashdot and on BBSes in northern Minnesota - but this may be the first time I've read a persuasive explanation of the morasses that online groups often fall into. In particular, Shirky's summary of W.R. Bion's work is of interest, as he seems to have nailed a big chunk of the phenomenon 50 years ago.

So it's interesting that Clay has recorded these lessons and presented them at ETech three years ago. Here I am reading them, and 273 other people have bookmarked them in delicious... but it doesn't seem that a significant portion of the people building and operating social software are aware of them yet.

Though I'm not clear on how directly the conclusions Clay draws are based on W.R. Bion's results, they sound good and I think they're worth considering. First, the inevitable features of social software systems:

  1. Technology and social structure are inevitably intertwined; you can't think about one without the other.
  2. Out of the greater mass of users, a subset will be qualitatively more involved. If the code doesn't treat them special they'll come up with their own ways of being special.
  3. The core group of users has rights in and of itself other than those of participating individuals.

Second, the factors you ought to include in your system's design, if you want it to work consistently with the above lessons:

  1. Some form of identity, at least strong pseudonymity.
  2. Recognition of good membership.
  3. Barriers / costs to participation. Optimize for ease-of-use for the core group, rather than any arbitrary individual.
  4. Limit scale to a reasonable number, so that the community doesn't deteriorate due to excess size.

[/general]