Npm is in the spotlight right now thanks to the company’s acquisition by GitHub. The free npm Registry and Node package manager support more than 11 million JavaScript developers with a colossal 75 billion downloads each month. Maintainers and teams behind more than 1.3 million JavaScript packages make them available to the open source community at large through npm. As those npm modules evolve and add functionality, thousands have become core to the work of corporate application development teams. But then, when their creators move on to other interests, maintenance of those packages often goes sideways.
The resulting need to handle the deprecation of modules in npm has long been an adventure for JavaScript developers. The Node.js ecosystem has ballooned with transitive dependencies, and for the most part, they’re an accepted part of the development landscape. But left unmanaged or unmaintained, transitive dependencies can become weak links in your codebase or even serve as backdoors for malicious activity.
Recently JavaScript developers saw the widely used request library deprecated. Plans to do so had been in the works for nearly a year, so developers relying on the 48,000 npm modules that have request as a dependency had plenty of time to think through their options.
Software teams cross their fingers that maintainers behind important JavaScript projects don’t move on to other work or interests. But what happens when they do?
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.
50 Milk St, 16th Floor, Boston, MA 02109