It's time to take dependencies seriously

Please read this post from Russ Cox on Google's Go team, about software dependencies.

He outlines many, many reasons why we all need to care about the dependencies we use. But then he notes just how hard it is today, and that few of us are truly following through:

"The kind of critical examination of specific dependencies that I outlined in this article is a significant amount of work and remains the exception rather than the rule. But I doubt there are any developers who actually make the effort to do this for every possible new dependency. I have only done a subset of them for a subset of my own dependencies. Most of the time the entirety of the decision is 'let’s see what happens.' Too often, anything more than that seems like too much effort."

There's this huge amount of work that developers would have to do to avoid very real risks…but it's impractical for individual development teams to take on comprehensively, because they would never get anything else done.

On our maintainer forum a few weeks ago, here’s how we framed the problem we want to solve for customers who buy the Tidelift Subscription:

"Today, when engineering leaders want to maintain the open source they’re reliant on, they have to use homegrown or costly tooling that surfaces lists of problems…and then dedicate engineering time to tackling the endless lists of problems. They also have to research and monitor package status (quality, roadmap, licensing, releases) themselves, package-by-package. This is unacceptable, because it’s too time-consuming to be practical. In practice, teams do not keep their dependencies adequately maintained, creating risks, fire drills, and sub-par quality. They often come to view dependencies as a liability to be minimized, rather than taking full advantage of open source."

Russ has three recommendations:

1. Recognize the problem

2. Establish best practices for today

3. Develop better dependency technology for tomorrow

We're on board and working hard on all three of those (and we can help you get started today!) but I'd like to add a fourth:

4. Develop ways to keep dependencies actively maintained

Open source dependencies see constant under-maintenance and maintainer turnover. As Russ puts it, now you have to not only evaluate dependencies but constantly watch them; some percentage of them will go into decline.

To truly address this problem, we need practices, and tooling, and also proactive dependency maintenance. That's why the Tidelift Subscription involves partnering with and paying the maintainers of all the exact packages our subscribers use, and asking them to proactively ensure their packages have the attributes software teams using those packages are looking for.