Dealing with maintainer fatigue: encourage crate multi-ownership

I believe one of the biggest threat to Rust crates community is maintainer fatigue. People get tired, loose interest, get "real jobs", and sometimes even die. As the result, crates become abandoned or "slow-maintained"... Remember xz "bug"? Forking is not always the answer because the users of a widely adapted crate will rarely re-analyze it for alternatives.

As a community, we should look how we can solve this problem, i.e. a way to socially encourage developers to share the control of their code. Note that there is no "simple universal solution". Instead, it should be many small efforts in both technology and social norm education.

Update: The primary goal is not to create new tools or web features. The goal is to encourage better social conventions for code maintenance in the longer run. These ideas might help us get there, but we could use different ones. Let's first agree that code maintenance is a problem to address.

Some ideas to encourage joint code ownership:

  • Improve crates.io search result view:
    • prominently display how many people can deploy a crate
    • introduce an icon of "multi-maintainer" crate, and explain why it is being shown and why its important
    • de-prioritize single-owner github repos
  • introduce "health score" for a crate, taking into account repo/crate update frequency, ...
  • allow community to suggest dead-crate alternatives that can be shown by cargo update
  • make crates.io more of a "wiki" with contributable modifications (i.e. editable portions for each crate's description, with ability to discuss, etc)
  • prominently show an icon to "invite collaborator" for the crate's owner
  • prominently show a warning icon for others that the crate is a higher risk of being abandoned
7 Likes

That strikes me as a choice that would unduly punish well maintained crates with a single owner or kill off crates that are struggling to find support.

13 Likes

@Coding-Badly all of these are up to discussion - so whichever features improve overall community, those are the ones we need to add, and the more questionable should not be done or at least should be reworked.

As for single ownership -- if a crate is well maintained today, but relies on a single point of failure, shouldn't we as a community encourage the owner to share responsibilities? If we keep telling the owner (via some icon/status/...) to find another maintainer, wouldn't it benefit both the owner and the rest of the community to add another person?

I guess you are familiar with the website Lib.rs by @kornel. I think some of the improvements you suggest for crates.io are a better fit for Lib.rs.

4 Likes

Are frequent updates deemed to be good or bad? You can look at it either way. A crate that is perfect when is first published will never be updated at all (possibly this would be unusual);

11 Likes

Are you sure that's the right example to cite here? That happened because the project added another maintainer.

18 Likes

I knew of lib.rs, but I had no idea it had such an extensive ranking/freshness aspect, thanks @rikyborg!

That said, it does not address the main concern. My goal is primarily social: to ensure the Rust crate ecosystem maintains code in the longer run, even after the author steps aside. Many amazing crates were created by "code heroes" - great individuals whose dedication should not be undervalued. We do not want those efforts to be undermined - there is a big cost of switching to a fork, and if we as a community can encourage crate collaboration (but NOT require!), we will all benefit. Just like "fmt" or "apache+MIT" licensing or styling Clippy lints - most crates follow, and it keeps ecosystem consistent. Think Wikipedia articles - some brave soul writes most of it, but lots of people can maintain it afterwards (not ideal analogy, but somewhat close).

So, to address above comments by @rikyborg @geebee22 and @Coding-Badly: my goal is not to improve crate freshness or rank quality or any other tool. That's a nice to have and could be used as a partial solution to the stated goal, but it is not the goal in of itself.

1 Like

:slight_smile: @sfackler, I was thinking it too, but I believe it is still relevant. The xz bug was not an issue of adding a second maintainer, it was a combined issue of 1) inability to consistently evaluate new contributors (i.e. no global "contributor trust score"), and 2) overworked maintainer who could not support the project any longer (exactly what this topic is trying to address to begin with). If we have a better systemic approach to the problem rather than each project dealing with it individually, we should be ok

(hope this does not derail the conversation too much from the main topic... but xz is an amazing topic to discuss too!)

1 Like

Sure, but you're also assuming there is someone else who is willing and able to co-maintain a crate. As the person who maintained time, I assure you that there is no one who has contributed consistently, let alone expressed interest in sharing maintenance burden. It's an "I know it when I see it" kind of situation.

6 Likes

@jhpratt I agree 100% that there is rarely a fully dedicated person like that, especially from the start, especially when there is one very active primary maintainer (and thx for maintaining it btw!). But wouldn't you also agree that you DO want to reduce the risk of a bus factor for such a critical crate? Shouldn't we encourage a contingency plan, rather than business as usual until it strikes?

We could have a community group that helps to onboard a new maintainer if the old one disappears -- e.g. by enlisting one's crates for such actions, or some other rules. We could have well known and respected individuals offer to be your github and crates.io backup even if they don't contribute much...

P.S. Github actually has a Deceased User Policy

P.P.S. It's a chicken/egg problem too - a newcomer won't participate because they don't feel the sense of "ownership" - but they won't feel it until they start owning more and more of it... Tough one, i know.

1 Like

As far as I'm aware, crates.io also updated their policy recently to make it easier to transfer ownership of unmaintained packages: 3463-crates-io-policy-update - The Rust RFC Book.

5 Likes

There was a prior initiative as well:

1 Like

I would think eventually there may need to be some kind of mechanism where you can subscribe to "crates.io with emergency fixes voted on by the community" or something of that nature, some kind of evolution in the policy for maintaining crates that are widely used but unmaintained and also need an update for some reason (and simply forking isn't practical).

3 Likes

I think that the overall idea to have multiple responsible people for one crate is good. However, I do not like most of the practical solutions you suggested. To me this feels like it highly de-incentivizes single-developer code bases and I believe that this is contrary to our actual goal. I think that backup-plans and ownership by a small community in case the original dev(s) is/are not able to continue working on the crate are very good ideas. But these are passive plans which do not actively by themselves interfere with ownership of actively maintained crates. And this distinction is important to me. :smiling_face:

5 Likes

I agree. If I happen to write some code that someone finds useful, unlikely but bear with me, and starts to depend on it, then that someone had better take care of their things without bothering me about it.

The xz situation is a classic case. Somehow half the world becomes dependent on the work of one man. Including large money making organisations. And yet somehow nobody among those users was lifting a finger to do any verification or quality control of the code they were using.