Open Source Programs Shift from Legal to Engineering Productivity Focus
Open source programs (also known as OSPOs) are now largely driven by engineering teams instead of attorneys — and created to refine engineering practices and attract developer talent rather than simply comply with licensing requirements, according to a new analysis of the open source survey conducted by The Linux Foundation’s TODO Group, VMware and The New Stack.
Open source license compliance has long served as a reason for companies to start formal open source programs. But that’s changing as automated tools such as the Linux Foundation’s OpenChain Project, Software Package Data Exchange (SPDX) and FOSSology improve code scanning and compliance, on top of modern commercial tools like FOSSA and Snyk.
The challenge, and opportunity, in open source management now lies in an organization’s ability to harness the open source culture that rewards code scrutiny through collaborative development practices. When done well, open source programs cultivate open source practices and lead to more resilient, innovative and differentiating architectures, improved code quality and security, and a faster time to market for products and services. These improvements, in turn, can help attract new developer talent.
Companies are now forming open source offices so they can add more developers to open source projects. This is true, most especially in the technology sector, which leads in open source office creation, as well as open source use and contribution. But the trend is being seen in other industry verticals as software development expands beyond the tech sector.
Executives across industries are realizing that it’s smart business and straightforward economics to contribute to the open source projects on which their commercial products depend. The open source community is a dispersed labor pool. This allows companies to quickly adopt modern software practices such as continuous delivery. There is now a deep appreciation for open source program offices’ importance in attracting developers who expressly are hired to work on open source projects.
Engineering Practices Improve with Open Source Programs
As the benefits of open source programs become evident, the creation of open source program offices is on the rise. And the job roles most closely involved in open source development and management have shifted from the legal department to engineering.
This is best demonstrated by a shift in the primary responsibilities of open source programs. Maintaining license compliance was the number two responsibility of open source program offices that respondents cited in our 2018 open source survey. It moved to number five in 2019 but represented the biggest drop, from 68% in 2018 to 58% of respondents in 2019.
The shift toward an engineering focus is also evident in how companies are defining success for their programs. Survey respondents are measuring success now primarily by the adoption or use of the open source projects companies are creating.
This shift in the focus of open source offices toward engineering practices is generating good results. More than 80% of respondents surveyed say their open source program has had a positive impact on their company’s software practices. License compliance is still the number one impact, with 9% of respondents seeing this benefit. But better code quality comes in at a close second (8%), followed by better time to market/ better agility and better security.
The companies that use and contribute upstream to open source projects are also more likely to deploy code more frequently. In our study, 39% of companies that frequently contribute to upstream projects are deploying at least daily, compared to 14% among those that never contribute.
As companies’ use of open source code in commercial products increases, so does the likelihood that they are deploying at least weekly. Companies that are deploying at least daily are likewise more likely to be frequently using code in commercial products — 61% as compared to 48% of everyone else.
Industries with Faster Deploy Times
Companies that deploy every day tend to use open source, contribute upstream and have more modern development practices. The largest of these companies have open source programs to manage and improve this process.
Cloud native architectures are defined by practices developed by software companies. In recent years, more companies in vertical markets have turned to cloud native architectures to develop their own at-scale software development, deployment and management practices. The practices that require cloud native architectures depend heavily upon open source technologies, showing how software development is now core to how any company views its business. Software is at the core of business, and open source is the foundation for how software is built.
In cloud native environments, increasingly companies are developing the same practices for open source as software industry leaders, and for the same reasons. No matter what vertical, the demand is for developers. Making developers happy hinges on a multitude of factors, but high on the list is the ability for them to use open source software. The dynamics that drive cloud native architectures are fueling the ongoing demand that companies have for dedicated open source program offices.
We’re coming to the point where it doesn’t matter what your industry vertical is. The practices will codify for software development. The best way to understand the evolution of open source programs is by studying the DevOps movement led by developers and the speed at which they’re developing applications. That’s led to deeper efficiencies and the evolution of cloud native technologies. Software companies have led the charge and now companies in other verticals are following. We’ll eventually get to the point where the software practices are the same across verticals. It will be the business perspective that differentiates them and makes the software teams more efficient and innovative.
The 22% of survey respondents that indicated they deploy hourly or daily also shared several firmographic characteristics. Notably, organizations with more than 10,000 employees (28%) and those associated with retail (46%) were more likely to deploy that frequently. Since large firms often have burdensome processes that can delay on-demand software delivery, they might not actually be doing continuous deployment, but that does not mean their development processes have not improved, especially in terms of the average development team deploying at least daily or even weekly. In fact, with their considerable resources, large enterprises are often early adopters of technology trends.
The “2019 Accelerate State of DevOps” report found that retail was the only industry that had a statistically significant improved outlook in software deployment metrics. We agree with the report’s assessment that competitive pressures have made it necessary to nimbly update customer-facing applications. Retail firms’ early embrace of A/B testing means that they are also likely among the leading users of feature flagging, which is a testing and release pattern commonly used by companies with the most mature DevOps practices.
The need for real-time software deployment also shows up among respondents in the defense industry, with 28% saying they deploy at least daily. Yet, only 6% of their average developer teams are deploying into production weekly. This indicates that for the most important national security systems, speed is valued, but at the same time risk aversion in the government may be slowing down developers.
The need to comply with regulation does not appear to significantly impact how quickly different industries deploy code into production. Manufacturing and raw materials are less regulated than most industries, but none of the survey’s respondents deploy hourly or daily. The degree to which an industry has been digitized may be a better explanation for differing deployment rates. Even if an oil company or a turbine manufacturer has embraced some information technologies, it may not need to have partly fast deployment cycles since its products are not delivered digitally.
More Perspective on Industry
Industry verticals have different patterns in which they have approached open source. Traditionally, regulated industries have been slower to adopt open source technology due to legal and security concerns. For most industries, legal obstacles appear to have been at least partly overcome by improved awareness and acceptance of open source licensing and compliance.
It is understandable that complying with regulations about patient data may make deploying software slower than average, and the chart above indicates that only 7% of healthcare companies are deploying hourly or daily. It makes less logical sense that the regulatory environment would affect decisions to use open source software, yet only 34% of respondents in the healthcare industry frequently use open source in commercial products as compared to the study average of 50%.
Generally speaking, companies that use open source code are also more likely to contribute to upstream projects. Software, IT, telecom and media companies lead in terms of both adoption and contribution to open source. Companies in these industries are also understandably more likely to have created an open program office or, at the very least, formal open source policies.
Risk aversion and competitive pressures explain variations in open source adoption and deployment speed among different industries. Simply saying that an industry is regulated should not mean that it is necessarily lagging in innovation and development speed.
Most experts agree that utilizing someone else’s code saves time, but maintenance and integration issues can evaporate some of those gains. Isolating open source usage or the presence of open source programs as the primary reasons or contributing factors for improved development speed is difficult, but that shouldn’t stop researchers from trying.
Likewise, DevOps, open source and cloud native best practices are so deeply intertwined that determining their independent effect on development speed, security and other benefits is challenging.
The 2020 version of our survey will strive to live up to these challenges. It will aim to quantify the degree to which open source improves overall code quality and development velocity. You are invited to weigh in on the next questionnaire.