Today the European Commission released the European Technological Sovereignty Package, a big push to reduce Europe's dependence on foreign technology.

Earlier this year, the Commission ran a public consultation, and I contributed two articles to it: the Software Sovereignty Scale and a follow-up, The Sovereignty Prerequisite.

So when the package was published today, I skimmed it right away. I was pleasantly surprised to find one of my articles cited in a footnote on page 18!

I won't pretend to have fully digested it yet, but one part immediately caught my attention: a new Open Source Strategy for Europe (Section 4 of the PDF, starting on page 16).

The highlights are significant:

• Around €2 billion over seven years to fund and maintain critical Open Source projects.
• "Public money, public code", so publicly funded software is released openly.
• Support for European foundations that can steward key Open Source projects.
• Open Source encouraged across research funding.
• An "Open Source"-first principle for public procurement.

One of the best parts of the strategy is that it treats Open Source as infrastructure that needs sustained investment, not as free software that magically maintains itself. I'll admit, that made me happy.

It is an argument Open Source advocates have made for years, and one I made in Funding Open Source like public infrastructure. The Commission now seems to agree, pointing to the lack of sustained funding, uncertain maintenance, and procurement barriers that hold Open Source back.

Just as important, the strategy reframes why Open Source matters. The old argument for Open Source was mostly about saving money. Here, Open Source is treated as a path to Europe's technological independence: software that Europe can inspect, maintain, and control. In other words, software that gives Europe "freedom of action".

None of this came out of nowhere. The story starts with the 2024 Draghi report, the Commission's landmark diagnosis of why Europe fell behind the United States and China. The Commission spent the next year turning that diagnosis into policy, and today's strategy is one of the results.

You can see how far the thinking has moved just by counting. In Draghi's 412 pages, "Open Source" appears twice. In the new plan, it appears nearly 300 times, in roughly a tenth of the space. It really shows that Open Source has moved from the margins of Europe's competitiveness debate into the center of its sovereignty strategy.

Still, it is worth being clear about what kind of document this is. This is not a law. It does not require companies to use Open Source or rewrite procurement rules across Europe. But it still matters. It moves Open Source from principle to policy: part of Europe's sovereignty agenda, backed by real funding, and a step toward stronger procurement rules.

The strategy notes that "the EU currently spends EUR 264 billion a year mostly on US proprietary IT products and services". That is not the Commission's budget; it is what the broader European economy spends each year on American software.

Set against that number, €2 billion over seven years for Open Source is a start, but a very small one. Seven years of Europe's Open Source budget is roughly three days of its annual American software bill. Europe has started to treat Open Source as sovereignty infrastructure, but it is not yet funding it like sovereignty infrastructure.

The strategy also stops one word short. In procurement, it tells public bodies to choose Open Source "first", not that they must. But "first" is only a preference. It is the kind of thing you talk yourself out of when the demo is shiny and the deadline is close.

For the systems a society cannot afford to lose, Open Source should not be preferred. It should be required. Europe is not there yet, but this is an excellent step in that direction.

European digital assets have a habit of not staying European – a problem current discussions about sovereignty are overlooking.

For example, Skype had Swedish and Danish founders, Estonian engineers, a Luxembourg headquarters, and proprietary code.

Every sovereignty credential was correct on the day it would have been assessed – and meaningless after eBay acquired it, Microsoft bought it, and eventually shut it down in 2025.

This speaks to a core tension at the heart of Europe's digital sovereignty moment. The real story has to do with licensing, dependencies, and supply chains more than it has to do with ownership or operational control – both of which can (and often do) change in Europe.

The current conception of cloud sovereignty asks the right questions about where data is stored, where companies are headquartered, and whether supply chains are European.

What they don't yet ask is whether the sovereignty they are assessing is durable and resilient – for example, whether it will survive a change of ownership, a corporate acquisition, or a disruption in the infrastructure the software depends on.

The European Commission's Cloud Sovereignty Framework provides a non-legislative assessment tool designed to evaluate the digital independence of cloud services in Europe.

It enables public authorities to rank services based on factors such as immunity from non-EU laws, operational control, and data protection.

The forthcoming Cloud and AI Development Act (CAIDA) – expected at the end of May – will possibly go further.

That said, while both are serious and welcome efforts, they are likely to solve only part of the problem.

'Buy European' is a fragile concept

Europe's 'Buy European' strategy is being built on two fragile foundations it hasn't yet explicitly addressed, and this could have disastrous implications in the cloud domain in particular.

Proprietary software with a perfect sovereignty score today is one acquisition away from a different answer tomorrow. Open Source software means the question doesn't arise.

The legal right to fork changes the power dynamic entirely: it gives you leverage, lets a community step in, and means the technology cannot be held hostage.

This is the distinction the Cloud Sovereignty Framework currently misses.

When Oracle acquired Sun Microsystems in 2010, governments running MySQL faced an immediate question: what happens to this software now?

The answer turned on one thing – the licence. Because MySQL was GPL-licensed, the right to fork and maintain it independently was already being exercised before the acquisition even completed.

MySQL's creator, Monty Widenius, forked it in 2009 precisely because he saw the acquisition coming – that fork exists today as MariaDB. The licence didn't prevent Oracle from buying Sun. It meant the acquisition couldn't end the software, and anyone paying attention could act on that right before any harm materialised.

Getting the licence right is necessary, but it is not sufficient.

In 2024, a conflict between WordPress co-founder Matt Mullenweg and WP Engine disrupted updates for millions of websites.

The code was Open Source. The delivery infrastructure had a single point of control. Most programming languages rely on a single central registry and most are controlled by US companies.

In 2019, GitHub restricted access for developers in sanctioned countries; since GitHub also owns npm, the JavaScript ecosystem's delivery infrastructure became subject to the same trade controls. These aren't interchangeable download sites you can swap out.

Sovereign software on fragile infrastructure is not sovereign. It is software waiting for a supply chain to break.

Both fragility problems point to the same conclusion: a 'Buy European' label is not a sovereignty guarantee unless it embraces licensing as a tool and helps to safeguard the supply chains the software depends on.

Consider two scenarios. A government running proprietary software on a European cloud has jurisdiction, but no exit if the provider is acquired – replacing the software could take years.

A government running Open Source software on Amazon Web Services (AWS) in Europe can move the same software to a European provider whenever it wants. Neither is ideal, but they are not equal.

