Open-source software (OSS) has won over the tech industry, a reality dramatically demonstrated by Microsoft’s evolution. When open source first emerged as a trend in 1998, Microsoft responded with hostility. By 2018, the company had changed directions completely and acquired GitHub, the leading platform for developing open source software. If you can’t beat ‘em, join ‘em.

With 90% of enterprise IT leaders aligned with Microsoft in their adoption of open source, we are now firmly in the final phase of the diffusion of innovation, with only the “laggards” still holding out. But even among organizations that have adopted open source, there is a notable spectrum of maturity: from consuming, to producing, to embracing open source.

Companies that incorporate the open-source principles of collaboration and transparency into their business model and company culture will realize benefits in efficiency, hiring and retention, and trust within the marketplace. Those that do not will increasingly be left behind. Therefore, forward-looking executives should think strategically about their company’s position on the open source maturity spectrum, and plan for increased adoption.

Consuming

The first step in the enterprise open source journey is simply consuming open-source software inside your organization. The truth is that it is very hard not to consume OSS in some form or fashion these days, because so many of the most common development stacks are built on open-source tools. However, this brings certain risks that must be managed — primarily license compliance and information security. It is important for organizations consuming OSS to work with their legal and security teams to develop and implement policies for inventory and vetting of the open-source components in their supply chain. These are not one-time concerns; they must be continuously addressed. Companies such as Tidelift, WhiteSource, Black Duck, and Snyk offer products to help with this.

A transitional step for many companies beyond consuming OSS is innersource, which is the application of open-source methodologies within the enterprise perimeter, allowing different development teams to see and participate in what each other are doing. Using on-prem platforms such as GitHub Enterprise, GitLab, or Azure DevOps Server, companies can break down silos and realize some of the benefits of open-source development, including higher velocity due to reduced friction between teams, and higher quality due to wider review processes. This can represent a significant cultural change for an organization and represents a step on the way from consuming to producing true open-source software.

Producing

Much of the conversation about enterprise open source has been about the consumption of OSS in the enterprise, as reflected in the questions asked in Red Hat’s State of Enterprise Open Source Report. But Red Hat itself is an enterprise producer of OSS, not only a consumer. In fact, TODO Group reports that about half of companies that consume open source have taken this next step in some form.

Corporate production of open source generally unfolds in stages. Once a company becomes comfortable with open-source practices between its own internal engineering teams, it may allow its engineers to contribute patches to upstream open-source projects in its supply chain. This type of contribution is the lifeblood of flagship open-source projects such as Linux, which saw corporate code contributions approach 90% in the latest 5.10 kernel release. For many of these companies, such as Huawei, Intel, and Google, contributing to Linux represents a significant research and development investment, even though they may not be considered “open source companies” in the way that Red Hat would be.

Conceptually, the incentive to invest in upstream open-source projects is clear. Enterprises gain an ability to influence, if not outright control, the direction and growth of projects. As Heartbleed demonstrated, investing in OSS can mitigate the risk that security vulnerabilities or other code quality issues will degrade the utility of a project within a company’s own products. Furthermore, open-source participation can help to attract talent.

Beyond contributing to third-party projects, leading enterprises are consolidating the benefits of open source participation by publishing infrastructure projects of their own. Google is a clear example, with Kubernetes, Go, and Chromium gaining wide adoption. Facebook has a win with React. But there is a long tail of organizations — Airbnb, PayPal, Indeed, Comcast, Capital One, and many more — that publish open-source projects as a way to recruit talent and ensure they are building their core business on a solid base. If you do find yourself with an open-source project that is a runaway success, the natural progression would be to find a home for the project at a foundation such as Apache, CNCF, or the Linux Foundation.

Embracing

The most forward-thinking companies go beyond publishing their own open-source projects and embrace open-source principles more deeply. Contributing financially to projects is a logical extension of contributing engineering effort, yet this can introduce insurmountable process friction at many organizations. It requires strong executive leadership to understand and act to realize the long-term shareholder value that comes from ensuring the vitality of the software supply chain through direct financial contribution. More public conversation in the vein of Nadia Eghbal’s work is called for here.

Then there are corporations that not only publish shared infrastructure projects but also build their core business model directly on open-source products. COSS Media counts 17 such companies that have gone public since 1999, or 0.4% of the 4,509 total initial public offerings (IPOs) that have occurred during this time period. It will be interesting to see how many IPOs in the next 20 years are open-source companies. I anticipate there will be a significant increase.

At the most extreme end of the OSS spectrum, some companies are pushing open-source principles so far that they are becoming what we might call open companies. In these companies, all but the most sensitive processes and data (e.g., customer data and other legally protected information) are shared publicly. Mozilla is an interesting early example. GitLab has some open company tendencies but stops short of full openness. Startups such as Glimesh, Buffer, and Liberapay are pushing the envelope even further by hosting public staff meetings, publishing salaries, and even implementing “take-what-you-want” compensation. It will be interesting to see if in another 20 years’ time a handful of fully open companies have scaled to success.

Conclusion

Open-source software has proven its worth, but not all adoption is equal. If your company is consuming but not producing OSS, then consider the benefits of publishing projects of your own. Look at the many examples of successful open-source programs that exist today and build the capacity in your own organization to avoid falling behind, realizing risk, and losing talent. If your company already has a track record of publishing successful open-source projects, consider embracing open-source principles in other corporate functions. Build the case with leadership so they understand that the competition for customers and talent will be won by organizations that build trust through transparency.

Chad Whitacre is Senior Software Engineer of Open Source at Sentry.