A Group Is Its Own Worst Enemy

Clay Shirky is at it again. Go read the whole thing, it’s awesome.

Shirky: A Group Is Its Own Worst Enemy:

n the Seventies — this is a pattern that’s shown up on the network over and over again — in the Seventies, a BBS called Communitree launched, one of the very early dial-up BBSes. This was launched when people didn’t own computers, institutions owned computers.

Communitree was founded on the principles of open access and free dialogue. “Communitree” — the name just says “California in the Seventies.” And the notion was, effectively, throw off structure and new and beautiful patterns will arise.

And, indeed, as anyone who has put discussion software into groups that were previously disconnected has seen, that does happen. Incredible things happen. The early days of Echo, the early days of usenet, the early days of Lucasfilms Habitat, over and over again, you see all this incredible upwelling of people who suddenly are connected in ways they weren’t before.

And then, as time sets in, difficulties emerge. In this case, one of the difficulties was occasioned by the fact that one of the institutions that got hold of some modems was a high school. And who, in 1978, was hanging out in the room with the computer and the modems in it, but the boys of that high school. And the boys weren’t terribly interested in sophisticated adult conversation. They were interested in fart jokes. They were interested in salacious talk. They were interested in running amok and posting four-letter words and nyah-nyah-nyah, all over the bulletin board.

And the adults who had set up Communitree were horrified, and overrun by these students. The place that was founded on open access had too much open access, too much openness. They couldn’t defend themselves against their own users. The place that was founded on free speech had too much freedom. They had no way of saying “No, that’s not the kind of free speech we meant.”

But that was a requirement. In order to defend themselves against being overrun, that was something that they needed to have that they didn’t have, and as a result, they simply shut the site down.

Now you could ask whether or not the founders’ inability to defend themselves from this onslaught, from being overrun, was a technical or a social problem. Did the software not allow the problem to be solved? Or was it the social configuration of the group that founded it, where they simply couldn’t stomach the idea of adding censorship to protect their system. But in a way, it doesn’t matter, because technical and social issues are deeply intertwined. There’s no way to completely separate them.

What matters is, a group designed this and then was unable, in the context they’d set up, partly a technical and partly a social context, to save it from this attack from within. And attack from within is what matters. Communitree wasn’t shut down by people trying to crash or syn-flood the server. It was shut down by people logging in and posting, which is what the system was designed to allow


This is a classic pattern that we re-invent on the internet time and time again:

First, we think of whatever we build as something new and revolutionary (which it may well be), and therefore we can ignore past history because it’s not relevant to what we’re doing (which is invariably wrong).

Second, we start using it with a small set of people who generally have a common set of goals and ambitions, so “can’t we all just get along” works. For a while.

Then, if the technology is useful and proves out, the user base expands. the more it expands, the more it gets used by people who’s goals and ambitions are different from the original core group, and the conflicts of “what’s appropriate” starts. How well a system scales is more dependent on how well it allows for these divergent uses than how well the technology can handle the load. the more these conflicts stand in the faces of the users, the more likely the system will fall over and die.

This is really the ultimate failing of mailing lists, because the only way to scale mailing lists across these conflicts of “what this list is about” is to create more mailing lists for each diverging sub-population, and once you split the group up enough ways into enough shards, it loses all context among shards and it’s no longer a community (if it ever way). the only way a mailing list scales and survives is to get seriously anal about focussing content on the tightest definition of “acceptable” for the community and limiting side chat, which is a serious limiter of building community among the users.

At some point, the freakers and trolls move in, because there’s a section of society that gets off on destroy stuff other people build. If you don’t plan for this, when they move in, you die.

And yet, with decades of repeating these mistakes under our belts, we keep re-inventing systems that don’t deal with these problems up front. USENET’s lack of any authority system. non-verified SMTP. Wiki’s without authentication. Anonymous blog comments. non-validated trackbacks. The list goes on. We end up wasting huge numbers of resources trying to backpatch solutions instead of designing them in up front.