Europe's sovereignty frameworks need to internalise this asymmetry. Structural sovereignty – the kind that survives change – requires open foundations that flow from licensing through the critical supply chains on which that software depends.

A call-to-action for the Cloud and AI Development Act

CAIDA should not make the same mistakes as the Cloud Sovereignty Framework. It would be a mistake to simply extend a 'Buy European' checklist. The legislation should instead define what makes sovereignty durable.

Two concrete steps would make an immediate difference.

First, it can make Open Source licensing a pass/fail gate for mission-critical procurement under the Cloud Sovereignty Framework – a condition of eligibility at the highest assurance levels, not a weighted factor in a composite score.

Second, it should require supply chain resilience assessments that distinguish between dependencies switchable in weeks and those that would take an entire language community years to replicate, with federated or mirrored European alternatives required where no fallback exists.

Yes, requiring Open Source for mission-critical systems narrows the field in the short term.

But the providers you lose are the ones whose sovereignty credentials don't survive change.

In the longer term, these requirements push European companies toward Open Source software – technology that no one can take away.

Procurement frameworks aren't the most exciting topic. But the European Commission is about to propose the Cloud and AI Development Act (CADA), and how it treats Open Source will affect every Open Source project and Open Source business operating in Europe. This is one of those moments where the details matter.

Last month, I proposed a Software Sovereignty Scale that grades software from A to E based on how easily your rights can be taken away. My core argument: if you want sovereignty that lasts, Open Source matters more than buying European proprietary software.

I submitted the Software Sovereignty Scale as feedback to the European Commission, recommending that Open Source carry more weight in the Cloud Sovereignty Framework, the tool EU institutions like the Commission and Parliament use to evaluate cloud providers when purchasing cloud services for their own operations.

The Cloud Sovereignty Framework only applies to how EU institutions buy their own cloud services. The Cloud and AI Development Act, which is expected to build on its approach, would set rules for the entire EU cloud market, across all 27 member states. The difference in scale is enormous, and the time to get this right is now.

My original recommendation was to give Open Source more weight in the Cloud Sovereignty Framework's scoring. I've since realized that isn't enough. Licensing shouldn't be in the sovereignty score at all. It should be a prerequisite.

Open Source is not a rounding error

The Cloud Sovereignty Framework evaluates providers across eight sovereignty objectives, each weighted into a composite score, as shown in the screenshot below. Contracting authorities use that score to rank and compare providers when selecting software and cloud services.

Technology Sovereignty (SOV-6), the objective that covers Open Source, accounts for 15% of the total. Within it, open licensing is one of four contributing factors. That means software being Open Source can contribute roughly 4% to a provider's final sovereignty score.

Does that feel right to you? The one thing that guarantees sovereignty long-term is worth ~4%.

A framework designed to measure sovereignty treats the one factor that makes sovereignty permanent as a rounding error. I could argue the percentage should be higher, or that Open Source supports other objectives, but even at 40%, licensing would still be in the wrong place.

Licensing is fundamentally different from every other objective in the framework. Skype checked every sovereignty box until eBay acquired it in 2005. Every credential was valid before the acquisition and meaningless after.

Had Skype been Open Source, no one could have taken the code away. You would still retain the right to use, modify, and fork it regardless of who acquired the company. That right is permanent, but a European headquarters is not.

That makes licensing a prerequisite, not something to average into a score. Scores compare trade-offs. Prerequisites define what is non-negotiable.

The gate already exists

Beyond the composite score, the framework defines Sovereign Effectiveness Assurance Levels, or SEAL levels. These range from SEAL-0 (no sovereignty at all) to SEAL-4 (full EU control with no critical non-EU dependencies).

For each of the eight sovereignty objectives, the contracting authority sets a minimum SEAL level. Any provider that falls below the minimum is rejected outright. These minimums work as pass/fail gates.

My proposal: licensing belongs in the gate, not in the score. Make Open Source a minimum requirement for the highest SEAL levels.

The Software Sovereignty Scale could map onto SEAL levels like this:

Under this proposal, mission-critical software with high switching costs would require a minimum of SEAL-3, making Open Source a requirement. For lower-risk procurement where the software is easy to replace, SEAL-2 would allow proprietary providers to compete.

Won't this exclude many proprietary providers? Yes, it would. But we have to be honest: proprietary software doesn't give you sovereignty that lasts.

I support the push to buy homegrown technology ("Buy European"). It keeps investment in Europe. But it doesn't solve the underlying problem.

Which government is sovereign?

Consider two scenarios. In the first, a government runs proprietary software on a sovereign European cloud. The provider gets acquired by a non-EU company, and the government can't migrate without replacing the software entirely. It has jurisdiction but ultimately no control. It's not very sovereign.

In the second, a government runs Open Source software on Amazon Web Services (AWS), a US-owned cloud provider with data centers in Europe. If AWS becomes a problem because of the CLOUD Act, policy changes, or geopolitics, the government can move the same software to a European cloud provider. Switching cloud providers can be hard, but switching software is much harder.

It may seem counterintuitive, but the second government is in a stronger position. Open Source on a non-European cloud gives you more sovereignty than proprietary software on a European one, because you can always change the infrastructure. You can't fix the licensing.

This doesn't make the second scenario risk-free. The ideal solution would be Open Source on a sovereign European cloud.

People overestimate jurisdiction and underestimate licensing. Licensing is not one sovereignty factor among many. It's the sovereignty prerequisite.

Special thanks to Tiffany Farriss and Sachiko Muto for their review of this blog post.

"Buy European" is becoming Europe's rallying cry for digital sovereignty. The logic is intuitive: if you want independence from American technology, buy from European companies instead.

However, I think "Buy European" gets one thing right and one thing wrong. It's right that Europe benefits from a stronger technology industry. But buying European does not guarantee sovereignty.

Sovereignty is not about where a company is headquartered or where software was originally written. It is about whether you retain "freedom of action" over the technology you depend on, even if the vendor changes strategy, gets acquired, or disappears.

The right question to ask about any technology: if conditions change, do you retain the freedom to keep using, modifying, and maintaining this software?

When evaluating sovereignty, it is not enough to ask how much control you have today. You also need to ask how much of that control is structurally protected, built into the legal and community foundations, so it can't be taken away tomorrow.

The proposed scale measures structural protection. It is not a ranking of openness, nor does it capture every dimension of sovereignty. The scale also does not imply that one license is always better than another.

