Welcome to the mind of David Eaves (@daeaves), public policy entrepreneur, open government activist and negotiation expert. Speaking in a rapid fire style, Dave admitted to "dumping" hours of negotiation theory in a few minutes in his OSCON session "Open Source 2.0: The Science of Community Management." I, for one, was delighted to be soaked by the firehose.
Dave started by debunking the 3 Great Myths of Open Source communities:
Myth 1) Your Open Source Community is a Meritocracy.
Admit it, the first 10 people to join your project have much more power than the next 10 that join, even the next 100. The first UI person to the project will be "the UI guy," it will take a serious stumble by him or a person drastically better then him to be displaced. The meritocracy myth is particularly harmful because it creates the promise that if you work really, really hard, you will have the same opportunities as everyone else in the community. Because of human nature, that's just not true. People are generally creatures of habit and go to the people they already know. It takes real effort to expand the circle/change their ways. For more information, you can read Structurelessness, feminism and open: what open advocates can learn from second wave feminists (this is in part about why open source communities are not pure meritocracies).
Myth 2) Open Source is about Collaboration
The genius of open source is how *not* to work together. It's about taking complex problems, breaking them into chunks and that individual developers can go work on and then can slide back into the whole. Collaboration is slow, expensive and high touch, community leaders should always think of ways to move from collaboration to cooperation. For example, it used to require long negotiations with the owners of the trunk to get extensions into Firefox (collaboration). With Firefox addons, community members could add functionality and users could pick it up much more easily (cooperation).
Myth 3) Coders Don't Need Soft Skills
If the success of your open source project is attracting (and keeping) community members, then your soft skills are your differentiator, not your coding chops. Be aware of the assumptions you bring to every conversation (Is this a negotiation? What's my goal? Is my goal just to prove the other guy wrong?). Your mindset can be resources are scarce, this is a battle, and eveyone else is stupid, crazy and evil. Or, you can believe that the pie can be made bigger, this is cooperative venture and people do what they believe is in their best interest. As a community leader, you can set the tone and maximize the outcome. Your job is not only to listen to what someone is saying, but to find out what are their real interests and concerns. A good solution may be closer than you think.
Architect in Cooperation
How can the OS community build "cooperation" into tools? Dave gave a few simple examples that would make Bugzilla more friendly:
Making Bugzilla a Little Friendlier
- marking a user a new or that English is their second language (ESL) [think before you flame]
- sample text in a fields that models "right behavior"
- providing a "Why?" field (getting to the underlying need).
- creating a "support" state (which automatically generates an email
that has links to similar entries in the support database rather than
only giving a user-hostile reply of "invalid).
Tools are especially challenging area for the open source community,
but it is time to start asking for (or building) ways to minimize the
high ‘transaction costs’ it takes to work your project. There's lots of work to do, but knowing you have a problem is always the first step. :-)
For more information, Dave provided links to Posts on Open Source Community Management. There's also a nice set of notes on the session by Jeff Longland.