Avoiding a Geopolitical Open Source Apocalypse
Is a bifurcation of open source communities looming on the horizon? I recently attended a CNCF: KubeCon + CloudNativeCon China Summit in Hong Kong, where Chinese speakers and presentations dominated. This is expected in Hong Kong, but perhaps most enlightening was the number of net-new open source projects being developed primarily out of China.
In recent years, China has increasingly become a center of gravity in the open source world. Chinese companies are also well-represented in major open source foundations such as OpenInfra and CNCF. Are we looking at a potential future rift in the open source world? Will there be an East and a West ecosystem that only touches occasionally? Or can we get past our differences for the common good?
China’s foray into open source might be marked by the advent of Red Flag Linux in 1999, but since then, there has been a proliferation of new open source projects from China. Chinese developers largely dominate these projects but seek to gain validation and create trust, usually by joining open source foundations.
As per a recent TechTarget (APAC) article, The rise and rise of open source in China, by Aaron Tan, “China has the second-largest number of developers on GitHub by country,” according to Stormy Peters, GitHub vice president of communities in her keynote at the event. China also now accounts for over 10% of foundation sponsorships. With Stormy Peters’ permission, I’m including a slide from her keynote to illustrate these points:
Will the West Adopt Chinese Software?
I don’t think any of this should come as a surprise. Like most countries, China wants to own its own destiny, hence creating its own Linux distributions and massive growth in homegrown open source projects. This seems positive for the open source world.
Certainly, you can’t begrudge the desire to become a primary mover and shaker in open source land. The West has dominated open source for a long time, and it’s only natural that Chinese companies feel more comfortable using software written primarily by Chinese developers.
But herein lies the problem: Given the current geopolitical climate, will Western companies be willing to adopt that same software? It’s hard to see a major U.S. financial institution migrating from RHEL to, say, Open Euler or OpenKylin. We already see a reasonable push to sideline hardware companies such as Huawei in the West.
It feels like a matter of time before pressure increases to use open source software that Western developers primarily develop. Simultaneously, Chinese institutions will likely favor homegrown open source projects over those originating from and dominated by the West.
While at the CNCF event mentioned above, one of my co-workers suggested partnering with an open source Database as a Service (DBaaS) project primarily developed in China. As I thought about the kinds of customers in our portfolio, I realized that it would be a hard sell to large financial institutions, government entities, telecom companies and the like.
When I looked at the customer list on the website for this DBaaS company, all of their listed clients were Chinese. Adoption by risk-sensitive Western companies of open source software written in the East and primarily used in the East is a hard sale. Perhaps there could be concerns about other countries, but this seems unlikely to be an issue given that they are not producing as much open source software, nor would they be considered as much of a national security risk as countries such as China and Russia.
Some think that open source software is generally more secure, but is it? Open source software mainly made in the West has well-documented security issues of its own, due in part to its heavy reliance on overworked and volunteer maintainers. Securing open source software requires time, energy and diligence. Unfortunately, many projects are very thinly resourced and lack the expertise required to look for security risks diligently.
More importantly, no open source software exists in a vacuum. Instead, there is a long “supply chain” of dependencies for any given piece of open source software, hence the advent of SBOMs (software bills of materials) to validate what other code is included when you adopt a given piece of software. However, this does not guarantee security.
Recently, what is most likely a state-sponsored actor infiltrated a backdoor into OpenSSH by attacking its software supply chain. The exploit, inserted into a dependency in some Linux distributions, was slowly introduced and then deliberately lobbied for inclusion in different distributions.
All of this is open source software, yet per the Substack article above, written by cybersecurity researcher and winner of the Lifetime Achievement Pwnie Award, Michał Zalewski, “we just witnessed one of the most daring infosec capers of my career.” Open source software is not inherently more secure just because the code is visible; in some ways, it might be more vulnerable to exploitation by bad actors. Validating and securing open source software on an ongoing basis will be a massive future challenge for everyone, both East and West.
Why We Need a Public Commons for Open Source
This is what sets us up for a potential Open Source Apocalypse: a splitting of open source into East versus West. Will each side of the divide trust the other side? Or are we looking at tribalism driving a bunker mentality, resulting in a significant schism in open source land? Open source has worked because it is a public commons. A schism would create two open source worlds, a divide where neither trusts the other, similar to what we see with the trade wars between the East and West today. This divide could slow innovation and adoption by either side of the best solutions available.
As a community, we must look beyond geopolitical conflicts and drive toward a public commons of trusted open source software, including its supply chain. A strategy of engagement between all stakeholders is mandatory. Creating shared interests and groups around securing software supply chains for all involved is critical, but it won’t be enough to rely on independent open source foundations alone.
Foundations can only do so much to bridge the divide. Today’s foundations don’t invest heavily in security, code analysis, or helping with software supply chain management. They act more as organizational and marketing entities, depending on their constituencies to enact technical measures. We need independent institutions similar to the ideas behind CVE (by MITRE corporation), whose mission is to help secure open source software and supply chains.
What might these institutions look like? First of all, they would need to have leadership from all geographies, a sort of United Nations of Open Source that equally represents all. Ideally, it would not be a “pay-to-play” situation, where those with greater financial means have greater say. These institutions would provide best practices for securing open source supply chains, mandating a specific codebase governance model to achieve security certification.
They would work with public and private institutions with code auditing and scanning capabilities that can be leveraged for any open source project. They may provide a way to authenticate and verify the identities of open source contributors such that there is a method for providing accountability for commits. Just providing best practices, free tooling and developer identity verification would go a long way to engendering trust in open source supply chains.
Right now, we manage codebase security on a project-by-project basis, and as long as that continues, we are all at risk. We must secure our open source software supply chains as a global community to avoid a future Open Source Apocalypse.
