Open-source software is fragmenting into walled gardens

The software commons that underpins much of the digital economy is undergoing a structural transformation that threatens its foundational premise. For decades, open-source development operated on an implicit bargain: volunteers and small contributors built shared infrastructure whilst large technology firms adopted the code, benefited commercially, and occasionally contributed improvements back upstream. That equilibrium is disintegrating.

Maintainers of foundational projects now face unsustainable workloads without corresponding compensation. The labour required to review contributions, address security vulnerabilities, manage dependencies, and coordinate releases has grown exponentially as open-source components have become embedded in critical infrastructure. Meanwhile, the assumption that corporate users would reciprocate through code contributions or financial support has proved increasingly hollow.

Large technology firms have responded to this tension not by shoring up the commons but by forking projects to suit commercial imperatives. When a maintainer changes a licence to require payment from large users, or when a project's direction conflicts with corporate strategy, the typical response is to create a controlled variant. The rhetoric of openness remains—source code stays visible, permissive licences are often preserved—but the collaborative practice erodes.

This fragmentation creates incompatible ecosystems where nominally open projects diverge in ways that make interoperability costly or impossible. A database management system might exist in half a dozen commercially backed variants, each with proprietary extensions, divergent roadmaps, and communities that no longer share improvements. The code is technically available, but the coordination that made open source powerful has fractured.

The economic incentives driving this shift are straightforward. Contributing improvements upstream means competitors benefit equally. Maintaining a controlled fork allows a firm to differentiate its offerings, lock in customers through proprietary features, and avoid the political complexities of community governance. The transaction costs of collaboration—negotiating with maintainers, adhering to project standards, accommodating diverse use cases—often exceed the perceived value of shared development.

Licensing changes intended to extract value from large users have accelerated the splintering rather than solving the sustainability problem. When a widely adopted project shifts from a permissive licence to one requiring payment above certain revenue thresholds, well-resourced firms typically fork the last permissive version and invest in maintaining their own variant. Smaller users and individual developers face a different calculus, often continuing with the new licence or migrating to whichever fork gains momentum. The result is a Balkanised landscape where the same logical project exists in multiple incompatible forms.

The sustainability crisis among maintainers is genuine and well-documented. Individuals who stewarded critical libraries for years without compensation have burned out, abandoned projects, or introduced breaking changes out of frustration. The psychological and practical burden of maintaining infrastructure used by billion-dollar enterprises whilst working unpaid in evenings and weekends has proved untenable for many. Corporate donations and sponsorship programmes have emerged but remain inconsistent and rarely match the value extracted.

Yet the corporate response—forking and control rather than funding the commons—reflects a deeper ambivalence about genuine collaboration. Open-source adoption was always driven more by cost reduction and avoiding vendor lock-in than by ideological commitment to shared development. When those instrumental benefits can be preserved through a controlled fork whilst eliminating the friction of community governance, the economic logic points clearly toward fragmentation.

The technical architecture of modern software development enables this splintering in ways that earlier generations of open source did not. Containerisation, cloud infrastructure, and automated tooling make it feasible to maintain a fork with relatively modest engineering investment. A firm can diverge from upstream, integrate proprietary components, and still market the result as open source because the code remains visible. The collaborative dimension—the hard work of coordinating contributions, resolving conflicts, and maintaining a shared roadmap—is quietly abandoned.

Some argue that fragmentation is a natural and even healthy evolution, allowing different use cases and business models to coexist. Markets will determine which forks succeed, and the best ideas will propagate across variants through imitation if not direct code sharing. Competition among forks might even accelerate innovation compared to the sometimes glacial pace of consensus-driven community projects.

This optimistic view underestimates the costs of incompatibility and the loss of network effects. Open-source software derived much of its power from the fact that improvements benefited everyone, creating a virtuous cycle where widespread adoption justified investment in quality and security. Fragmented variants dissipate that dynamic. Security patches may not propagate across forks. Expertise becomes balkanised. Developers must choose which ecosystem to support, and the choice increasingly depends on corporate backing rather than technical merit.

The infrastructure implications are particularly acute for organisations that depend on open-source components but lack the resources to evaluate and maintain forks. A small firm or public institution might find that the library it relies upon has splintered into three commercially controlled variants, none of which maintains full compatibility with the original. Migrating between them involves substantial engineering effort, yet staying with an under-resourced fork risks security vulnerabilities and stagnation.

Governance structures that might mediate these tensions remain underdeveloped. Foundations and consortia exist for some prominent projects, but they struggle to balance the interests of volunteer contributors, corporate sponsors, and user communities. Decision-making processes that work for small projects often collapse under the weight of competing commercial agendas when a project becomes critical infrastructure. The result is either paralysis or capture by the best-resourced stakeholders.

The regulatory environment has yet to grapple with these dynamics in any systematic way. Open-source software occupies an ambiguous position in policy frameworks designed around proprietary products and clear vendor relationships. Liability for defects, responsibility for security maintenance, and obligations to support critical infrastructure all become murky when software is nominally a commons but practically controlled by corporate forks. Policymakers have shown little appetite for intervening in what is perceived as a technical community matter, even as the infrastructure implications grow.

Some maintainers have experimented with alternative models that attempt to preserve collaboration whilst ensuring compensation. Dual licensing, where the code is open for non-commercial use but requires payment for commercial deployment, represents one approach. Contributor agreements that require firms to share improvements back upstream represent another. These mechanisms face their own challenges: enforcement is difficult, definitions of commercial use are contested, and the administrative overhead can exceed the capacity of small projects.

The cultural dimension of this shift is perhaps the most profound. Open source emerged from a tradition that valued transparency, meritocracy, and the belief that collaboration produced better software than secrecy. The migration toward controlled forks and proprietary extensions preserves the surface aesthetics of openness whilst hollowing out the substance. Code remains visible, but the collaborative ethos that distinguished open source from merely published source code is fading.

What remains unclear is whether this trajectory is reversible or represents a permanent transition in how digital infrastructure is built. The economic pressures are structural rather than cyclical: as software becomes more complex and more critical, the maintenance burden grows whilst the incentives for genuine collaboration weaken. Firms that once contributed upstream because they lacked the resources to maintain forks now find that forking is cheaper than navigating community governance.

The consequences extend beyond the software industry. Open-source components are embedded in everything from medical devices to financial systems to government services. A fragmented, commercially controlled landscape where compatibility and security depend on the strategic priorities of a handful of firms represents a form of infrastructure brittleness that is poorly understood and largely unaddressed. The resilience that came from a genuine commons—where many eyes reviewed code and many hands maintained it—is quietly being replaced by oligopolistic control dressed in the language of openness.

The central question is whether new institutional forms can emerge that reconcile sustainability with genuine collaboration, or whether the economics of software development inexorably push toward fragmentation. The answer will shape not only how code is written but how power is distributed in digital infrastructure, who bears the costs of maintenance, and whether the commons that built the internet can survive its own success.

This article was produced with AI assistance and reviewed against our editorial standards.