And we probably will continue to. sigh.

To me, it ends up to a few simple rules:

Anonymity bad. The net mixes these things up pretty badly. Anonymity implies there’s no way to know who you are, so there’s no way to police or manage your actions. Reality: for every person with a legitimate need for Anonymity, there’s 99 hackers, trolls and freakers taking advantage of the system to frack things up.

Pseudonymity good. No Anonymity doesn’t imply full disclosure. It’s not about knowing who you are, it’s about being able to know that YOU ARE YOU, so that if what you do is unacceptable, it can be policed. And yes, it means that some people (site admins) need to have some identifying info about you, but it can be implied identification, maybe as little as an email address or an IP address. Enough to give them a handle to enforce rules, although obviously, a really motivated troll will make any admin grumpy in any online system, if they want to. Fortunately, those types are fairly rare.

Always authenticate. Every village needs walls and gates, because if you don’t have them, when the vikings arrive up the river, they WILL burn the village. Even with walls and gates, they may still burn the village, but if you don’t do the basics, you dn’t have a chance. And they will arrive, someday. In my experience, usually at 2AM when you’re on deadline before vacation…

You need authority. Anarchy is a nice theory, but if you don’t set rules, when people push beyond what’s acceptable for the group, you have problems putting the genie back in the bottle. The middle of a crisis is a lousy time to try to build consensus on where to draw the lines.

You need police. Even if they spend 99.9% of the time in the donut shop drinking coffee (and in a good community, they will, because it self-polices well) that over .1% of the time, they can mean the difference between losing the community over a conflict.

But beware of self-appointed police. There will be people who will want to define things in terms of what they want instead of what the community at large wants, and will enforce their personal rules on the community if you let them. Don’t let them.

Enable the quiet voices. Most of the material created within a community is from a very small percentage of the user base. Look for ways to find those “quiet voices” that get crowded out of the mosh pit and enable them to contribute. It’s well worth it. Not everyone wants to be part of the loud and noisy group that loves the fight to be heard — and many times, those quieter voices will be your most interesting contributors, if you get them involved.

Beware the squeaky wheel. Just because there are some folks loudly complaining about something doesn’t mean they speak for the community in general. It’s key to understand these complaints in the larger context of the entire group. For me, a classic example of this is “reply-to” on mail lists. If you didn’t set it, there were always a couple of people loudly whining that it was the One True Way of setting up mailing lists, and they hated taking no for an answer. In reality, every time I did a survey of the ENTIRE mailing list population, I found — invariably — that the vast majority (80% or so) simply didn’t care either way, and of the ones that did, the “pro reply-to” group was the minority. I did this survey maybe a dozen times over the years, and got the same result on every list despite wildly divergent populations (from geek to sports fan to skiffy fan). the pro reply-to people hated this, because, of course, they knew better than the entire list population what was good for them….

I always saw the communities I built as community bars where people of similar interests congregate, in fact, I liked to promote the mailing lists not as “a place to talk about the San Jose Sharks” as much as “A place for Sharks fans to talk about stuff”. you’d never walk into a sports bar and get told to shut up if you tried to talk about something other than sports, for instance, but online, that’s fairly common — but in the side chatter is where the friendships and community building happen.

As an admin, don’t be afraid to let a group self-police. Probably the hardest lesson I ever learned. But having said that, the key to being a successful admin is knowing when to step in, and doing so decisively when necessary. Lots of admins (and the most active members of the mosh pits of the community) like to think they can just let the group figure it out; the reality there is that the loud and noisy and the trolls and freakers will drive out everyone else, and then all you have left are noisy freakers and trolls.

If you don’t police it, you’ll end up with that friendly community sports bar being turned into a biker bar by the bikers — at which time the people you built the thing for will all run off and find some other place to watch sports and chatter. Is that really what you wanted to run? a biker bar? Maybe, but not me.

Of course, the bikers always hated that… funny, that.