
If it's not fun anymore, you get nothing from maintaining a popular package - jashkenas
https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36b8d83b3a
======
gwicks56
Personally I felt people on GitHub were being way too harsh. He built
something, moved on, and gave it away. He had no way of knowing the person who
took it over would use it maliciously.

Seriously, some of the comments blew my mind. Because he built it, he had a
responsibility to maintain it forever, and was responsible for everything that
happened with that code forever?

Maybe calling free software "Open Source" was a mistake. If something is
"free", then you have to accept you may get what you paid for. If you are
using somebody else's code, is it their responsibility to look after it years
after they have moved on, or your responsibility to make sure it's not full of
bugs or malicious code.

~~~
aikah
People are dealing with a lot of negativity in their life, they shouldn't have
to deal with that entitled bull-crap online, especially when doing unpaid
work. Should the maintainer have been more cautious? no, he should have
straight out closed the project and just ask people to fork it or use
something else. If you are not going to maintain something anymore, don't even
bother worrying about passing the torch. That way nothing is your
responsibility anymore. The people who complain, insult the maintainer in
Github issues right now will be at the root of a shift of mindset from
contributors that will end the "golden age of open source".

~~~
kylecordes
I think this is the clearest, easiest, correct answer. If you no longer have
the time and motivation to maintain a project, and are also not in a position
to hand over control to someone you have good reason to trust, the easy, safe
answer is to retire it, and have others fork.

Then in the original project you can say “the last version of this project is
N.N; here are some possible candidate successor forks, which have not been
vetted”.

This way no one who is merely keeping up with version numbers will
accidentally step off of a reasonably good package on to a fraudulent package.

~~~
wpietri
I 100% guarantee you that if he did that, he'd be getting a lot of static
about how he should have handed the package over to some contributor.

~~~
danso
Which other similar situations are you thinking of?

~~~
Rotten194
left-pad

~~~
mifreewil
left-pad was a very different situation. The maintainer unpublished the module
from npm. I forget the reason, but I want to say it was some sort of rage
quit.

