Open Source Culture Starts with Programs and Policies
More than anything, open source programs are responsible for fostering “open source culture,” according to a survey The New Stack conducted with The Linux Foundation’s TODO Group. By creating an open source culture, companies with open source programs see the benefits we’ve previously reported, including increased speed and agility in the development cycle, better licence compliance and more awareness of which open source projects a company’s products depend on.
But what is open source culture, why is it important and how do we measure it? Based on survey data and reporting from this summer’s Open Source Summit, we believe open source programs support a corporate culture that prioritizes DevOps and microservices architecture, and enables developers to quickly use and participate in internal and external projects. It’s no longer sufficient to measure a company’s open source culture by counting what percentage of their technology stack is open source. Businesses interested in improved developer efficiency should examine their participation in open source projects and support a culture that nurtures code sharing and collaboration on externally maintained projects.
Defining Open Source Culture
Open source culture is more than just reusing free code on GitHub to get products to market faster. It is is an ethos that values sharing. The culture embraces an approach to software development that emphasizes internal and external collaboration, an increasing focus on core competencies instead of core infrastructure, and implementation of DevOps processes commonly associated with microservices and cloud native technologies.
Collaborating on community projects is a way of thinking associated with open source development. Software engineers that use externally created open source components need to collaborate with the people responsible for project maintenance. Usually, interaction is as simple as making sure software updates are integrated into new deployments, which can be solved with a continuous deployment pipeline that checks to ensure components are current and synched with the latest repositories and libraries. This is a good first step to get organizations comfortable with external dependencies, but two-way communication with other project maintainers is what truly denotes the type of collaboration that is essential to maximizing the benefits of open source culture.
Moving from an external to an internal mindset is what inner sourcing is all about. “Inner source” is an increasingly popular term to describe OSS development principles that are applied within an organization. According to GitHub, “Innersource is a development methodology where engineers build proprietary software using best practices from large-scale open source projects.” Many companies such as Capital One are using inner sourcing to increase collaboration and code sharing within their company, thus increasing developer efficiency and speeding innovation This includes making required development artifacts accessible to all employees leveraging the software. It also often encourages decisions based on egalitarian and meritocratic criteria.
Another key aspect of open source culture is that IT departments are less likely to think they are responsible for creating and maintaining the entire technology stack. When explaining why their organization is considering creating an open source program, a survey respondent wrote, “We no longer think that the right answer for a problem that isn’t key to our profitability is to write new code. Instead, we look for projects that are generally moving in the direction we want to go and try to adapt and pitch in.”
A willingness to use open source lets people focus on their core competencies and less on infrastructure, according to Dirk Hohndel, VMware’s chief open source officer. In an interview with The New Stack, Hohndel explained that companies like Capital One have decided their core product is software. In Capital One’s case, that means the corporate culture encourages values like speed and agility that are not always prioritized in the banking industry. Hohndel says that open source is already pervasive at companies like AWS and VMware. Both these behemoths, and companies without a technology focus, are increasingly using open source to “generate consensus at the edge instead of the core.”
Hohndel makes a jump and connects open source with several other major trends. He said, “Open source culture has supported the DevOps practices and microservice architecture that are required to make this cloud native infrastructure — based on open source — work.” As reported in “Open Source Programs are a Best Practice Among Large Companies,” a majority of companies with programs know that they have an impact on DevOps processes.
A connection between DevOps and open source was identified from survey data reported in DORA’s Accelerate: State of DevOps 2018: Strategies for a New Economy, which finds that the best performing organizations are 1.75 times more likely to extensively use open source. The report also shows the use of cloud native technologies, and CI/CD pipeline technologies is associated with high performance. Since all these practices often appear together, we think they as a whole indicate that an open source culture has taken root. As the next section explains, we believe the culture, and not the technology, improves performance.
Impact of Open Source Culture
According to our survey, the top three benefits of open source programs are 1) increased awareness of open source, 2) more speed and agility in the development cycle, and 3) better license compliance. Chris Aniszczyk, co-founder of the TODO Group and CTO of the Cloud Native Computing Foundation (CNCF) told The New Stack that there two types of open source programs, one that defines success around improved developer efficiency and the other justifying their existence based on reduced compliance risk.
Fifty-percent of survey respondents with open source programs in place say open source culture is how they measure their program’s success. Other measures of activity are used to gauge this culture shift. This article describes how you can determine if your company has a strong open source culture.
Aniszczyk said many long-standing programs justified their existence by how much risk and costs they could reduce. He explained that accidentally shipping a GPL or AGPL code, for example, can create a compliance issue where a company will consequently delay future product releases or even open source the entire project, thus losing intellectual property that might have been monetized.
Developer efficiency is where Aniszczyk sees open source programs really making a difference. He explains a common situation where a company like Facebook may want to contribute to an Apache project that is already used internally. Traditionally, if the company has forked the project, and wants to give back some of the changes, it has to go through an exhaustive legal process that can take weeks and even months. In the meantime, the project’s direction may have diverged, which means the development project gets out of sync and delayed.
Aniszczyk believes setting up an easy process for engineers to contribute upstream makes development faster and more sustainable. In addition, developers can become more efficient by open sourcing an existing project since this distributes the burden of maintaining a project across its users, freeing up internal time to focus on new features that can help the company, not just the project, thrive. Furthermore, research shows that organizations that contribute to the open source projects they consume can increase their ability to capture up to 100 percent more productive value from usage of open source than their free-riding competitors.
Look at Efficiency, Not Velocity
We now have to address a widely held misconception. Developer efficiency is not the same thing as developer velocity. Open source participation and DevOps processes do not automatically make the software development life cycle shorter, nor do they mean products will be released faster in the short term. Instead, developers’ efficiency increases as they become more productive by focusing on what’s important and allowing the open source community to maintain core infrastructure.
The aforementioned DORA report describes a common situation where adopting DevOps processes helps companies achieve immediate improvements in stability, but also causes a short-term drop in speed (see the J-curve of Transformation below). The phenomenon occurs because automation of the CI/CD pipeline often increases testing requirements, which are often dealt with manually. Put another way, many companies had not been applying best practices about using the latest open source dependencies, and to do things right requires increased manual work.
We saw a similar paradox when we asked how often an average application development team releases code into production. Our survey found that just having an open source program had no impact on developer speed. In fact, among open source programs, companies where a respondent said a top program benefit is increased speed and agility were much more likely to be slower, with 24 percent releasing code less than once a month as opposed to only six percent among the other companies.
The J-curve of transformation helps us understand that companies taking more than a month to release code are doing so because of newly instituted, manual processes that will eventually be automated. Another reason why some companies appear slower than others is that they are actually focused on metrics. In this context, ignorance is bliss. In fact, 33 percent of companies that say speed/agility is not a benefit answered “don’t know” when asked how long it takes between releases.
Companies with existing open source programs have about the same release frequency as those with no plans to create a program. Company size and industry vertical have a greater impact on developer velocity.
At first glance, it appears that companies are misinformed about the speed/agility benefits of open source management programs. Closer analysis indicates that many companies that prioritize velocity metrics are more likely to collect that data.
Policies Promote Culture
Many benefits of a vibrant open source culture are hard to measure in the short-term and closely correlate with the existence of DevOps processes and the use of cloud native technologies. To determine if an open source culture exists, it helps if specific activities occur and if there are policies governing the use of open source. We asked about both in our survey and found companies with an open source program were much more likely to contribute code upstream. We believe this is due at least in part to policies governing upstream contributions.
As can be seen in the chart below, companies with open source programs are much more likely to have policies about open source dependencies in products and lists of acceptable licenses. These policies are associated with the primary goal of reducing the risk involved with using open source. They are also more likely to have policies about releasing source code and contributing to external open source projects. These activities are more directly associated with the developer efficiency that can be attained by using open source. Even more so than actually maintaining your own project, allowing developers to work with others is the epitome of open source. The TODO Group maintains example policies and templates you can leverage to create your organization’s open source policy: https://github.com/todogroup/policies
Policies about upstream contributions exist at 65 percent of companies with an existing open source management program as opposed to only 11 percent at companies with no plans to create such a program.
Conclusion
A company’s values are manifested in their policies and actions. Actually having policies about contributing to open source projects means that senior management has accepted that benefiting from open source requires more than freeloading — it is about giving back.
Open source programs are instrumental to promoting a culture that makes companies more productive. Fostering “open source culture” is the primary purpose of open source programs. Measuring a program’s success is inherently difficult. Just like with corporate diversity initiatives, progress should initially be measured by the existence of policies and the implementation of DevOps processes strongly associated with open source culture. With these two outcomes, we expect companies will be able to reap the rewards of the open source mindset.
