I haven't thought about it much and I'm not a project maintainer. As for your bus factor of 1: a) it only matters when there's actually a large group relying on your project and b) the answer is "have multiple maintainers with commit bits."

To take a shot at something "more concrete":

    * New releases will be cut at least on a quarterly schedule
    * When the number of open issues passes 25, a new maintainer shall be added (if not sooner)
    * Maintainers may leave a project at any time and are encouraged to do so if they need to move on to other things
    * Maintainers may return when they have time
    * Once per year, maintainers shall either reaffirm their desire to continue maintaining the project or step back from maintaining
    * After 2 merged PRs, a contributor is promoted to a maintainer

The main functions here are 1) add clarity to whether anyone is actually maintaining the project & who 2) Clarify that maintaining the project is an ongoing commitment & it's perfectly fine to step back from that 3) Create a mechanism to add maintainers & to signal when new maintainers are needed and 4) Create some general guidelines around releases, so people know what to expect (and know when things are no longer happening).

This is certainly not a good governance plan for everyone, some may find it too prescriptive, but it seems like it could be a good start for projects like axios & pipenv. The idea is to prevent "is this project dead" type issues before they arise. When a project is losing maintainers & no one wants to step, it's clear that the project is waning.

Of course it's also perfectly reasonable to say "that's too much work" or "f*ck off, it's my project." This convention would help people make more informed decisions when adopting a project for use. Some will be fine with "whatever", some will want a clearer plan, both are OK.

I’m in a similar situation, maintaining a project that’s used widely enough it should probably have a continuity plan, but not enough that it’s developed a robust community of other contributors who could step in.

Jazzband [0] seems meant to address exactly this: “a collaborative community to share the responsibility of maintaining Python-based projects.” And it looked promising, but it’s not entirely clear that the Jazzband project itself is all that active (only news status update is the launch announcement from 2015; last public Twitter activity was in 2017).

[0]: https://jazzband.co/

Oh, just realized that pip-tools (being discussed favorably downthread as a pipenv alternative) is a Jazzband member project: https://github.com/jazzband/pip-tools.

I actually think that accepting contributions productively is almost a full-time position and will turn you from programmer to manager.