WiserEarth Governance

by Clay Shirky, AKA The Power of Organizing without Organizations

100 pages into it in a day, I highly recommend it for anyone working in online networks, community, or collaboration.

And here are some discussion-worthy snippets from excellent articles in shirky's website, which imho, relate to WiserEarth as a social software, and it's governance aspects. The last article is especially related to the design of a social software (most have been adequately addressed by WiserEarth, imho).


~~~ In Praise of Evolvable Systems: Central Planning vs. Evolution
@ http://www.shirky.com/writings/evolve.html

"It's easy for central planning to outperform weak but evolvable systems in the short run, but in the long run evolution always has the edge."

"Evolvable systems -- those that proceed not under the sole direction of one centralized design authority but by being adapted and extended in a thousand small ways in a thousand places at once -- have three main characteristics that are germane to their eventual victories over strong, centrally designed protocols:
1) Only solutions that produce partial results when partially implemented can succeed. The network is littered with ideas that would have worked had everybody adopted them. Evolvable systems begin partially working right away and then grow, rather than needing to be perfected and frozen.
2) What is, is wrong. Because evolvable systems have always been adapted to earlier conditions and are always being further adapted to present conditions, they are always behind the times. No evolving protocol is ever perfectly in sync with the challenges it faces.
3) "Evolution is cleverer than you are", the ability to understand what is missing at any given moment does not mean that one person or a small central group can design a better system in the long haul."

"Centrally designed protocols start out strong and improve logarithmically. Evolvable protocols start out weak and improve exponentially. It's dinosaurs vs. mammals, and the mammals win every time. "



~~~ Social Software and the Politics of Groups: Software designed for groups encodes political bargains
@ http://shirky.com/writings/group_politics.html

"Designing software for group-as-user is a problem that can't be attacked in the same way as designing a word processor or a graphics tool."

"Social software is political science in executable form."

"...a group changes its behavior in response to changes in software. Because of these effects, designers of social software have more in common with economists or political scientists than they do with designers of single-user software, and operators of communal resources have more in common with politicians or landlords than with operators of ordinary web sites."

"Social software has progressed far less quickly than single-user software, in part because we have a much better idea of how to improve user experience than group experience, and a much better idea of how to design interfaces than constitutions."

"One fruitful question might be "How can we test good group experience?" Over the last several years, the importance of user experience, user testing, and user feedback have become obvious, but we have very little sense of group experience, group testing, or group feedback. If a group uses software that encourages constant forking of topics, so that conversations become endless and any given conversation peters out rather than being finished, each participant might enjoy the conversation, but the software may be harming the group goal by encouraging tangents rather than focus."

"If a group has a goal, how can we understand the way the software supports that goal? This is a complicated question, not least because the conditions that foster good group work, such as clear decision- making process, may well upset some of the individual participants. Most of our methods for soliciting user feedback assume, usually implicitly, that the individual's reaction to the software is the critical factor. This tilts software and interface design towards single-user assumptions, even when the software's most important user is a group."

"There are thousands of other questions. Can we produce diagrams of social networks in real time, so the participants in a large group can be aware of conversational clusters as they are forming? What kind of feedback loops will this create? Will software that lets groups form with a pre-set dissolution date ("This conversation good until 08/01/2003.") help groups focus? Can we do anything to improve the online environment for brainstorming? Negotiation? Decision making? Can Paypal be integrated into group software, so that groups can raise and disperse funds in order to pursue their goals? (Even Boy Scouts do this in the real world, but it's almost unheard of online.) And so on."

"The conversations we can have about social software can be advanced by asking ourselves the right questions about both the software and the political bargains between users and the group that software will encode or enforce."



~~~ Communities, Audiences and Scale: Audiences scale. Communities don't
@ http://shirky.com/writings/community_scale.html

"...communities have strong upper limits on size, while audiences can grow arbitrarily large. Put another way, the larger a group held together by communication grows, the more it must become like an audience -- largely disconnected and held together by communication traveling from center to edge -- because increasing the number of people in a group weakens communal connection."

