Chapter 10 The Commons and the Corporation (circa 2005-2010) (c. 2005)

“Our commitment to open source is a business strategy, not a philosophy.”
The words appeared in an interview with a senior vice president at Oracle Corporation, published in a trade magazine in the autumn of 2005. They were offered not as a confession, but as a point of clarity. The context was Oracle’s deepening engagement with the Linux kernel and its recent, quiet acquisitions of key open source database companies. The pressure was competitive and financial: the old world of expensive, proprietary Unix systems and the software that ran on them was eroding, undercut by commodity hardware and the operating system that had come to dominate it for free. To speak of philosophy here was, from the corporate vantage, a sentimental distraction. The statement was a boundary marker, drawn in the language of the boardroom. It framed the terrain of the next conflict. The wars over the infrastructure—the servers, the kernels, the protocols—were concluded. The victors had arrived to survey the field, and their concern was sovereignty over what grew upon it.

International Business Machines had drawn the first map. Its billion-dollar pledge to Linux in 2000 had been a seismic declaration of legitimacy, a corporate defection that reshaped the landscape. By 2005, that pledge was not a prediction but an operational reality. Hundreds of IBM engineers contributed code to the kernel, their labor paid from corporate profits, their workdays dedicated to improving this communal asset. Their patches passed through the same community mechanisms Linus Torvalds had built—the mailing lists, the version control, the hierarchy of maintainers. The code, by the terms of the GNU General Public License, was irrevocably returned to the commons. The kernel’s quality advanced; its support for enterprise-scale hardware deepened. This pattern replicated at Hewlett-Packard, at Intel, at Novell, at Oracle. Professional, salaried developers became some of the most prolific contributors to what had begun as a volunteer bazaar. The Apache Software Foundation, steward of the web’s dominant server software, found its projects fortified by full-time corporate contributors. This was the visible, material promise: corporate capital and communal genius aligned.

The commons would be enriched by the corporation’s wealth and discipline; the corporation would prosper by building upon a richer, more stable commons. Yet a grant of resources carries its own gravity, and gravity bends trajectories. The first subtle tension emerged not in public conflict, but in the quiet prioritization of problems. Who set the technical agenda for the Linux kernel? The answer remained, formally, with Torvalds and his network of trusted maintainers. But the agenda was increasingly shaped by the challenges faced by the largest deployers. Performance scaling for vast database clusters. Security hardening for global financial networks. Reliability features for telecommunications grids. These were substantial, worthy engineering problems. Their centrality, however, began to edge out other priorities—optimization for older or idiosyncratic hardware, refinement of the desktop user experience, exploration of novel architectures without a clear corporate patron. The bazaar still functioned, but its most well-stocked stalls were now corporate subsidiaries. The cathedral, in its old proprietary sense, had been dismantled.

A new order, however, was being inscribed within the bazaar’s apparent chaos, an order dictated by the economic mass of its most powerful participants. This gravitational pull manifested most concretely not in whispered influence, but in the deliberate, legal architecture of the license. Here, the corporation engaged with the commons not merely as a contributor, but as a strategist. And the strategy increasingly favored structures that built fences within the open field. Consider the trajectory of MySQL AB, the company behind the world’s most popular open source database. Released under the GNU GPL, a license that enforced reciprocal sharing, MySQL fueled a wildfire adoption from tiny web startups to massive internet properties. For a company selling support and consulting, this was an ideal engine. But as MySQL became crucial to the operations of large enterprises, a new demand arose: the desire to embed the database within a proprietary application without being forced to open that application’s own source code. The GPL forbade this. In response, MySQL AB crafted a dual-licensing model.

