Application dependencies are code. Like all code, this code needs care and feeding.

The packages in between your application and the cloud infrastructure layer—the packages you're loading into the actual address space of your application, that go into the container image that you build—are almost all run exclusively by volunteers, usually a single person.

The dilemma teams face today:

• These packages and frameworks in the middle make it much, much faster to ship working apps. Implementing HTTP from scratch isn't the sort of thing your team should be doing! Rapid application development depends on open source code re-use.
• The packages aren't always in great shape. 10-20% of them aren't seeing any maintenance activity at all. Many more are under-maintained. Few have adequate security procedures, with a number of high-profile incidents as a result.
• If legal asks for the licenses on all the code you're using… have fun, because there's no reliable annotation.
• Meanwhile the packages that are maintained can be fast-moving, and there's a need to keep up… or you won't have bugfixes, security fixes, or new features.

When engineering teams want to manage technical, legal, and security risks in these open source libraries they rely on, they have to use homegrown or costly tooling that surfaces lists of problems...and then dedicate engineering time to tackling them. They also have to research and monitor package status (quality, roadmap, licensing, releases) themselves, package-by-package. (Many teams use thousands of packages, by the way.)

Because this is too time-consuming to be practical, in practice, teams don't do it. Inadequately maintained-and-monitored dependencies create risks, fire drills, sub-par quality, and engineering rabbit holes. Teams often come to view dependencies as a liability to be minimized, rather than taking full advantage of open source code re-use.

At many companies, there's a huge gap between stated open source policy (diligent research, monitoring, approval, and maintenance) and reality (everyone ignores the policy).

Could a managed open source approach save you money?

What if you could have a managed open source strategy for taking good care of your open source dependencies? What could that mean exactly?

The best analogy might be to go back 15 years ago or so to the world before cloud computing. In those days, if you were trying to launch a new SaaS app, you’d need to rent space from a reputable hosting facility, buy and install servers to ensure your app has appropriate backup / failover, and configure all of the software you need on those servers. Then, if something went wrong with a server, you’d have to drive or fly to the hosting facility, swap it out, install software updates, etc.

Today, you simply tap a couple of buttons or run a script, and your favorite cloud provider manages all of that for you.

But when it comes to all of the open source components your app relies on, development teams today still need to do a lot of the heavy lifting themselves.

We think a similar managed approach—managed open source—might allow you to get back the time you are currently spending wrangling open source dependencies, which frees you and your team up to focus on the truly differentiating features of your app.

We've built one approach to this at Tidelift. In brief, we keep track of the recommended versions (and recommended packages) you should be on, and give you the tools and guidance to stay on those—with the expert help of the open source maintainers who created your packages.

Without well-managed open source dependencies, what could go wrong?

As always, xkcd explains the problem well. We can't say when spottily maintained dependencies will bite you, but we know they will.

Cartoon courtesy of xkcd

The scariest risks involve security breaches and lawsuits. The most inevitable consequence of poorly maintained software, though, is wasted time. The saying goes that "open source is free if your time is worth nothing."

This is why you purchase managed cloud services for your compute, storage, and database, rather than owning and operating them yourself. Application dependencies are no different. They need care and feeding, and if you're doing it yourself, you're probably getting an inferior result at higher cost. Home brew dependency stacks are undifferentiated heavy lifting. They don't create business value.

According to our surveys, developers spend about 30% of their time on maintenance and 25% of that is open-source related. So let's say 8% of developer time is open-source related maintenance. That's a lot of time to save and you can calculate the developer salary you're spending on it using our ROI calculator.

But the real costs go even beyond developer salary; two in particular:

• opportunity cost: what core business capability could your developers be working on instead, and what's the value of that?
• risks: legal, technical, and security-related icebergs that arise from insufficient maintenance of your dependencies; the most common risks are technical and could cost a few months of time; bad legal and security outcomes are less common, but can be mind-meltingly expensive.

This is a significant unsolved problem for the software industry. How are you thinking about it in your organization? I'd love to hear from you in the comments.