Tag Archives: dependency

Maybe we should think about how we use language ecosystems

Posted on by
2

Over the weekend, Bleeping Computer reported on thousands of packages breaking because the developer of a package inserted infinite loops. He did this with intent. The developer had grown frustrated with his volunteer labor being used by large corporations with no compensation. This brings up at least three issues that I see.

FOSS sustainability

How many times have we had to relearn this lesson? A key package somewhere in the dependency chain relies entirely on volunteer or vastly-underfunded labor. The XKCD “Dependency” comic is only a year and a half old, but it represents a truth that we’ve known since at least the 2014 Heartbleed vulnerability. More recently, a series of log4j vulnerabilities made the holidays very unpleasant for folks tasked with remediation.

The log4j developers were volunteers, maintaining code that they didn’t particularly like but felt obligated to support. And they worked their butts off while receiving all manner of insults. That seemingly the entire world depended on their code was only known once it was a problem.

Many people are paid well to maintain software on behalf of their employer. But certainly not everyone. And companies are generally not investing the sustainability of the projects they rely on.

We depend on good behavior

The reason companies don’t invest in FOSS in proportion to the value they get from it is simple. They don’t have to. Open source licenses don’t (and can’t) require payment. And I don’t think they should. But companies have to see open source software as something to invest in for the long-term success of their own business. When they don’t, it harms the whole ecosystem.

I’ve seen a lot of “well you chose a license that let them do that, so it’s your fault.” Yes and no. Just because people can build wildly profitable companies while underinvesting in the software they use doesn’t mean they should. I’m certainly sympathetic to the developers position here. Even the small, mostly unknown software that I’ve developed sometimes invokes a “ugh, why am I doing this for free?” from me—and no one is making money off it!

But we also depend on maintainers behaving. When they get frustrated, we expect they won’t take their ball and go home as in the left-pad case or insert malicious code as in this case. While the anger is understandable, a lot of other people got hurt in the process.

Blindly pulling from package repos is a bad idea

Speaking of lessons we’ve learned over and over again, it turns out that blindly pulling the latest version of a package from a repo is not a great idea. You never know what’s going to break, even if it’s accidental. This still seems to be a common mode in some language ecosystems and it baffles me. With the increasing interest in software supply chains, I wonder if we’ll start seeing that as an area where large companies suddenly decide to start paying attention.

left-pad exposed the real problems

Posted on by
4

During halftime of Super Bowl 49, “Left Shark” became an instant pop culture phenomenon. Last week, an 11-line software package called “left-pad” became an instant tech culture phenomenon.

In you’re not familiar with what happened, here is a basic summary as I understand it: the social network/chat company Kik approached a developer and threatened him with lawyering if he didn’t remove or rename his “kik” NPM package (the package was in no way related to Kik the company). When the developer refused, Kik went to NPM, who acquiesced and reassigned ownership. As a result, the developer pulled all of his packages, including left-pad, from NPM.

Normally, this wouldn’t get much attention. However the Node.js ecosystem apparently favors many small packages, such that you end up with single-function packages like left-pad. Many NPM packages either depend on left-pad or depend on packages that in turn depend on left-pad. This led to, as some people hyperbolicly said, the Internet breaking.

Much of the discussion has focused on the technical matters. The NPM ecosystem is the subject of a great deal of ridicule. The opinion isn’t unanimous, but ridicule is the prevailing sentiment. And rightfully so, but not for the reason being discussed.

The real problem with NPM isn’t the numerous tiny packages. The problem is with how the ecosystem is apparently managed. Breaking dependencies by “unpublishing” packages is not something a mature ecosystem allows. Removing a package without consent because another developer wants to use the name is a terrible way to build and maintain a community.

The other bad part is how Kik’s lawyers were able to make all of this happen. Trademarks are not universal. Just because Kik has trademarked the term in the context of a messaging platform, that doesn’t mean the term can’t be used in another context. Maybe in this specific case, there’s infringement here. I’m not a lawyer or a judge. But the way it was handled was not at all suitable. As Ben Thompson said, “lawyers overreaching on trademark were the Mentos to an open source absolutist’s cola.”

It’s a bit unfair to pin this on “an open source absolutist”. Azer Koçulu may or may not be an open source absolutist, that’s irrelevant. Lawyers tossing threat grenades and ecosystem managers not protecting the ecosystem are more important than the number of packages or having trivially-small packages.