The Great Enclosure: How Open Source Is Being Rewritten for the Cloud Era

In quiet conference rooms and cavernous datacenters across the globe, a transformation is overtaking the software world, one that’s upending decades-old business models, reframing the meaning of “openness,” and raising profound new challenges around sustainability, community, and power. The open source movement, long heralded as a bastion of collaboration and shared progress, is at a turning point. To understand where it might go next, it’s worth peering at the tectonic shifts playing out in real time, and the debates roiling the very people who’ve built the software that underpins today’s technology infrastructure.

The latest round of upheaval centers on what you might call the “great enclosure.” Many of the most influential open source projects, foundational tools like Redis, HashiCorp’s Terraform, MongoDB, Elasticsearch, and others, have in recent years abruptly changed their licenses. A wave of near-identical stories is traceable: brilliant engineers conjure a tool that solves a problem, release it under a “permissive” license (MIT, Apache, etc.), and win massive adoption. Then, after years of organic growth and ecosystem-building, something changes: major cloud providers, notably AWS, begin to offer hosted versions of those tools as paid services, often contributing little back to the original maintainers.

Feeling exploited, the creators make a radical decision, usually shifting to a “source available” license, such as the Business Source License (BSL) or Server Side Public License (SSPL), which allows users to read and modify the code for their own use, but crucially forbids competitors (especially SaaS giants) from offering hosted, monetized versions without a commercial agreement.

For many open source purists, this shift is heretical. Richard Stallman, the father of the Free Software movement, once called “open source” a weaker cousin to his vision of software freedom. Now, as companies draw up more restrictive licenses, some argue we’re witnessing the “open washing” of what was meant to be a profoundly democratic idea: the right to freely use, study, share, and improve code, for any purpose.

But the story isn’t so simple. The BSL and SSPL, for example, leave the code public and usable for most individual or organizational needs, but draw a line at direct competition via commercial hosting. For creators, these licenses aren’t betrayals so much as strategic necessities, a way to continue funding development, hire maintainers, and fend off what many see as predatory cloud tactics. As one HashiCorp executive explained, “We’re not against competition; we’re against unfair competition where our code is used to undermine our own sustainability.”

Much of the current debate, then, is about what kind of sustainability is possible, and desirable, for open source in 2024. The traditional model, in which companies gave away their crown jewel software and made money on “support contracts” or “enterprise features,” is increasingly squeezed. As cloud platforms aggregate value and abstract away the infrastructure layer, the risk of “strip mining” by hyperscalers grows. Without protective licenses or some form of monetization, many open source projects face a Sisyphean task: keeping up with bug fixes, security patches, and new features, without the revenue or recognition enjoyed by the platforms that package their work.

This new landscape encourages a search for creative forms of resilience. Some projects choose to double down on community, forming non-profit foundations that act as stewards and rulemakers, the Linux Foundation being the flagship example. Others experiment with dual licensing, offering strict open source for individual use and commercial terms for hosted or at-scale usage. Still others seek recurring community support via Patreon, Open Collective, or GitHub Sponsors, though for large infrastructure projects, this revenue is rarely enough.

Underlying it all are thorny questions about what we want open source to be. Is it a moral rubric, a guarantee that code will never become proprietary? Or is it, in practice, a set of pragmatic levers that founders can pull to survive in a market dominated by a few well-heeled platforms? Kevin Xu, author of the Interconnected newsletter, points out that “the tension between values and commerce isn’t new, it’s just been sharpened by the massive scale of cloud computing.” Stakeholders are now forced into choices that reveal their deepest priorities, and not always comfortably.

The fallout is deeply personal for many individual developers. When HashiCorp relicensed Terraform under the BSL, a passionate cohort of users forked the codebase, launching the “OpenTF” fork to “protect true open source values”, eventually succeeding in gaining foundation backing and significant community momentum. In parallel, other communities have accepted more limited openness, so long as development remains transparent and public-facing.

There are no easy answers. It’s clear, though, that both opportunity and risk abound. On the one hand, broader access to code remains a powerful democratizer, enabling startups, researchers, and even governments to build atop proven components and avoid costly reinvention. The great cloud platforms, for all their dominance, have spread open source software to every corner of the enterprise, and created enormous markets for anyone able to ride their wave.

On the risk side, the enclosure of formerly open tools can lead to fragmentation, as competing forks emerge and standards splinter. It can also chill experimentation, as would-be contributors wonder whether their efforts serve users or simply fatten up someone else’s profits. For all the passionate debate, it’s tough to see how any licensing regime will fully square the circle of open collaboration and long-term financial sustainability against a backdrop of relentless platform consolidation.

So what can be learned by technologists, founders, and users alike? At minimum, the era of naïve idealism about open source is over. Today’s project leaders must think tactically about how to fund and protect their work, while remaining as open as possible, a complex balancing act with no universal playbook. End-users must scrutinize what “open” means in practice (is this project truly community-driven? Could it be relicensed? Do I depend on a single company’s goodwill?). Policymakers ought to consider whether network effects and winner-take-all economics in the cloud create unlevel playing fields that drain innovation from the commons.

The open source movement, galvanized by its own contradictions, is reinventing itself for a new era, less utopian, perhaps, but still full of possibility. If the last decades were about seeding digital commons, the coming years will be about managing their stewardship, ensuring that the benefits of shared code flow as widely, and as sustainably, as possible. For all its turbulence, the open source world remains one of our most vital crucibles for invention. But, as always, its future depends not on declarations but on the choices, sometimes messy, often contested, of its communities and stewards.