I used five levels, modeled on Europe's familiar A-through-E labels for energy efficiency and food nutrition, from structurally sovereign to fully dependent. Frameworks like the European Commission's Cloud Sovereignty Framework do not yet make these structural distinctions. This scale aims to improve on what exists and is used today, and I expect it to improve further through scrutiny and feedback.

The most important distinction in the scale is between Open Source and proprietary. Grades A, B and C all require Open Source and give you freedom of action: the right to use, modify, and maintain the software independently, forever. The differences between A, B, and C reflect how structurally protected that freedom is against acquisition, relicensing, or a change in a project's strategic direction.

Jurisdictional obligations change with ownership

At the bottom, grade E, is foreign proprietary software: no source code, no right to modify, and no alternative if the vendor changes terms. Your vendor is subject to its home government's jurisdiction, and by extension, so is your data.

Grade D is European proprietary software, which is where "Buy European" usually comes in. It has real benefits: European jurisdiction, GDPR alignment, local accountability, and it keeps investment circulating in the European ecosystem. As someone who has started companies and invests in startups, I want more technology companies to succeed, not fewer. But "European" can be a temporary property of a company: it can change with a single board meeting.

Skype was founded by a Swede and a Dane, built by Estonian engineers, and headquartered in Luxembourg. eBay acquired it in 2005, and Microsoft acquired it in 2011. The eBay transaction turned a world-leading European technology into an American one, and it was cemented with the Microsoft deal.

So ownership and jurisdiction matter, but they're not enough. A European company can be acquired tomorrow. Open Source offers something more important: it separates the code from any single company or country.

Not all Open Source is equally sovereign

Open Source is what makes real sovereignty possible. At the same time, Open Source sovereignty exists on a spectrum. The level of protection comes down to two legal levers: the license itself, and the copyright ownership, which determines who has the power to change the license.

Grade C is Open Source under a permissive license like BSD, MIT, or Apache. You can view the code and fork it if needed, but the license does not require improvements to remain open. A company can take the code, build on it, and release a proprietary version.

The relicensing risk applies mainly to single-vendor projects. When a permissive project is hosted at a vendor-neutral foundation like Apache or Eclipse, the foundation holds the governance and the relicensing risk is minimized. The relicensing risk in grade C mainly comes from corporate control, not from the license itself.

Redis shows how this dynamic unfolds. It was Open Source under a BSD license for fifteen years. In March 2024, Redis Ltd. relicensed it under restrictive terms that the Open Source Initiative does not approve as Open Source.

Fortunately, the community forked the last open version as Valkey, and Valkey is thriving. That is the strength of permissive Open Source: you can escape when terms change. Governments were fortunate Redis was forked, but the structural risk remains, and in many cases end users are not so lucky. They are left maintaining the software themselves, which can be costly and unsustainable.

Grade B is Open Source under a copyleft license like the GPL. Copyleft adds a protection permissive licenses lack: any derivative of released code must also remain Open Source. For policymakers, this is a meaningful upgrade.

This is the level that saved MySQL. MySQL AB, the Swedish company behind the MySQL database, released it under the GPL. When Oracle acquired MySQL through the Sun Microsystems deal, the GPL ensured the code remained open. Michael Widenius, MySQL's original creator, took the code and built MariaDB, which he had to make available under the GPL.

And because MariaDB was forced to inherit MySQL's GPL license, it must remain open as well. This is sometimes referred to as the "viral" nature of the GPL. No future acquirer can make MariaDB proprietary. This is the difference between copyleft and a permissive license: copyleft lets someone fork and forces all forks to stay open.

But grade B still has one limitation. When copyright is concentrated, the holder can release future versions under a different license. The existing code is protected by the GPL, but the project's future direction depends on who holds the copyright and how they are governed.

Some projects amplify this risk by requiring contributors to sign a Contributor License Agreement, or CLA, which grants the project owner the right to relicense contributed code. Elasticsearch, founded in Amsterdam, used its CLA in 2021 to relicense from Apache 2.0 to a non-open-source license, despite having over 1,500 contributors.

Finally, grade A is copyleft Open Source with no relicensing risk. This typically happens when copyright is governed by a neutral foundation, or when hundreds or thousands of contributors each own their portion of the code. In that case, relicensing would require consent from every contributor, and any refusal would force the project to rewrite that code from scratch. The more distributed the ownership, the harder relicensing becomes.

Drupal has had contributions from tens of thousands of people across 25 years, which makes relicensing structurally impossible. No acquisition, no board vote, no change in strategy can take these projects away from the people who build and depend on them. Drupal's code is structurally sovereign by design.

Of course, copyleft projects with fewer independent contributors and less history could be easier to relicense. There are simply fewer people whose consent would be required to change the license.

Sovereignty is a long-term commitment

Moving from E to D is progress. Moving from D to C is what really matters. Above C, the scale highlights smaller but still important tradeoffs, so when governments choose a lower grade, they do so knowingly rather than unknowingly.

An Open Source project that loses important funding often needs investment to remain viable. But unlike acquisition or relicensing, funding risk is largely within the EU's control through government procurement and public investment.

Recommendation for the European Commission

Sovereignty involves many things: data location, supply chains, technical talent, and standards. Licensing and copyright form the structural foundation because they determine whether legal independence is even possible.

The European Commission's Cloud Sovereignty Framework reflects this broader view. It evaluates cloud software across eight sovereignty objectives, each scored and weighted into a composite sovereignty score. Technology Sovereignty (SOV-6), the objective that covers open licensing, accounts for 15% of that composite. Within it, open licensing is one contributing factor among four, alongside open standards, architectural transparency, and EU computing independence.

This dramatically underweights what matters most: Open Source. Open standards, transparency, and computing independence are capabilities that proprietary software can also provide. They can change if a vendor is acquired or shifts strategy.

Open licensing creates permanent, irrevocable rights to use and modify the software regardless of what happens to the vendor. It is the only contributing factor within Technology Sovereignty (SOV-6) that makes sovereignty structural rather than situational, yet the framework does not distinguish it from the others. Nor does it recognize that open licensing underpins the other sovereignty objectives: operational independence, supply chain resilience, and jurisdictional flexibility all depend on whether you have the right to move, modify, and maintain the software. I would encourage the Commission to strengthen its Technology Sovereignty objective in three ways:

