Have you ever faced a no-good-options "dependency hell" choice, like the one in this tweet?
The root cause: lack of maintenance. When open source code isn’t well maintained (often because the maintainers are volunteers!), your team picks up the pieces by taking on non-core work.
And what happens when something goes wrong?
We hope you've never been thrown under the bus in front of Congress, like the poor person who failed to update Apache Struts at Equifax.
It's absurd to blame this sort of maintenance failure on one person, rather than processes and practices. Those processes and practices take time to do well.
You're already outsourcing whatever you can, but some code can't be a service. 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.
But you haven't addressed the ongoing maintenance of these packages.
What if someone was proactively managing your open source dependencies for you, helping ensure they continue to get better and play well with each other and your own code? What if you could have the flexibility to bring in open source components with the confidence that they are being maintained well?
The end result? All of the capabilities you expect from commercial-grade software, for the full breadth of open source you use. That means less time grappling with esoteric open source trivia, and more time building your own applications—and your business.
Ready to see how the Tidelift Subscription would look with your codebase?