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.
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.
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
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.
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!