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 , followed by IBM breaking records with their of Red Hat. $7.5 billion $34 billion acquisition 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 boasting of its contribution to open source projects, an impressive 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 . Salesforce list of enterprises 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 , 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 . Ecstatic 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 , giving light quite a few issues. on GitHub 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 after instant-messaging 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. withdrew his modules from npm app 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 , 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. http-server 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 meant that it could be used by all sorts of users, including businesses, he found that some businesses were quite demanding of his time. MIT open source license 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 , and projects like have found ways to help companies support the open source projects that they are using to ensure that the projects remain fresh and secure. Tidelift GitHub Sponsors 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.

Stellar

Facebook

Google

Intel

Microsoft

Salesforce

Championing open source security and compliance with WhiteSource

Security Could be the Proverbial Straw that Breaks the Open Source Community’s Back

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

102 Stories To Learn About Open Source Software

10 Repositories that Will Transform the Way You Approach Technical Interviews

10 Python Projects with 10 Lines of Code

10 GitHub Repositories to Follow

12 cool things you can do with GitHub

12 Techniques We Used to Get 4.7K+ GitHub Stars for Our Open Source Project in 6 Months

102 Stories To Learn About Open Source Software

10 Repositories that Will Transform the Way You Approach Technical Interviews

10 Python Projects with 10 Lines of Code

10 GitHub Repositories to Follow

12 cool things you can do with GitHub

12 Techniques We Used to Get 4.7K+ GitHub Stars for Our Open Source Project in 6 Months

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps