Edit: I'm closing this initiative. I still encourage you to find backup owners for your crates, but I can't provide that myself.
Do you have a specific list of packages in mind, being kind of system-critical? Do you have a list of crates, requesting for adoption (RFA)?
I'm my case it's (almost) every create by me: https://crates.io/users/kornelski
I'm thinking about organising volunteers/establishing a best practice in general. It would be best if crates could be given backup owners as soon as they're published, rather than later after it's discovered that the original owner is lost. So more like godparents rather than foster parents.
Can help on some of the crates if needed
While it doesn't help with managing owners, I'm an advocate for creating github orgs and relying on teams. This helps centralize management of ownership.
Some orgs I'm aware of to consider moving crates to
- clique for CLI libraries
- assert-rs for testing
- crate-ci for CI and release management libraries and tools
I will admit, usage of teams is non-obvious from the web UI. I found it is documented but I only hunted for it because I had heard rumor of the feature.
That's a good tip!
Adding teams is safer (doesn't give full ownership). Unfortunately, crates.io only allows team admins to add crates.
I think this is a good subject and project for the ecosystem working group. It comes up regularly, but no action ever came out of it.
I think if someone made a good case for groups, crates.io could totally grow that feature.
I like the idea of allowing crates to be owned and managed by teams, not just individuals. Not only would it increase the bus factor, but there are a lot of benefits to having multiple sets of eyes looking at the same project and it'd hopefully lower the barrier to entry for enthusiastic new rustaceans to get involved in the community.
So kinda like how various services will prompt you to add things like 2FA if you haven't already. We could have a thing which periodically checks the crates on crates.io and send people a friendly message along the lines of "it looks like you're the sole owner of the XXXX crate, you may want to consider adding a backup owner to increase your bus factor and lighten the load. See [insert link here] for more details".
Here are a few things to do
Nah. Most crates are fine with single authors. We could create an advanced criteria that picks crates that:
- have a lot of open issue & PRs
- creates with no activity for more than 6 months
- crates marked for it at a specific places on the crates website.
If we had any kind of notification, my main criteria would be number of dependent crates. If it is a low usage crate, there is little impact if the author disappears. If its a high usage crate, then having backups becomes important. Things come up in life, though usually not as dramatic as a literal bus hitting a person, and the intention is to not have the ecosystem come to a halt because of it.
yeah thought about that but forgot to add it to the list
@dylan.dpc Thanks for your offer. I've sent you invites to some of my crates.
Thanks for the link @Pauan! The article makes a good point that this is very much a social problem and can be solved by cultivating co-maintainers and having a healthy community of people willing to help out.
Didn't get any invite yet
Is it a good idea for add this for all open source crates I publish or it is only for some important/notable/serious projects that are expected to have some userbase or contributors (or at least some real reverse dependency)?
Shall I run something like
for i in code/rust/*; do (cd $i; cargo owner --add github:rust-bus:maintainers) done
IMHO it's fine for all crates. You never know which ones may become popular when you're not looking
@kornel I'd be keen to help out! My GitHub username is the same as here,
I'd also like to add my ffi_helpers crate because I can see that being quite valuable to the community, particularly those who need to use a Rust library from other languages. I'll run
cargo owner ... when I get home.
I like this idea! Lately we've been trying to pull libraries out of the
nursery, and one of the side-effects is that the nursery libs team on GitHub remains crate owners along with the new team (the more the merrier). Solidifying that side effect in a bus-factor team for the wider ecosystem sounds great to me. I'll just go ahead and blat some of my own disorganized thoughts now
It's probably not likely the team will need to act anytime in the near future so it might be good to work out some semantics and capture them in a repository under that organisation you created first?
The big questions for me are:
- what is an abandoned crate?
- what does the team do with abandoned crates?
From that we can answer what does it mean for the bus factor team to share ownership over a crate?
Different crate authors would probably have different opinions and expectations. Finding a balance of proactive and reactive responses to keeping the ecosystem moving forward is probably going to need some more thought. I think a library needs to be in a particular state of maturity before you could proactively shift maintainership if the current maintainer shifts their attention elsewhere temporarily and have it then shift back.
Personally, I'd also be cautious about conflating shared ownership of a collection of crates with shared maintainership of that collection right now. So when faced with an abandoned crate, my preference would be towards facilitating its handover to a new group of maintainers, rather than having the bus factor team take on that maintenance responsibility (handover might involve triaging, working through outstanding PRs, setting up communication channels, but not indefinitely). The reason is that in my experience, the bigger and less cohesive a collection of libraries gets the harder it is to give each library the dedicated, domain-specific maintenance attention it needs.
Anyways, I'm excited about this idea, and would love to get on board and help out too!
What we can do is create teams within the bus organisation or give them the option to create their own organisations (the way we did for UUID).