OSCON talk: "Open Source 2.0: The Science of Community Management"

One of the best talks I saw at OSCON 2012 was "Open Source 2.0: The Science of Community Management" by David Eaves, a consultant who specializes in negotiation.  He had a very short talk during the opening plenary session (this part was videotaped).  Then, he had a full 40-minute slot, which I attended because I had enjoyed the keynote.  I didn't take any notes because I had to stand in the back with a lot of other people who had crowded into the room, so this summary will be impressionistic.

Eaves talked cogently about specific challenges faced in building community around open-source projects.  These include their distributed nature, differing motivations, part-time attention from members, and the fact that email is a terrible communication mechanism that is highly susceptible to misinterpretations of meaning.

Eaves contrasted the typical zero-sum, adversarial approach to negotiation to one in which the parties respect one another, attempt to understand one another, and seek a solution that is advantageous to everyone.

Eaves emphasized the importance of listening.  He caterogized different purposes of communication.  Then, he characterized one long thread in a bug-tracking database as everyone trying to prove a point without anyone listening.  Understanding the needs and motivations of others will make you much more effective, but too many people don't do it.

Eaves noted that people are not evil or irrational.  People act rationally to maximize their perceived self-interest.  Thus, understanding their self-interest, and their perception of it, can help you to find solutions that satisfy both them and you.  (That also might include educating them about their true self-interest, if you can do it without being bombastic.)  It's important to know your own self-interest and to be rational about it.  Separate out the things that are actually important to you from the things that have to do with your ego, or with one particular way of achieving those ends, or from your first ideas about a solution.

Eaves discussed that open-source projects tend to be unfriendly to newbies, as I mentioned above.  Reactions to suggestions from new members, or to suggestions that are slightly off, can be aggressive and downputting.  There are several rational explanations for this behavior.  One explanation is that developers believe that thick skin is correlated with competence; thus, their behavior is an effective and efficient way to weed out people who would not make valuable contributions.  (It's a different question whether that correlation actually exists, and thus whether the developers' behavior is productive.)  Other explanations include that developers are protecting their own time or increasing their reputation.  Eaves suggested a "newbie" badge beside newcomers' posts, so that other people would treat them more gently.  I had always thought that the badge was there as a return mechanic -- people will want to keep posting to get "newbie" off their profiles -- but this is another excellent reason for it.  Some people will treat the newbies more gently, and other people might be more inclined to ignore them.

Overall, Eaves provided good information about seeking win-win, and not in a perfectly fluffy and content-free context, but with examples and exercises.

He recommended two books, "Getting to Yes" and "Difficult Conversations", both of which were already on my list of books to read -- maybe now I will actually read them.

He also pointed at some of his blog posts, which I have not yet read:
  http://eaves.ca/2011/06/14/how-github-saved-opensource/
  http://eaves.ca/2011/04/07/developing-community-management-metrics-and-tools-for-mozilla/
  http://eaves.ca/2007/02/05/wikis-and-open-source-collaborative-or-cooperative/

OSCON talk: "Harnessing the Good Intentions of Others for your OSS Project"

I attended OSCON 2012 in Portland last week, and I saw some good talks and some bad ones. (Mine was middling -- a disappointment, but I will use what I learned to improve for the future.)

One good OSCON talk I attended was titled "Harnessing the Good Intentions of Others for your OSS Project", by Llewellyn Falco and Lynn Langit:

The idea is that there are a lot of developers out there who would love to help you, but the barriers to their entry are too high.  A potential contributor must understand your system, figure out where to make a patch, and submit it.  This is already more than the two hours or so that most people are willing to spend making a contribution to your project.  (A related point made by David Eaves at the same conference, and possibly repeated in this talk, is that when the maintainers review the patch, they usually reject it.  The main feedback to the newbie is the "invalid" status of the bug report.)  The end result is that almost no new developers ever join an open-source project.  The speakers claim to have a 98% conversion rate (though I am not sure how meaningful that statistic is) and shared their approach.

Here are three key points I took away from it.

1. Listen for feedback and problems.  The speakers suggested setting up a Twitter search (you can get an RSS stream or a Google alert), and also searching StackOverflow and blogs.  Whenever you get a comment, repsond quickly -- definitely within two days, and usually faster because after two days the person has completely moved on from the issue.  It may seem overwhelming to look in so many places for buzz or anti-buzz about your product, but start small and build up as you build your developer base.

2. Pair Programming.  Whenever you get a communication with another developer, offer to pair program and don't stop asking until the other person agrees.  This can compress the other developer's learning time into the two hours they are likely to be willing to spend, and the other developer is much less likely to become frustrated or confused.  It can also help you to understand the patch.  A speaker recounted that he hated one proposed patch because it wasn't elegant and didn't fit into the system's intended design.  Rather than just rejecting it, he pair programmed with the proposer and after a while realized that his system was architected in a way that prevented any cleaner, better solution.  So he accepted the patch, and that patch has been important for his community of users.

When pair programming, start with the camera on for a few minutes to establish a personal connection.  Then, after that, go voice-only and use screen sharing.  Even Skype's crummy screen sharing works pretty well, and other systems like join.me are even better, especially ones that let you share the keyboard and mouse as well as the screen.

The "98% conversion rate" statistic was very fuzzy to me.  I suspect it is the percentage of pairing sessions that eventually led to at least one commit by someone.  I would find it hard to believe as the number of developers who became active in the project.  I wish the presenters had been more clear and upfront about this, because it felt like they were misleading or overselling.

A downside is that pair programming is an incredibly time-consuming approach:  it's hard to imagine spending multiple hours for each communication that comes to an open-source project.  The speakers don't consider this work:  they enjoy pair programming so it is just fun.  Furthermore, the potential benefit from a fix for an important bug or from attracting a new developer may be very large, so significant time investment is worthwhile.

3. Action items.  In any presentation, your final slide should contain a single, specific action for someone to take.  One speaker recounted that when he started putting a download button on his talks, his downloads went up a lot.