How do we attract contributions to our small and niche but open-source repositories?


I manage a number of open-source Python libraries for Raspberry Pi HATs, pHATs and other add-ons. We don’t see a tremendous number of contributions, issues or pull requests across these libraries- and I want to find a way to incentivise people to contribute, and break the ice for beginners.

Since the market with serve has a very large crossover with education and tends to attract many beginners, I’m also keen to encourage users to “practise” on our repositories by submitting examples, making tweaks to documentation and so on. (I’m keenly aware that this will create more work for me, but I’m keen to pay forward the help and patience which was demonstrated to me when I was first learning to code)

I appreciate that some people might not be keen making contributions to libraries that may require a hardware buy-in, but I think there are enough users out there to make this worth trying.

I’ve seen suggestions here for beginners to seek out the “good first issue” label, but we don’t really have a project large enough to generate any suitable issues. Could I, perhaps, externalise my roadmap for library improvements and invite users to build out new features?

I guess my TLDR is; how does a small GitHub repository motivate and invite its users to make contributions?


You could have a sprint event. I’m just out of one for Jupyter notebook

1 Like

I am a maintainer for several small and some very large open source projects. Without knowing more about what those libraries are and who the demographic is I can’t really say. Open source adoption is often driven by need, so the question is where does your demographic look to for solving problems. Having a really great documentation site is super helpful.

One thing that we found is that IRC was alienating many of our newer users and decided to switch to slack (enabled the IRC gatreway for those who didnt want slack client) as this is what our community wanted after polling multiple times. I think it’s really great to connect the developers in real time with a project with it’s consumers regardless of what tech is used to facilitate. We also created a community repo to start building out a lot of things that make a project successful such as:

  • good contribution gudelines

  • information on accepting new libraries/plugins from the community

  • information on who are maintainers on various areas (if applicable)

  • insight into the pull request process

  • insight into how changelogs should be handled

  • build and release process (including cadence)

  • communication channels and how to use them ( having people ping @channel is a great way to piss off users at 3AM because they are in a very diffrent time zone ). Ideally restrict @shoutouts to maintainers to protect users from themselves and eachother.

One thing I find helpful for smaller projects is to try to invite repeated contributors who have quality work as a collaborator quickly. This helps give them assurance that even if you fall off the face of the planet they can keep maintaining it. For lareger projects similar principles apply however they tend to have more need to be cautious with inviting maintainers. 

Also having good pull request and issue templates really help with improving the quality of the issues and pull quests. They help you say collect say version information that the user might not have included and rather than being able to say that was fixed in version x.y.z you have to ask for it. Same thing with pull requests. For example if you want people to update the changelog or require a testing artifact then have that be a checkmark they can click after creating the PR. This helps set expectations and allows them to react to your project needs, wants, etc. The less a user feels like they are fulfilling some nitpicky maintainers whims and more ok that’s something the project expects me to do makes it a bit smoother. 

I try to always leave a reply before reviewing to people who have not previously contributed thanking them for their hard work and willingness to share back with the community.

I think one of the more important things in keeping your contributors happy is to quickly review and release. Nothing is more frustrating when a project has a pull request that was merged say 8 months ago but never released. 


This is fabulously in-depth and helpful, thank you!

I particularly like your approach to community guidelines and process- the separate “Community” repository is definitely something I’ll look into adopting.

Since our libraries are intended- first and foremost- to support our hardware products we don’t have quite the same fuzzy feeling of a less specific open-source project. We do have quite a few code projects that have a wider appeal, however, including libraries for indivudual ICs, but these have a very limited utility outside of people looking to integrate those things into a design.

Still, in the interest of full disclosure (actually I wasn’t intending to be coy about this) I’m referring to our Pimoroni GitHub organisation:

Any single product has a base of possible contributors narrowed down to only people who own that specific product, or perhaps have a unique contribution to make otherwise. I’m looking for anything I can do to lower the friction between those users and making their first contribution.