Open Source, Innovation, and the Changing Rules of the Game
Summary
An overview of the forces shaping open source today — from licensing and governance to sustainability and competitive risk — and what they mean for organizations choosing to build, buy, borrow, or open source software.
Due to time constraints during the talk (whether caused by the countdown clock or by my long hiatus from public speaking!), I may not have been able to fully convey every aspect of this discussion, which this written version aims to capture more completely.
The Birth of Copyleft and the On-Premise Assumption
In the early days, software was free by default. This era drew to a close between the late ’70s and early ’80s. A symbolic turning point was Bill Gates’ famous “An Open Letter to Hobbyists” of January 31, 1976, which preceded changes to U.S. copyright law later that year.
The response to the new copyright regime came from Richard Stallman, who, in 1980, found himself unable to adapt the software of a Xerox 9700 printer due to newly imposed restrictions. This led him to launch the GNU Project in 1983, found the Free Software Foundation in 1985, and release the first version of the GPL in 1986. This was the birth of copyleft, the ideological opposite of copyright, and the parent of all “reciprocal” licenses that require modified versions of the code to be distributed under the same terms.
The GPL aimed to “hack” copyright, fostering a virtuous circle of shared improvements. Crucially, however, it assumed an on-premise world. With the rise of the cloud, a major vulnerability emerged: it became easy to exploit the GPL loophole, using GPL-licensed software to provide online services without ever distributing the modified code.
The License Wars and the Limit of Reciprocity
Over the years, a multitude of licenses emerged: permissive ones like BSD, MIT, and Apache posing minimal restrictions on how the software can be used, modified, and distributed; weaker copyleft licenses like MPL and LGPL, allowing the code to be combined with or linked to proprietary software without requiring the entire project to be Open Source; and stricter reciprocal licenses like the AGPL, introduced specifically to close the cloud loophole.
Their fortunes have varied dramatically. We witnessed MySQL monetize dual licensing, SugarCRM swiftly license its community edition under the AGPL, and vendors engineer “source-available” models to block cloud exploitation — episodes likely to vanish from history, like tears in the rain.
Before examining other non-functional aspects of Open Source software — such as governance models, intellectual property management, and how these factors, together with licensing, inform the decision-making process — we must first address a more fundamental question: which path should we choose when building software? Should we make our own, buy a proprietary solution, or adopt an existing open source artifact?
Not Invented Here: The Cost of Dependency
When designing a solution, teams face the classic Make or Buy decision. Open Source introduces a third option: Borrow. Respecting the license, teams can build something new by standing on the shoulders of established components and libraries—without reinventing the wheel. The benefit is directly proportional to the time saved versus the time required to master the borrowed component.
While writing a small function from scratch may be reasonable, the dependency cost often goes beyond the build-versus-master trade-off. Software is free until you start using it. From that point on, it becomes a crucial dependency and, as such, a recurring “cost.” This cost includes continuous updates, security patching, and application rebuilds.
When I was consulting to large companies back in 2009 I designed a methodology to assess free software sustainability, as when you procure it you need to make an effort to choose the one that has more probability to be maintained over time. Today, however, assessing a project’s sustainability has become remarkably straightforward: leveraging the analytical power of Large Language Models (LLMs), one can use properly formed prompts to instantly get answers to the typical questions that the methodology was designed to address. But there is more to that, as recently a spectre is haunting Europe: the EU Cyber Resilience Act (CRA), the European answer to software insecurity, places full responsibility on developers, even for free software not primarily monetized. This will certainly make it harder for new Open Source projects to be born organically, and may even cause existing ones to shut down to avoid compliance burdens.
Long story short: choose your open source dependencies carefully — measure twice, because once you commit, there is no second “try.”
The Father, the Son, and the Holy Ghost
For years, many mistakenly believed the license alone determined the “architecture of participation,” to borrow Tim O’Reilly’s well-known expression.
In reality, the project’s openness is defined by the holistic combination of Governance, Intellectual Property Management (IPR), and the License. Fundamental indicators include public access to the latest source code, the ability to contribute, and the freedom to create derivative projects.
Of course, all of the above — and likely more — should be carefully evaluated before any adoption decision. Even greater caution is required if you are considering open-sourcing your own software, as outlined below.
Cui Prodest? Open Source Clubs and Differentiating Tech
Academic discussion and empirical studies focus on motivations like gift culture or ideological alignment. Here, we focus on why organizations choose to release software under open licenses.
As Bruce Perens, architect of the Open Source Definition, articulated in his 2005 paper, successful open source strategy begins by clearly distinguishing between two categories of technology:
- Differentiating Technology: The core competitive advantage that makes your product uniquely compelling;
- Enabling (Non-Differentiating) Technology: The fundamental components necessary for operation but which do not confer a market advantage.
When the software is non-differentiating, Buchanan’s club theory applies: an Open Source project becomes a technological club where participants share costs, governance, and the common code.
Such clubs often gather under a foundation, which provides legal protection, governance structures, and predictable inclusion/exclusion rules that reduce risk.
Not all foundations operate the same way:
- The Linux Foundation uses a membership model where (costly) participation may grant governance privileges and often includes sponsoring key maintainers;
- The Apache Software Foundation accepts only individuals and is entirely volunteer-driven;
- Others exist in-between (e.g., MariaDB Foundation, WordPress Foundation).
The decision becomes far more complex when the software embodies a true breakthrough innovation. In such cases, releasing it as open source risks enabling competitors to benefit — and potentially to outperform the original innovator — especially those with stronger infrastructure, greater marketing reach, and established channels for cross-selling or up-selling from their existing portfolios.
Note that a technological club could also form under a single-vendor open source project, where a private company retains control of IP, branding, and governance. Contributions may be accepted but often require a Copyright License Assignment (CLA), enabling the company to relicense contributions at will.
The Innovation Engine and the Risk to the Commons
Why would any company Open Source its Differentiating Technology — code that helped it carve out a Blue Ocean?
The initial answer lies in the marketing flywheel: releasing innovative software under a permissive license can trigger explosive adoption, helping cross the infamous “chasm.”
However, rapid success brings a clear danger: the risk of competitors exploiting the very differentiating code that fueled the project. This is where the Single Vendor model becomes essential. It is extremely rare, if not impossible, to observe innovation happening collaboratively from day one. The examples of Kubernetes (Google), Chaos Monkey (Netflix), or even OpenStack (NASA and Rackspace) are exemplary: the initial idea, design, and development effort always start because of the desire of a specific entity, not the result of a collective club effort.
At some point, these Single Vendor innovators are targeted by hyperscalers, who, as Salvatore Sanfilippo has explained, can easily appropriate the majority of returns from the commons built by these third parties. The hyperscalers reuse the code, monetize it heavily, and in some cases even abuse the vendor’s trademark to promote their derived commercial offer.
When faced with this complex situation, vendors initiate what is often called the “rug pull”: they change their license, often making it sound Open Source while clearly being proprietary. This move alienates the user base and, critically, often opens the door to forks from third parties committed to maintaining an open version. The dynamics that drive this are clear: licenses are failing to protect the producers of innovation from the exploiters of the digital commons.
Faced with this imbalance, many producers respond by progressively closing their licenses in an attempt to safeguard their commercial interests. While understandable, this reaction risks undermining the very principles that enabled open collaboration in the first place — and, as the saying goes, two wrongs do not make a right.
Reply