Great Wide Open

How to Attract More People to Your Open Source Project

Do you wish you had more people contributing to your FOSS project? These suggestions have worked for other people. Maybe they can help you, too.

The borderline between mentoring and good community practices is a hazy one, especially when it comes to attracting new contributors to an open source project. In the process of researching my feature article, Mentoring in Open Source Communities: What Works? What Doesn't?, FOSS experts shared several bits of advice that were not-precisely-mentoring, but were too valuable to leave on the cutting room floor. So in this blog post, I'll collect several suggestions about the care-and-feeding of newbie users. (It might help you to read the longer article, first.)

[ See also: Convincing the Boss to Accept FOSS ]

One repeated suggestion is to create a system to encourage participation. There are lots of ways in which to do this, though it's clear the underlying requirement is for someone in the FOSS project to think, "How can we make it easier for new people to get on board?"

A seemingly-obvious answer is to have an "Absolute Beginner" forum, though I've visited dozens of projects that lack one. As Kevin Brown, an architect at Speech Systems says, "Newbies usually don't know where to post correctly for help." Moving threads out of the general-use forum can chase people away.

Similarly, Denise Paolucci, co-owner of Dreamwidth Studios, a fork of the open source LiveJournal project, recommends an IRC channel for the beginners, known as #dw_kindergarten or "the kindergarten," where people can ask beginner questions without feeling like they're interrupting or worrying that they'll look stupid. Her project also has a Dreamwidth-based community which serves the same purpose, for people who don't like to visit IRC, and several "getting-started" tutorials on the Wiki that assume nothing about someone's experience level. Don't assume that people all like to use the same communication medium!

It's also important to create a culture that welcomes new people rather than one in which there's an "in-crowd" or clique. I can speak with personal experience on this point. My husband is a committer on Plone, an open source content management system, and I tentatively offered my writing and editing services during a Plone sprint. Two people (both women, as it happens; my anecdotal observation is that FOSS women are relentlessly friendly) went out of their way to make me feel valued and part of the community. Others joined in with virtual and In Real Life smiles. I've stayed "connected" ever since.

As Brown points out, communities need to be vigilant about community bullies, those who belittle posters for whatever reason. "It shouldn't be tolerated at all, and repeat offenders should be banned, no matter how brilliant they may be," he says.

If you give one person overall responsibility for the community role (which is recommended by several people in the original article), you can make an even bigger difference. Nancy Garrity, Alfresco community manager, is putting into place a forum "points" program in which users can award points for helpful answers; each month, Garrity gives an award to the top point gainer. She’s also set up a process to deliver codecamps. "I’ve invited a select group of our SI partners to receive advance “partner enablement” on our new technology," she says. "Last year we did one on Surf, our new web development platform. I will be doing one next month on CMIS (Content Mangement Interoperability Spec) development. Partners who participate agree to then conduct small, hands-on codecamps for community members. These have worked very well."

It's also okay to act locally. Garrity is working with Alfresco community members around the world to establish local communities. "Ubuntu does this very successfully," she says. "The idea is that local community members lead these groups and we support them. What Ubuntu does so well and we hope to emulate is that these meetings are at times 'purpose-driven.' They get together and find and fix bugs, translate documentation, code up some module or perform other tasks."

If it takes new users extra effort to install and set up your software — that's going to be so for plenty of complex apps — make it easy for prospective users to learn the user experience without requiring them to invest the time and effort. I've seen some projects successfully show off what's possible using short videos. But Paolucci credits much of Dreamwidth's success to the hosted development environments they created. "The DW code is crazy-hard to install even to hack on and requires a bunch of dependencies and annoyances," she says. "So, instead of requiring people to have their own development environment to generate patches or hack on the code, we offer hosted 'sandbox' dev environments." The Dreamhack service gives everyone who's interested in hacking on the DW code their own instance, as production-like as possible. "Just by doing this, we cut the amount of time and effort someone has to put into getting started with us to nearly nothing," she says. "When we started, it cost us around $70/month. We've expanded it since then, but my point is that it doesn't need to break your project's bank — and there's plenty of grant money that you can apply for."

It also helps to use good coding practices in a manner that makes it easy for someone to contribute "just a little" and minimize the fear that a project (or programming) newbie will feel she's done something wrong. Paolucci starts with, "Have clear, extensive, and easily-findable programming style guidelines." Any style issues that will cause a patch to be rejected should be documented, as should architecture considerations or best-practices. "Someone experienced should be able to come in and immediately know where your project stands on tabs-vs-spaces, postfix conditionals, four-or-eight-space indents, bracket style, etc.," she points out.

Also, she suggests, log bugs for everything you want to improve, no matter how small or minor, the minute it occurs to you. Don't try to keep the bug list in your head even on a small project. Use a bug tracker such as Bugzilla, Fogbugz, or RT. "Keep it public, so absolutely anyone can come along and view the outstanding bugs," Paolucci advises. "Keep it categorized by product/component. But also keep it categorized or keyworded by the amount of effort/experience each bug needs, so newcomers will be able to instantly identify the list of bugs you think are suitable for beginners.

Putting these suggestions into place will make your project more interesting, no matter who is scanning the website (even, say, a press person). It also has an impact on the overall health of the particular open source community. "We saw a bunch of things that worked to limit participation and keep the OSS end of [LiveJournal] from taking off: long waits for patches to get reviewed and committed, nowhere to really go and get advice and/or help, no clear patch submit guidelines, no documented programming style guidelines (but plenty of undocumented ones), insufficient feedback as to why patches got rejected, etc.," says Paolucci "Over time, the OSS community that was working on LJ drifted away, to the point where it became rare to get more than one or two patches a year, with all development done in-house." Now? By applying all the processes above, and being willing to teach people of any experience level, Dreamwidth has attracted a vibrant community. It's also 60-70% women. "Over two-thirds of our contributors have never programmed before, never worked on an OSS project before, or never worked in Perl before," she says.

That's the viewpoints of just a few (very smart) people. Surely, your open source community has done some things to attract more people to try out the software — and to get involved in improving it? Share a few of them in the comments, and everyone can learn.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world