Bus Factor +1 for crates

[kornel]

Lots of crates on crates-io have only a single owner. That’s a huge responsibility for the sole owners, and also a risk for crate users. When solo owners disappear (for lots of reasons — life happens) it’s a major problem, because the crate becomes impossible to change: there’s nobody to release a bug fix, and there isn’t even a way to add new maintainers. Users are left with an abandoned crate, and forks of these creates, which are eventually abandoned too, and so on.

I think it’s best to solve this problem proactively by having a group of volunteers who are happy to be added as backup owners of crates. It’s especially important for new projects that may not have anybody to invite as co-owner yet.

Introducing: Rust Bus. It’s a group with me (@kornel), @dylan.dpc, @Michael-F-Bryan, @jschievink (…).

You can add rust-bus-owner as an owner of your create and:

• We promise not to touch the create as long as its actively maintained. You add rust-bus-owner only as a backup to maintain the create in your absence.
• If an urgent bugfix is needed (e.g. compatibility with next version of Rust, or a security issue) and you’re gone for weeks or longer, we may release a patch version with the fix.
• If you’re gone for months, we’ll help find a new maintainer and a new home for it. If there’s an active fork, we’ll help migrating users to the fork. You will always remain as the owner of your crate in case you choose to continue maintaining it in the future.

---

Run cargo owner --add rust-bus-owner in your create. Anyone can do that for any create.

I’ll then replace the rust-bus-owner user with github:rust-bus:maintainers team. That oddity is because ideally crates should be managed by teams, but Cargo doesn’t support adding teams by non-team-members (yet, hopefully).

[frehberg]

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)?

[kornel]

• 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.

[dylan.dpc]

Hey.

Can help on some of the crates if needed

[epage]

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.

[kornel]

That’s a good tip!

Adding teams is safer (doesn’t give full ownership). Unfortunately, crates.io only allows team admins to add crates.

[skade]

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.

[Michael-F-Bryan]

I’m an advocate for creating github orgs and relying on teams.

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.

t 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 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”.

[dylan.dpc]

Here are a few things to do

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”

Nah. Most crates are fine with single authors. We could create an advanced criteria that picks crates that:

1. have a lot of open issue & PRs
2. creates with no activity for more than 6 months
3. crates marked for it at a specific places on the crates website.

[epage]

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.

[dylan.dpc]

yeah thought about that but forgot to add it to the list

[Pauan]

Relevant: http://fitzgeraldnick.com/2018/01/30/foss-maintenance-stress.html

[kornel]

@dylan.dpc Thanks for your offer. I’ve sent you invites to some of my crates.

[Michael-F-Bryan]

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.

[dylan.dpc]

Didn’t get any invite yet

[vi0]

cargo owner --add github:rust-bus:maintainers

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

or not?

[kornel]

IMHO it’s fine for all crates. You never know which ones may become popular when you’re not looking

[Michael-F-Bryan]

@kornel I’d be keen to help out! My GitHub username is the same as here, Michael-F-Bryan.

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.

[KodrAus]

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!

[dylan.dpc]

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 communiiscation channels, but not indefinitely)

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).