Every open source or open science project has a contribution model, whether it was designed intentionally or not. This model determines who can contribute, what counts as a contribution, and how the project responds to their work. Basically, it shapes the whole experience of getting involved.
The model most projects run is inherently code-centric. This code-centric model often fails to capture the breadth of labour required to maintain a healthy open project, such as documentation, community building, design, etc.
Consequently, projects unintentionally exclude potential contributors with high-value skills in communication, organisation, or user experience but lack the specific technical specialisation or time availability to navigate a pull-request-based workflow. This narrow definition creates a negative feedback loop: valuable expertise is lost, and the burden of non-code maintenance falls disproportionately on a small core of maintainers.
This article examines how maintainers can design inclusive contribution models in ways that are sustainable for their projects.
What does an inclusive contribution model look like?
An inclusive contribution model begins by broadening its definition of contribution. If we strip away platform mechanics, metrics, and norms, a contribution is any act, big or small, that adds value, time, or resources to make a project better.
Based on this definition, you could think about contributions along a number of dimensions, such as:
- Where the contribution adds value:
- Knowledge: writing documentation, creating tutorials, answering questions, translating content, or blogging about the project.
- Quality: reporting bugs, testing new features, running user research, doing accessibility audits, or giving design feedback.
- Community: welcoming and onboarding new contributors, organising events, moderating discussions, or facilitating meetings.
- Infrastructure: setting up CI/CD, building tools, managing projects, or working on governance design.
- Finance: donating money, securing grants, or finding other sources of funding.
- How contributors engage: Is the work episodic or recurring? Synchronous or asynchronous? High- or low-commitment?
- The type and level of expertise involved: Is specialised knowledge required, or can the task be handled by newcomers? Does it draw on technical, organisational, design, or social skills?
This helps maintainers design contribution pathways that reflect how people actually participate.
Another approach to designing an inclusive model is to think about the kinds of contributors your project is likely to attract and design pathways with them in mind. You could consider creating “contributor personas” who are representative of those you’d like to attract to your project or those who could be interested in participating in your project.
The important caveat is that personas work best when they're built from aspiration rather than from your existing contributor base. If you model your personas on the contributors you already have, you'll optimise for the people you've already attracted, which mostly means encoding your current blind spots into your design. The more useful question is: who isn't here yet, and what would their experience look like if they tried to contribute today?
It helps to model your potential persona using the curb-cut principle. Design for the most constrained contributor, and you improve the experience for all contributors.
How it looks in practice
Say you're a maintainer and you want to put all this into practice. You’d want to start with an audit. That’s how you figure out where you may be lacking and where the contribution would add value. Maybe you realise that your documentation needs a major update.
From there, you think about how someone would engage with that work. Does it need to be done in one sustained push, or can it happen in smaller pieces over time? Then you think about expertise. Does this task require deep familiarity with the codebase, or does it primarily need someone with strong writing skills and enough context to understand the project's purpose? If it's the latter, you've just opened the pathway to a much wider pool of people.
Having a user write documentation often produces better results because they’re closer to the audience's perspective and less likely to skip details that code owners take for granted.
When you document this pathway, whether as an issue, in your CONTRIBUTING file, or your README, a contributor can read it and know immediately whether it fits their situation. A student with three weeks of dedicated open source time, the right skills, and a need to build their portfolio can pick it up with confidence, make a real contribution, and move on, without worrying that their short-term involvement makes their work less valid.
That's the practical payoff of designing around dimensions rather than just task types: you stop accidentally filtering out contributors whose circumstances don't match an assumed default.
Conclusion
You can foster inclusive contribution models in your open projects by expanding your current model to accommodate contributions beyond code and by using dimensions of participation as a lens for designing with diverse contributors in mind.
None of what this article proposes requires a complete overhaul. The framework here is intentionally flexible—something a solo maintainer with a small utility and a foundation-backed project with thousands of users can both work with, at whatever pace their project allows. It gives you a clear view of your project's contribution model, so you can improve it one pathway at a time.
Further Reading
Acknowledgements
This guide was written by Victoria Nduka and reviewed by Riva Quiroga.