Define a policy for transferring crates ownership in the case if existing owners can not be reached.
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).
- 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.
- Advertise cargo bus initiative and rely on it.
- Promote namespaces and active crate forking.
- More extensive and less conservative squatting policy.
- Do nothing and rely on “funny” names à la
- 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)