“A Group Is Its Own Worst Enemy”, 2005 (; backlinks; similar):
…We had new applications like the Web, email, instant messaging, and bulletin boards, all of which were about humans communicating with one another through software. Now, suddenly, when you create software, it isn’t sufficient to think about making it possible to communicate; you have to think about making communication socially successful. In the age of usability, technical design decisions had to be taken to make software easier for a mass audience to use; in the age of social software, design decisions must be taken to make social groups survive and thrive and meet the goals of the group even when they contradict the goals of the individual. A discussion group designed by an usability expert might be optimized to make it easy to post spam about Viagra. But in social software design it’s pretty obvious that the goal is to make certain things harder, not easier, and if you can make it downright impossible to post spam, you’ve done your job. Features need to be designed to make the group successful, not the individual.
Today, hardly anybody really studies how to design software for human-to-human interaction. The field of social software design is in its infancy. In fact, we’re not even at the point yet where the software developers developing social software realize that they need to think about the sociology and the anthropology of the group that will be using their software, so many of them just throw things together and allow themselves to be surprised by the social interactions that develop around their software. Clay Shirky has been a pioneer in this field, and his talk “A Group Is Its Own Worst Enemy” will be remembered as a watershed in the widespread realization that in this new era, sociology and anthropology are just as crucial to software design as usability was in the last. —Joel Spolsky
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, heterogeneous groups. “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.
You cannot completely separate technical and social issues
Members [power users] are different than users.
The core group has rights that trump individual rights in some situations.
…if you don’t accept them upfront, they’ll happen to you anyway. And then you’ll end up writing one of those documents that says “Oh, we launched this and we tried it, and then the users came along and did all these weird things. And now we’re documenting it so future ages won’t make this mistake.”
…If you were going to build a piece of social software to support large and long-lived groups, what would you design for? The first thing you would design for is handles the user can invest in.
you have to design a way for there to be members in good standing. Have to design some way in which good works get recognized. The minimal way is, posts appear with identity. You can do more sophisticated things like having formal karma or “member since.”
Three, you need barriers to participation. This is one of the things that killed Usenet. You have to have some cost to either join or participate, if not at the lowest level, then at higher levels. There needs to be some kind of segmentation of capabilities.
And, finally, you have to find a way to spare the group from scale. Scale alone kills conversations, because conversations require dense two-way conversations.
View PDF: