It’s no secret that open source software is powering modern application development. In our own surveys, we’ve found that more than 90% of applications incorporate open source components, with open source typically making up 70% or more of the average application's codebase. Open source software accelerates value delivery and innovation—enabling the creation of humanitarian tools and traversing the universe. 

However, despite all its amazing-ness, open source also comes with management costs. 

In many cases, an open source package is being maintained by a lone maintainer whose passion project is now being relied on by businesses, governments, and individuals around the globe. In our most recent maintainer survey, we found that 60% of open source projects are maintained by people who describe themselves as unpaid hobbyists. These volunteer maintainers often lack the time and incentives (pay the maintainers!) to ensure the project follows the secure software development practices organizations probably require of any software developed within their organization.

So how can organizations start making more informed decisions about which open source components to use in their applications? 

To help answer that question, Tidelift co-founder and chief architect Havoc Pennington, Tidelift VP of product Lauren Hanford, and Tidelift principal product manager Bill Nottingham shared the 10 critical things to know before depending on an open source project. This webinar dove into the ways in which an open source project can be seen as reliable and how to best receive and assess that information, including using methods that Tidelift offers as part of our subscription.

What are the risks of using insecure or under maintained open source software? 

When talking about the benefits of open source, you’ll often hear about the associated risks that come with using it. To paint a more holistic picture, Lauren explained some of the risks in more detail: 

“Some of the risk that folks can take on if they’re not aware of these insecure or under maintained (or unmaintained):

• Data risks: as an organization you could lose access to your data or have sensitive data stolen. This can lead to a loss of trust and brand reputation, and is often followed by legal or regulatory fines.
• Loss of productivity: within your development team and within teams who are relying on those developers.
• High cost of remediating risk: in particular, this tends to get worse and worse as it goes on. 

All of this is going to affect your ability to deliver value to your customers, and when it goes wrong, you can erode trust quickly.”

A defense-in-depth approach to open source software security

Historically, software composition analysis (SCA) tools have been used to highlight and address vulnerabilities as they happen. This is a reactive approach, that in our experience, while valuable, is not enough by itself. Lauren went on to explain why SCA tools are only a piece of the security puzzle:

“SCA tools are going to make sure that you don’t retain known things that aren’t fit for use in your company, but we believe that you should do more than working to not retain things that aren’t good for your organization, and work on consuming things that are healthy and lead to good outcomes. It’s important that you’re creating healthier and more supported open source in the long run—it’s a better investment for your business to be innovative and to drive safely into the future.”

“At Tidelift we’re asking, how can we minimize these risks and the likelihood of being affected by these vulnerabilities in the first place. Our response is to be both proactive and reactive. By being reactive, we want to identify and resolve known issues and vulnerabilities in the open source packages your organization uses—Tidelift’s model also ensures that the partnered maintainers that we work with have the time and the capability to deliver vulnerability fixes that you need to be able to apply this.”

“On the proactive side, we want to protect against future issues. Before a vulnerability shows up, you want to know: has this package been deprecated? Is it appearing maintained? Does it look like the community needs more support? Is the maintainer or maintenance team likely to be responsive to issues? Working to answer these questions is a more proactive, intentional approach instead of waiting for something bad to happen.” 

What should organizations know before depending on an open source project? 

At the heart of the webinar, Havoc, Lauren, and Bill provided anecdotal examples of how Tidelift and our partnered maintainers have worked to address important questions we believe organizations should ask when choosing which open source packages to depend on. 

An example scenario: The one where the maintainer deleted their GitHub repo

In this anecdote, Havoc told the story of a time when a maintainer, in response to a new, mandatory GitHub 2FA security requirement, deleted their GitHub repository, and how a Tidelift sponsored maintainer stepped in. This example addresses three of the ten critical things we recommend organizations know before depending on an open source project: 

• Is the project abandoned or is it actively maintained and receiving fixes?
• Who are the maintainers and how many maintainers are behind the project
• What are the associated project and release dependencies?

From Havoc himself, “Something we’ve learned over the years at Tidelift, when digging into open source data, is that it’s really common for maintainers to quiet quit. They become unresponsive and start ignoring the issues and contributions they receive. However, instead of ghosting, last year someone explicitly quit, and explained why.”

“It was with a package called minimist—it just had one maintainer. He got tired of being asked to do non-coding tasks with no support. As I understand it, the straw that broke the camel’s back on this was npm, the node package hosting repository, which started to require maintainers to implement two-factor authentication (2FA). In this specific scenario, he didn’t have a phone, so he couldn’t easily adopt that practice. In response, this maintainer started to delete the GitHub repository for minimist and stopped maintaining it. This package was used by 31,000 other packages and it had been dropped.”

“The lesson here is when you’re depending on a package that’s solo maintained by an unfunded maintainer, they could be in a similar scenario where they can’t meet requirements because they don’t have a phone, or they get pulled away from their package because of day time job requirements, or they decide they want to go into woodworking—whatever it is, you’re assuming that maintainer is going to stick around. And often they don’t, and that’s totally understandable, because they owe us nothing.”

“What’s cool in this case is that we were able to work with a Tidelift partnered maintainer who stepped up and took this over. The problem was solved and the package now has support, enough to keep a maintainer on it, and that’s why the ecosystem didn’t see a lot of disruption in this particular case. Though, that might not always be true, and migrating 31,000 packages off of something would not have been a simple undertaking” 

— — — — — — —

With the Tidelift Subscription, organizations can protect against future issues by identifying which open source packages your organization uses follow secure development practices. We partner with—and pay—our partnered open source maintainers to help provide organizations with package data that’s been researched and validated by those who created and maintain the packages themselves. For the rest of our recommended things to know when relying on an open source project and to hear more stories and an engaging Q&A, watch the entire webinar now and receive a handy one-pager to reference in your future open source decision-making.