How do we think we should handle maintainers moving on?

152 points ShantyShark 133 comments

This post is not meant to shame maintainers. Maintaining crates is a difficult and thankless job, and I don't blame any developer for choosing to move on.

However, the method by which we handle this may not hold up long-term. More and more crates will come and go, and the ecosystem may eventually become clouded with deprecated crates and forks of forks of forks of forks, getting us yaml-rust17, the currently maintained fork of yaml-rust16, a previously maintained fork of yaml-rust15 and so on.

For example: dotenv, Unmaintained as of December 2021. dotenv is still available, and the crates.io page and its github repo make no mention that its use is discouraged.

Someone could easily cargo add dotenv rather than the now-recommended dotenvy, and receive no warning except by cargo-audit or the like. This is trivial example, as a .env loader doesn't have a lot of safety implications, but one could imagine the problem extending to much more impactful crates.

The authors of bincode (crates.io & github) published an article explaining their departure and concerns here, which spurred me to ask the community's opinion.

The crux of all this yapping:

Should we allow (by community vote, by the Foundation, or by some other measure), the passing of ownership to a new maintainer?

Maintainers can pass on their crate, but the burden is on them, and they're ready to move on. And what if the last maintainer passes away?

This does raise some questions though:

  1. Would we increment a major version, so that upgrading is manual?
  2. How could we communicate the change in ownership to dependants?
  3. Do we take a page from hackage and let these crates become "orphans", then allow someone to petition to "adopt" them?
  4. Do we take a page from npm and let the ecosystem get flooded with useless cruft and name-squatting?
  5. How could we avoid abuse, or the npm kik left-pad incident?
  6. Would this make supply chain attacks easier, or more subtle? XZ Utils already proved maintainer burnout is a viable attack vector.

Names on crates.io are strictly scarce though not practically (64 ASCII alphanumerics plus - and _ for ~10^100 potential names), but good names might be.