Speaking only at a very high level & trying not to get too deep into technical issues (I agree with sgrif’s post in that regard).
I think it would be valuable for the registry to somehow enable some kind of very visible shared branding among crates by the same project. I don’t think this has anything to do with squatting per se, though it may eliminate some squatting we see today: for example, some people currently squat obvious names that would be associated with their brand so that other people can’t claim them and dilute their identity. However, its clear that some projects value their identity and want to protect it, and that users sometimes make trust decisions based on the belief that a package is part of a project, rather than a third party extension to it. All in all, I think it would be really great to have a way of very clearly and visibly identifying packages that are part of the same project.
(I’ll note that by introducing the hyphen mapping you seem to weaken this branding aspect of your proposal because packages from the “foo” project won’t be distinguished from other packages beginning with “foo-”. Indeed from a technical perspective this mapping seems to be very untenable, we can’t allow crate collision.)
However, I’m not certain that this shared identity should have the properties of a namespace. One other reason people like optional namespaces is that it makes it easy to upload forks, e.g. I could upload withoutboats/libc
to fork libc. While technically I can already upload withoutboats-libc
, the system doesn’t really have an affordance for adding forks to the registry, making it very uncommon, whereas I think this would make it more common.
I think enabling forks to be a part of the registry is on the surface appealing, but could have very serious negative consequences. While I could fork serde
, for example, once I do, all of my libraries that depend on my fork are incompatible with libraries that depend on proper serde
, because withoutboats_serde::Serialize
is not the same trait as serde::Serialize
. Encouraging forks breaks up the ecosystem, which is a negative outcome we’re trying to avoid. That’s why all of our mechanisms for supporting forks and downstream patches are designed to avoid allowing you to upload your fork to crates.io.
So I’d be inclined to enable a more visible shared branding without all of the consequences of “optional namespaces.” As a minimal first step, one thing we could do is just make ownership more visible in the web interface, without any change to cargo. For example, if you have a github organization as an owner of a package, we could make the page different so that the GitHub org is very prominently displayed, we link to other packages owned by that org, etc.