Hi,
I'm currently writing a large e-book and document reader powered by Rust. One of the file formats it supports is Microsoft's compressed HTML help files, chm. there's a crate that binds chmlib, but it hasn't been updated in over 6 years, doesn't build on the latest Rust, and the author hasn't responded to an issue I opened about it. I have fully working chmlib bindings for my project, and would like to publish them to crates.io. However, the name chm is taken by a CLI tool, and chmlib is taken by this stale, unmaintained project. I could go for chm-lib but that feels kind of ugly to me, and almost like I'm trying to typo-squat. Is there a more standardized way of handling stale crates like this? Could we maybe implement a policy that allows users to submit a request to reclaim a crate name after the repo has been stale for 5+ years?
Thanks!
Note that crates.io does have a policy for crate ownership transfers (my emphasis):
If you want to take over a package, we recommend you try and contact the current owner directly. If the current owner agrees, they can add you as an owner of the crate, and you can then remove them, if necessary. For security reasons, the crates.io team will not transfer ownership of existing crates without the explicit approval of the current owner.
The crates.io team used to offer assistance with ownership transfer:
If the current owner is not reachable or has not published any contact information the crates.io team may reach out to help mediate the process of the ownership transfer.
But the statement got removed from the policy. While RFC 3463 kept a PEP 541-like solution open to a new RFC, RFC 3646 (the one for removing the transfer mediation statement from above), does not sound like the crates.io team would be willing to implement such a policy and mediate transfers again.
chmlib2?
Not a bad idea, I also have now emailed the author instead of going through just a GitHub issue upon reading the other replies in this thread.
I would worry that a crate that appears abandoned is actually used my somebody who will be mighty annoyed when it disappears or gets replace by something that does not work quite the same.
Why not call it "quin-chimlib" or some such.
Nods, this is a fair point and one that I hadn't considered until I was giving this topic some consideration over breakfast earlier. IMO the ideal solution would be for packages on crates.io to be namespaced behind the author's name, similar to how NPM does it, but it's definitely too late for something like that now 
There's also the case that a crate might not be abandoned - it may just be small enough that it is actually done.
I agree. I remember a discussion with the maintainers where such an idea was planned; I'm not sure why it hasn't moved forward.
Do you think it's too later? I believe it's possible to keep the legacy and continue with that system, but there might be other problems to solve; for example, what do you do if the original author wants to transfer the ownership to someone else? Changing the "domain name" of a crate would break all the other crates depending on it. Maybe a field forwarding to a new domain name could solve that, even if it slowed down the whole system a little (it probably doesn't occur too often to be a real concern).
Without a solution like that, though, there will be more and more collision problems with time. Names will start getting numbers, and we'll wonder whether that crate's a new evolution from the same crate or something entirely different from another user. Or artificially elongated names.
There's RFC 3243: Packages as (optional) namespaces (tracking issue).
It's a lot of work and unfortunately hasn't progressed much yet.