What makes an open source package “bad” for enterprise use?

The most effective development teams adopt a proactive approach to managing the health and security of their open source dependencies. Explained in very simple terms:

If you’re spending lots of time fighting fires in your software, consider choosing better software.

Let’s say you have a leaky roof. You can spend a lot of time putting buckets all over the place, and maybe you’ll do that in the short term, but it might be smart to fix the roof as well.

Open source dependencies come in the form of packages, downloaded from Maven Central, npm, or similar public repositories. Some packages are more likely than other packages to cause problems for typical enterprise software development teams. It makes sense to adopt a practice of reducing your team’s use of these packages.

As a shorthand, we’ve found that people end up calling them “bad packages”—bad packages are the ones they’ve decided to try to avoid. We’ve adopted that “call a duck a duck” language in much of our documentation. But what do teams mean by this? What should they mean by this? What is a “bad package”?

These questions can have context-dependent answers, but there are some common themes to keep in mind.

Why might you avoid certain packages, again?

Here are some of the benefits we’ve seen from making better dependency choices. As you think about which packages to try to avoid, keep in mind the point of the exercise—why are you doing this proactive work?

• Reduced security risk. If a package is more likely to have vulnerabilities, it’s more likely to result in some kind of security incident.
• Improved productivity. If a package is more likely to have vulnerabilities without easy fixes, or stuck on an older platform like Java 8 or Python 2, it is more likely to waste the team’s time working around problems.
• Improved application quality. If a package isn’t seeing new feature development or bug fixes, the team may be working around bugs or missing capabilities. The package will also fall farther and farther out of sync with the latest frameworks and other related open source packages.
• Reduced audit risk. Compliance processes can slow down business initiatives, for example when trying to sell your product, procurement teams might flag vulnerabilities or license concerns that have to be addressed.

How might you define “bad packages” to avoid?

At Tidelift, we believe all open source software is good! But not every package is the right choice in every context, and in our experience open source developers agree with that completely. Some packages were never intended for enterprise use (perhaps they are fun hobby projects); some have been abandoned; still others were carefully deprecated and end-of-lifed for very good reasons.

To define “bad packages” for your organization’s context, think about what makes a package fit for enterprise use; or on the flip side, what makes it more likely to introduce risks or waste your team’s time.

If you’re using Tidelift’s web UI, CLI, or APIs, we provide a default classification for packages, and also provide the raw data you need to create your own classification. You might choose to use our default classification directly or you might choose to create your own, but here’s how we define our categories, as a starting point:

1. Not recommended. We outright do not recommend a package if it’s end of life, scheduled to become end of life, or appears to be “de facto” end of life. If the developers of the package have documented it as end of life, that’s a simple example. But we also look for signals such as: the package has no activity, has been ignoring vulnerabilities, or has been marked deprecated.
2. Caution advised. These packages are not end of life, but we’ve identified some concerns that they aren’t going out of their way to meet enterprise development standards. They may not be using two-factor authentication, may have active vulnerabilities, or may have concerning dependencies.
3. Neutral. We don’t have any known concerns about these.
4. Recommended. These packages have affirmatively expressed their intent to uphold secure development and maintenance standards, and have a plan for financial or institutional support to give them the time and incentives to do that.

You can learn more about our categorization and our criteria in our documentation, and access our categorization of each package through the package details API.

What can you do with this information?

Our customers have seen success with four practices that can reduce the number of bad packages in use at their organization. Any one of these can help make meaningful progress in reducing reliance on bad packages; there’s no need to undertake all four at once.

1. Review packages prior to adoption.
2. Monitor packages in use to discover anything that’s showing new signs of not meeting your criteria.
3. Undertake an initiative or practice to work down the list of already-adopted bad packages.
4. Provide support to the original developers of packages that are looking shaky, to keep those packages from becoming bad in the future.

In our getting started guide, we have some ideas on how to go about each of these activities.

The teams that see the most success don’t try to boil the ocean. They identify a few bad packages and make some progress. Then on a regular schedule, they keep making a little more progress. They measure their results. It isn’t about fixing everything all at once; it’s about sustainable, regular practices.

Book a demo or read our getting started guide to learn more about how your organization can reduce reliance on bad open source packages and ensure the open source projects you rely on keep getting better.