1. Give open licensing significantly more weight in the sovereignty score. Open licensing is not comparable to the other three contributing factors in Technology Sovereignty. It is the only one that creates permanent, irrevocable rights. The framework should reflect that.

2. Distinguish between license types. Permissive licenses (BSD, MIT, Apache) place no obligation on derivatives to remain open. Copyleft licenses (GPL, AGPL) require derivative works to be released under the same open terms.

3. Assess copyright concentration and relicensing risk. Not all projects carry equal risk of relicensing. A project controlled by a single company can be relicensed. A project with distributed copyright ownership, or one governed by a vendor-neutral foundation, is far more resistant to relicensing. This is the difference between a revocable and an irrevocable commitment to openness.

Open licensing is not one consideration among many. It is the foundation that makes all other sovereignty objectives durable. I think European procurement policy should weight it accordingly. The Software Sovereignty Scale can help: when a government selects a content management system for its public websites or a database for its national health records, it should know the structural sovereignty grade of the technology it depends on.

For critical software, the question is simple: how easy is it for someone to take the software away from us?

Special thanks to Sachiko Muto and Bert Boerland for their review and contributions to this blog post.

As global tensions rise, governments are waking up to the fact that they've lost digital sovereignty. They depend on foreign companies that can change terms, cut off access, or be weaponized against them. A decision in Washington can disable services in Brussels overnight.

Last year, the International Criminal Court ditched Microsoft 365 after a dispute over access to the chief prosecutor's email. Denmark's Ministry of Digitalisation is moving to LibreOffice. And Germany's state of Schleswig-Holstein is migrating 30,000 workstations off Microsoft.

Reclaiming digital sovereignty doesn't require building the European equivalent of Microsoft or Google. That approach hasn't worked in the past, and there is no time to make it work now. Fortunately, Europe has something else: some of the world's strongest Open Source communities, regulatory reach, and public sector scale.

Open Source is the most credible path to digital sovereignty. It's the only software you can run without permission. You can audit, host, modify, and migrate it yourself. No vendor, no government, and no sanctions regime can ever take it away.

Though as I discuss in The Software Sovereignty Scale, some Open Source licenses offer stronger structural guarantees than others.

But there is a catch. When governments buy Open Source services, the money rarely reaches the people who actually build and maintain it. Procurement rules favor large system integrators, not the maintainers of the software itself. As a result, public money flows to companies that package and resell Open Source, not to the ones who do the hard work of writing and sustaining it.

I've watched this pattern repeat for over two decades in Drupal, the Open Source project I started and that is now widely used across European governments.

A small web agency spends months building a new feature. They design it, implement it, and shepherd it through review until it's merged. Then the government puts out a tender for a new website, and that feature is a critical requirement. A much larger company, with no involvement in Drupal, submits a polished proposal. They have the references, the sales team, and the compliance certifications. They win the contract. The feature exists because the small agency built it. But apart from new maintenance obligations, the original authors get nothing in return.

Public money flows around Open Source instead of into it. Multiply that by every Open Source project in Europe's software stack, and you start to see both the scale of the problem and the scale of the opportunity. Open Source is public infrastructure but we don't fund it that way.

This is the pattern we need to break. Governments should be contracting with Open Source maintainers, not middlemen.

Public money flows around Open Source instead of into it. Governments should contract with Open Source maintainers and builders, not middlemen who merely resell it.

Skipping the maintainers is not just unfair, it is bad governance. Vendors who do not contribute upstream can still deliver projects, but they are much less effective at fixing problems at the source or shaping the software's future. You end up spending public money on short-term integration, while underinvesting in the long-term quality, security, and resilience of the software you depend on.

If Europe wants digital sovereignty and real innovation, procurement must invest in upstream maintainers where security, resilience, and new capabilities are actually built.

The fix is straightforward: make contribution count in procurement scoring. When evaluating vendors, ask what they put back into the Open Source projects they are selling. Code, documentation, security fixes, funding.

Of course, all vendors will claim they contribute. I've seen companies claim credit for work they barely touched, or count contributions from employees who left years ago.

So how does a procurement officer tell who is real? By letting Open Source projects vouch for contributors directly. Projects know who does the work.

We built Drupal's credit system to solve for exactly this. It's not perfect, but it's transparent. And transparency is hard to fake.

We use the credit system to maintain a public directory of companies that provide Drupal services, ranked by their contributions. It shows, at a glance, which companies actually help build and maintain Drupal.

If a vendor isn't on that list, they're likely not contributing in any meaningful way. For a procurement officer, this turns a hard judgment call into a simple check: you can see who builds Drupal. This is what contribution-based procurement looks like in practice.

Fortunately, the momentum is building. APELL, an association of European Open Source companies, has proposed making contribution a procurement criterion. EuroStack, a coalition of 260+ companies, is lobbying for a "Buy Open Source Act". The European Commission has embraced an Open Source roadmap with procurement recommendations.

Europe does not need to build the next hyperscaler. It needs to shift procurement toward Open Source builders and maintainers. If Europe gets this right, it will mean better software, stronger local vendors, and public money that actually builds public code. Not to mention the autonomy that comes with it.

I submitted this post as feedback to the European Commission's call for evidence on Towards European Open Digital Ecosystems. If you work in Open Source, consider adding your voice. The feedback period ends February 3, 2026.

Special thanks to Taco Potze, Sachiko Muto, and Gábor Hojtsy for their review and contributions to this blog post.

Fifteen years ago, I laid out a theory about the future of Open Source. In The Commercialization of a Volunteer-Driven Open Source Project, I argued that if Open Source was going to thrive, people had to get paid to work on it. At the time, the idea was controversial. Many feared money would corrupt the spirit of volunteerism and change the nature of Open Source contribution.

In that same post, I actually went beyond discussing the case for commercial sponsorship and outlined a broader pattern I believed Open Source would follow. I suggested it would develop in three stages: (1) starting with volunteers, then (2) expanding to include commercial involvement and sponsorship, and finally (3) gaining government support.

I based this on how other public goods and public infrastructure have evolved. Trade routes, for example, began as volunteer-built paths, were improved for commerce by private companies, and later became government-run. The same pattern shaped schools, national defense, and many other public services. What begins as a volunteer effort often ends up being maintained by governments for the benefit of society. I suggested that Open Source would and should follow the same three-phase path.