~~~
beaconstudios
he had a package called kik, which npm dropped for the benefit of kik the
company (though I don't know whether they requested they do so). In response
the author unpublished everything from npm.

------
bit_logic
The community discussion is focused on the wrong thing. Here is the problem:

[https://github.com/dominictarr/event-
stream](https://github.com/dominictarr/event-stream)

Look at that URL. It has "dominictarr" in it. Now click on the URL. Look at
the big "dominictarr/event-stream" in the upper left of the screen.

Many are going to conclude that this package belongs to dominictarr. Almost
everything in the UI indicates this.

Developers don't trust code, they trust people and organizations. NPM and
Github needs to make it very clear when ownership has changed. And needs
defaults that properly inform all users when ownership has changed. For
example, when I SSH into a server the first time, it asks if I trust the key.
Then one day, what if it asks again? Then I can stop and investigate why the
key has changed, what's going on, and if I should trust it again.

With the current NPM/Github there's no warning to users. A developer could've
checked dominictarr's background and decide they are trustworthy, which would
then extend to event-stream as well. But where's the warning to users when
ownership of event-stream has changed and they need to re-evaluate whether to
trust the new owner? And why does it look like the project still belongs to
dominictarr when it actually doesn't? Those are the key issues here.

~~~
trickstra
> Developers don't trust code, they trust people

well the code doesn't write itself, so partially true. But ultimately it's
about accountability. If Dominic himself added the backdoor, his presence in
the community would end that day. If an anonymous alias does that, we don't
even know who to blame. Dominic's fault is not the backdoor, but the
irresponsibility of handing over a used package to an anonymous alias. Not
being clear about the fact that the package is abandoned. I wouldn't depend on
an abandoned package, if I knew that.

~~~
QuantumGood
> Not being clear about the fact that the package is abandoned

This is really the key point here.

------
codezero
I feel bad for the guy, he's not wrong, that's for sure, but a recent example
of "doing this right" is here:
[https://news.ycombinator.com/item?id=18525025](https://news.ycombinator.com/item?id=18525025)
/ [https://github.com/FineUploader/fine-
uploader/issues/2073](https://github.com/FineUploader/fine-
uploader/issues/2073) (FineUploader is shutting down)

At least, it seems that way to me. If I were ever in a burdensome positioning
of maintaining a package I didn't want to maintain, I'd go for the explicit
archive/sunset route. At that point if someone wants to fork and re-package,
they can do it, but it won't mess with anything directly downstream
immediately.

------
danso
I agree that the author has every right to quit being a maintainer, for any
reason, but I don't believe that he is necessarily absolved of all judgment
just because it was a free project he did on his own time.

He's obviously a prolific and generous author, but that experience also means
he's very aware about real-world practices (especially in the npm ecosystem)
to know that ceding control of a popular library, without taking any
precaution, has the potential to put a significant number of users at risk.
Should the users be less complacent? Sure, but that's not currently the world
we live in, and the author is not ignorant of that.

If an experienced electrician volunteers his time to a homeless shelter, and
decides to quit halfway through a rewiring project, it's his right to quit
whenever. But the manner in which he leaves the project is also important.
There's a huge difference between:

\- Confronting the shelter manager and saying _" Hey, I can't do this anymore,
and you get a professional ASAP to fix my work because I can't guarantee that
I've properly grounded everything"_

\- Exchanging pleasant goodbyes with the shelter staff, and not giving them
any reason to worry about what you may or may not have done.

The latter situation is akin to a silent failure -- even stomping off the job
and telling the shelter to go fuck themselves is ultimately preferable, since
the shelter staff at least are very aware that your work may be dangerously
unfinished. While you may not be liable if anyone gets shocked/electrocuted
from your leftover work, that doesn't mean the shelter staff are obligated to
not grumble and warn anyone else who might be relying on you for volunteer
work.

edit: that said, I don't have a major objection to the author's response, as
submitted here. I was referring to people who think that any significant
criticism is unwarranted, just because the work is free. The author, to his
credit, made a decently detailed reply and continues to make thoughtful
responses.

~~~
mehrdadn
I think your example makes your point weaker rather than stronger, because
unlike the electrician, this guy has no reason to believe he's done a bad by
job himself, because he's not putting anyone's life in danger, and because
others who are using his work are also supposed to be similar professionals in
their technical fields and taking similar responsibility. Comparing it to
laymen who know potentially nothing about secure wiring getting potentially
electrocuted because of a malpracticing electrician is not a great comparison.

~~~
danso
> _and because others who are using his work are also supposed to be similar
> professionals_

I have a hard time believing that anyone who has built so many popular
packages on npm (or any open source) also believes that the hundreds of
thousands of users who install his work are "similar professionals" to him,
or, even if they were, that they have built safeguards against this kind of
scenario. I've barely used npm/node in the past few years and even I'm still
aware of how the ecosystem makes silent changes to dependencies non-trivial to
detect.

> _because he 's not putting anyone's life in danger_

Software has real-world implications.

~~~
mehrdadn
I'm trying to help you make a potentially good argument stronger, not trying
to shut it down. Disputing it and telling me I'm wrong (even if I am) and that
electrocuting people is like JS frameworks having "real-world implications" is
not going to help you with that.

~~~
danso
Thanks for the help, but I don't see the need in perfecting the analogy. My
argument is that volunteer work can be criticized, despite its altruistic
intentions. I have no interest in debating with you about how software impacts
lives. Apparently, this case has enough potential impact to be a much-
discussed controversy.

------
notacoward
So much for "many eyes make all bugs shallow" I guess. Problem is that 99% of
those eyes are turned only toward using the product of someone else's good
will for their own personal profit. And 99% of the remainder are only looking
for bugs in the features they use, or just aren't that good at spotting bugs.
This only gets worse in environments like NPM, which make it easy for
dependencies to proliferate beyond anyone's expectations, so people don't even
know what code they should be looking at.

This is still better than the situation with proprietary software, but
problems like these are kind of inevitable in an ecosystem where people
typically write 5% of the code themselves and blindly pull in the other 95%
from who knows where via unchecked package dependencies.

~~~
wtracy
Those "many eyes" are the reason this was caught at all. I could easily
imagine situations where this backdoor would go unnoticed for months or years.

~~~
notacoward
Some tiny subset of those many eyes might have found it, but by then its
impact was far from shallow. In some open-source ecosystems (e.g. GNU or BSD)
the ratio of useful eyeballs to vulnerable ones is much higher. It almost
seems to be a goal of NPM to maximize the blast radius before a problem is
noticed. That's not a healthy way to manage open-source projects.

------
pmoriarty
I've written a lot of software in my life -- almost all of it for myself, and
I just never bothered to open source most of it, because if I'm going to open
source it I want to make a good impression, so I want to clean up the code and
write some docs and make sure it it builds ok for others, think of a name for
it, upload it somewhere, etc. It's just so much easier to keep it for myself
and not bother with any of that.

Despite all this, I have open sourced a couple of things here and there.
Little things. Things that virtually no one ever used, as far as I know. But
once I did get a very polite feature request from someone on something that
I'd moved on from, so I told them I wouldn't do it.

That was more than a decade ago, and I still think about it and feel kind of
guilty for not doing it.. even though I know I have nothing to feel guilty
about.

I can imagine being the author or maintainer of a popular package must be like
this times a thousand. You have to put up with so much negativity and pressure
from people who demand you do work for them for free.

I feel for these people. Anyone who spends even the smallest fraction of their
life to give a gift to the world does not deserve anything but praise from
those who benefit from it.

~~~
type0
> Despite all this, I have open sourced a couple of things here and there.
> Little things. Things that virtually no one ever used, as far as I know.

You wouldn't know, when learning every help and every practical example can be
useful. I understand that not everyone likes to learn by reading someones code
but it can be invaluable especially for students in places where books are
prohibitively expensive compared to the living standards. You're doing good
deed, even if it's just small things, but make sure to document it properly.

------
madrox
Anyone blaming Dominic for not being more responsible should blame themselves
for the same reason. This isn't the first time Node has had horrible
dependency issues. Have we forgotten left pad?
[https://news.ycombinator.com/item?id=11340510](https://news.ycombinator.com/item?id=11340510)

Ultimately, you can't take dependencies for granted.

~~~
bendmorris
>Ultimately, you can't take dependencies for granted.

The problem is that JS dependencies are _so_ modular that shifting the burden
to vet your dependencies to developers is generally not realistic. Creating a
new project with one of the current popular frameowrks will bring in hundreds
or thousands of dependencies. Who can possibly vet that?

To compound things, this package could be a transient dependency of a
transient dependency, so I may not even know the person who decided to depend
on it in the first place, or the reason why, or what the package does.

It's not that people are taking dependencies for granted - it's that there is
no reasonable alternative.

~~~
starbeast
Dependencies should be nailed to versions and upgraded conservatively. The
default shouldn't be the latest and greatest, it should be the last thing that
worked.

~~~
PeterisP
This also has security implications as in this approach you don't get the
fixes to known vulnerabilities. If you update to 1.2.4 as soon as its out, you
_may_ be vulnerable to a takeover like this (which happen but are rare), but
if you're still running 1.2.3 when 1.2.4 is out, you're _definitely_
vulnerable to all the things that 1.2.4 fixed, and these risks are far more
common.

If semantic versioning always behaved as it should be, the default shouldn't
be the last thing that worked but rather the major/minor version of the last
thing that worked followed by the latest and greatest patch version.

~~~
bendmorris
>If semantic versioning always behaved as it should be

The exploit in question specifically relied on this expectation, by creating a
new patch release for the exploit. Even if you could trust well-intentioned
maintainers to use it correctly, there's always this risk.

------
kylecordes
I have observed an ongoing pattern. People who create a thing (that becomes
somewhat popular) in some sense get credit for it. They are mentioned as the
creator of it, forever. It becomes part of their resume, their online
reputation. Perhaps they go on to create another thing.

This happens to a far lesser extent for people who adopt a project later to
become an ongoing maintainer.

A project might have an originator who works hard for six months, and rewarded
forever, and some maintainers who work hard for six years and gets very little
reward.

Out of respect for many people who do great work, I will not name names. :-)

------
davej
Personal attacks are completely unwarranted. I think a more useful (and
certainly more constructive) way to look at this is to frame it as a learning
experience and figure out what we can do to minimize the effect of this in
future.

It's almost impossible to vet every sub-sub dependency of a large codebase
without dedicating huge resources. Perhaps there needs to some sort of a
javascript code signing standard that requires a level of user identity
verification. This is a solved problem with Authenticode and Gatekeeper for
executables on Windows/Mac. We have been able to hide behind the fact that
we're devs (we know what we're doing!!), but many consumer-level applications
(mainly Electron-based) now run node modules with user-level (or higher)
permissions. Maybe we need to become a bit more diligent in this area and look
at less ad-hoc ways of managing dependencies and identity verification.

------
jeswin
Dominic is a prolific contributor and compassionate leader in the JS and P2P
communities - and it was a disheartening thread to read. The suggestions that
he (working for free!) should have done more seemed unfair.

We should look to fix these:

\- If we're going to rely on hundreds of packages per project, we need fine
grained security like Android or iOS. deno seems to be doing node right -
[https://github.com/denoland/deno/issues/171](https://github.com/denoland/deno/issues/171)

\- Lock down versions for now. Use 1.2.1 instead of ~1.2.1 or ^1.2.1.

\- If npm must remain at the center of node's module system, they might have
to add auditing and approval tools. 'npm install' can warn about unaudited
modules. The problem with that is that it will make npm (a business) even more
central to the node ecosystem - which may not be a good thing.

------
raphlinus
I think this is a major loss of innocence moment for open source. The only
sustainable solution to this sort of problem is to pay people to do at least
minimal curation and maintenance of open source libraries.

In an ideal world, the payment would go to people who actually create open
source value. However, I'm cynical enough about human nature and business to
suspect that it will mostly go to middlemen like record distributors and
academic publishers, who create very little actual value but somehow make
themselves indispensable in the ecosystem.

------
_nalply
I found this comment insightful:
[https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36...](https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36b8d83b3a#gistcomment-2769564)

Summary:

1\. Mark as deprecated

2\. Change the name by adding "-archived"

3\. Turn off Github issues

4\. Give away ownership if there is at least a mini-community

~~~
ship_it
but noo, uh .. my fame!!! :'( cries in npm

------
preommr
Is there even a generalized guideline on how to handover npm packages?

It would seem like common sense to let something die and let any new
interested maintainers fork the project thank to just wantonly hand it over to
a complete stranger. But I could easily see someone getting into the habit of
trusting people and not thinking about it too much.

Maybe a combination of better guidelines, some kind of code of ethics along
with better means of communicating these changes through npm would've helped
this issue a lot more. If not to actually prevent the problem then to at least
have some ground to hold people accountable other than accusations of people
should know better.

~~~
runarberg
Perhaps you should suggest these guidelines:

[https://npm.community/](https://npm.community/)

------
flocial
I don't know what it is about the current environment but it pains me to see
people get the life sucked out of them for sharing code and making the world a
better place. It's also equally disheartening to see prominent open source
contributors essentially close their social media because they're constantly
hounded by entitled "community" members and trolls.

------
Domenic_S
> _There are too many NPM packages, and worse, too many people quick to add as
> many dependencies as possible, resulting in crazy dependency trees that you
> should never actually see in the wild. Additionally, it seems to only be in
> the node ecosystem that you see single authors with hundreds of packages.
> Why they do this, I do not know..._

Because javascript has a weak standard library.

~~~
PhilWright
Maybe the most popular small libraries should be merged together into a single
library that can be used to reduce the number of dependencies, in the hope it
can become a standard. Like a jQuery for npm.

~~~
kangax
I think that was the motivation of
[https://js.foundation](https://js.foundation)

------
brians
And this is why professionals didn’t depend on build-time fetch of
dependencies.

------
gumby
Always makes me think of Brian Fox's canned response to people who flamed him
about bash: "Please return your copy of bash for a full refund."

------
nkkollaw
I read this: [https://github.com/dominictarr/event-
stream/issues/116#issue...](https://github.com/dominictarr/event-
stream/issues/116#issuecomment-440927400), which might seem controversial, but
what was he supposed to do?

I guess just let it rot and tell people to fork.

------
ptx
"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](https://felixge.de/2013/03/11/the-pull-request-hack.html) open
source is driven by sharing! It's great!"

Yes, but, quoting from his post he cites:

"So should you really do this for all pull requests? Probably not. While I've
given a large amount of users access to various projects of mine, I'm still
looking for:

"Github profile: Does this user stand to lose a reputation by doing something
stupid?

"Skill: Based on the patch, do I think the user could be a good developer?

"Usefulness: Is this patch solving a valid problem?"

------
carapace
So NPM users et. al. are a hoard of unwashed children. This is like Lord of
the Flies.

------
udithishara
> If I had realized they had a malicious intent I wouldn't have

Welcome to the Internet

There are people buying chrome extensions, so they could inject something else
this guy is surprised when someone did it to his project, which he handed over
for free

------
jahaja
However you frame it, a very widely used package management system based
essentially on trust and a community that doesn't expect any amount of
responsibility with regards to those packages seems like a bad combination.

------
mmgutz
I dont get why the original author is getting so much flack. This is a problem
with semver and npm. I hope versions are immutable on npm.

~~~
aequitas
You could argue he could have done a better job in communicating he and his
reputation is no longer what is behind this project. But that it has moved to
someone else.

------
classichasclass
I have a rule I don't maintain software I don't personally use. It's kept me
from picking up projects other people ask me to do for them, and it's been a
good dividing line when it's time to hang it up. I think his major mistake
wasn't advertising he'd moved on, and I feel badly for the heat he's taking.

------
drwl
This references
[https://news.ycombinator.com/item?id=18534392](https://news.ycombinator.com/item?id=18534392)

It looks like it's title has been changed from when I first read it.

~~~
jashkenas
Yep. I submitted it with "Dominic Tarr’s Statement on the hacker hijacking of
the event-stream NPM module", which was as descriptive of a title as I could
think of quickly.

It looks like the moderators have dinged the submission and changed it to: "If
it's not fun anymore, you get nothing from maintaining a popular package" ...
which I think we can all agree is generic, and fails to make the connection to
the big news of the day.

It may just be whispering into the wind, but if the mods are listening — how
about "Dominic Tarr: statement on event-stream compromise", which uses the
Gist's description, and helps folks know what this link is all about?

------
bytematic
That was incredibly well written and I believe him truly. I had not considered
that the amount of these tiny packages was probably people trying to learn.

------
peteradio
Why wasn't NPM monitoring for this kind of behavior? I guess it wouldn't catch
all bad behaviors but this is just asking for it.

------
devxpy
What happened to tidelift? [https://tidelift.com/](https://tidelift.com/)

------
randomsearch
This is a little orthogonal, but I'd really appreciate thoughts on this:

Is FOSS a good idea?

I've always assumed yes. Think of all the libraries in the Python ecosystem,
for example. I've used them to build tons of things, even a couple of things
that made a little money and allowed me to get myself a new laptop. I've
written open source projects myself, filed issues and helped fix bugs in
others. The code I've written represents a lot of time, and I'm happy to give
it away.

Think about Linux, and what it has done for the world. I've used it for non-
commercial purposes all over the place, and it's made research and teaching
I've been involved in much easier; it may have been impossible to achieve many
things without it.

But recently I've begun to question the idea of FOSS, sparked by Jaron
Lanier's concerns. There's something clean about paying someone for their
software: you have an entity responsible for the code, you can pay for
support, you have recourse if you need it. There are clear incentives and
rewards, and money earned is properly redistributed. I know that companies
like Google do a lot for FOSS, but it's probable that their contributions are
minuscule compared to the monetary value they have extracted from it.

The alternative is not closed-source: e.g. with web dev you can provide the
source code but charge for licensing, etc. So it's more about "free" vs "non-
free" than "open" vs "closed".

The idea of people coding for free is quite an odd one. Imagine if the world's
graphic designers en masse started providing millions of free designs covering
every possible icon and situation? (I'm aware of small examples, but they're
not at the scale of OSS). Designers don't do it. You would make a lot of
people redundant overnight - not all designers, but a lot of them.

What do people think? I can't see how we could have this amazing ecosystem
without FOSS... but maybe some kind of transactional funding model is needed
to make it sustainable, more secure, etc.

My instincts were for FOSS, but there's often a difference between what sounds
beautiful conceptually and the problems of how it works in practice.

RMS' ideas were very attractive, but then you see the modern world from a
musician's point of view and it sucks - the long-term effects of ignoring
copyright have been to diminish income for musicians. Whilst I improve my
friend's quality of life by giving them a copy of some music, their kids might
grow up in a world with less good music as a result. I know the record
industry sucked, but free copying is not the only alternative.

I'd really appreciate input here, as I have failed to resolved this either
way. Thoughts?

------
ngcc_hk
A free gift like fire to mankind can be both great if useful and bad if
misused. Just nature. And the being helped it forever have an eagle chasing
his liver ... or he has to do the stone.

------
purplezooey
Makes you wonder if we are at Peak Open Source

~~~
ralph84
The largest pure-play open source company and the largest open source host
both being acquired within the last 6 months is a strong indication.

------
magma17
the quid is if the maintainer is a douchbag or not

------
matte_black
So much good software out there is forever hidden from the world because the
creators are afraid to be seen failing publicly, because of shit like this.

To the brave souls who release open source packages, here’s to you.

