Our mission at Tidelift is to make open source software work better—for everyone.
What’s the best way to make it work better? A win-win value proposition, where both those who create open source software and those who use it clearly benefit.
Over the past few months we’ve been in dialog with both open source maintainers and professional development teams about their experiences with open source (and if you have a perspective to share, we’d love to hear from you). We’ve learned a lot from these conversations, insights we plan to continue to share over the coming months.
In my previous post, Pay the Maintainers!, I highlighted one (painfully) obvious way to ensure that those creating open source software can sustain their effort. It raises the question, when we pay the maintainers, what exactly are we paying them for? Or even more directly, what do professional users of open source want, that they don’t already have, and that they’d be willing to open the checkbook to get?
In a recent Tidelift survey, we learned that 83% of organizations are open to paying for security, legal assurances, and maintenance around the open source software they already incorporate into their applications.
We believe the answer is in this datapoint.
With Tidelift, open source maintainers can get paid by providing professional software development teams with security, maintenance, and legal assurances for the software they already depend on. The equation is simple:
But to make the win-win value proposition work, to give professional development teams something they’d be willing to pay for, we need to understand the business-critical questions around open source that are not well addressed today. Let’s take a closer look at these three things we know professional development teams will pay for: security, maintenance, and licensing.
Open source software components, like all software, are susceptible to security vulnerabilities caused by programming oversights, or even intentional sabotage. Government-sponsored projects like Common Vulnerabilities and Exposures (CVE) compile lists of common identifiers for publicly known cyber security vulnerabilities, including those in open source software.
However, few commercial organizations have robust and effective processes in place to ensure that all of their software is continually assessed for known vulnerabilities. One painfully familiar example is the Equifax exploit of 2017.
While it’s easy to point fingers at Equifax, the reality is that not many organizations are set up to do better. The number of open source dependencies in a single application can easily run into the hundreds of packages. And even once a vulnerability is identified, fixing it without breaking something else is another matter.
Professional development teams are willing to pay to have an expert third party ensuring the security of the open source software they are using, with a single process and tooling that covers all of their dependencies.
Highly-compensated software development teams waste a lot of valuable time assembling, integrating, and testing open source components—ensuring they play well together.
This causes painfully real business impacts, including:
This maintenance work could be done better and at a lower cost by a dedicated third party outside of the organization. Ideally it should be done by someone who focuses on these tasks as their primary responsibility, investing the effort necessary to do the work once comprehensively, with many organizations sharing the benefits. While open source project core teams and maintainers often endeavor to address these needs within the scope of their individual projects, each open source community follows its own process and standards, and thus the step of pulling it all together often falls between the cracks.
Professional development teams will pay to get the confidence that the software their team uses is properly maintained and managed, both at the level of individual projects, but also in terms of how these projects depend on each other.
Software licensing and intellectual property law are key “technologies” that enable open source software to exist in the first place. By definition, every piece of open source software has a license that governs its use. In large software projects with many dependencies, open source license compliance can become a major headache.
Often, individual software developers on professional teams are tasked with making critical decisions about the licenses of their open source components—a complex and nuanced area of expertise that they are typically not well-equipped to handle.
Potential business impacts include:
Professional development teams will pay for legal assurances around the open source software they use, not only to address whether the license is properly documented in the first place, but also whether these licenses are compatible with how they are using the software.
So in summary, the win-win for open source looks like this:
If you’d like to learn more, check out these resources: