Oh, the hate!
This story has brought out the worst in developers everywhere. It saddens me to see the amount of hate being thrown around, and how many seem to be willing to throw more back. There seems to be a few different camps that are showing themselves here.
Haters of a company for taking legal action to forcibly remove a package due to a naming collision. Implying: A power-hungry company that doesn’t care for open source or respects their authors.
Haters of the package manager for not standing up for the package-author to try to stop said company’s legal train. Implying: A spineless package manager community that cares more about pleasing corporate vs standing up for the little guy.
Haters of the package author for reacting in such an irresponsible way, and “breaking the internet”. Implying: Irresponsible package author has lost his mind and has turned “evil” by pulling down all his packages that people’s relied upon.
Haters of developers that have put themselves into this position and made themselves dependent on an 11 line library and have broken their app. Implying: Irresponsible developers who don’t take the time and care to code everything themselves. Make it yourself instead of pulling in a dependency.
Haters of one of the most used programming languages coming out of the woodwork and calling out how useless this language is, how flawed it is and how anyone developing with it cannot be called professional developers. Implying: Developers that use this language are by default irresponsible because they don’t take programming paradigms seriously and the language is fragile and useless.
Have you considered…
I don’t have any of the background facts here except what’s in this article. But I would like to explore the possibility of approaching this incident slightly differently. Some may say naively.
Company is making a move into open source and would like to publish a package matching their brand, but there’s an existing package with same name. This is important to the company and they involve their legal department to help them figure out how to approach and request a name change. When this fails they approach the package manager responsible party and requests they remove the package in legalese. Meaning they did what they felt was right. This doesn’t mean they’ve done the right move, but they’ve done a move that is natural given their position. That doesn’t make them evil.
The package manager community is faced with a legal claim to a name, which is will win in a court-ruling. They try to broker a deal with the original package owner and also explore options that doesn’t involve pulling his package but is finally faced with reality. They aren’t an “Apple” in a position to fight the “FBI”. They give in to the demands and (hopefully) have exhausted all options before taking this drastic measure. This does not make them weak or evil or backstabbers. It’s legal doing its thing.
The package author gets a legal letter telling him to step away from his package and to rename it. Forcing that packages users solutions to stop working since they have to rename their dependency. The wording of the letter pushes his buttons and doesn’t seem inviting to a dialogue, but more “comply, or else”. He declines the request and hopes everyone can move on. When he discovers that his package has been forcibly removed, he sees no other option than to actually take a step back. He is hurt, mad, frustrated and decides to pull all of his packages. What about people who depend on the, though…? Well it’s only a few lines of code, they can move that into their project or create a new package that is maintained by someone else. He reacts to the situation that arises and does what he believes to be right.
To developers hating other for taking (small) dependencies. Have you considered that this is how many developers do their work? They don’t re-invent the wheel every time they work on a new project. Smart developers have a tool belt full of re-usable tools that can be imported into new projects to give them a flying start so they can just get going with where the added value is. Before people used to have a pen-drive with these dependencies, now we have package managers that allow us to re-use our own components and allow others to share them as well. Other smart developers realise that previous smart developers have already done this and use said shared tools and libraries. Packages can be modified, changed or withdrawn at any time, so at this time a developer can choose to lock to a specific version, make modifications on a fork with or without a pull-request or just pull it directly into their project. There is nothing controversial here. This is package management. This is the paradigm of npm-packages. Oh, and nothing actually broke in production, but it did make it hard on the development team that didn’t have a local nom cache-server.
My take on it all
I don’t know the facts except what’s in this article. I choose to accept what has happened at face value and reflect on the learning opportunity that lies here.
Teams with broken builds: Fix those builds, consider pulling a dependency into your project or finding another one to depend on. It’s part of the responsibility you have as a developer to consider what makes sense to rely on or to own.
NPM: Certain trust issues have arisen. Could enforcing a policy of not being able to delete a package like Nuget for C# be an idea?
Shit happens, whether we like it or not. Pointing fingers and shouting out other people’s supposedly bad choices are not how to learn and move on. Consider framing your approach and mindset in a way that brings value to the topic at hand since you may have very valid points. Don’t let that drown in all the noise.
Update: Kik messengers side of the story
Update2: npm.js official take on the story
Update3: npm.js concrete action to improve
I would love to hear your thoughts on this matter. Feel free to drop off a comment or reach out to me
Photo credit feature image: Brian LeRoux via Visualhunt / CC BY-NC-SA