Tidelift's annual managed open source survey explores how technologists use open source to build applications at work. Over 600 people shared 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 this post, we share the seventh of nine key findings. If you don’t wait to wait for the rest of the results, you can download the full survey report right now at the link below.
More and more organizations are taking a top-down approach to promoting open source, but for many developers, their first open source experiences take place outside of the workplace. They learn a new language by going through online tutorials or pursuing a hobby. Then, at some point they get an epiphany and realize they could apply this language to the programming they are doing at their day job.
What happens next is the subject of another question we asked in this year’s survey. We wanted to learn whether it’s common for organizations to have formal processes for introducing new open source components into their codebase. We had previously asked a question about this in our 2018 survey and were interested to learn whether organizations were maturing in their practices around managing open source.
We saw a jump from 2018 to 2020 in terms of the percentage of organizations that have a formal evaluation and approval process for introducing new open source dependencies. Only 10% of respondents in 2018 had a formal process, and the percentage nearly doubled to 17% in this year’s survey. In addition, the percentage of organizations with an informal process also increased slightly, going from 22% in 2018 to 26% this year.
On the other end of the spectrum, a smaller percentage of organizations (15%) allow each developer to decide on their own which components to use as compared to 23% in the 2018 survey.
So at the extremes, more organizations are introducing formal or informal processes for managing open source dependencies, while fewer organizations are allowing each developer to make their own decisions about bringing in new components.
Yet the most common process for introducing components is to make decisions at the team level. This response stayed consistent between the two surveys, with 43% in 2018 and 41% in this year’s study.
As one might expect, the largest companies are more likely to have some sort of organization-wide process—formal or informal—for managing their open source components. Sixty percent of organizations with 10,000 or more employees selected one of these two responses compared with 41% for organizations with less than 10,000 employees.
But zooming out for a second, it is still important to note that less than half of organizations (43%) have any organization-level evaluation and approval process—formal or informal. And over half (56%) of organizations are still making decisions at a team or individual developer level.
We are making progress, but it is slow. Why?
As we wrote about in a previous finding, one possible reason is that approval processes at larger organizations are often viewed as burdensome or bureaucratic. There is a strong link between these two findings as respondents who reported that their organizations required a formal approval process were much more likely to say that the process is unclear, confusing, or takes too long (50% for those with a formal process vs. 37% for the full sample).
Perhaps organizations fear putting more processes in place because they worry these processes might reduce risk and improve reliability—but force development velocity to take a hit. Which is where there is a huge opportunity for organizations to implement strategies that don’t force them to make a choice between these two extremes.
Want the full survey results in one report? Get them here now.
Read more about how we conducted the survey, see the survey demographics, and learn why we call it the managed open source survey.
50 Milk St, 16th Floor, Boston, MA 02109
.svg){kind=icon}