Over the past fifteen years, paying people to maintain Open Source has shifted from controversial to widely accepted. Platforms like Open Collective, an organization I invested in as an angel investor in 2015, have helped make this possible by giving Open Source communities an easy way to receive and manage funding transparently.

Today, Open Source runs much of the world's critical infrastructure. It powers government services, supports national security, and enables everything from public health systems to elections. This reliance means the third and final step in its evolution is here: governments must help fund Open Source.

Public funding would complement the role of volunteers and commercial sponsors, not replace them. This is not charity or a waste of tax money. It is an investment in the software that runs our essential services. Without it, we leave critical infrastructure fragile at the moment the world needs it most.

The $8.8 trillion dependency

A 2024 Harvard Business School study, The Value of Open Source Software, estimates that replacing the most widely used Open Source software would cost the world $8.8 trillion. If Open Source suddenly disappeared, organizations would have to spend 3.5 times more on software than they do today. Even more striking: 96% of that $8.8 trillion depends on just 5% of contributors.

This concentration creates fragility. Most of our digital infrastructure depends on a small group of maintainers who often lack stable funding or long-term support. When they burn out or step away, critical systems can be at risk.

Maintaining Open Source is not free. It takes developers to fix bugs, maintainers to coordinate releases, security teams to patch vulnerabilities, and usability experts to keep the software accessible. Without reliable funding, these essential tasks are difficult to sustain, leaving the foundations of our digital society exposed to risk.

Addressing this risk means rethinking not just funding, but also governance, succession planning, and how we support the people and projects that keep our society running.

When digital sovereignty becomes survival

Recent geopolitical tensions and policy unpredictability have made governments more aware of the risks of relying on foreign-controlled, proprietary software. Around the world, there is growing recognition that they cannot afford to lose control over their digital infrastructure.

Denmark recently announced a national plan to reduce their dependency on proprietary software by adopting Open Source tools across its public sector.

This reflects a simple reality: when critical public services depend on foreign-controlled software, governments lose the ability to guarantee continuity and security to their citizens. They become vulnerable to policy changes and geopolitical pressures beyond their control.

As Denmark's Ministry for Digitalisation explained, this shift is about control, accountability, and resilience, not just cost savings. Other European cities and countries are developing similar strategies. This is no longer just an IT decision, but a strategic necessity for protecting national security and guaranteeing the continuity of essential public services.

From Open Source consumption to contribution

Most government institutions rely heavily on Open Source but contribute little in return. Sponsorship usually flows through vendor contracts, and while some vendors contribute upstream, the overall level of support is small compared to how much these institutions depend on said projects.

Procurement practices often make the problem worse. Contracts are typically awarded to the lowest bidder or to large, well-known IT vendors rather than those with deep Open Source expertise and a track record of contributing back. Companies that help maintain Open Source projects are often undercut by firms that give nothing in return. This creates a race to the bottom that ultimately weakens the Open Source projects governments rely on.

As I discussed in Balancing makers and takers to scale and sustain Open Source, sustainable Open Source requires addressing the fundamental mismatch between use and contribution.

Governments need to shift from Open Source consumption to Open Source contribution. The digital infrastructure that powers government services demands the same investment commitment as the roads and bridges that connect our communities.

Drupal tells the story

I have helped lead Drupal for almost 25 years, and in that time I have seen how deeply governments depend on Open Source.

The European Commission runs more than a hundred Drupal sites, France operates over a thousand Drupal sites, and Australia's government has standardized on Drupal as its national digital platform. Yet despite this widespread use, most of these institutions contribute little back to Drupal's development or maintenance.

This is not just a Drupal problem, and it is entirely within the rights of Open Source users. There is no requirement to contribute. But in many projects, a small group of maintainers and a few companies carry the burden for infrastructure that millions rely on. Without broader support, this imbalance risks the stability of the very systems governments depend on.

Many public institutions use Open Source without contributing to its upkeep. While this is legal, it shifts all maintenance costs onto a small group of contributors. Over time, that risks the services those institutions depend on. Better procurement and policy choices could help turn more public institutions into active contributors.

The rise of government stewardship

I am certainly not the only one calling for government involvement in Open Source infrastructure. In recent years, national governments and intergovernmental bodies, including the United Nations, have begun increasing investment in Open Source.

In 2020, the UN Secretary General's Roadmap for Digital Cooperation called for global investment in "digital public goods" such as Open Source software to help achieve the Sustainable Development Goals. Five years later, the UN introduced the UN Open Source Principles, encouraging practices like "open by default" and "contributing back".

At the European level, the EU's Cyber Resilience Act recognizes Open Source software stewards as "economic actors", acknowledging their role in keeping infrastructure secure and reliable. In Germany, the Sovereign Tech Agency has invested €26 million in more than 60 Open Source projects that support critical digital infrastructure.

Governments and public institutions are also creating Open Source Program Offices (OSPOs) to coordinate policy, encourage contributions, and ensure long-term sustainability. In Europe, the European Commission's EC OSPO operates the code.europa.eu platform for cross-border collaboration. In the United States, agencies such as the Centers for Medicare & Medicaid Services, the United States Digital Service, the Cybersecurity and Infrastructure Security Agency, and the U.S. Digital Corps play similar roles. In Latin America, Brazil's Free Software Portal supports collaboration across governments.

These efforts signal a shift from simply using Open Source to actively stewarding and investing in it at the institutional level.

The math borders on absurd

If the top 100 countries each contributed $200,000 a year to an Open Source project, the project would have a twenty million dollar annual budget. That is about what it costs to maintain less than ten miles of highway.

In my home country, Belgium, which has just over ten million people, more than one billion euros is spent each year maintaining roads. A small fraction of that could help secure the future of Open Source software like Drupal, which supports public services for millions of Belgians.

For the cost of maintaining 10 miles of highway, we could secure the future of several critical Open Source projects that power essential public services. The math borders on absurd.

How governments can help

Just as governments maintain roads, bridges and utilities that society depends on, they should also help sustain the Open Source projects that power essential services, digitally and otherwise. The scale of investment needed is modest compared to other public infrastructure.

Governments could implement this through several approaches:

• Correctly assess software sovereignty risk. Governments should understand how much control they have over the software they depend on, and how easily that control can be lost through acquisition, relicensing, or policy changes. My Software Sovereignty Scale provides a framework for making these risks visible.