The software remained available under the strict GPL for those who would abide by its terms. For a fee, however, a company could purchase a commercial license that liberated it from the obligation to share. The codebase was identical; the freedom to use it diverged at the point of payment. This was not an abandonment of open source, but a sophisticated operationalization of its mechanics. The open source license became an unparalleled distribution and marketing tool. It seeded the software in every corner of the market, creating a massive user base and a de facto standard. The commercial license then harvested revenue from those users whose business models depended on circumventing the very freedoms that enabled that spread. The commons created the value; the corporation sold exemptions from the commons’s own rules. It was a brilliant, capitalist adaptation of the viral nature of the GPL itself—a use of the license’s strength to create a market for its bypass. The model proliferated under names like “open core.”

A foundational project would be developed as open source, often under a permissive license. This core would attract developers, build a community, and achieve widespread adoption. The additional features deemed essential for enterprise deployment—advanced management tools, proprietary connectors, security enhancements—would be kept closed, sold as a commercial product. The boundary between the open commons and the proprietary product was a business decision, mutable with each release. Features might migrate from the commercial tier to the open core to stimulate adoption, or new capabilities might be held back to maintain revenue streams. The community around the open core often served, knowingly or not, as a testbed and a talent pipeline for the commercial entity. They debugged the foundation; the company sold the finished house. This corporate calculus reached its starkest expression in the act of acquisition. The open source project itself became an asset to be purchased, its strategic value quantified. In 2005, Oracle Corporation, whose proprietary database software competed directly with MySQL, began a series of precise maneuvers.

It acquired Innobase Oy, the company that produced InnoDB, a critical storage engine at the heart of MySQL’s performance. Later, it acquired Sleepycat Software, makers of Berkeley DB, another embedded database used in numerous open source projects. Each acquisition was a quiet assertion of control over a piece of infrastructural plumbing. The message was unambiguous: the value of open source lay not only in using it, but in owning the entities that steered its development. The ultimate prize, MySQL AB itself, would fall to Sun Microsystems in 2008, and then into Oracle’s own hands when it consumed Sun in 2010. The cycle was complete: a project born in the commons, scaled by a hybrid commercial-open model, ended as an entry on the balance sheet of one of the world’s most proprietary software firms. The code remained open, but its roadmap was now set in a boardroom.

These parallel lines—the injection of resources and the subtle shift of governance, the dual-license and the corporate acquisition—formed the new geography of open source in the middle of the first decade of the twenty-first century. It was a landscape of profound and productive ambiguity. To argue that corporations had “stolen” or “perverted” open source was to ignore the tangible benefits they conferred: stability, scalability, and a passport into the heart of global enterprise. To argue that it was a harmonious partnership was to ignore a fundamental divergence in first principles. The community ethos, distilled from Richard Stallman’s crusade that began with a printer driver and the GNU Emacs project—an effort to replace a proprietary tool with a free one, line by line—held that software freedom was an end in itself, a moral good enabling learning, sharing, and autonomy. The corporate embrace treated software freedom as a means to other ends: cost reduction, accelerated innovation, market disruption, strategic leverage. These ends were not inherently malevolent. They could align perfectly with community goals for extended periods.

But when alignment frayed, the corporation held decisive levers: the paid developers, the legal ownership of trademarks and copyrights, the control over relicensing decisions, the capital to acquire. A single document from this period encapsulates the resulting duality. In 2006, Sun Microsystems, a company built on proprietary hardware and software, announced it would release the source code for its Java platform under the GNU General Public License. The announcement was heralded as a historic victory for open source. Java, a ubiquitous language for enterprise and web applications, would finally be libre. Yet Sun’s release was meticulously engineered. It involved not only the code but a “technology compatibility kit”—a suite of tests any implementation had to pass to bear the “Java” trademark. Control over that trademark and kit allowed Sun to maintain definitive authority over what constituted Java, even as the code was open for anyone to modify and redistribute. The community gained the right to inspect the engine and suggest improvements, but Sun retained the right to define the vehicle itself and its official specifications.

