I recently attended a great little conference about the craft of software development and where it’s going. It was called Monki Gras, and it was run by the fine analysts at Redmonk. It was held in London, UK. Three talks provided three great perspectives on the care and feeding of a developer community:
- Kohsuke Kawaguchi (@kohsukekawa) talked about making everything relentlessly easier to attract new collaborators based on his experiences in the Jenkins community.
- Dave Neary (@nearyd) of Gnome fame talked about mentoring and apprenticeship to anchor and grow new contributors.
- Donnie Berkholtz (@dberkholz) talked about the long term economic cost of trolls and troublemakers to a community based on his experiences in the Gentoo world.
Kohsuke presented the idea that there’s a developer funnel in an open source community project, just like there’s a customer funnel in a business. Every potential future developer starts as a visitor to your project website. It’s the project leader and committers job to encourage the visitor to become a user, and the user to become a developer. To this end, EVERYTHING must be easy to do to get started as both a user and then as a developer.
Kohsuke gave some excellent examples (and counter examples) of actions a project can take to make participation easy. It all revolves around the idea that the smartest developers may not work for you (yet), but in that very limited time when they are giving your project some attention you must make it easy for them to become a user otherwise they will take their attention (and energy) elsewhere. If they feel they’re wasting time trying to understand how to download and install your project, they’ll leave.
We used to talk about the ten minute rule in the packaged software world, i.e. if a potential customer couldn’t install and make your software do something useful in ten minutes, you’ve probably lost the customer. So too with participants in an open source project. There’s just too many other things in the world to focus attention on over your hard to use software. Going from user to developer needs to be equally easy to understand for someone to invest their time in contributing software to your project.
Kohsuke’s slides for “Creating a Developer Community” are on SlideShare. I posted additional notes on Kohsuke's talk on the Outercurve Foundation blogs.
Dave Neary took a look at a different phase in the community engagement process. Once you have developers beginning to contribute, how do you then anchor them in the project and bring them into your project’s development culture? Dave presented ideas based on apprenticeship and mentoring from a variety of perspectives. He too presented a number of anti-patterns that get in the way of successfully creating a mentoring environment (e.g. tasks that take too long, or tasks that are too big). As with Kohsuke's ideas, a project leader needs to remember that new talent isn't necessarily inexperienced, just inexperienced in the particular way your project culture works.
While Dave’s slides are not available, many of his ideas are well captured in a post on his blog on "Effective Mentoring Programs".
Lastly, Donnie Berkholz took a look at the cost of trolls and troublemakers in a community. While everyone chuckled on his opening title that “Assholes are Ruining your Project”, he quickly established the reality and cost to a project. Donnie is a self-professed data geek. He likes to measure things. So he looked at the growth and collapse of the Gentoo Linux community based on when certain troublesome people entered the community. His ideas built on the idea that contributors create results in a community that then builds the reputation of the community that then attracts new contributors.
Bad elements entered the Gentoo community. They lost 20% of their participation. That’s the initial cost. Then they dealt with the problem, but that 20% never returned. It was permanent damage and a permanent cost. And the damage wasn’t just in participation, the Gentoo reputation suffered to the point they didn’t attract replacements and there is still a perception problem. While sociological models suggest that it takes five positive acts to counter a negative act in a relationship, and Donnie had some great ideas for handling and preventing rogues and rabble-rousers, his closing remarks were that trying to work with them is never worth it.
Donnie’s slides are available on SlideShare.
They were three great presentations highlighting the importance of attracting, encouraging and protecting developer communities. I wrote up my notes on the conference overall, which proved to be one of the best small conferences I’ve attended.