Chapter 11 The Cloud and the Commons (circa 2007-2010) (c. 2007)

Back in 2007, the power to decide what would be built next upon the common ground of open source, and who would control the doors to those new structures, was quietly consolidating in hands that viewed openness as a strategy, not a creed. That spring, a post on a developer blog operated by a bookselling company declared: “Imagine you could stand up a complete LAMP stack—Linux, Apache, MySQL, and PHP/Perl/Python—in minutes, not weeks. Imagine you could scale it from one server to one hundred without ever talking to a procurement department. That world is here.” The announcement was for the general availability of Amazon Elastic Compute Cloud. It spoke not of freedom, but of frictionless deployment. It promised abstraction—the abstraction of hardware, of system administration, of scale itself. With a credit card and a few clicks, the collective work of thousands over decades became a consumable utility. The code was present, but sight of it was optional. The stack had become a service.

The cathedral’s stones now formed the unseen foundation of a new, proprietary edifice whose architects were not masons, but landlords. This shift marked the pivotal and paradoxical moment when the open source methodology, having conquered the server room, became the essential yet invisible substrate for a new commercial paradigm: the proprietary cloud. The rise of platform-as-a-service, epitomized by Amazon Web Services and Google App Engine, represented not a rejection of open source but its ultimate instrumentalization, divorcing the practical benefits of collaborative development from the ideological goal of user freedom. The collaborative bazaar had produced the world’s most robust, scalable, and cost-effective software for running the internet. This LAMP stack was the bedrock. Yet in being baked into an on-demand, pay-as-you-go utility, these projects underwent a profound transformation. They were divorced from their tangible form as inspectable code and re-presented as function, as output, as a black box. The practical benefits of the commons—reliability, rapid innovation, lack of single-vendor control—were delivered to the customer. The ideological goal of user freedom—the right to study, change, and redistribute—became irrelevant to the transaction.

One could consume the fruit of the orchard without ever walking among the trees, without knowing their names or the soil that sustained them. The mechanism began with a simple, powerful outcome: developers flocked to the cloud for convenience. The economic promise was seductive. Before 2006, launching a web application required capital—purchasing servers, configuring networks, securing data center space. It demanded systems expertise alongside coding skill. Amazon Web Services, emerging from the infrastructure built to handle its own retail spikes, offered a different model. Its first public service, Simple Storage Service, launched in March 2006, provided cheap, reliable storage via an API. Elastic Compute Cloud followed in beta that summer, offering resizable virtual servers. The pricing was revolutionary: pay by the hour for compute, by the gigabyte for storage. Fixed capital cost became variable operational expense. For a developer with an idea, the barrier to entry vanished. You could start with one small virtual server for cents an hour. Success meant adding a hundred more with a script, not a purchase order.

The inner workings of this revolution were built almost entirely upon open source software. An EC2 instance did not boot a proprietary operating system. It booted a Linux kernel. The default images were versions of Linux—Fedora, CentOS, Ubuntu—packaged with a standard suite of open source tools. The hypervisor technology was often Xen, an open source project. The management fabric, Amazon’s secret, relied on countless open source libraries and protocols. Apache powered the web servers; MySQL and PostgreSQL powered the databases; Memcached provided caching; the scripting languages Perl, Python, and PHP were all freely available. Google’s entry, App Engine, announced in April 2008, pushed abstraction further still. It offered no virtual machines, only a runtime for Python and Java. Developers wrote to Google’s APIs; Google handled everything else: deployment, scaling, load balancing, storage. The underlying infrastructure was a vast, global machine, opaque and unknowable, yet constructed from the same open source components that powered the public internet. This packaging generated immediate and divergent consequences for each party in the old triad of user, developer, and community.

For the cloud provider—Amazon, then Google, then Microsoft with Azure—the consequence was soaring corporate value and market dominance. They had discovered how to monetize the software commons at a layer above the code itself. They were not selling Linux or Apache; they were selling the reliability, scalability, and operational simplicity of a platform that used Linux and Apache. The value resided in the service level agreement, the global data centers, the management dashboard, the billing system. The open source components were raw materials, essential but low-margin. The proprietary service was the refined product, commanding premium prices. AWS transformed Amazon from a retailer into a technology conglomerate. Its astronomical growth was built upon a foundation it did not own but could freely use and modify. The licenses permitted this. The GPL for Linux, the Apache License for its namesake server, ensured freedom for the software, not for the service built upon it. A company could run modified versions of GPL-licensed code on its own servers indefinitely without releasing those modifications, provided it did not distribute the software itself.

