There is no fixed definition. Open Source Guides says what these roles mean is up to each project. A maintainer usually feels responsible for the project's direction and need not write code. A contributor is anyone who adds value. A committer is someone with commit access. So read each project's own governance notes.
What the guide says
Open Source Guides, in its leadership and governance chapter, lists common roles and stresses that their meaning is entirely up to the project. In some projects maintainers are the people with commit access. In others they are simply the people listed in the README. A maintainer does not have to write code. They may have evangelised the project or written documentation. What they have in common is a sense of responsibility for direction.
| Role | Typical meaning | What to check |
|---|---|---|
| Maintainer | Feels responsible for direction, may or may not hold commit access | Who is listed and who can release |
| Contributor | Anyone adding value, from issue triage to a merged pull request | Whether regular contributors exist beyond the maintainers |
| Committer | Has commit access, a specific type of responsibility | How access is granted and removed |
The guide adds that larger projects may form a core team or subteams for areas such as security, issue triage or conduct, and that formal roles help people know who to ask for help.
Why consumers should care
When you depend on a library, the real question is who can ship a fix. The roles tell you how many people can merge a security patch, whether a security subteam exists, and how the project would cope if one person left. A project with a single maintainer and no written process has a different risk profile from one with a documented core team.
The guide also notes there is no right time to write governance down, and that early documentation about expected behaviour and the contribution process is a start. A project that has a governance file at all is usually easier to assess.
Steps for assessing a project
- Open the README and look for a list of maintainers or a MAINTAINERS file.
- Look for a governance file, contributing guide and security policy.
- Count how many people have merged changes recently, using the repository history.
- Check whether a security contact is separate from the general issue tracker.
- Ask who can publish a release to the package registry, and how access is protected.
- Record the answers in your dependency review notes.
For maintainers
Write down who the maintainers are, who can release, and how someone joins or leaves. It takes a page. It also helps your users know who is responsible for a fix when you are away.
Quick check
Is a maintainer the same as the owner of the repository?
Not necessarily. Projects define the role themselves.
Does a contributor need to write code?
No. The guide includes triage, documentation and organising events.
Where do I find a project's rules?
In its README, governance, contributing and security files.
How Safeguard helps
Safeguard's SBOM and dependency scanning show which upstream versions you depend on, and reachability analysis helps you decide which advisories matter for your code. Compliance and evidence automation can record how you handled each one. Autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can run the free scan on a manifest to see where you stand.
Sources
- Open Source Guides, Leadership and Governance: roles and governance advice. Fetched 19 October 2026.
Last reviewed: 19 October 2026.
