Event-stream: 100 million downloads, unmaintained, hacked. Now can we pay the !@#$% maintainers?

Late last week, users of the popular JavaScript library event-stream discovered a vulnerability in the package caused by a malicious actor who had taken over as the project maintainer.

The project had been largely unmaintained, seeing only 11 commits in the past three years before the attacker took over. Despite this inactivity, event-stream was still seeing nearly 2 million downloads per week, and was used by large open source projects such as Angular, Mocha, and Electron, as well as commercial codebases all over the world, including BBC News and Microsoft.

The quick resolution of the issue is a testament to the power of open source as a means of software development. But the process of discovering the vulnerability itself led to some intense discussion covering topics such as legal and ethical responsibility of open source maintainers, financial support for open source development, community governance, and the challenge of vetting the thousands of open source dependencies that comprise a typical contemporary application.

Two sides of the same coin

How did we end up here? Well, it’s actually pretty simple, and the original maintainer of event-stream answers it succinctly when he explains why he transferred ownership of the library:

We’ve discussed at length the importance of paying the maintainers, but here we have another concrete example of the risks associated with not doing so. Maintainers have no obligation to continue working on a library just because it’s popular, leaving a package that could be unmaintained, vulnerable, or broken, yet still widely used.

What’s more, by not having someone supporting the libraries that your applications depend on, you’re opening yourself up to this risk with each one of your dependencies. For even the simplest JavaScript app, these can number in the thousands.

A common argument is that the maintainer has an ethical obligation to continue maintaining a package that they know is widely used, but such an argument is unjust and unfair to maintainers; for a commercial entity or business user to make this request (oftentimes more of a demand) is an abuse of individual labor.

Or, as tj, an open source creator of mythical proportions, more aptly stated:

This brings another issue into question: who is responsible identifying the security, maintenance, and community around a dependency? Should individual maintainers shoulder this burden, or should each end-user perform their own due diligence?

Ultimately, it falls on both parties—maintainers should make what they believe are the best decisions for the project, but developers should monitor and analyze their dependencies before making use of them. That said, there’s still a big problem:

Option 2 (vet all dependencies) is obviously impossible. Last I looked, a new create-react-app had around a thousand dependencies, all moving fast and breaking things.

— Gary Bernhardt (@garybernhardt) November 26, 2018

All of this is to say, that despite the innumerable benefits of using open source libraries to aid in your development process, there are challenges. But these challenges all follow a common thread: maintainers deserve and require financial support from their commercial users, proportional to the value that they’re creating, and those users want to more safely and effectively utilize their dependencies to help them build better products.

We want to fix this

So once again we have a visceral example of the way we all would benefit if maintainers had a stronger incentive to keep maintaining their packages. Maybe if he was getting paid for his work, Dominic would have kept maintaining event-stream. Or perhaps if he was just no longer interested, but the reward was worth the labor, someone else would have stepped in.

We think there is a simple way to fix this problem in a win-win way.

1) Give professional users a standard set of security, maintenance, and licensing assurances for the open source packages they use, provided directly by the people who created and maintain them, at a reasonable cost.

2) Use this money to pay the maintainers. Projects with lots of paying users would make lots of money, projects with fewer paying users might make less, but still enough so that keeping them well maintained is worthwhile.

This is what we have built with the Tidelift Subscription. If it sounds interesting, you can learn more here.