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.