Things are starting to shift in the field of digital dependency. The conversation in the public sector has moved from civil society warnings to parliamentary reports, from IT conferences to cabinet agendas. Academia was tracking this before it became a policy priority: Paul van Vulpen began researching digital sovereignty and decentralised IT governance when neither was high on anyone’s agenda. He defended his dissertation Debating Digital Dominance: Decentralized Technology Governance For Strategic Autonomy at Utrecht University in January 2026.

We thank him for it. His work gives policymakers a well-grounded framework that moves past the choice between “stay with the current vendor” and “build everything from scratch.” Available open access at doi.org/10.33540/3269.

This article maps his key findings onto the Belgian situation and points to what is already possible.

The structural problem, clearly named

Van Vulpen’s central argument is not that US tech companies are bad actors. It is that the economics of software push digital infrastructure toward concentration: near-zero marginal cost, network effects, and ecosystem lock-in all work in the same direction. Any sufficiently dominant actor will, over time, set conditions that serve its own interests. That is not inherently a bad intention of an actor; it is how markets with these properties tend to work.

For public bodies, the consequence is tangible. A municipality or hospital that cannot practically switch its core software provider has tied its operational continuity and its citizens’ data to a contract with a foreign corporation operating under foreign law. The recent databreach with ChipSoft in the Netherlands (76% of the hospitals) and also some Belgian hospitals, clearly illustrates this point.

Van Vulpen also addresses a tempting shortcut: building a European equivalent of Microsoft or AWS. He examines this directly and finds it insufficient. Centralising control within a single European entity, however European, recreates the same structural concentration. The problem is not where the company is headquartered; it is the degree of dependency itself.

Federated Technology Governance: the middle road that works

Van Vulpen calls it Federated Technology Governance (FTG): a hybrid model between full centralisation and full decentralisation, both of which he finds unworkable in practice. FTG is the conceptual realization that integrates the best of both centralization and decentralisation.

A central authority defines architecture, standards, and long-term vision. Decentralised actors handle implementation and local adaptation. Strategy is determined collectively, not by a small executive layer. Subsidiarity applies: local entities retain control over their data and services within the shared structure.

He borrows Eric Raymond’s cathedral-and-bazaar metaphor, and consolidates them: the cathedral symbolizes the top-down strongly architected development of a project, the bazaar reflects the organically growing small projects that cater to local needs. Where Raymond sees them as opposing, the FTG-model interweaves them in a way the two approaches enhance each other. What we need, is a structured, standards-based foundation with a diverse, open ecosystem on top. The foundation provides coherence; the ecosystem provides adaptability.

This is not a theoretical construct. It is already happening, also in Belgium.

What experiments in collective governance teach us

Van Vulpen’s second research lens examines decentralised autonomous organisations: collective governance structures where rules are made explicit, encoded, and enforced by the community itself rather than by a central authority. The technical implementations he studied are primarily blockchain-based, but the governance lessons generalise well beyond that context.

The starting point is Elinor Ostrom’s work on commons governance. Ostrom observed that communities managing shared resources (fishing grounds, irrigation systems, forests) consistently succeeded or failed based on whether they had established certain governance principles: clearly defined membership, rules adapted to local conditions, collective participation in rule-making, monitoring, graduated sanctions for violations, accessible conflict resolution, and nested layers of organisation that allow local autonomy within a broader structure. Communities that lacked these principles tended toward what Hardin called the tragedy of the commons: individually rational behaviour that produces collective harm.

Van Vulpen applies this directly to shared digital infrastructure. Every municipality that procures IT software individually is acting rationally in its own interest. The collective result — fragmented systems, duplicated costs, no shared bargaining power, and accumulating vendor dependency — is the digital equivalent of overgrazing. The commons governance literature suggests the solution is not central control or full privatisation, but a third path: structured collective governance by the affected stakeholders themselves.

What the DAO research adds is a set of concrete design lessons about what makes that collective governance work or fail in practice.

