In June of 2019, Tidelift and The New Stack jointly fielded a survey of professional software developers. Almost 400 people responded with thoughts about how they use open source software today, what holds them back, and what tools and strategies would help them use it even more effectively. In particular, with this survey we were interested in learning how a managed open source strategy might help developers reclaim time, speed up development, and reduce risk.
In this post, we share the seventh of eight key findings. If you want to see all of the results in one place, you can download the full survey report right now at the link below.
Finding #7: Almost half of organizations have policies requiring commercial support for the software they use.
It’s the age-old managerial objection to using open source: “But who are we going to call when something breaks?” While in the early days of open source, this was a common refrain with the suit-and-tie crowd. Now, thanks to companies like Red Hat, Elastic, and Cloudera, which provide enterprise-class support and assurances for open source, this objection has become much less common with some heavily used open source projects.
Yet, for the vast majority of open source components used to build applications, there is no commercial organization backing them up. We wanted to learn more about how larger organizations handle this conundrum. Are they required to have a vendor backing up all of their open source dependencies? Or do they self-support and take on the risk themselves?
Like other open source policies we asked about, many respondents are unsure if their organization requires commercial support for software components. A full 24% have no idea whether their organization mandates commercial support for any type of component used in a production environment.
When we look at companies with more than 50 employees, 29% have policies in place requiring commercial support for all software components, including those that are open source. An additional 18% have policies in place requiring commercial support for any components that are not open source. This means that almost one-half of organizations with more than 50 employees require some sort of commercial support option for the software they use.
This raises a question: Why the gap between commercial support of open source and proprietary components? Why would an organization that needs commercial support for software components exclude open source?
The likely answer is that it is because developers don’t have to go through a traditional procurement process to download freely available open source components, skipping their legal and procurement departments entirely by installing a package at the command line. Where procurement doesn’t have a mechanism to pay, they cannot limit usage.
Almost one-half of organizations with more than 50 employees require some sort of commercial support option for the software they use.
Is this OK? At some point, this lack of oversight might come back to haunt these organizations, as it has for companies like Equifax.
One other possible explanation is that these companies aren’t yet aware of any option that will give them support and assurances for the open source components that aren’t backed by large commercial open source vendors. Even if they have a checkbook in hand, they don’t know who to pay.
Fortunately, a managed open source strategy can help address this problem. With managed open source, an organization can pay one vendor to get enterprise-grade coverage for the vast array of open source packages they use, across common ecosystems like JavaScript, Python, Java, Ruby, and more. As more organizations that require support for their software understand the benefits of managed open source, hopefully, this “but who are we going to call when something breaks?” issue for all open source components finally becomes a thing of the past.
Want the full survey results in one report? Get them here now.
50 Milk St, 16th Floor, Boston, MA 02109
.svg){kind=icon}