• Track the health of critical Open Source projects. Just like we have safety ratings for bridges, governments should regularly check the health of the Open Source projects they rely on. This means setting clear targets, such as addressing security issues within x days, having y active maintainers, keeping all third-party software components up to date, and more. When a project falls behind, governments should step in and help with targeted support. This could include direct funding, employing contributors, or working with partners to stabilize the project.

• Commit to long-term funding with stable timelines. Just as governments plan highway maintenance years in advance, we'd benefit from multi-year funding commitments and planning for critical digital infrastructure. Long-term funding allows projects to address technical debt, plan major updates, and recruit talent without the constant uncertainty of short-term fundraising.

• Encourage contribution in government contracts. Governments can use procurement to strengthen Open Source. Vendor contribution should be a key factor in awarding contracts, alongside price, quality, and other criteria. Agencies or vendors can be required or encouraged to give back through coding, documentation, security reviews, design work, or direct funding. This ensures governments work with true experts while helping keep critical Open Source projects healthy and sustainable.

• Adopt "Public Money, Public Code" policies. When taxpayer money funds software for public use, that software should be released as Open Source. This avoids duplicate spending and builds shared digital infrastructure that anyone can reuse, improve, and help secure. The principle of "Public Money? Public Code!" offers a clear framework: code paid for by the people should be available to the people. Switzerland recently embraced this approach at the federal level with its EMBAG law, which requires government-developed software to be published as Open Source unless third-party rights or security concerns prevent it.

• Scale successful direct funding models. The Sovereign Tech Agency has shown how government programs can directly fund the maintenance and security of critical Open Source software. Other nations should follow and expand this model. Replacing widely used Open Source software could cost an estimated 8.8 trillion dollars. Public investment should match that importance, with sustained global funding in the billions of dollars across countries and projects.

• Teach Open Source in public schools and universities. Instead of relying solely on proprietary vendors like Microsoft, governments should integrate Open Source tools, practices, and values into school and university curricula, along with related areas such as open standards and open data. This prepares students to participate fully in Open Source, builds a talent pipeline that understands Open Source, and strengthens digital self-reliance.

Keeping the core strong

Concerns about political interference or loss of independence are valid. That is why we need systems that allow all stakeholders to coexist without undermining each other.

Government funding should reinforce the ecosystem that makes Open Source thrive, not replace it or control it. Companies and volunteers are strong drivers of innovation, pushing forward new features, experiments, and rapid improvements. Governments are better suited to a different but equally vital role: ensuring stability, security, and long-term reliability.

The most critical tasks in Open Source are often the least glamorous. Fixing bugs, patching vulnerabilities, updating third-party dependencies, improving accessibility, and maintaining documentation rarely make headlines, but without them, innovation cannot stand on a stable base. These tasks are also the most likely to be underfunded because they do not directly generate revenue for companies, require sustained effort, and are less appealing for volunteers.

Governments already maintain roads, bridges, and utilities, infrastructure that is essential but not always profitable or exciting for the private sector. Digital infrastructure deserves the same treatment. Public investment can keep these core systems healthy, while innovation and feature direction remain in the hands of the communities and companies that know the technology best.

Conclusion

Fifteen years ago, I argued that Open Source needed commercial sponsorship to thrive. Now we face the next challenge: governments must shift from consuming Open Source to sustaining it.

Today, some Open Source has become public infrastructure. Leaving critical infrastructure dependent on too few maintainers is a risk no society should accept.

The solution requires coordinated policy reforms: dedicated funding mechanisms, procurement that rewards upstream contributions, and long-term investment frameworks.

Special thanks to Baddy Sonja Breidert, Tim Doyle, Tiffany Farriss, Mike Gifford, Owen Lansbury and Nick Veenhof for their review and contributions to this blog post.

I recently bought a Peloton bike as a Christmas gift for my wife. The Peloton was for our house in Belgium. Because Peloton does not deliver to Belgium yet, I had to find a way to transport one from Germany to Belgium. It was a bit of a challenge as the bike is quite large, and I wasn't sure if it would fit in the back of our car.

