Remembering the Future

A Group Is Its Own Worst Enemy If these assumptions are right, one that a group is its own worst enemy, and two, we're seeing this explosion of social software, what should we do? Is there anything we can say with any certainty about building social software, at least for large and long-lived groups? . . . So there's this question "What is required to make a large, long-lived online group successful?" and I think I can now answer with some confidence: "It depends." . . . Social software is like that. You can find the same piece of code running in many, many environments. And sometimes it works and sometimes it doesn't. So there is something supernatural about groups being a run-time experience. . . . 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. the first is that you cannot completely separate technical and social issues. . . no one could fork the conversation between social and technical issues, because the conversation can't be forked . . . 2. Members are different than users . . . 3. The core group has rights that trump individual rights in some situations . . . the core group needs ways to defend itself . . . 1. If you want a good reputation system, just let me remember who you are. And if you do me a favor, I'll remember it. . . Users have to be able to identify themselves and there has to be a penalty for switching handles . . . 2. Have to design some way in which good works get recognized . . . 3. Three, you need barriers to participation . . 4. 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