April 24, 2003
[ETech] Clay Shirky Keynote
Clay is going to talk about a pattern in social software that consistently emerges: Groups are their own worst enemy.
Prior to the Internet we had lots of ways of doing point-to-point and one-to-many communication. Before the Internet, we didn’t have a good way to do “ridiculously easy group forming.” Now we do. But the patterns that emerge are due not to the technology but to how humans behave in groups.
Part 1: Why groups are their own worst enemy.
Wilfred Bion wrote in the middle of the 20th century. He believed that we are irreducibly social and individual. Bion found three patterns. First, groups engage in flirtatious sex talk among pairs, no matter what the ostensible group purpose. Second, they identify and villify enemies. Third, they nominate and venerate a hero beyond critique. All three of these are obvious on the Internet also. Groups “sandbag their sophistcated goals with these basic urges.”
Bion concluded that group structure is necessary to defend the group from itself. It exists to keep a group on track. Group structure defends a group from the actions of its own members. For example: CommuniTree, a BBS in the ’70s that failed when adolescents posted obscenities all over.
Groups come to a constitutional crisis where they not only need rules, they need rules about making rules.
Part 2: Why now?
If these things have been happening forever, why is it important now?
Observationally, there’s a revolution in social software happening. (Social software: software that supports groups.) Small groups are different than big groups. Now we’re getting weblogs and wikis and platform stuff that lets us try new things rapidly that support small to midsize groups, e.g., RSS.
Why now? Really: Why did it take so long? Why did it take so long to get weblogs, for example? WEW could have weblogs when we had the first forms-capable browser. Answer: It just took us that long to figure it out.
Second, this stuff is truly Web-native, unlike, say, Notes with a lightweight Web interface.
Third, we can easily put stuff together. E.g., Joi Ito’s conference call with a chat attached and then a wiki. It was a broadband conference call, but it’s a simple little thing.
Fourth, ubiquity. We can now assume, in many situations, all people have access to the Web. “All is a different kind of amount than most.” And within a meeting, we can begin to assume everyone is online. Clay no longer runs meetings without an online component (chat, wiki).
Part 3: Things core to social software
What makes a large, online group successful? After ten years of research, Clay can say with confidence: “It depends.” [Laughter]
The normal experience of social software is failure. Yahoo Groups, for example, exhibits a power law: few succeed. But there are about half a dozen things true of software that supports large and long-lived groups:
1. You can’t completely separate technical and social issues. E.g., you can’t separate the two mailing lists. “You can’t specify all social issues in technology.” The group can’t be programmed. Let the group decide what its value is and give them the tools to defend it; do not try to build the value into the software.
2. In a successful group, there is a core that cares about the integrity of the group and “gardens” it. The software ought to let the group express this fact. If you don’t, the group will invent its own ways.
3. Some members need more power than others. E.g., the Wikipedia’s “fire brigade” that undoes destructive changes.
What would you design for if you build social software?
1. Anonymity doesn’t work in group settings. I need to be able to associate who’s talking now with what’s been said before. Reputation is not portable from one situation to another: someone who cheats on his wife may not cheat on his taxes. Ebay’s linear metrics works well in a linear transaction system but not in non-linear conversation spaces. So, for social software to work, users have to identify themselves and there has to be a penalty for switching handles.
2. You need a way to recognize good members.
3. You need barriers to participation, some segmentation of capabilities. “Otherwise the core group won’t have the tools they need to defend themselves.” This flies in the face of ease of use, but focusing on ease of use looks at it from the individual, not the group. “The user of social software is the group, and ease of use ought to be for the group, not the user.”
4. You have to find a way spare the group from scale. “Scale kills conversations.” Metcalfe’s Law means the density of conversation falls off rapidly. You need “soft forking.” (LiveJournal does a great job of this.) Metafilter shuts off the “new user” page when they get too many users.
“The act of writing social software is more like the work of an economist or social scientist.” The people using the software will act as if they have rights. The site is theirs.
In response to a question: Old social software has been architectural: build a place where people can meet. Now we’re moving to a ship-building model: Build a place where people can go somewhere together.
[Great presentation.]
FUN QUOTE 1: “Learning from experience is the worst possible way of learning. It’s one up from remembering.” It’s better to learn from reading.
FUN QUOTE 2: Sophisticated computer graphical worlds look real “if you’re drunk and in the barrel” looking out the bung hole.
