Open? Check. But Is Your Community Growing?

There is much—legitimate, mind you—celebration of late about the continued success of open source within software development. But there are times when that success may not be enough, even when good-faith efforts are made.

It is one thing to have an open source software project and quite another to have a healthy and growing open source community. Even when a company or project is making legitimate and strong efforts to free and open source processes and values, it may not always hit the mark—especially when it comes to community.

There are quite a few software projects that we in the Open Source and Standards group work with, both on personal and professional levels, and one of the key differentiators that gives a community better growth is the presence of what we call "onboarding."

Onboarding, in this context, is the term used to describe the process used to get people into a community. That process can take many forms, and there can be more than one path into your community, but the key thing is there needs to be a process. Otherwise, you will have a project where no one will actually participate.

The biggest enemy to onboarding is not, as some would believe, a lack of advocacy or marketing. These things help, but you can tweet all the live-long day about a project and still get nothing but casual interest. No, the biggest enemy to community growth is friction.

Friction can take many forms, but there are some of the more common ways it shows up:

• A lack of description of the project and its goals
• No easy way to access the project's output
• No clear path to contributing to the project

In other words, you have to make the project easy to understand, easy to use, and easy to change.

One project that does this well for its community is OpenStreetMap (OSM). A wiki mapping platform, OSM has made it very easy for anyone with a browser to come into the project and start making changes and improvements to its content. Examples of onboarding paths include:

• A home page with clear links to immediate tutorials
• A robust and active wiki for documentation
• An active event calendar with regional and local meetups
• Projects like MapRoulette, Improve OSM, and a Battle Grid to help users find known issues and correct them.

While mapping might not be your cup of tea like it is for a map nerd like me, the way OSM has built so many clear and defined paths for any user to access and change its data can be an example for many free and open source projects.

Indeed, OSM's methods may seem daunting to many: how can we possibly recreate so much documentation, tutorials, and tools? To be fair, OSM has been doing this for a while, and has had time to build these onboarding paths. Another thing they did is leave the older paths open. One could argue that the goals and datasets of Improve OSM sort of overlap with Battle Grid, so why keep the older Battle Grid around? Clearly, the OSM folks have taken the "if it ain't broke" approach here and decided to leave the Battle Grid tools in place, because if that's a way people want to use to find errors on OSM, then why not use it? Data are getting fixed, regardless.

For other projects with more modest resources, OSM's multi-path approach mat seem unattainable. But you don't have to try to emulate this. One clear approach is all you need to start. Identify friction points in your project that might keep people from participating in your project and then hack away at them like a machete in the jungle.

Get that onboarding path built, and you will see more community growth.