AWS distributed nothing but electricity and API responses. For the developer, the consequence was a dramatic gain in productivity paired with a gradual loss of visibility and control. Early testimonials were hymns to liberation. Blog posts from 2008 and 2009 marveled at the simplicity. A solo developer could build and deploy a global application in an afternoon from a coffee shop. The chores of “racking and stacking,” of patching systems, of managing backups, were abstracted away. The developer’s mental horizon shrank from the entire systems stack to the single layer of their own application code. This was empowering. It was also insulating. The underlying stack became a mystery. When performance lagged, was it the code, the database configuration, the kernel’s network stack, or the hypervisor? Tools to investigate deep into the infrastructure were absent or required permissions the provider did not grant. Freedom from operational burden came at the cost of operational understanding. The developer traded root access for a management console. They traded the ability to tweak the MySQL source code for a dropdown menu to select “instance size.”

The commons lay buried under strata of proprietary automation. For the open source projects themselves—Linux, Apache, MySQL, PHP—the consequence was an ambiguous new role as invisible substrate. Their success was total. They were the default choice for the most dynamic sector of computing. Their contributor bases remained strong, their releases regular. Yet their relationship with their ultimate users grew distant and mediated. A generation of developers knew MySQL not as a database they compiled from source, but as “Amazon RDS,” a managed service where they selected a version from a list. They knew Apache as part of “Elastic Beanstalk,” an orchestration service. The projects thrived, but as commodities. Their identities blurred. The vibrant communities around them, the mailing list debates about features and bugs, continued unabated, yet these discussions now occurred in a realm disconnected from the experience of millions who relied on their output daily. The cloud acted as a buffer, absorbing complexity and delivering only function.

Ideological debates about copyleft versus permissive licensing, about user freedom versus developer convenience, seemed academic to a developer whose only interaction with the software was through a monthly bill from Seattle. This instrumentalization did not go unchallenged within the communities that had built the tools. The mailing lists and forums became arenas where the new reality was dissected with anxiety and anger. If the cloud was simply a more efficient way to run free software, some argued, it was a victory. More people than ever benefited from robust, low-cost software. If, however, the cloud was a way to strip the “free” from “free software” by denying users access to the modified versions running on the provider’s servers, it was a betrayal. The GNU General Public License, version 2, had a loophole. It required distribution of source code only when you distributed the software itself. Running software on your own servers for others to access—the “Application Service Provider” loophole—did not constitute distribution under the strict terms.

A company could host a modified Linux on ten thousand servers without releasing a single line of its changes. This perceived flaw ignited the last great licensing war of the free software movement. The Free Software Foundation began drafting version 3 of the GPL in 2006 explicitly to address this issue. One proposed provision sought to close the “ASP loophole” by requiring service providers to release source code for any modified GPL-licensed software used to provide public-facing services. The reaction was volcanic. Many corporate contributors and some community leaders saw it as overreach, an attempt to regulate a business model rather than protect software freedom. Linus Torvalds firmly rejected applying GPLv3 to Linux, keeping the kernel under GPLv2. He argued the license should govern code, not behavior. The drafters compromised. The final GPLv3, released in June 2007, did not contain a blanket “ASP clause.” Instead, it included a more limited requirement in section 13 addressing “remote network interaction,” but its language was complex and its applicability uncertain. Parallel to this, a new license was forged: the GNU Affero General Public License.

Initially developed by Affero Inc. In 2002 and later adopted by the FSF as AGPLv3 in 2007, it was GPLv3 with one critical addition: it explicitly required releasing source code if the software was used to provide services over a network. Designed as a weapon against the cloud’s abstraction, it stated that if you used AGPL-licensed software to power your web service, you had to give your users the code. For projects fearing “cloud-wash,” it offered a shield. Few major established projects adopted it; the cost of switching licenses and alienating corporate users was too high. But for new projects, it became a strategic choice. The debate laid bare the fundamental tension. The GPL was designed for a world where software was a thing you distributed. The cloud world was one where software was a service you accessed. The old licenses were maps of a fading continent. The polyphony of documents from this period reveals not consensus but a fraying alignment of interests. From the corporate strategy memo: An internal Amazon analysis from circa 2009 listed “lock-in” as a primary advantage.

It noted that while customers could theoretically move their virtual machine images elsewhere, deep integration with Amazon’s proprietary services—its unique storage, queuing, and management tools—created “significant migration friction.” The infrastructure was built on open standards, but the value layer was proprietary and sticky. From the developer’s blog post: “I don’t care if it’s open source,” wrote a startup CTO in a 2009 review of Google App Engine. “I care that it scales automatically and I don’t have to wake up at 3 a. m. When a server dies. My investors care about velocity, not ideology.” The post received hundreds of comments, some praising its pragmatism, others accusing the author of betraying the principles that made his stack possible. From the community mailing list: On a MySQL list in 2008, following news of Amazon’s booming RDS business, a long-time contributor wrote: “We do all the work. They make all the money. What is our incentive now? To be the free R&D department for AWS?” Another replied: “Our incentive is that our software is used by millions more people than ever before.

