The more code you have, the more slowly your team moves. We've all been there. Faced with a business problem, you start to build software. As the code grows, you spend more and more of your team's capacity maintaining code you already have.
You're already outsourcing whatever you can, but some code can't be a service. SaaS takes software off your plate and puts it in the hands of a vendor, but it's tough to do this with a JSON parser, an ORM, or a web framework. That's when you pull open source packages into your application, "outsourcing" the initial development of reusable components and libraries. Without open source packages you'd spend the first two years of every project reinventing wheels.
Many assume that widely used open source software always gets maintained somehow. Nothing could be further from the truth; it's become an industry crisis. The Ford Foundation report Roads & Bridges did a lot to raise awareness, but we're reminded daily by crises like the recent hack of event-stream.
This is slowing your team down and draining their attention, and we haven't even talked about actually improving these packages, or keeping them in sync with new frameworks and architectures… who's doing those things?
For many packages, nobody is.
How much faster could you move if your dependencies had that last 10% of refinement: decent documentation, nicer error messages, removing that one annoying limitation with 107 upvotes on GitHub…
“We’ve lost half a day at release time because of a sudden vulnerability in a dependency and having to figure out whether to update and hope it doesn't break anything.”
You can buy tools to generate long lists of legal and security concerns. We've spoken with hundreds of companies who bought these, and frequently… the list of concerns is just sitting there. Nobody has time to slog through countless false positives and maybe-you-should-investigate-this warnings related to the thousands of open source projects.
A cynic might say these tools are a way for security and legal teams to blame engineering… you knew about the big list of warnings! Why didn't you fix them all?
Of course, even if you worked through all the security and legal warnings, it would do nothing for general maintenance and bug-fixing of the libraries you depend on.
"Existing tools are helpful for guiding conversations, but don't get to the heart of the problem"
"I need to get maximum time for senior engineers on senior things, not babysitting PRs"
You can adopt a vetting or approval processes for every new package. This fails in two ways:
When you buy software as SaaS or from a vendor, it's the vendor's problem to fix licensing issues, keep the code maintained, and tell you when and how to patch security vulnerabilities.
What if open source worked like that?
It'd be great to choose any open source you need from Maven Central, npm, Rubygems, PyPI, or wherever, and have someone take care of it.
Instead of buying a scanner tool to tell you all the stuff you need to fix in your open source dependencies, what if you could buy… open source dependencies that don't need fixing?
You probably see where this is going. That's the product we've built.
It's called the Tidelift Subscription. Here's how it works, from the perspective of your software team:
Please don't buy (or, ugh, build) tools that create more busywork and bureaucracy for your team around open source packages. Instead, for a fraction of one developer's salary, hire Tidelift to do this for you. Outsource this non-core task!
Ready to learn more?
How do we do it? We've set up software and business processes to manage all open source packages, at scale, for our subscribers. The two key elements:
Here's exactly what happens when you subscribe to Tidelift.
If you already subscribe to another open source problem-discovery service, send us the complaints it has about your dependencies. We'd be happy to bring you solutions instead of bringing you more problems.
Next time legal asks for a list of packages with their licenses, download them as CSV from your Tidelift Subscription dashboard. We'll actually have correct license information for all of your packages—and if we don't, you can make it our problem.
Next time there's a security vulnerability in one of your dependencies, we'll give you a new package that's actually practical to upgrade to. If it's necessary to fork an old version of the package and backport a fix—we'll maintain that for you.
When there's a new version of a package you use, we'll tell you whether and when to update to it. Maybe it's compatible, maybe it isn't—maybe it fixes something important and maybe it doesn't—we'll give you that guidance.
Managing your open source dependencies can be a solved problem. Your job is to tell us what you use, and our job is to keep it in good shape. We can keep track of thousands of dependencies both better and at lower cost than someone on your team could.
Ready to see how the Tidelift Subscription would look with your codebase?