For long running projects, having many developers added over the years, it may be necessary to remove inactive developers for security reasons. *

Do active & long-running open-source projects have a policy for removing commit access from inactive developers?


  • This is something nearly every active open-source project would have to deal with.
    Unlike closed source software that is unlikely to have volunteer contributors.
  • Other projects must have run into this before, so knowing what they found works well is useful information.

* having a large number of people able to modify your source code increases the attack surface of the project.

  • I've re-worded the title, removing the term "good" as it's too subjective.
    – ideasman42
    Feb 18, 2021 at 1:55
  • I think it matches much better softwareengineering.stackexchange.com .
    – peterh
    Feb 18, 2021 at 9:16
  • 2
    @peterh-ReinstateMonica, Open Source projects have some special considerations here, because the involvement of someone with the project cannot be tied to their involvement/employment with a particular company. Feb 19, 2021 at 7:10

2 Answers 2


As an example of an active & long-running open-source project, I will use Debian.

First of all, you don't get commit access to the repositories all that easily. From the guide on how to contribute:

Contributing. [...] You don't need to be an official Debian Developer to carry out just about all of these tasks. Existing Debian Developers acting as sponsors can integrate your work into the project. It is generally best to try and find a developer who is working in the same area as you and has an interest in what you have done.

Finally, Debian provides many teams of developers working together on common tasks. Anybody can participate on a team, whether an official Debian Developer or not. Working together with a team is an excellent way to gain experience before starting the New Member process and is one of the best places to find package sponsors. So find a team that suits your interests and jump right in.

Joining. After you have contributed for some time and are sure about your involvement in the Debian project, you can join Debian in a more official role. There are two different roles in which you might join Debian:

  • Debian Maintainer (DM): The first step in which you can upload your own packages to the Debian archive yourself.
  • Debian Developer (DD): The traditional full membership role in Debian. A DD can participate in Debian elections. Uploading DDs can upload any package to the archive. Before applying as an uploading DD you should have a track record of maintaining packages for at least six months. For example uploading packages as a DM, working inside a team or maintaining packages uploaded by sponsors. Non-uploading DDs have the same packaging rights as Debian Maintainers. Before applying as a non-uploading DD, you should have a visible and significant track record of work inside the project.

As you can see, you have to prove that you are willing to really commit to the project before you get the rights to upload stuff. Once people have gone through that process, it becomes less likely that they will suddenly disappear.

But as even dedicated volunteers sometimes take a leave-of-absence or stop entirely, there is a process in place on how to do that gracefully, which can be found at https://www.debian.org/doc/manuals/developers-reference/developer-duties.en.html#retiring.

If you choose to leave the Debian project, you should make sure you do the following steps:

  • Orphan all your packages, as described in Orphaning a package.
  • Remove yourself from uploaders for co- or team-maintained packages.
  • If you received mails via a @debian.org e-mail alias (e.g. [email protected]) and would like to get removed, open a RT ticket for the Debian System Administrators. Just send an e-mail to [email protected] with "Debian RT" somewhere in the subject stating from which aliases you'd like to get removed.
  • Please remember to also retire from teams, e.g. remove yourself from team wiki pages or salsa groups.
  • [...]

It is important that the above process is followed, because finding inactive developers and orphaning their packages takes significant time and effort.

Also, if someone has put considerable time and effort into a project, it is likely they have also made friends among the other maintainers/developers and they would likely inform those if they are planning to stop contributing to the project for whatever reason. That again reduces the number of unannounced disappearances.

And finally, you can have a policy that if somebody doesn't check in with the project for an X amount of time (without prior notice) that their accounts will be revoked.

The policy for Debian, which @MadHatter was kind enough to supply, is

Following each Debian release, all DMs who did not make an upload during the cycle for that release will be automatically retired.

For example: after the release of Stretch, DMs who did not make an upload since the release of Jessie will be retired.


What is "good" is subjective. You could just make a rule that anyone who hasn't made contact with the dev team for a year gets removed, and they can be added back later if they ask.

But another solution would be to restrict direct commits entirely. Github (and the other hosting services probably have something similar) lets you block all direct commits to your master/main branch, and instead all changes must go through pull requests. You can then add further restrictions, such as requiring a certain number of code reviews, or signed commits.

  • 1
    While that is true, that you can put repository access behind review, that basically changes the problem/question to 'who has owner rights to the project to make such changes and approve access and when is that revoked? ' Feb 17, 2021 at 23:25
  • 1
    Yes, it transfers the problem to that of managing the approved reviewers. I would hope that's a smaller and more stable set of people, but still in need of a policy. Feb 18, 2021 at 13:10
  • "But another solution would be to restrict direct commits entirely." Even if you do this, with a large enough project this may still be many developers.
    – ideasman42
    Feb 19, 2021 at 11:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.