This post is a summary of this essay by Clay Shirky. It details social / technical issues that you need to accept or design for when building social software for long-lived groups. The full article is interesting and well worth the read, but the following serves as a useful summary of the take-away ideas.

Things to accept:

1. You cannot completely separate technical and social issues.
2. A pattern will arise in which there is some group of users that cares more than average about the integrity and success of the group as a whole. And that becomes your core group, Art Kleiner’s phrase for “the group within the group that matters most.” Now, the software does not always allow the core group to express itself, which is why I say you have to accept this. Because if the software doesn’t allow the core group to express itself, it will invent new ways of doing so.
3. The core group has rights that trump individual rights in some situations. So the core group needs ways to defend itself so that it can stay on its sophisticated goals and away from its basic instincts.

Things to design for:

1. Handles (an identity) the user can invest in.
2. You have to design a way for there to be members in good standing. The minimal way is, posts appear with identity. You can do more sophisticated things like having formal karma or “member since.”
3. You need barriers to participation. It has to be hard to do at least some things on the system for some users, or the core group will not have the tools that they need to defend themselves. Now, this pulls against the cardinal virtue of ease of use. But ease of use is wrong. The user of social software is the group, not the individual.
4. You have to find a way to spare the group from scale. You can’t try to make the system large by taking individual conversations and blowing them up like a balloon; human interaction, many to many interaction, doesn’t blow up like a balloon. It either dissipates, or turns into broadcast, or collapses. So plan for dealing with scale in advance, because it’s going to happen anyway.

In response to this post, I’ve written an equivalent script in python (because I’m too lazy to get the CPAN lib):

#!/usr/bin/python

from twyt.twitter import Twitter
import sys

username = ''
password = ''

def tweet(message):
    twitter = Twitter()
    twitter.setauth(username, password)
    twitter.status_update(message)

if __name__ == '__main__':
    message = ' '.join(sys.argv[1:])
    tweet(message)

It depends on python-twyt. Enjoy!

I had a request for a script to delete all the tweets in an account, so here it is:

twitter-obliterate-0.1

May be harmful to your tweets, use at your own risk! I’m not sure how fast it is, since I’ve only tested it on an account with about 10 tweets. It has to send a separate HTTP request for each tweet, and it does so serially. Hopefully it’ll be adequate for all but the most massive accounts.

The tarball includes a version of the python-twyt library, modified to add support for the archive command. Patch on the way to the maintainer shortly…

Update: I’ve done a few tests and it appears the code has some bugs, but due to lack of demand I haven’t investigated any further. Let me know if you’re interested in a fix!