Scaling your developer community with plugins

Community managers care about growth in their community, but growing development communities is hard work. It's rare for developers to start contributing code to projects they've never worked with before—it's far more likely that your developers were (or still are) users of the project, too.

So, this is easy, right? Scale the user community, and the developer community should grow too. But, how? Attracting users isn't easy either—there's a reason we have marketing. Unless you have a big budget for events, materials, adverts, etc., scaling the user community isn't much easier than scaling the developer one.

So we have limited options for attracting users, and virtually none for the developers. What are we left with? Well, for ideas we could look to the ways users become developers.

You'll always have a few people that were destined to become contributors—the right mix of domain knowledge, interest/drive, and programming skill. But there's a larger group who have an itch to scratch but perhaps aren't so confident in diving into the full code base. These are the people we need to target.

As evidence, here's some data from the most recent Foreman Community Survey (the community I work in) showing nearly one-third of the 160 respondents would like to contribute but don't know where to start.

Image by:

^{Foreman Community Survey 2018: Do you contribute to Foreman?}

Many of these people would like to do things like reporting bugs or doing translations, but some will want to code.

Plugins to the rescue

Plugins are a fantastic fit here. With appropriate tooling to help a new author get started, they provide a way for people to get used to some of a project's internals without being tied to the review process, release cadence, continuous integration (CI) systems, and other processes that can make contributing to a project daunting.

With that in mind, here are a few thoughts on implementing plugin support to encourage contributions to a project.

Do: Have a template

This is requirement number one and (in my view) absolutely non-negotiable. A new author needs as much hand-holding as you can provide, and a template plugin provides this in quantity.

Make it easy to enable (in our project it's done with git clone then adding one line to the main project configuration). Make sure there are plenty of examples of ways you can alter the core project (UI changes, system logic alterations, orchestration additions—whatever makes sense). I've seen this done as a git-branch-per-example or all in one go (which is what we do).

To get you started (if you do Rails), here's a link to our plugin.

Do: Have good docs

Almost as important as the template is your documentation. The second thing a new author will do is try to change the template, so they need to find out where to affect the thing they're trying to accomplish.

Redmine has some great examples in its docs.

Do: Provide internal APIs

This lesson brought to you by the voice of experience.

Some programming languages will force this in how they work—it's not possible to make runtime changes to the core code. However, some languages make it easy to alter almost anything (Ruby is notorious for this; see alias_method_chain). If you don't provide ways to hook into appropriate parts of the application, authors will do it some other way. When the project evolves and these hacks break, they'll blame you (even if they shouldn't have been using the hack in the first place). Even plugin development is political, it turns out.

Don't: Break your promises

Related to this, once you provide APIs, honor them. Don't change them on a whim—deprecate cleanly over a few versions, and be sure that the feedback loop to authors works. You don't want them to have to drop everything and fix a plugin right now because the internal API changed.

Don't: Make it hard to install plugins

If plugins are hard to get running, people just won't use them. This is relevant for users, too, but for authors it matters twice—it has to be easy for them to enable an in-development plugin, and it has to be easy for them to deploy it to production after it's ready.

What "easy" means for your project will vary. In our project, we ship plugins as RubyGems (and also package the gems as RPMs and DEBs for easy installation), which are loaded with one line in a configuration file. That's because our project is aimed at system administrators, who generally like installing things from package managers. Other projects use an in-app method (e.g., Nextcloud, which can download bundles into its directory) or through altering container configuration (e.g., Discourse plugins). Whatever you choose, it has to make sense for the project's users.

Do: Keep communicating

The strategies above can increase your developer community—there are about 100 plugins available for Foreman now, and there are others that aren't published publicly; however, none of these are one-and-done things. As your core project evolves, you need to keep in touch with your plugin authors, both to let them know what core changes are coming that may affect them, and to learn their pain points that they want improved. The effort is never-ending, but it is worth it!

Greg Sutcliffe will present Scaling Your Developer Community via Plugins at Open Source Summit Europe, October 22-24 in Edinburgh, Scotland.