[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.

[mcguire]

jquery, jquery-forked, new-jquery, forked-jquery, my-jquery, this-is-the-real-jquery, potato-headed-rat-bastard-jquery, ...

[Klathmon]

npm has scoped packages, so you could make @mcguire/jQuery and I could make @klathmon/jQuery

[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.

[danShumway]

The problem is that if I mark my original right_pad as deprecated and then point to yours, we're in the exact same situation -- people who blindly follow the instructions on my repo will still download your compromised version and have their credit cards stolen.

If I mark my package as deprecated and I don't point to yours, then malicious actors flood with copycat namespaces, and you have @klathmon/right_pad, @danshumway/right_pad, @linus/right_pad, and even the occasional phished @k1athmon/right_pad. Would that extra confusion be enough to trigger an audit for a company that wasn't planning to audit the original dependency anyway? Would an overworked engineer have the presence of mind to double check that their version has the right prefix?

There are, I'm sure, people who think it's OK to upgrade a package without worrying about the security implications, but not OK to switch to another package when the original is marked as deprecated. But I don't know that those people are in the majority. Certainly, anyone who's not already using a lock file and freezing their dependencies is probably not gonna think too hard about this.

(Somewhat to my shame) I can think of several instances where I personally have found a repo marked as deprecated on Github, went to the repo that it pointed me at, and started using it without even checking to see who the new author was.

Maybe I'm atypical with that behavior?

[perpetualcrayon]

I don't think anyone would expect different behavior out of end users. But the "instant gratification" a malicious actor is seeking by asking to "maintain a package" will be delayed substantially. In fact, if you are straight up with folks telling them that you don't personally know who is now maintaining the fork, folks who do decide to trust them will know to proceed with caution and will probably watch the PRs on the repo for a period of time. So, technically not only are we delaying instant gratification of being given access to probably millions of "hits", we're forcing the malicious actor to actually maintain the package and gain the trust of the community independently before they can wreak havoc.

Then over time if it's an important enough package there will probably be discussions or blog posts about the new maintainer and what a "fantastic" or "terrible" job they're now doing.

[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.