crate.io's policy/perspective on trust and crate squatting

[softprops]

I am a big fan of rust and a big fan of the rust community. However there are still some areas that I think could use some improvement in terms of things that may erode trust for engineers new to rust and exploring the crate landscape. In particular crates.io's policy on crate squatting.

Here are two scenarios that are not ideal and have actually happened to me more than once and which I would like to shield from new rust users and enthusiasts.

advertisement of placeholder crates

Let's say a user new to rust, Jim, get's an earful of excitement from his co-worker Jill about rust and this new ecosystem of async io libraries called tokio. Jim has his own go-to language but is now curious and little excited about rust and would like to compare it his typical developer experience. He installs rust and checks out crates.io. He notices right off the bat that there are three new crates related to tokio.

Wow, sounds like Jill was right! Jim clicks on one of the crates, cut and pastes the crate's name into his Cargo.toml file, then runs cargo update.

He's smiles when he sees the lock file generated as a result. Unsure of what do to next he heads back to crates.io to take a closer look. He then notices the description "Empty crate, used only to reserve the name". This must be my mistake...

Hrm that's interesting. Jim scrolls down and see that 3 others have downloaded this crate
Are 3 others really using this crate???

Jim goes back to the two tokio crates and notices all three are in the same state. Jim goes to work the next day and says, no thanks to rust. It looks interesting but the ecosystem looks very immature. A lots of crates that do nothing!

the let down of ambitious librarians

Let's switch to an alternate scenario. This time Jill a long term rustacean is burning the midnight oil on a new tokio library that handles dns resolution, let's say she wants to call it tokio-dns has it does dns resolution.

She excitedly types cargo publish to share her hard work. Whoops looks like that name's taken. Okay she thinks, it's kind of lame because the crate claimed that name is actually just a place holder.

She shrugs it off and thinks about a another name. She does a string replacement across her code with a new name, tokio-lookup. cargo publish round two. Nope, its claimed and again only parked.

Jill gets frustrated at the first two strikes and is loosing steam but she's not ready to give up. She picks a much less ideal name tokio-resolve. Round three, once again she is defeated. Jill's respect for crates.io just went down and she goes to sleep for the night.

thoughts and suggestions

Crates.io doesn't seem to have an official policy that would remediate this kind of eroded trust in the ecosystem. In fact the lack of a policy may encourage it as more crate authors learn to park their name to ensure it will be available before they've actually made a commitment to publish any content. This of course is a problem if they change their mind later a never decided to publish any content.

One solution could be namespaces which could have other interesting properties because crate name collision avoidance, but I'm not sure how that would work in extern crate declarations.

Thoughts?

[carols10cents]

As another data point, rubygems.org has had the same first-come-first-serve naming policy for 8 years, and trust in the ecosystem has not eroded that I can tell.

[steveklabnik]

Crates.io doesn't seem to have an official policy that would remediate this kind of eroded trust in the ecosystem.

To be clear, here's the policy: http://doc.crates.io/policies.html

[sgrif]

Perhaps it's worth further clarifying what the policy is when a crate has been inactive for a sufficiently long period of time (e.g. years), and the existing owner(s) cannot be reached?

[steveklabnik]

Perhaps it's worth further clarifying what the policy is when a crate has been inactive for a sufficiently long period of time (e.g. years), and the existing owner(s) cannot be reached?

The policy is clear already, imho:

We will do what the law requires us to do, and address flagrant violations of the Rust Code of Conduct.

That's it.

[sgrif]

I think this line is confusing then:

If necessary, the team may reach out to inactive maintainers and help mediate the process of ownership transfer.

To me it implies that there would be some action for those cases.

[steveklabnik]

Gotcha. Yes, that should be made more clear, then. Like, we will try to help, but unless the owner of the crate says okay, we will not do anything.

[softprops]

rubygems.org has had the same first-come-first-serve naming policy for 8 years, and trust in the ecosystem has not eroded that I can tell.

I'm fine with first come first serve but it feels odd for a package manager to expose/advertise empty packages.

I'm guess I'm asking if there's any hesitation to raise the bar in terms of what you'll find on crates.io vs other package hosts. This was probably a more extreme example but I have came across 0.1.0 crates in the past that only contained the default hello world contents while they advertised something more.

If there's a low effort solution for reducing disappointment I think it may be a worth while endeavor if for no other reason than setting and meeting expectations.

[carols10cents]

I'm guess I'm asking if there's any hesitation to raise the bar in terms of what you'll find on crates.io vs other package hosts.

To be clear, rubygems.org does not have any bar to clear for publishing code there either.

[softprops]

I'm ok with this issue being closed if there's nothing to change.

I can empathize with a rationale of having a low bar of entry for inclusiveness. Anyone that has tried to set up a project to publish to maven central will as well ;)

Thanks for posting the policy link about name squatting. I think that's all I really needed.

[carols10cents]

Ok, thank you!!