Learning about this incident and its consequences, as well as the problems it highlights, really got me thinking about NPM, OSS and how I take certain things for granted.
So I thought I’d add my own worthless 2 cents to the discussion, and give my opinion on some of the issues raised.
Firstly, let me just congratulate some quick-thinking bloggers and thinkers who, in these difficult circumstances, under pressure, found a way to attach the suffix ‘-gate’ to this controversy. Well done guys.
If you don’t know what I’m talking about, a guy called Azer rage-quit NPM, because a company called kik seized the package name ‘kik‘, which he was using. The removal of one of his packages caused a million dependent packages to not be able to install, sending NPM Inc. into a panic.
Let’s start with some thoughts on the human aspect
Azer’s language in his correspondence, as well as rage-quitting in response to NPM’s actions, is quite childish
Personally, I would have recognized that kik (the company) has some legit claim to that name, and at least tried to negotiate some agreement with them.
Unless kik was your late grandmother’s nickname, and you’re very personally attached to it, there’s no reason why you wouldn’t be willing to part with it, for a reasonable compensation.
However, we mustn’t forget that this guy wrote and maintained these packages free of charge. That means that he doesn’t really owe anyone anything;
He could’ve decided to unpublish his stuff based on the fact that he disapproves of NPM’s CEO’s new hairstyle, and still be within his rights.
His motives here are of the least importance. He just serves as an example of the bigger issues within NPM.
Yes, kik have been, as Azer put it, dicks
You can’t say “We’re sorry for creating any impression that this was anything more than a polite request” when you’re repeatedly threatening with lawsuits.
Also, that open source package wasn’t in any way competing or pretending to be kik messenger. And in the end, they didn’t even take up the name! what dicks.
As a software company, which, I’m sure, uses quite a lot of FOSS, I would expect a little more respect to an open-source contributor.
Startup-timelines wrote about this in more detail.
Undoubtedly, the worst thing about this is NPM’s behaviour
I’m not talking about re-publishing (or un-unpublishing) the left-pad package; if the project’s license allowed for that (AND the new maintainer agreed)- then it’s perfectly reasonable to do so.
I’m talking about the fact that NPM is trying to be a repository, a home, for open source projects.
It makes its livelihood providing access to open source libraries, and thus is dependent on people like Azer. As such, it should have been much more careful in handling this situation.
Even if they’re technically right, according to their policies, they really can’t afford to antagonize the community.
And nothing would antagonize open source folk faster than surrendering unconditionally to corporate lawyers.
So what could they have done better?
- Follow their own goddamn guidelines, which state that they’ll intervene in cases such as this: ‘Alice works for Foo Inc, the makers of the critically acclaimed and widely-marketed foo JavaScript toolkit framework. They publish it to npm as foojs, but people are routinely confused when npm install foo is some different thing.‘
Well, kik messenger never even published their package, so how can you claim that people ‘are routinely confused’? - Give Azer some time to shut down his project gracefully instead of seizing it immediately
- Offer to change ownership of the package under a condition that Azer be compensated for his troubles
..or any number of other courses of action that would show a bit more empathy to the package author, instead of treating him like a criminal.
Now, it’s conceivable that NPM employees didn’t deem these actions necessary, as they did not anticipate the shitstorm that ensued. That’s understandable.
However, refusing to acknowledge that they did wrong even after the fact, in light of the flack they received, is a big red flag, and an indication that they are disconnected from the community they depend on.
Like many have stated before, the whole model of micro-modules and open-source software is based on trust. But it’s not only package users who need to trust package authors; Package authors need to trust NPM Inc.
They need to be able to trust this company to treat their code in a fair way, and they need to feel that NPM has their backs.
Handing over the rights to the package name without hesitation, and failing to address community concerns in the aftermath is not conducive to that.
Even if their actions are completely legal / in accordance with policies, trust doesn’t work that way.
Technical aspect
This whole story highlighted some glaring problems with the node / JS community:
Why on earth do we need a dependency in order to pad a string?
or to check if something is an array?
As Haney correctly points out in the blog post above, a function is not a module, and should not be treated as such.
I’m all for using utility modules (such as lodash, jQuery and such) where you need them, but a single function is not a module. Just copy it into your own damn code.
It seems that years of browser compatibility issues have turned javascript programmers a little paranoid; Here’s a personal example-
Recently, I did a little personal front-end project. Since I didn’t have a whole day to spend on just setting up a build chain for a ‘proper’ JS framework, I thought to try vanilla javascript instead.
Now, I’ve done around 2 years of development in AngularJS, and in jQuery before that.
I hadn’t interacted with the DOM using native JS in I don’t know how long.
I had a notion that the APIs were messy, not well supported, that anything beyond the ‘$‘ function was ‘here be dragons’ territory.
Well, it turned out that it was (almost) just as easy for me to do what I wanted to do in the DOM using plain ol’ js as it was with any of these frameworks.
And it worked on all browsers (* IE is not a browser. If you need to support it, it’s perfectly easy to find polyfills for it).
Previously, using “A Framework” whenever I needed something done in the browser was a no-brainer. Now, I’d actually need to justify doing that.
How the hell can you allow someone else to re-publish an abandoned package?
If there had been a quick-to-react malware author who would have picked up one of these abandoned packages, they could have published a virus as version 1.0.0 of left-pad, and anyone who required it with a non-specific version would have been vulnerable.
The sensible thing to do would be to block anyone from picking up abandoned package names, until NPM can verify their proposed package.
I’m happy to see that they plan to do that now, but really, it should have been there from day one.
In any case, it made me even more aware of the importance of shrink-wrapping.
Actually, I don’t see why NPM doesn’t do that by default, like ruby’s bundler.
Our release process depends on some 3rd party service
Or, as a reddit commenter put it ‘if you have to go to the internet in order to build your application, I pity you‘.
This was a big realization for me; I just always took it for granted that npm install just works.
But what if NPM is down? or a package is missing? or my corporate firewall has been updated to block npm.org?
I can’t release now?? that’s ridiculous.
You could use local registries, cache your dependencies, or even bundle your dependencies.
That’s an operational consideration that we need to be aware of. I wasn’t.
Conclusions
Better not trust rely on NPM Inc. and its packages
As a for-profit organization, by default their higher interests are not necessarily those of the community.
That doesn’t make them “evil”. That’s the definition of ‘for-profit’.
Should a not-for-profit community be heavily reliant on a for-profit product? probably not.
I would love to see an open-source solution for this. In the meantime (or in addition)- I’ll make sure to set up solutions such as caching to avoid everything going to shit in the event of a breakdown, or someone taking down the useful GoldMansaChs package.
Even if all of the above is fixed, there are still a whole bunch of potential failure points.
Think about your dependencies
How often have you updated your project’s dependencies to make sure you have the latest security patches?
And when you have- have you read their release notes? looked at the diff? looked at their source code at all? at their dependencies?
How many times have you gone through your package.json file and removed unused packages?
If you’re anything like me, your answer would be somewhere in the vicinity of ‘never’.
We need to realize that dependencies need to be managed; It’s not a ‘fire and forget’ action. “A package is for life, not just for Christmas”!
* My girlfriend's comments to this post: "I thought a repository is something you put up your bum"
The Useless Dev blog 