Our colleague has written an article. We’re sharing it here.
When the European Commission opened its consultation on Europe’s Open Digital Ecosystems Strategy, more than 1,600 responses came in. That’s an unusually large number. It reflects how broadly the question of digital infrastructure is now felt.
One idea – the digital commons – is featured prominently in the responses. With the launch of multiple Digital Commons European Digital Infrastructure Consortia across member states, this concept is likely to shape a great deal of what follows.
I think that’s a problem.
Say the word “commons” in a room full of people who work in digital infrastructure and two associations fire immediately.
The first is Creative Commons: open, shareable, free to use. The second is the tragedy of the commons: the classic story of a shared pasture grazed into ruin because no individual actor has enough incentive to hold back.
Both associations are instructive. The first tells you how people feel about open source software. The second tells you exactly what can go wrong with it.
What the metaphor doesn’t do is tell you anything accurate about who is actually in the room.
Open digital infrastructure is built and used by at least three very different types of actors.
The first group is community-driven projects – OpenStreetMap, OSGeo, Wikipedia, thousands of volunteer-maintained repositories. Commons governance actually fits here. Participants broadly share motivations. Reciprocity norms work. Funding often comes from grants and donations. This is where the metaphor was born.
The second group is commercial contributors, companies that build products and services on open-source foundations while also investing back into them. In the geospatial sector, companies contributing to QGIS, PostGIS, GDAL, and OpenLayers while running commercial operations sit here. These are not community actors. They have payroll, customers, and competitors.
The third group is the largest and least visible: organizations that depend on open digital infrastructure but participate in neither its governance nor its maintenance. Telecommunications providers, financial institutions, logistics platforms, AI developers, cloud infrastructure companies. They are not breaking any rules. Open source licenses explicitly allow this. But they exist entirely outside the systems that sustain what they use.
The commons frame sees community-driven projects clearly. It sees commercial contributors partially. It does not see other users of open digital infrastructure at all.
Open source policy discussions spend a lot of energy on free riding within the contributor ecosystem: supposed commercial contributors that benefit from shared infrastructure without investing in it. Some consultation responses propose procurement frameworks that reward upstream code contributions. The instinct is understandable.
But it addresses the smaller problem.
The majority of value extracted from open digital infrastructure happens well outside the open source industry. Research suggests that 70-90 percent of modern software contains open source components. Most of the organizations running that software are not part of any ecosystem that governs or maintains it.
Government procurement checks for code contributions reach a narrow slice of total economic activity. They leave the vastly larger dynamic completely untouched.
And here’s the part worth sitting with: all commercial actors extract value from open source, one way or another. Some monetize it directly. Others use it as an input to something they monetize elsewhere. The distinction between “contributor” and “free rider” doesn’t cleanly separate good actors from bad ones. It mainly separates visible actors from invisible ones.
Here is where the commons metaphor creates its most specific problem for commercial contributors.
When contributing companies are placed under the commons frame alongside community projects, they absorb an expectation that their competitors do not. The expectation is this: you are building for the benefit of humanity.
This is not a cynical or malicious expectation. Many people in open source genuinely hold it, and some of the best work in the field has been motivated by exactly this sentiment.
The problem is the asymmetry. A company that invests in maintaining shared infrastructure operates under community expectations – lower margins, mission-adjacent positioning, implicit obligations to the ecosystem. A company that simply consumes the same infrastructure operates under purely commercial expectations.
The contributing company and its non-contributing competitor use the same codebase. One of them is expected to act like a steward – and, implicitly, to price like one too. The other is just running a business. The result is a structural squeeze: contributing companies incur higher costs by investing in the ecosystem, then face pressure to charge less because they are perceived as part of it. Their competitors carry neither burden.
None of this means the commons framing is wrong about what it describes. Community governance, volunteer labor, reciprocity norms – these are real and they matter. The commons metaphor is accurate for community-driven projects and partially useful for understanding commercial contributors.
It’s an aspiration. What it cannot be is the basis for industry policy.
Commercial contributors to open ecosystems are for-profit companies. Their sustainability depends on delivering business value and making a profit. That means they need institutional structures outside the commons – groups that allow competitors to collaborate where necessary while still competing: industry associations, standards consortia, and yes, lobbying groups.
The large technology platforms Europe hopes to reduce its dependence on hold shareholder value as their reason to exist. The open source community has more values than that. But still you cannot build an industry without creating an environment where commercial actors make a profit. Industrial policy centered on the commons metaphor risks giving its own commercial actors a structural disadvantage from the start.
We’d love to hear your thoughts. Please share your ideas in the comments on the original LinkedIn post.
