In open source, all you have is social capital

Over a month ago, I watched this keynote by David Eaves that he gave at DjangoCon. Yes, I'm way behind on the list of things I'd like to blog about. I blame Bugzilla :-) Also, quite a few people at EclipseCon Europe came up to me and mentioned that they really enjoyed reading my blog. Thanks - I enjoy writing!



David Eaves is a negotiation consultant. He helps people on opposite sides of an issue come to an agreement, and has clients in open data, government, industry, and open source communities. He has done work at Mozilla to help manage contributor engagement and implement measures to keep contributors working in the community.

He starts off by telling the story, that as part of of his work with Mozilla, he thinks that he should submit a bug. He submits his first Thunderbird bug and announces on Twitter or Facebook that he's excited to submit his first bug. To which he gets the reply "I bet it's a duplicate".  According to this presentation, 50% of all bugs are duplicates.  It may be a duplicate, but this response isn't the best approach to encouraging future participation from a new contributor.

He then says that most open source communities don't have financial capital.  They don't have money flowing in to influence people.  "All you have is social capital".  Social capital consists of the people that contribute to your community and make it successful.  In theory, in a corporation, human resources tracks how to retain and manage its people.  In open source, we spend very little time managing our social capital or even better, tracking  it.

He then continues that one of the mantras of open source is that it's a meritocracy and your coding skills are the key to success within the community.  But if you look at people who have spent a lot of time in an open source community and are considered leaders,  many of them spend a lot more time working with people and  managing their community as opposed to coding.  To which he says "We pull people in based on their coding skills, and we promote people based on their negotiation skills".  Also, he remarks that nobody tells us that, and that we all stress that technical skills trumpet negotiation skills despite the evidence to the contrary.

He then gives examples of funny or misunderstood Mozilla bugs.  He states how it's harder to communicate with people when only via the written word.  I find that myself.  I've met quite a few people at conferences who I've found to be rude in Bugzilla to only find that in person they seem like a totally different person.  Reasonable.  Friendly.  Helpful.  Anyways, since Bugzilla is a written medium he suggests that the best way to interact on it is to ask questions.  He states that often people just have a solution in mind as a bug fix and aggressively push their solution where in fact they should ask the user what they want to do in the first place.  Also, you should paraphrase and repeat what the user said to gain understanding, acknowledge the problem and advocate for a solution. All great advice!

The next section of the talk discusses the architecture of a community.  Fork used to be a four letter word in open source  But with the advent of GitHub, it's not, but rather a way to empower the user.  It also absolves you from seeking anyone's permission before contributing.  He says we need to design our communities to "Architect for cooperation and away from collaboration"  It's great if a new contributor can start fixing a problem without the transaction costs associated with interacting with a committer.  We can spend our time on other tasks.  He also states that we need to empower the lowest people on the stack, such as those triaging bugs.  He also remarks that immediately marking a bug as invalid without acknowledgement of the effort required to report it doesn't build community loyalty.

GitHub Octocat

Image ©sunfox, http://www.flickr.com/photos/sunfox/4365495446/  licensed under Creative Commons by-nc-sa 2.0

The final section of the talk described applying metrics to the show what is going on in a project.  To measure contributor patches from non-paid staff is a way to measure social capital.  To determine why people have stopped contributing.  To measure wait time for before a patch is submitted.  He also states that it would be interesting to have a repository API and once you attach a patch to a bug, it would update the bug with the anticipated  wait time, to set expectations for the reporter.  He states that Wikipedia segments users based on metrics and they applies actions, such as suggesting mentors for new contributors.

I think having metrics for new Eclipse contributors would be very interesting.  I rarely have people contributing patches to my bucket other than from other Eclipse or Equinox project committers, but I'm sure the metrics would be very interesting for other components.   It would also be valuable to determine the reason that people stop contributing, and implement measures to encourage people to continue to their involvement.

He finishes by stating that there needs to be a social infrastructure for the community, not just code.  Also, in some cases, you many need to remove people from the community to reduce negative social capital.  A great talk, I highly recommend  it - extremely informative and funny. 


Notes:
 
David Eaves also blogs at http://www.eaves.ca on open data, open source and other interesting topics.
His keynote is here http://blip.tv/djangocon/keynote-david-eaves-5571777