Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I've since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I've written way better modules than this, the internet just hasn't fully caught up.
@broros
otherwise why would he hand over a popular package to a stranger?
If it's not fun anymore, you get literally nothing from maintaining a popular package.
One time, I was working as a dishwasher in a resturant, and I made the mistake of being too competent, and I got promoted to cook. This was only a 50 cents an hour pay rise, but massively more responsibility. It didn't really feel worth it. Writing a popular module like this is like that times a million, and the pay rise is zero.
I've shared publish rights with other people before. Of course, If I had realized they had a malicious intent I wouldn't have, but at the time it looked like someone who was actually trying to help me. Since the early days of node/npm, sharing commit access/publish rights, with other contributors was a widespread community practice. https://felixge.de/2013/03/11/the-pull-request-hack.html open source is driven by sharing! It's great! it worked really well before bitcoin got popular.
So right now, we are in a weird valley where you have a bunch of dependencies that are "maintained" by someone who's lost interest, or is even starting to burnout, and that they no longer use themselves. You can easily share the code, but no one wants to share the responsibility for maintaining that code. Like a module is like a piece of digital property, a right that can be transferred, but you don't get any benefit owning it, like being able to sell or rent it, however you still retain the responsibility.
I see two strong solutions to this problem...
- Pay the maintainers!! Only depend on modules that you know are definitely maintained!
- When you depend on something, you should take part in maintaining it.
Personally, I prefer the second, but the first probably has it's place. These arn't really mutually exclusive, anyway.
As to this particular issue, I have emailed npm support and suggested that they give the module to @FallingSnow and ar @XhmikosR
I see some people calling for an apology. I don't think that's in order. I have my own not positive feelings about what @dominictarr did, but I'd prefer we just learn from this rather than pointing fingers at someone who contributed when he didn't have to. Most developers never take that step so I'd prefer not to pile on one who did.
Speaking as someone who has created, maintained and, for all intents and purposes, abandoned F/OSS projects, it's a tough situation to be in. Hopefully every maintainer of every project does feel a sense of responsibility to the community they build, but on the other hand, we can't expect people to not walk away for various reasons (including, as some have pointed out: death). It's simply the nature of the game. But knowing that, you've got to do it responsibly (when possible).
Now, is that responsibility entirely on the single person maintaining the project? Effectively yes, but it probably shouldn't be - it should also be on the community I think. After all, many people seem to think a maintainer has a responsibility to the community (which I agree with), but doesn't the community also have some responsibility to the maintainer? Isn't that kind of one of the basic principles of OSS? I think so.
Given that, my suggestion would be the kind of model that Meetup.com uses for abandoned groups, with some additions/mods.
First, a maintainer clicks a button somewhere that says "I intend to abandon this project". At that point, a clock starts ticking. By the time it goes off, say maybe 90 days in the future, one of two things happens. The first possibility is someone steps up and says "I would like to take stewardship" (and the maintainer can nominate people if they already have someone lined up too). If more than one, that's fine too. At that point, verified members of the community begin to vote (one vote per account naturally, and the vote can be changed up until the clock stops). Whoever has the most at the end is the new maintainer. Simple as that! The expectation is that, in basic open-source fashion, more eyeballs will yield better results. Voters would be expected to do some vetting, in whatever way makes sense. They can comment and discuss, and those up for a vote can, of course, comment back, try and sell themselves in essence.
In short: it becomes an election process that the entire community of the project participates in.
The other possibility is nobody steps up (or, I suppose, nobody gets any votes). In that case, the answer is simple: the project is frozen at the point that "I'm outta here" button is clicked (and that would happen either way in fact, but just temporarily if someone is ultimately elected). It's still available for use, but no more commits, no more bug reports, no nothing. It is then marked abandoned, deprecated, whatever status makes sense (maybe a new one even) and that's that. You make sure it's abundantly obvious on the screen that this project is no longer maintained, big red flashing banner, whatever.
If someone comes along later and wants to take over, they go through the voting process as described but they then have to fork the project with a new name. Some links can be added from the original project to indicate "hey, switch to this if you want the maintained version", but the old continues to exist in its final state, no longer able to hurt anyone (aside from bit rot).
I would suggest that anyone interested in the project must sign up for a mailing list and those people will be automatically contacted when a maintainer says they intend to abandon a project. I suppose it could go out to a wider audience, all registered NPM users or something like that, but I'd think something more akin to a "hey, I'm interested in/use this project, lemme know if anything happens with it" kind of self-limiting list would be more appropriate.
As a corollary, I would also suggest, essentially, a "dead man's switch" applied to all packages that leads to the same election process. If the maintainer doesn't perform some action for, say, six months, then the process automatically kicks off. Well, first they get an automated "hey, you still good?" message, with maybe a week or two to reply to halt the process from beginning. If not, THEN it's election time!
I think, in my mind, something like this would be the best of all possibilities. Projects can still be abandoned, but now it's a much more transparent and planned for event, even in the case of unavoidable sudden departures. I'm sure it's not a perfect system, but to me, I think it makes a lot of sense to at least explore such a thing. It probably makes the most sense to be built right into the NPM infrastructure, but it really might not have to be (aside from the whole freezing the project aspect) because I can envision someone building this as a third-party service that ANY F/OSS project anywhere could then hook into. I wish I had the time to put into building it myself, but I don't. I'll regret it I make someone else a millionaire of course :) But, I'd rather put the suggestion out there and let it either die on the vine or let someone run with it for the benefit of all.