Earlier this year, we launched our first professional open source survey. Our goal? To gain deeper perspective about what can be done to make open source—especially as it is used in professional settings—work better for everyone. We wanted to understand what professional users of open source look like and what matters to them. And we wanted to understand the needs, problems, and passions of those who create and maintain the software they use.
Our hope was that we could find some common ground, a win-win for both those who use and maintain open source software.
We received over 1,200 responses, and now we’re sharing our key findings and more details about our dataset. In our last post, we dove into the most important factors for companies evaluating open source libraries: maintenance, active community, and security. But we also saw the value of licensing assurances for enterprise companies, with over 24% ranking it as their most important factor in open source components. This begged the question: how exactly do companies evaluate their open source libraries today?
With open source being used in almost all professional applications, and with different development teams valuing different aspects of the software they use, we wanted to know how these teams actually decide which libraries to use. Do they have a process that the entire company employs? Or is it up to the individual developer, with little visibility and consistency across teams?
What we found was, by and large, companies lack processes—particularly formal processes—around how they evaluate or approve their open source dependencies. Two-thirds of respondents said they rely on the individual team, or even the individual developer, to vet open source packages for their application. Only 9% (!) of companies have a formal process for introducing new open source dependencies.
But what distinguishes the companies with formal processes for evaluating open source from those that rely on teams or individuals?
For starters, 49% of teams with a formal process for introducing new open source dependencies also reported that they currently pay for a commercial open source distribution. In fact, companies paying for open source support are almost three times as likely to have a formal process for introducing dependencies. Conversely, companies that don’t pay for open source support are much less likely to have a formal process for introducing dependencies.
Diving in a little deeper, we see that 47% of companies with a formal open source evaluation process have more than than 500 employees working in software development. This means big companies—or at least companies with big development teams—are over four times more likely to have a formal process for evaluating open source. This is pretty intuitive. As is the fact that larger teams seem particularly averse to individual developer decision-making regarding open source dependencies: only 2.7% of these larger teams have developer-level policies.
Lastly, what do these companies value in their open source? Those with formal processes are almost three times as likely to want to pay for licensing and IP assurances around their open source than those without processes.
So would companies actually be willing to pay for more dependable open source software? And if so, how much? We’ll dive into this in our next post! In the meantime, let us know if you’d like to receive updates, and follow us on Twitter.