Takeover Requests for Abandoned Packages

if, when, and alternatives

Any software package should be (in descending order of preference):

  1. active: maintained by truly dedicated developer(s) – i.e. fully knowledgeable of & committed to users’ expectations
  2. maintenance-mode: security-only updates
  3. abandoned
  4. borked: taken over by person(s) who put their needs before the existing userbase

To demonstrate you are worthy of taking over maintenance of a package, score points to signal that you will NOT downgrade it to category 4:

action examples points
support ask/answer a question, start a discussion 4
issue bug report 5
issue feature request 6
“minor” pull request (PR) fix typos 6
“major” PR alter core logic, overhaul docs 12

Below 30 points, you should fork the package (possibly with a different name) instead of trying to take over.

In any case, leave unresolved issue(s)/PR(s) open on the original package (don’t close them in frustration) as they may inspire others to take more responsibility!

Collectives (charitable public groups) looking to take over packages should also have published mitigation/remedial policies for dealing with the bad actors who will inevitably infiltrate their ranks.