"Because growth in group size alone is enough to turn a community into an audience, social software, no matter what its design, will never be able to create a group that is both large and densely interconnected."

"This sparse organization of the larger group can of course encompass smaller, more densely clustered communities."

"...one of the design challenges for social software is in allowing groups to grow past the limitations of a single, densely interconnected community while preserving some possibility of shared purpose or participation, even though most members of that group will never actually interact with one another."



~~~ A Group is Its Own Worst Enemy: Persistent patterns in long-lived online groups
@ http://shirky.com/writings/group_enemy.html

"[Social software is]software that supports group interaction."

"...group structure is necessary to defend the group from itself. Group structure exists to keep a group on target, on track, on message, on charter, whatever. To keep a group focused on its own sophisticated goals... Group structure defends the group from the action of its own members."

"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, heterogenous groups."

"The downside of going for size and scale above all else is that the dense, interconnected pattern that drives group conversation and collaboration isn't supportable at any large scale. Less is different -- small groups of people can engage in kinds of interaction that large groups can't. And so we blew past that interesting scale of small groups. Larger than a dozen, smaller than a few hundred, where people can actually have these conversational forms that can't be supported when you're talking about tens of thousands or millions of users, at least in a single group."

"Is there anything we can say with any certainty about building social software, at least for large and long-lived groups? What is required to make a large, long-lived online group successful?"

"...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."

"Three Things to Accept:
1.) You cannot completely separate technical and social issues.... the best pattern, or at least the pattern that's worked the most often, is to put into the hands of the group itself the responsibility for defining what value is, and defending that value, rather than trying to ascribe those things in the software upfront.
2.) Members are different than users. 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."
3.) The core group has rights that trump individual rights in some situations. This pulls against the libertarian view that's quite common on the network, and it absolutely pulls against the one person/one vote notion. But you can see examples of how bad an idea voting is when citizenship is the same as ability to log in... absolute citizenship, with the idea that if you can log in, you are a citizen, is a harmful pattern, because it is the tyranny of the majority... So leveraging the core group is a really powerful system.
Now, when I say these are three things you have to accept, I mean you have to accept them. Because if you don't accept them upfront, they'll happen to you anyway."

" All groups of any integrity have a constitution. The constitution is always partly formal and partly informal. At the very least, the formal part is what's substantiated in code -- "the software works this way." The informal part is the sense of "how we do it around here." And no matter how is substantiated in code or written in charter, whatever, there will always be an informal part as well. You can't separate the two."

"Four Things to Design For:
1.) The first thing you would design for is handles the user can invest in... If you give users a way of remembering one another, reputation will happen, and that requires nothing more than simple and somewhat persistent handles... Users have to be able to identify themselves and there has to be a penalty for switching handles. The penalty for switching doesn't have to be total. But if I change my handle on the system, I have to lose some kind of reputation or some kind of context. This keeps the system functioning.
2.) Second, 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."
3.) 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... 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. Ease of use is the wrong way to look at the situation, because you've got the Necker cube flipped in the wrong direction. The user of social software is the group, not the individual... and ease of use should be for the group. If the ease of use is only calculated from the user's point of view, it will be difficult to defend the group from the "group is its own worst enemy" style attacks from within.
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. In conversational contexts, Metcalfe's law is a drag. The fact that the amount of two-way connections you have to support goes up with the square of the users means that the density of conversation falls off very fast as the system scales even a little bit. You have to have some way to let users hang onto the less is more pattern, in order to keep associated with one another... So plan for dealing with scale in advance, because it's going to happen anyway.
Now, those four things are of course necessary but not sufficient conditions."

"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."

"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."

Good point David. Using analogy to explain things, generally is a tricky business. Maybe you can let the author know about this?

Continuing with the links, here's a video and audio of Clay Shirky discussing the book:
http://cyber.law.harvard.edu/interactive/events/2008/02/shirky