I tried measuring the trunk of my car, along with another Peloton. I wasn't positive if it would fit in the car. I tried Googling the answer but search engines aren't great at answering these types of questions today. Being both uncertain of the answer and too busy (okay, let's be real – lazy) to figure it out myself, I decided to ship the bike with a courier. When in doubt, outsource the problem.

To my surprise, when Microsoft launched their Bing and ChatGPT integration not long after my bike-delivery conundrum, one of their demos showed how ChatGPT can answer the question whether a package fits in the back of a car. I'll be damned! I could have saved money on a courier after all.

After watching the event, I asked ChatGPT, and it turns out the Peloton would have fit. That is, assuming we can trust the correctness of ChatGPT's answer.

What is interesting about the Peloton example is that it combines data from multiple websites. Combining data from multiple sources is often more helpful than the traditional search method, where the user has to do the aggregating and combining of information on their own.

Examples like this affirm my belief that AI tools are one of the next big leaps in the internet's progress.

AI disintermediates traditional search engines

Since its commercial debut in the early 90s, the internet has repeatedly upset the established order by slowly, but certainly, eliminating middlemen. Book stores, photo shops, travel agents, stock brokers, bank tellers and music stores are just a few examples of the kinds of intermediaries who have already been disrupted by their online counterparts.

A search engine acts as a middleman between you and the information you're seeking. It, too, will be disintermediated, and AI seems to be the best way of disintermediating it.

Many people have talked about how AI could even destroy Google. Personally, I think that is overly dramatic. Google will have to change and transform itself, and it's been doing that for years now. In the end, I believe Google will be just fine. AI disintermediates traditional search engines, but search engines obviously won't go away.

The Big Reverse of the Web marches on

The automatic combining of data from multiple websites is consistent with what I've called the Big Reverse of the Web, a slow but steady evolution towards a push-based web; a web where information comes to us versus the current search-dominant web. As I wrote in 2015:

I believe that for the web to reach its full potential, it will go through a massive re-architecture and re-platforming in the next decade. The current web is "pull-based", meaning we visit websites. The future of the web is "push-based", meaning the web will be coming to us. In the next 10 years, we will witness a transformation from a pull-based web to a push-based web. When this "Big Reverse" is complete, the web will disappear into the background much like our electricity or water supply.

Facebook was an early example of what a push-based experience looks like. Facebook "pushes" a stream of aggregated information designed to tell you what is happening with your friends and family; you no longer have to "pull" them or ask them individually how they are doing.

A similar dynamic happens when AI search engines give us the answers to our questions rather than redirecting us to a variety of different websites. I no longer have to "pull" the answer from these websites; it is "pushed" to me instead. Trying to figure out if a package fits in the back of my car is the perfect example of this.

Unlocking the short term potential of Generative AI for CMS

While it might take a while for AI search to work out some early kinks, in the near term, Generative AI will lead to an increasing amount of content being produced. It's bad news for the web as a lot of that content will likely end up being spam. But it also is good news for CMSs, as there will be a lot more legitimate content to manage as well.

I was excited to see that Kevin Quillen from Velir created a number of Drupal integrations for ChatGPT. It allows us to experiment with how ChatGPT will influence CMSs like Drupal.

For example, the video below shows how the power of Generative AI can be used from within Drupal to help content creators generate fresh ideas and produce content that resonates with their audience.

Similarly, AI integrations can be used to translate content into different languages, suggest tags or taxonomy terms, help optimize content for search engines, summarize content, match your content's tone to an organizational standard, and much more.

The screenshot below shows how some of these use cases have been implemented in Drupal:

The Drupal modules behind the video and screenshot are Open Source: see the OpenAI project on Drupal.org. Anyone can experiment with these modules and use them as a foundation for their own exploration. Sidenote: another example of how Open Source innovation wins every single time.

If you look at the source code of these modules, you can see that it is relatively easy to add AI capabilities to Drupal. ChatGPT's APIs make the integration process straightforward. Extrapolating from Drupal, I believe it is very likely that in the next year, every CMS will offer AI capabilities for creating and managing content.

In short, you can expect many text fields to become "AI-enhanced" in the next 18 months.

Boost your website's visibility by optimizing for AI crawlers

Another short-term change is that marketers will seek to better promote their content to AI bots, just like they currently do with search engines.

I don't believe AI optimization to be very different from Search Engine Optimization (SEO). Like search engines, AI bots will have to put a lot of emphasis on trust, authority, relevance, and the understandability of content. It will remain essential to have high-quality content.

Right now, in AI search engines, attribution is a problem. It's often impossible to know where content is sourced, and as a result, to trust AI bots. I hope that more AI bots will provide attribution in the future.

I also expect that more websites will explicitly license their content, and specify the ways that search engines, crawlers, and chatbots can use, remix, and adopt their content.

As can be seen from the screenshot above, I specify a license for all 10,000+ photos on my site. I make them available under Creative Commons. The license is specified in the HTML code, and can be programmatically extracted by a crawler. I do something very similar for my blog posts.

By licensing my content under Creative Commons, I'm giving tools like ChatGPT permission to use my content, as long as they follow the license conditions. I don't believe ChatGPT uses that information today, but they could, and probably should, in the future.

If a website has high-quality content, and AI tools give credit to their sources, this can result in organic traffic back to the website.

All things considered, my base case is that AI bots will become an increasingly important channel for digital experience delivery, and that websites will be the main source of input for chatbots. I suspect that websites will only need to make small, incremental changes to optimize their content for AI tools.

Predicting the longer term impact of AI tools on websites

Longer term, AI tools will likely bring significant changes to digital marketing and content management.

I predict that over time, AI bots will not only provide factual information, but also communicate with emotions and personality, providing more human-like interactions than websites.

Compared to traditional websites, AI bots will be better at marketing, sales and customer success.

Unlike humans, AI bots will possess perfect product knowledge, speak many languages, and – this is the kicker – have a keen ability to identify what emotional levers to pull. They will be able to appeal to customers' motivations, whether it's greed, pride, frustration, fear, altruism, or envy.

The downside is that AI bots will also become more "skilled" at spreading misinformation, or might be able to cause emotional distress in a way that traditional websites don't. There is undeniably a dark side to AI bots.

My more speculative and long-term case is that AI chatbots will become the most effective channel for lead generation and conversion, surpassing websites in importance when it comes to digital marketing.

Without proper regulations and policies, that evolution will be tumultuous at best, and dangerous at worst. As I've been shouting from the rooftops since 2015 now: "When algorithms rule our lives, who should rule them?". I continue to believe that algorithms with significant effects on society require regulation and policies, just like the Food and Drug Administration (FDA) in the U.S. or the European Medicines Agency (EMA) in Europe oversee the food and drug industry.

The impact of AI on website development

Of course, the advantages of Generative AI extend beyond content creation and content delivery. The advantages also include software development, such as writing code (46% of all new code on GitHub is generated by GitHub's Copilot), identifying security vulnerabilities (ChatGPT finds two times as many security vulnerabilities as a professional software security scanner), and more. The impact of AI on software development is a complex topic that warrants a separate blog post. In the meantime, here is a video demonstrating how to use ChatGPT to build a Drupal module.

The risks and challenges of Generative AI

Even though I'm optimistic about the potential of AI, I would be neglectful if I failed to discuss some of the potential challenges associated with it.

Although Generative AI is really good at some tasks, like writing a sincere letter to my wife asking her to bake my favorite cookies, it still has serious issues. Some of these issues include, but are not limited to:

• Legal concerns – Copyrighted works have been involuntarily included in training datasets. As a result, many consider Generative AI a high-tech form of plagiarism. Microsoft, GitHub, and OpenAI are already facing a class action lawsuit for allegedly violating copyright law. The ownership and protection of content generated by AI is unclear, including whether AI tools can be considered "creators" of original content for copyright law purposes. Technologists, lawyers, and policymakers will need to work together to develop appropriate legal frameworks for the use of AI.
• Misinformation concerns – AI systems often "hallucinate", or make up facts, which could exuberate the web's misinformation problem. One of the most interesting analogies I've seen comes from The New Yorker, which describes ChatGPT as a blurry JPEG of all of the text on the web. Just as a JPEG file loses some of the quality and integrity of the original, ChatGPT summarizes and approximates text on the web.
• Bias concerns – AI systems can have gender and racial biases. It is widely acknowledged that a significant proportion of the content available on the web is generated by white males residing in western countries. Consequently, ChatGPT's training data and outputs are prone to reflecting this demographic bias. Biases are troubling and can even be dangerous, especially considering the potential societal impact of these technologies.

The above issues related to legal authorship, misinformation, and bias have also given rise to a host of ethical concerns.

My personal strategy

Disruptive changes can be polarizing: they come with some real downsides, while bringing new opportunities.

I believe there is no stopping AI. In my opinion, it's better to embrace change and focus on moving forward productively, rather than resisting it. Iterative improvements to both these algorithms and to our legal frameworks will hopefully address concerns over time.

In the past, the internet was fraught with risk, and to a large extent, it still is. However, productivity and efficiency improvements almost always outweigh risk.

While some individuals and organizations advocate against the use of AI altogether, my personal strategy is to proceed with caution. My strategy is two-fold: (1) focus on experimenting with AI rather than day-to-day usage, and (2) highlight the challenges with AI so that people can make their own choices. The previous section of this blog post tried to do that.

I also expect that organizations will use their own data to train their custom AI bots. This would eliminate many concerns, and let organizations take advantage of AI for applications like marketing and customer success. Simon Willison shows that in a couple of hours of work, he was able to train his own model based on his website content. Time permitting, I'd like to experiment with that myself.

Conclusion

I'm both intrigued, wary, and inspired as to where AI will take the web in the days, months, and years to come.

In the near term, Generative AI will alter how we create content. I expect integrations into CMSs will be simple and numerous, and that websites will only have to make small changes to optimize their content for AI tools.

Longer term, AI will change the way in which we interact with the web and how the web interacts with us. AI tools will steadily alter the relative importance of websites, and potentially even surpass websites in importance when it comes to digital marketing.

Exciting times, but let's move forward with caution!

Put simply, Section 230 provides websites immunity from liability from third-party content. This internet legislation is a double-edged sword. On the one hand it has allowed the dangerous spread of misinformation on social media. On the other hand it has helped the internet thrive.

If I write something untrue and damaging about you on Facebook, you might be able to sue me, but you can't sue Facebook. As a result, social media companies don't really care what is said on their platforms. Their immunity is a big reason why fake news, hate speech and misinformation has been able to spread uncontrollably.

At the same time, Section 230 makes it possible for bloggers to host comments from their readers, for Open Source communities to work together online, and for YouTubers to share videos. Section 230 enables people to share, innovate and collaborate. It has empowered a lot of good.

President Biden has suggested revoking Section 230. Other policy makers would like to reform Section 230. Either revoking or modifying Section 230 could have a big impact on any organization that hosts online content.

Hosting companies could be impacted, but also bloggers and Open Source communities. Having to police all content could quickly become unsustainable, especially for individuals and small organizations. People publish so much new content every day!

As Katie Jordan, the Director of Public Policy and Technology for the Internet Society said, If cloud providers get wrapped up in this conversation about pulling back intermediary liability protection, then by default, they're going to have to reduce privacy and security practices because they'll have to look at the content they're storing for you, to know if they're breaking the law..

A wholesale repeal of Section 230 seems too far reaching to me. It could cause more harm than good. A careful reform seems more appropriate.

Instead of being so focused on Section 230, I'd start by regulating search and social media algorithms. Hosting content is one thing, but recommending content to millions of people is another. When search and social media companies reach billions of people, their content recommendation algorithms can sway public sentiment, introduce bias or rapidly spread misinformation. We should start there.

I've said in the past that we need an FDA for large-scale algorithms that impact society. Just as the FDA ensures that pharmaceutical companies aren't lying about the claims they make about their drugs, there should be a similar regulator for large-scale software algorithms. For example, we need some level of guarantee that companies like Google, Twitter and Facebook won't intentionally (or unintentionally) manipulate search results to shape the public opinion.

Last week, I published an opinion piece on CNN featuring my thoughts on what is wrong with the web and how we might fix it.

In short, I really miss some things about the original web, and don't want my kids to grow up being exploited by mega-corporations.

I am hopeful that increased regulation and decentralized web applications may fix some of the web's current problems. While some problems are really difficult to fix, at the very least, my kids will have more options to choose from when it comes to their data privacy and overall experience on the web.

You can read the first few paragraphs below, and view the whole article on CNN.

I still remember the feeling in the year 2000 when a group of five friends and I shared a modem connection at the University of Antwerp. I used it to create an online message board so we could chat back and forth about mostly mundane things. The modem was slow by today's standards, but the newness of it all was an adrenaline rush. Little did I know that message board would change my life.

In time, I turned this internal message board into a public news and discussion site, where I shared my own experiences using experimental web technologies. Soon, I started hearing from people all over the world that wanted to provide suggestions on how to improve my website, but that also wanted to use my site's technology to build their own websites and experiment with emerging web technologies.

Before long, I was connected to a network of strangers who would help me build Drupal.

Milestones like this get me thinking about the positive impact a free and Open Web has had on society. Without the web, billions of people would not have been able to connect with one another, be entertained, start businesses, exchange ideas, or even save lives. Open source communities like Drupal would not exist.

As optimistic as I am about the web's impact on society, there have been many recent events that have caused me to question the Open Web's future. Too much power has fallen into the hands of relatively few platform companies, resulting in widespread misinformation, privacy beaches, bullying, and more.

However, I'm optimistic that the Open Web has a chance to win in the future. I believe we'll see three important events happen in the next five years.

First, the day will come when regulators will implement a set of laws that govern the ownership and exchange of data online. It's already starting to happen with GDPR in the EU and various state data privacy laws taking shape in the US. These regulations will require platforms like Facebook to give users more control over their data, and when that finally happens, it will be a lot easier for users to move their data between services and for the Open Web to innovate on top of these data platforms.

Second, at some point, governments globally will disempower large platform companies. We can't leave it up to a handful of companies to judge what is false and true, or have them act as our censors. While I'm not recommending governments split up these companies, my hope is that they will institute some level of algorithmic oversight. This will offer an advantage to the Open Web and Open Source.

Third, I think we're on the verge of having a new set of building blocks that enable us to build a better, next-generation web. Thirty years into the web, our data architectures still use a client-server model; data is stored centrally on one computer, so to speak. The blockchain is turning that into a more decentralized web that operates on top of a distributed data layer and offers users control of their own data. Similar to building a traditional website, distributed applications (dApps) require file storage, payment systems, user data stores, etc. All of these components are being rebuilt on top of the blockchain. While we have a long way to go, it is only a matter of time before a tipping point is reached.

In the past, I've publicly asked the question: Can we save the Open Web? I believe we can. We can't win today, but we can keep innovating and get ready for these three events to unfold. The day will come!

With that motivation in mind, I want to wish a special happy birthday to the world wide web!