It was an open source release architected to preserve central control. This pattern repeated with Sun’s OpenOffice. org, an open source competitor to Microsoft Office. The code was released, a community formed, but Sun kept a firm hand on development priorities and brand management. The tension between corporate project managers and volunteer community contributors simmered in mailing list debates. The corporation saw a large, free development workforce and a strategic weapon against a rival. The community saw a chance to build a powerful, libre alternative for the world. Their labors could overlap, but their ultimate motivations—market victory versus software freedom—were not identical. The unease was structural, embedded in the very workflows designed for collaboration. The version control repository, once a simple record of changes, became an arena where commit rights signaled authority. Who had the power to merge code into the official branch? Was it a trusted volunteer who had contributed for years out of conviction, or a salaried corporate employee whose contributions were more numerous and systematic?

The mailing list, once a forum for pure technical debate, now hosted discussions laden with strategic implication. A proposal to alter an application programming interface could be debated on its technical merits, but it was also a business decision for companies whose products depended on that interface. The language of engineering often masked the silent calculus of capital. And so, by 2010, the idea of open source had been irrevocably entangled with the modern corporation. It had secured its place as the infrastructure of the digital world precisely by becoming indispensable to the corporate world. The methodology’s success in the enterprise arena had triggered the profound tension this chapter chronicles: between the creation of a public commons and the imperatives of private capital. The tension was not resolved; it was managed, negotiated daily in code reviews and licensing committee meetings. In their 2010 survey “Open source software: A survey from 10, 000 feet,” researchers Stephanos Androutsellis-Theotokis, Diomidis Spinellis, Maria Kechagia, and Georgios Gousios noted this transformation as an established reality.

This gravitational pull of corporate priorities extended beyond the kernel’s feature list and into its very development cadence. The Linux kernel release process, once a reflection of Linus Torvalds’s personal rhythm and the community’s organic pace, began to synchronize with the fiscal planning cycles of its largest industrial contributors. Major releases were increasingly expected to deliver specific, enterprise-grade features—enhanced virtualization support, improved filesystem performance for large-scale storage arrays—that aligned with product roadmaps for servers and cloud infrastructure. This was not a conspiracy but a convergence of practical necessity; the corporations funding the work logically needed outcomes by certain deadlines. The result was a professionalization of the bazaar’s timeline, transforming what was once a “release when ready” model into a more predictable, almost product-like schedule. This predictability itself was a boon for enterprise adoption, yet it further cemented the kernel’s identity as industrial-grade infrastructure, subtly distancing its development culture from the more experimental, hacker-centric rhythms that had characterized its earlier decades.

The institutionalization of influence found another expression in the rise of vendor-neutral foundations, which served as both buffers and conduits for corporate agendas. The Apache Software Foundation’s model of collaborative, consensus-based development under a permissive license proved exceptionally palatable to corporate participants. Companies like IBM and Google could contribute code to projects like Hadoop or HTTP Server without the reciprocal licensing constraints of the GPL, and could do so within a foundation structure that managed trademarks, resolved disputes, and provided legal shelter. This was not co-option in a hostile sense, but a sophisticated form of assimilation. The foundation’s governance—built on meritocracy and signed contributor agreements—formally equalized volunteer and corporate contributors. In practice, however, the sustained, funded effort of a corporate team often translated into greater influence over a project’s direction. A company could afford to dedicate engineers to not only writing code for a critical component, but also to shepherding that component through the foundation’s bureaucratic processes, serving on project management committees, and building consensus around technical visions that served broader corporate strategies. The community’s rules were followed scrupulously; they were simply mastered by those with the most resources to invest in the game.

This dynamic played out with particular clarity in the Eclipse Foundation, born from IBM’s donation of its Integrated Development Environment (IDE) codebase in 2001. By 2005-2006, Eclipse had become a hub for corporate open source collaboration around development tools, with members including Borland, Wind River, and Sybase. The foundation provided a shared platform that reduced costs for all by eliminating redundant investments in basic tooling. Yet this collaboration also created a form of soft standardization that benefited established players. The direction of the Eclipse platform naturally favored extensions and integrations that served the needs of large-scale, commercial software development—the very environment its member companies inhabited. Niche or academic interests, or tools designed for radically different programming paradigms, found less oxygen within this consortium. The foundation model thus became a powerful engine for open source development, but one that often steered the commons toward domains where corporate interests were already aligned, leaving other potential fields fallow.