Explicit constitutions matter. The DAOs that functioned well had founding documents that collectively defined membership boundaries, decision-making processes, conflict resolution mechanisms, and sanctions for violations. Those that relied on implicit norms or informal leadership tended to fragment or be captured. For a shared public software cooperative, this means the governance document is not a bureaucratic formality but the structural foundation that prevents the cooperative from drifting toward the interests of its most active or most resourced members.

Decentralising infrastructure is not the same as decentralising governance. This is one of Van Vulpen’s sharpest findings. Several DAOs decentralised their technical infrastructure — distributing data and computation across many nodes — while leaving strategic decisions in the hands of a small founding team or a single admin key. The result was the appearance of decentralisation without the substance. The lesson for public IT is that running your own servers does not make you sovereign if the software strategy, roadmap, and vendor relationships are still controlled elsewhere. What matters is who governs the strategy layer.

Incentive design is a real problem. Shared software projects face a free-rider dynamic: it is rational for any individual member to use the shared resource without contributing to its maintenance or development. Successful DAOs invested heavily in designing contribution incentives — reputation systems, financial rewards, and what Van Vulpen calls a culture of participation. iMio addresses this through its in-house procurement principle and co-production model, where municipalities collectively fund the features they need. That is an incentive structure, even if no one calls it that.

The failure modes are instructive. Van Vulpen documents cases where governance was exploited: a DAO whose treasury was drained through a hostile governance proposal, another where a single admin key holder effectively controlled a nominally decentralised organisation. These are not exotic edge cases. Any shared public IT structure that concentrates effective control in a single administrator, a single vendor, or a small founding group carries the same structural vulnerability — regardless of how its governance documents are written.

Ostrom’s eighth principle is perhaps the most directly relevant for Belgium: nested layers of organisation, where local entities retain autonomy within a broader federated structure, and where local jurisdiction is recognised by higher authorities. That is roughly the model iMio has built in Wallonia over the past decade.

iMio: a Belgian blueprint that has been running for over a decade

In the mid-2000s, two small groups of Wallonian municipalities, five in each, decided to stop procuring IT individually and start building together. They created shared open-source tools for council meeting management, permit handling, and citizen portals. In November 2011, those two communities merged into iMio (Intercommunale Mutualisation Informatique et Organisationnelle), with backing from the Walloon regional government.

Today, iMio serves 404 local authorities, including 244 of Wallonia’s 262 communes (93%), alongside provinces, CPAS social welfare centres, police zones, and fire zones. Around 25,000 civil servants use its platform daily. The annual operating budget is €6 million, covered entirely by member contributions with no structural subsidies from the Walloon region. iMio has been financially self-sustaining since 2021.

The governance model is equally notable. The general assembly has 362 members. Municipalities set the product roadmap. When a new feature is needed, iMio first checks whether something already exists elsewhere before building from scratch. When it does build, the code is published openly for anyone to reuse.

iMio won the European Commission’s Sharing and Reuse Award in 2017. It is a working public institution that has quietly demonstrated, right here in Belgium, that the federated model Van Vulpen describes is achievable at scale.

Flanders too has its achievements. The MAGDA platform, a data exchange service used by 190 agencies and 30 departments of the Flemish government as well as 308 local governments, won second place in the same 2017 awards and was subsequently contacted by the Netherlands, France, and Germany for cross-border use. Digitaal Vlaanderen publishes components openly on GitHub, including MAGDA tooling and the OSLO vocabulary framework for linked government data. Flanders is also working with SOLID for citizen data pods and made a major public investment in the technology. These are production systems, not experiments.

Belgium is clearly not starting from zero. The question is how to build on these foundations more systematically.

What Belgium looks like from the outside

BeLibre has spent the past year mapping Belgian public sector dependency on US cloud infrastructure. The picture that emerges is not a set of deliberate choices. It is the accumulated result of individual procurement decisions, each locally reasonable, with no coordinating framework to assess the overall picture.

All Belgian police zones use Microsoft 365 through a centralised framework contract. In the hospital sector, we mapped 158 institutions: dependency on US cloud providers for clinical systems, imaging infrastructure, and administrative software is widespread.

