ETech: Lessons for social software design

Related link: http://human-nature.com/group/chap3.html

As we've come to expect from our cult leader Clay Shirky, his talk "A group is its own worst enemy" was densely packed with valuable information for anyone wishing to design social software. Rather than going over the entire talk, I'll focus on Clay's conclusions. For more detailed notes on the entire talk, check out Cory's notes.

Clay suggests that if you're going to design social software, you should accept the following points:

• You cannot separate the social issues from the technical issues. They are too intertwined and it does not work to separate them; as an example read LambdaMOO Takes a New Direction.

• Software only determines what people will do -- up to a point. Software cannnot influence/control all social aspects; groups have their own mentality that cannot and should not be boxed in by software. The group must have control over defining their own values.

• Members are different from users. Social software will have some people who care and contribute more than others and it's important to recognize the valuable contributors. Members in good standing in the community will find others in the same community. The social software should give the members the ability to find and communicate with other members in good standing.

• The core group has rights that trump individuals in some situations. A good example is the Wikipedia group defending itself from malicious individuals who trash wiki pages. The group's goal is to create a comprehensive encyclopedia wiki and when a few individuals work against that goal, their individual rights should get squashed preserve the rights (goals) of the group.
  

Furthermore, if you're going to design social software, you should consider the following points:

• Groups need a social contract. Since software only determines what people do to a point, a social system needs to have a constitution in place that governs the social aspects of the group.
  
• Handles for the user that matter. Users need handles (user names) that matter to them, and there must be a penality for switching user names. A good example of this is the Kaycee Nicole Hoax.
  
• Members in good standing need to be recognized. Just like in open source software, members respond to being recognized for their good work. Social software needs to have method for quantifying and recognizing the work of its members.
  
• Some barriers to participation are needed. Some things in the system need to be hard to do. The core group members needs some way to differentiate and defend itself from the mass of users.
  
• You have to spare the group from scale. (For once) Metcalfe's law is a drag -- as social software systems get larger, supporting a meaningful conversation becomes harder. Some social software systems shut off access to new users as the system reaches its useful limits.
  

These points seem to cover the most pertinent aspects of social systems -- of course things are lots more complex than that. Clay refererred to
Group Relations, which covers Bion's work and a book by Wilfred R. Bion.

What other social software points should be considered?