Beneath these structural shifts lay a quieter, human tension: the changing relationship between the volunteer contributor and the paid professional within the same project. For the early community, contribution was an act of passion, identity, or intellectual curiosity—a direct expression of the “scratch your own itch” philosophy. The corporate employee contributing on company time operated under a different set of motivations: fulfilling assigned tasks, advancing career goals within the firm, and aligning with team objectives that ultimately served shareholder value. These motivations could produce superb code and genuine dedication to project health, but they were inherently instrumental. This created an implicit hierarchy within projects that formally celebrated meritocracy alone. A volunteer might submit a brilliant patch solving a personal frustration; a salaried developer from Red Hat or IBM would be tasked with implementing an entire subsystem over months, their contributions accumulating systematically to grant them deep institutional knowledge and inevitable influence. The community’s social capital began to blend with corporate professional capital, often to the latter’s advantage.

The psychological landscape for volunteers grew complex. Some found their hobbyist passion transformed into lucrative careers as companies sought out their expertise—a positive outcome by any measure. Others felt a gradual alienation as projects they loved became dominated by arcane debates over enterprise scalability or by commit logs dominated by corporate email addresses. The very language of collaboration evolved. Mailing list discussions were now peppered with references to internal ticket systems (“this aligns with JIRA PROD-102”), quarterly release goals, and performance metrics that made sense within a corporate context but felt foreign to an independent developer contributing from a home office. The culture was not corrupted so much as it became bifocal—one lens focused on the pure technical problem, the other on its business implication. For those wearing only one set of glasses, the conversation could seem partially obscured.

This corporatization of workflow reached its apotheosis in the systematic use of open source as a talent acquisition pipeline. Companies like Google and Facebook didn’t just contribute to existing projects; they created major new ones—Android, Chrome, React—and released them under open source licenses from their inception. This served multiple strategic goals: it accelerated external innovation around their platforms, built immense goodwill, and created a global showcase for their engineering philosophies. Crucially, it also functioned as a prolonged interview process. Developers who immersed themselves in these ecosystems, who built skills in Googley or Facebook-flavored technologies, were naturally primed for recruitment. The company’s technical vision became the industry’s standard practice; their open source code became the textbook from which a generation learned.

Open source was no longer a movement defined primarily by its opposition to proprietary software. It was the background condition, the default “how” of software development for corporations and communities alike. Its motivations, they observed, were now a complex amalgam: belief in philosophy, personal interest, caring about the community, and corporate strategy. The once-clear lines had blurred into a spectrum of engagement. The consequence of this entanglement was a kind of silent partition within shared space. In a single codebase, one could find modules written by a volunteer in Prague on weekends sitting adjacent to modules authored by a team at IBM’s Austin laboratory, all integrated by a maintainer who might be employed by Red Hat—a company whose entire business model was selling support for this free assemblage. The legal text of the LICENSE file at the root directory governed them all equally, but the reasons behind each commit told different stories. The commons and the corporation now cohabited the same digital territory, their outputs indistinguishable in function, their intentions layered like a palimpsest beneath the surface.

This coexistence was productive and stable, but it was not neutral. It established a new default: open source would grow through corporate subsidy and be shaped by corporate needs. It left the original moral crusade—the crusade that began with a withheld printer driver and the rage for accessible source code—as one voice among many in the polyphony, still audible but no longer conducting the orchestra. The infrastructure stood, and it was open. The tools to build upon it were freely available to all. Yet the power to decide what would be built next upon that common ground, and who would control the doors to those new structures, was quietly consolidating in hands that viewed openness as a strategy, not a creed. The stack had won by becoming invisible; now, those who understood its blueprints best were laying foundations for their own houses on that common land, houses with rooms they could lock at will.