Is that not the point?”
From the license discussion forum: In a thread debating the AGPLv3 on a software freedom forum in early 2010, a participant argued: “The cloud is just another form of distribution. If you believe in freedom for users, you must ensure they have freedom in the cloud as they do on their desktop.” An opponent countered: “You cannot license a business model. You can only license code. This is an attempt to use copyright law to punish success, and it will only drive developers away.”
Each voice was correct within its own frame. The corporation saw efficiency and market opportunity. The developer saw productivity and reduced risk. The community loyalist saw exploitation and dilution. The license philosopher saw a new frontier requiring new legal instruments. They observed the same seismic shift from different elevations, and their diagnoses were irreconcilable. The shift was epistemological. It changed how software was known. In the early days of computing, particularly during the 1950s and 1960s, programmers and developers commonly shared software to learn from one another and advance the field.

This culture of transparency formed the ancestral soil for the movement, a legacy from the 1950s and 1960s when programmers commonly shared software to learn from one another. The cloud erected a new layer atop this culture. One could now use the outputs of that culture without participating in its practices of knowledge-sharing. You could benefit from collective intelligence without joining the collective. The cloud was the ultimate expression of open source as a production methodology, severed from its roots as a social movement.

Early systems such as Unix provided users with access to their source code, allowing them to understand and modify their tools. This culture of transparency formed the ancestral soil for the movement. The cloud erected a new layer atop this culture. One could now use the outputs of that culture without participating in its practices of knowledge-sharing. You could benefit from collective intelligence without joining the collective. The cloud was the ultimate expression of open source as a production methodology, severed from its roots as a social movement. This divergence had concrete architectural consequences. Application design changed to suit the cloud’s logic. Applications became “cloud-native,” designed for ephemeral servers, distributed stores, and proprietary platform services. They locked into APIs that existed only on one provider’s platform. The portability that open source once guaranteed—the ability to take your Linux system and run it anywhere—was sacrificed for the convenience of managed services. Freedom to leave was constrained not by software licenses but by architectural decisions and economic switching costs.

The commons provided the bricks, but the cloud providers designed blueprints for houses that could only stand on their land. The reckoning arrived through quiet, irreversible daily choices. Each time a team chose Amazon RDS over self-managing MySQL, each time they chose Google’s Datastore over designing their own schema, they voted for convenience over control. They accepted a narrower sphere of sovereignty in exchange for freedom from operational toil. This was often the rational business choice. The aggregate effect transferred profound power and knowledge upward to the platform providers. The paradox solidified: the most successful practical implementation of the open source philosophy now served as the engine for a system that made that philosophy seem optional. The infrastructure of the moral crusade had become so reliable and ubiquitous that it could be taken for granted. It could be hidden. Its success enabled its own obscurity. Between 2000 and 2002, Eric Raymond created Configuration Menu Language 2 (CML2), a source code configuration system; while originally intended for the Linux operating system, it was rejected by kernel developers. Raymond attributed this rejection to “kernel list politics,” but Linus Torvalds said in a 2007 mailing list post that as a matter of policy, the development team preferred more incremental changes. The tool was designed to bring order and clarity to a complex process, but the community chose its own messy, organic path. A decade later, that community’s output was being ordered and clarified not by internal tools but by external platforms that rendered its internal complexity invisible. The bazaar’s product was being repackaged and sold in cathedrals built by others.

The tool was designed to bring order and clarity to a complex process, but the community chose its own messy, organic path. A decade later, that community’s output was being ordered and clarified not by internal tools but by external platforms that rendered its internal complexity invisible. The bazaar’s product was being repackaged and sold in cathedrals built by others. By 2010, the pattern was set. The cloud was ascendant. Open source was its unshakeable foundation and its silent partner. The community’s work was everywhere and nowhere. The mailing list debates continued—fierce, detailed, passionate—but they echoed in a chamber increasingly separate from the mainstream of development happening in the abstracted layers above. One document stands as a monument to this ambiguous triumph. In 2010, as part of a series called The Britannica Guide to the World’s Most Influential People, Linus Torvalds was listed among The 100 Most Influential Inventors of All Time. He was honored for Linux, for his management of the global bazaar that built the kernel.

That same kernel was now booting millions of invisible virtual machines in Amazon’s data centers, generating billions in revenue for a company whose relationship to the free software ethos was purely transactional. Torvalds’s invention had escaped its creator’s intent and become part of the plumbing for a commercial empire. This was neither betrayal nor failure; it was the fate of a tool that worked too well. Once an idea begins to circulate, it no longer fully belongs to its originators. The concrete pressure point exposed by this abstraction was an ideological schism within the world that had built the tools. It was no longer merely “the community versus the corporation.” The corporation was now inside the community’s house, running its most successful utilities as a business. The new fracture lay between those within who saw this as ultimate validation—proof that open source could win on sheer utility—and those who saw it as final surrender—proof that utility alone would never guarantee freedom. This tension could not be resolved by a new license or a mailing-list debate.

It was a fault line through shared history and identity. The cloud had forced a choice about what “open source” was ultimately for. That choice, unresolved and simmering beneath every technical discussion about contributions and governance, would soon break into open conflict, fracturing old alliances and redrawing the map of the commons itself.