This is the pattern Van Vulpen describes: individually rational decisions that produce a collectively significant outcome: for every municipality or public service provider, a locally developed solution is much more expensive and less feature rich than the offerings of big players like Microsoft or Google. Each institution chose what was available, affordable, and supported. The key question to ask is now: What changes when municipalities or hospitals would team up? How does this alter the equation? The iMio case teaches us what van Vulpen postulates: the business case fundamentally improves for a collectively developed solution.

There is also a legal dimension worth stating. In footnote 82 of the dissertation, van Vulpen raises a question about the Dutch situation that applies directly to Belgium. Microsoft falls under the US CLOUD Act, which gives US law enforcement and intelligence services access to data held by US companies, including data stored outside the United States. The Dutch National Audit Service noted that almost the entire Dutch central government was moving to Microsoft 365, and asked: does this mean the US government can access all the information the Dutch government holds about its citizens?

The CLOUD Act does not require a mutual legal assistance treaty. It does not require notification of the affected government. Belgium is in the same position. We covered the structural legal constraints in more detail in our SEAL-based assessment of Microsoft’s sovereignty claims.

What the research says governments should do

Van Vulpen’s policy recommendations (section 9.3.4 and 9.3.5) are concrete. None of them require starting from zero.

Mandate open source in public procurement. Infrastructure that public institutions depend on should not be closed source. An open-source requirement encourages reuse and transparency, and gives institutions the practical ability to audit what they run. iMio is the proof of concept.

Reform procurement to build a market. Prioritising European and domestic software providers creates the customer base that makes a viable European software ecosystem possible. Demand shapes what gets built, and public procurement is one of the most powerful levers a government holds.

Invest in sovereign cloud infrastructure. No European cloud provider currently operates at the scale of AWS or Azure. European governments are running critical services on infrastructure subject to non-European jurisdiction. Addressing this requires long-term public investment with a clear mandate, not another procurement cycle.

Build on Linux for the operating system layer. There is no fully European-controlled operating system in wide public sector use. Van Vulpen proposes building on Linux to develop secure, auditable operating systems for public sector and strategic applications. The German government has already gone this route for specific use cases.

Fund open source as a long-term public good. Germany’s Sovereign Tech Fund supports open-source infrastructure the way governments fund roads: shared public infrastructure, not a commercial product. The EU’s Next Generation Internet programme is moving in the same direction. While van Vulpen is uncertain of their impact, they do exist. And Belgium can draw on both.

Think in years, not tender rounds. Procurement cycles alone cannot address accumulated legacy dependency. What is needed is a sustained development strategy and the institutional structure to carry it. iMio is that structure for Wallonia. A municipal software cooperative on the same model does not yet exist in Flanders. That is a policy gap, not an inevitability.

Questions worth asking before the next contract

Van Vulpen’s framework implies a short checklist that any public administrator should be able to answer before signing an IT contract.

• Is this software open source, and if not, what does the exit path look like if terms change or the supplier is acquired?
• Can we switch providers without losing access to our own data, and in what format is that data stored?
• Where is this data physically hosted, and under which legal jurisdiction?
• Does this contract create lock-in at the infrastructure, integration, or data layer, and which of those can realistically be undone within a reasonable timeframe?

In practice, these questions are rarely asked systematically. A mandate, a framework contract, or even a policy letter can change that.

The opportunity

There is also an economic case for action. Van Vulpen argues that public procurement favouring European and domestic software providers creates the market that makes a viable European software ecosystem possible. The €264 billion that flows annually from European public and private sectors to US technology companies represents capacity that could support European businesses and IT talent.

Schleswig-Holstein migrated 40,000 mailboxes to open source alternatives for a one-time investment of €9 million, saving more than €15 million per year. France is building La Suite Numérique, a shared open-source workspace for millions of civil servants, together with Germany and other member states. Wallonia built iMio from five municipalities and a subsidy, and it now serves 93% of the region’s communes.

None of these started with a complete solution. They started with a decision.

Van Vulpen’s dissertation gives that decision an academic backbone. iMio shows it works in practice, here in Belgium. What happens next is up to the people reading this.