Corporations are in a race to embrace open source, with 2018 being a stellar year for acquisitions of companies that support the use of open source software.
Microsoft grabbed major headlines by acquiring open source repository GitHub for $7.5 billion, followed by IBM breaking records with their $34 billion acquisition of Red Hat.
These acquisitions should have settled any questions about how the corporate world views the importance of open source in the future of commercial software development and business.
As a part of this effort to embrace the open source community, a growing number of companies across all industries are backing and contributing to open source projects.
Like Salesforce boasting of its contribution to open source projects, an impressive list of enterprises are taking part in the advancement of corporate open source engagement. Google, Facebook, Intel, and Pivotal are only a few of the other big names that contribute heavily to open source projects.
Given these steps towards supporting open source, it’s tempting to believe that we have entered the golden age of open source, in which corporations and the open source community cooperate in a win-win-win development ecosystem.
Unfortunately, a recently published security issue in a small open source project highlights the fact that there are still gaps in the relationship between the businesses who use open source components and the community of developers who not only write the code but are expected to maintain them over time.
This recent incident reveals that it’s not all unicorns, rainbows, corporate love, and collaboration.
The Vulnerability that Exposed Critical Flaws in the Open Source Community
Ecstatic, like many open source projects that help fuel our software projects, was mostly a one-dev show. The simple static file server middleware that works with core HTTP, express/connect, or on the CL was created by a young and eager developer about eight years ago. This small JavaScript component may have gone on to live a long and satisfying life in many a server across the land if it weren’t for a relatively mild open redirect security issue discovered in late April and published on the npm security advisory.
Issues in open source components are discovered, published and fixed all of the time. This is actually an increasingly common practice as both the open source community and open source usage continue to grow. However, in this particular case, ecstatic’s primarily lone, hard-working-for-free creator and maintainer had had enough and wrote a lengthy and quite illuminating post on GitHub, giving light quite a few issues.
According to ecstatic’s creator, after he had issued an updated version to fix a security vulnerability reported to the npm team, he was disappointed with the lack of support he received from the npm team that confirmed the issue and passed it on to him. He then requested that vulnerable versions of ecstatic be unpublished.
It’s worth noting that this course of action has seen disastrous results in the past. In 2016, a developer withdrew his modules from npm after instant-messaging app Kik's legal team claimed brand infringement over one of his modules, and npm appeared to take the corporation’s side. That’s when the world of JS applications found out that this included one extremely widely-used module that projects like Node and Babel used. The fallout was not pretty.
While ecstatic isn’t as gigantic as that notorious 11-line dependency, ecstatic's creator quickly found out that ecstatic powers quite a few projects, like http-server, which, in turn, is used by some commercial outfits. Some of these commercial users were desperate to get back the outdated ecstatic versions, and according to ecstatic’s creator, felt entitled to demand a quick fix that supported the outdated versions that they were using.
Sadly, they were less enthusiastic about actually supporting or backing maintenance and updates.
Open Source Labor: Free, As in Beer?
ecstatic’s creator built the project, like many a young developer, as a labor of love. While he admits that publishing it under a permissive MIT open source license meant that it could be used by all sorts of users, including businesses, he found that some businesses were quite demanding of his time.
He was disappointed to learn that as he continued to maintain and develop the project, most enjoyed his contribution and offered little to no additional support. Eight years later, when users demanded he re-release old versions and fix them to help support their “multi-million dollar enterprise solution” for free, he decided that he was done, and ended the project. Can we really blame him?
The story of the relatively quiet demise of ecstatic highlights how versatile and complex the term “free” is when it comes to open source components. Just because a developer puts software out in the world for all to use doesn’t mean that they are at your beck and call. In fact, if your business depends on them, you might want to consider investing some resources into its maintenance, or you might find yourself in the unfortunate place where that anonymous multi-million dollar solution floundered.
How to Make Sure Open Source Projects Stay Alive
The reasons that led ecstatic’s creator to discontinue development and maintenance tells us a lot about the current state of the open source community — creators, maintainers, users, and everything in between.
While many industry giants have come to embrace and support the community of open source developers, there are still countless open source projects that are built primarily on love, sweat, tears, and precious free time. Companies like Tidelift, and projects like GitHub Sponsors have found ways to help companies support the open source projects that they are using to ensure that the projects remain fresh and secure.
If companies don’t start taking some of the weight off of independent open source developers’ shoulders, and help support the open source projects that help them create and ship their magic, we will find ourselves with many more ecstatic-like predicaments.
Companies need to understand that while developers are passionate about — or at least devoted to — their open source project, it might not be their top priority.
Their paid work, family, and other human activities may come first. If businesses depend on open source software, then they are going to have to acknowledge that just like in-house software, they need to be well resourced.