[perpetualcrayon]

I say force the new maintainer to fork and then leave a note in your README that the currently maintained version is (here).

This way anyone who decides to trust the new maintainer will be able to act as a "canary in the coal mine", notifying others if they run into issues. This also delays the gratification to the new maintainer. If they're truly malicious they'll need to spend maybe months / years maintaining the code / fixing bugs until they'll be able to hit pay dirt. I think most malicious devs will not want to pay this price.

EDIT: This would also act as a window for (a) folks to find other alternatives for their projects, and (b) inspire folks to build alternative options.

I think the willingness to fork over access to widely used packages isn't just a reflection on your desire to move on from the project, but it also reflects your blatant disregard of the thousands, maybe millions, of people who depend on what you've built.

[ATsch]

The problem here is that often, there's not just the github repo, but also the non-namespaced language package manager, e.g. npm, pypi. You'd have to transfer that at some point. I'm also unsure how you can notify your users... I have not looked at the readme of some dependencies for years.

[perpetualcrayon]

I'd say force a fork there too. It's not difficult to switch to a new package once you find it and know the URL. I say force each user (whether it's end user or library maintainer) to switch manually to the new maintainer's fork of your project.

"I have not looked at the readme...". Maybe this will create a market for a new type of project. The one that lets folks know the status of the packages they use in their project.

[Klathmon]

As others have said, npm has ways of marking a package version as deprecated and npm also has scoped packages.

So if you wanted to stop maintaining your very own `right_pad`, you could mark it as deprecated so devs installing it get a warning in the CLI, and I could then publish my own `@klathmon/right_pad` and if you want you could endorse it in your readme if you wanted.

[albedoa]

> You'd have to transfer that at some point.

Why do you say that? The point is that you do not transfer it.

[madeofpalk]

> I'm also unsure how you can notify your users

There's properties you can set in the package.json to indicate that a package is deprecated and/or has moved.