Your open source supply chain may include abandoned or inactive projects
Almost every new application developed today relies on open source code. Enterprise software development and DevOps teams understand the many advantages of open source, including rapid innovation and code quality. It’s typical that custom functionality and business logic comprises only about 10% of an application’s codebase.
Fewer open source users realize that many projects—including those that enjoy strong momentum and use at launch—are inactive within a few years. Turns out that selecting an open source component is one thing, but managing its use over time is an altogether different undertaking.
Recently we surveyed software developers to better understand how they pick open source components for their applications. Hundreds responded, and we learned there’s remarkable consistency in the factors they consider before choosing an open source project on which to build their app.
Use of an acceptable open source license is a top item considered—86% of respondents said it’s a significant factor. This isn’t surprising given that most big corporations maintain lists of licenses that are OK and others that are dealbreakers. We also found that developers look for signals that a project is well-maintained. 86% of respondents said the number of commits and pull requests matters, and 80% indicated they care about maintainer responsiveness. Digging in further, 74% of respondents flagged days since last activity as a key metric when evaluating open source projects.
In short, developers have a process they follow for selecting open source components when building applications.
But then…the maintainer’s interests can change. A new job doesn’t allow time to work on the project any longer. Or maybe they burn out and choose to step back from the project altogether, with or without transitioning the project to another maintainer. Developers’ processes for vetting open source components generally don’t catch these changes, yet such changes in a component’s status or maintenance occur every day.
A managed open source approach helps you spot deprecated projects and fixes related issues
If your team has taken a commercial dependency on one of these projects, how will you know that features are no longer being added and vulnerabilities aren’t being patched, even if reported? When an npm module that depends on a deprecated library is flagged, whose job is it to gauge whether you should take action in your application? Your development team, their DevOps colleagues who manage the production application, or your AppSec team?
These things happen in open source. Components are retired or fall out of favor and new things take their place. We built the Tidelift Subscription to not only track these changes and flag them for your team, but to fix problems they create in your applications. Working in collaboration with the maintainers of thousands of open source projects, we’re looking out for things like this, so you don’t have to. When we see this happen, we’ll identify it for you, and suggest a recommended path to replace it with something that will be maintained into the future.
If you’re interested in learning how you can better manage your open source components, including surfacing issues with packages that are no longer being maintained, we can help.