Define a policy for transferring crates ownership in the case if existing owners can not be reached.
Motivation
Most of the published crates have bus factor of 1, including crates with “generic” names, which users often will try first. Even today we can see examples of crate owner effective disappearance, which results in an unmaintained crate, deadlocked to the inactive owner. It leads to pollution of crates.io and negatively influences perceived quality of the crates ecosystem. It can be projected that his problem will only become worse in future.
Additionally it’s worth to mention several examples of generic name squatting. While it could have been done with a good intent, it’s not guaranteed that they will be available later (e.g. mahkoh didn’t answer to my emails).
The Policy
If someone wants already registered name for their project and current owner(s) can not be contacted, they can write a request in which they are encouraged to show code which is best published under the requested name. The code could be a fork of the crate published under the desired name.
Request can be written for crates which were not updated in 12 months.
All requests and their current status are made public. (perhaps in a special github repository?) All community members are free to comment and leave their opinions regarding them.
crates.io team (or designated sub-team) will review such requests and will try to contact owner(s) of the crate, at least 3 times over 3 months.
If one of the owners explicitly says “no” to the transfer, request will be automatically denied, even if the crate does not have any code (i.e. name was squatted). No new “expropriation” requests can be filled for the crate in question for another 6 months.
If the team is unable to establish contact with the owner in 3 months, crate will be transferred to requestee if he/she is still interested in it.
If there is several competing requests for the name, the team will make judgement based on the quality of the presented code, its fitness for the name and general community reaction.
The team has right to deny request at any time.
Crates with malicious code can be expropriated without notice, crate ownership will be revoked and affected crate versions will be yanked.
More extensive and less conservative squatting policy.
Do nothing and rely on “funny” names à la reqwest.
Unresolved questions
Timeframes tuning.
Do we need security measures against yanking versions or publishing patch updates? It can be used to patch bugs and security vulnerabilities, but also it can be abused as well. (e.g. by publishing malicious code under a new patch version and rely on auto-updates)
Completely independent of this, it’s probably a good idea to include in the “good practices” document for more than one contributor to have publish access, as a safeguard against single points of failure, if it’s not there already.
I think transfering of ownership can be made safer by setting a minimum version that the new owner can publish to semver_major+1 of the existing version. This way code by the new owner (typically) won’t be automatically picked up by existing users.
So if there was an abandoned crate with max version 1.2.3, the new owner can publish 2.0.0, or 99.999.99, but not 1.2.4. Or if max version was 0.1.0, the next allowed is 0.2.0
(Although transfer of ownership may happen because the crate needs an urgent fix, so that may be an option decided on case by case basis?)
Would it make sense to have some (token) notability requirement of the person claiming the name? e.g. have published a crate with at least 1000 downloads, 200 of which are “recent” (just to make something up)? The point being not to lock out real users with low impact crates, but to put a token barrier against people going through the process to “take over” a name without at least a small history of having contributed to the crates ecosystem.
EDIT: perhaps it could scale with the notability of the crate you’re claiming. That way it’s easy for anyone to claim a squatted name but someone claiming a used crate needs to have shown ability to author a useful crate.
Though it should be mentioned that this is just a popularity metric.
As a member of the crates.io team I will admit that I am not personally interested in reviewing any community members code as it applies to it being published on the crates.io registry. I would want a solution here to not include needing to review end user code. The reason I do not want to review end user code is because the quality standards are both undefined, and I, personally think, undefinable.
As it pertains to the rest of your proposal, I think your proposal would be stronger with this code review portion eliminated.
I think that a process like this would reduce the openness of the platform and reinforce a bubble type structure that I personally do not believe will lead us to a “better” crates.io. I’d prefer a system that doesn’t privilege previously existing crate authors.
I think it would be very difficult to “police” this type of policy (as you demonstrate and explain yourself) and as a result would require an immense amount of overhead from the very small crates.io team.
Building out tools to do that will take a lot of time and then incur ongoing maintenance in the future. I worked for npm for 3 years, and even an ecosystem as mature and robust as that doesn’t have many internal tools for handling this. Package transfers are done by their paid team of support staff that manually processes the requests. We don’t have the luxury of paid staff currently. The primary goal of the team right now is to grow the team and address the currently extremely urgent issues we have.
There is a future where this is possible, though I think it is a long way off. I have encouraged folks to join the team but you may be surprised to here that I (and the team) have received literally zero inquiries re joining or observing team meetings. I hope that will change, but until it does I do not personally think that expanding the number of services we currently maintain is a good idea.
Who decides which volunteers should take on this role? What happens when segments of the community disagree with the volunteers' decisions? What happens when we don't have enough volunteers to keep up with the workload?
It is what I had in mind as well, but I am on the fence here. I guess we could start without this precaution (especially considering that it will require implementing such restriction functionality) and add it later if there will be a need for it. Though I think that automatic expropriation of crates with malicious code could remedy this problem to some extent.
There is no quality requirements for the project, only existence of it (with a reasonable amount of code) will be enough, no need for in-depth review. It's mostly just a recommendation: "if you want the name, you should have a relevant project", which could filter out some of the requests from people who would like to squat an existing name "for future use".
That is a quality requirement. What does "reasonable" mean here? I'm not interested in defining that for several reasons:
it's easy to game
it could easily spill to the rest of the ecosystem, i like the fact that people who are learning can publish silly busted crates that don't even work. the openness of the platform is part of it's special power. i specifically do not want a quality requirement on crates.io beyond explicitly forbidding malicious code.
i do not want to enforce these guidelines and i do not want to ask a team to do that as it's gonna be a huge amount of work (with lots of risks, and in my opinion, very little reward.)
I guess then this part can be replaced by the following clause “the review team has right to deny request at any time before transfer” to create an escape hatch if community reaction will be overly negative for some reason.
Gonna try this again here: if you are passionate about these topics, please consider joining the crates.io team as an observer (the first step towards formally joining the team). We have a meeting today at 4pm ET in the #ops/crates-io discord channel.
NOTE: We have a lot more to cover than just namespacing, so please do not be surprised if the vast majority of the time is spent talking about other more pressing issues. Joining the team meeting will be a good way to see exactly how small the team is and how many things we need to work on. We would love help and look forward to you joining us!
These are good questions. I'm not sure I have right answers off top of my head, but I think these are possible to work out.
cratesio team
I'm assuming we'll have some sort of RFC process to bikeshed the guidelines. Then, if volunteer didn't follow guidelines, the cratesio team could intervene/override the decision. If the guidelines were followed but resulted in a bad decision, then we'd probably have an RFC to amend the guidelines.
The queue becomes longer. The proposed process is already stretched in time, so extra delay seems acceptable.
Regarding squatting, I'd be OK if "don't squat" rule was put in place now, even if there's zero capacity to handle it right now, and the resolution would be delayed by years. That's because a) eventual resolution is better than no recourse at all, b) the rule adds long-term risk for squatters, which changes incentives.
This is a lot of work. Do you think this problem is so critical at the moment that the crates-io team should prioritize it above other tasks, including but not limited to, formalizing the team and participation policies, deciding on a Terms of Service, replacing inactive and old web libraries and other dependency rot in the code base, growing the operational team and infrastructure?
Or is this something that we can add to the queue and address when the team has more bandwidth? Overall I agree on some of the approach, I struggle with the sense of urgency around it.
BTW, thank you for taking time to respond to this.
It’s probably not the most important/urgent thing to address. A response along lines of “it’s a problem, we just don’t have time to deal with it now” is much better than “we will not revise our policy even if egregious spam happens” followed by “I told you so”.