How a Group is its own Worst Enemy/Conclusion

			Member Resources

Veterans Affairs Team "Sim long and prosper" Overview VA Team Members Past Accomplishments Building Community User Right-to-Leave Democracy in UFOP Voting Fair Process Backroom Decisions Open Process Importance of Online Identity Building Stronger Community Barnraising Radical Inclusiveness The Dark Side of Community Conflict Resolution The Conflict Paradox How a Group is its own Worst Enemy Vested Contributers Community Security Veterans Affairs Forum Facilitator: Roshanara Rahman Edit this Nav How a Group is its own Worst Enemy Written by Clay Shirky Intro • Part 1 • Part 2 • Part 3 • Part 4 • Conclusion Conclusion Now, those four things are of course necessary but not sufficient conditions. I propose them more as a platform for building the interesting differences off. There are lots and lots and lots of other effects that make different bits of software interesting enough that you would want to keep more than one kind of pattern around. But those are commonalities I'm seeing across a range of social software for large and long-lived groups. In addition, you can do all sorts of things with explicit clustering, whether it's guilds in massively multi-player games, or communities on Live Journal or what have you. You can do things with conversational artifacts, where the group participation leaves behind some record. The Wikipedia right now, the group collaborated online encyclopedia is the most interesting conversational artifact I know of, where product is a result of process. Rather than "We're specifically going to get together and create this presentation" it's just "What's left is a record of what we said." There are all these things, and of course they differ platform to platform. But there is this, I believe, common core of things that will happen whether you plan for them or not, and things you should plan for, that I think are invariant across large communal software. Writing social software is hard. And, as I said, the act of writing social software is more like the work of an economist or a political scientist. And the act of hosting social software, the relationship of someone who hosts it is more like a relationship of landlords to tenants than owners to boxes in a warehouse. The people using your software, even if you own it and pay for it, have rights and will behave as if they have rights. And if you abrogate those rights, you'll hear about it very quickly. That's part of the problem that the John Hegel theory of community -- community leads to content, which leads to commerce -- never worked. Because lo and behold, no matter who came onto the Clairol chat boards, they sometimes wanted to talk about things that weren't Clairol products. "But we paid for this! This is the Clairol site!" Doesn't matter. The users are there for one another. They may be there on hardware and software paid for by you, but the users are there for one another. The patterns here, I am suggesting, both the things to accept and the things to design for, are givens. Assume these as a kind of social platform, and then you can start going out and building on top of that the interesting stuff that I think is going to be the real result of this period of experimentation with social software. Thank you very much.

			Department of Veterans Affairs