A Government Guide to Open Protocols
Public sector teams must go beyond the in-house or off-the-shelf dichotomy to take advantage of open protocols, which offer a unique way to manage both software costs and geopolitical exposure
From Vendor Dependency to Coordination Systems
For most of the history of digital infrastructure provision, public institutions faced two uncomfortable options: deep dependency on large proprietary vendors such as Microsoft or Oracle, with all the lock-in and geopolitical exposure that entails; or the enormous difficulty and expense of building and maintaining systems in-house.
Open protocols offer a third path. Infrastructure that no single actor owns, that evolves through distributed processes, and that can be implemented by anyone with the technical capacity to do so. The sovereignty offered by this approach is not about ownership, but about institutions understanding how their systems work, being able to participate in them, and retaining the option to move or adapt if needed.
Public institutions across Europe and beyond are increasingly taking this third option. Public digital infrastructure is becoming dependent on systems that no single actor controls. Messaging platforms, digital ID systems, and cross-border government digital services increasingly rely on open protocol ecosystems. In Europe, this acceleration is shaped by two pressures: the call for digital sovereignty and legally mandated interoperability. The French government’s digital directorate, DINUM, for example, runs Tchap – a secure messaging platform for the French public administration – on Matrix, an open protocol maintained by a distributed global community rather than any single vendor.
Overdependence on dominant corporate vendors or external jurisdictions is increasingly seen in Europe as a real political and strategic risk. The European Commission has put digital sovereignty and open strategic autonomy high on the agenda because control over digital infrastructure now touches everything from economic security to democratic resilience and Europe’s geopolitical standing. In that context, open protocols have advantages. They allow governments to reduce dependency on individual vendors without cutting themselves off from global technology ecosystems.
At the same time, interoperability is no longer aspirational. With the adoption of the Interoperable Europe Act, cross-border compatibility and the reuse of public sector digital tools, standards, and components have become regulatory requirements rather than best practices. Public administrations are expected to build digital services that can function across Member States and integrate into shared European infrastructures. That legal shift creates pressure toward open standards and protocol-based systems, because interoperability at scale is difficult to sustain if the underlying evolution of systems is controlled unilaterally.
As a result, many major public digital infrastructure projects over the next decade will involve protocol deployments. Realising the potential of this change, however, requires something most public institutions have not yet done: treating protocol engagement as a first-class infrastructure responsibility rather than a background technical detail.
The Problem with How Institutions Procure
The problem starts with how institutions think about procurement. Servers can be audited. Vendors can be contracted. Systems can be upgraded through planned lifecycle management. When something breaks, there is someone to call. The governance of these third-party relationships is externalised into contract law, and the institution can, at least in principle, hold the counterparty to account. Even open source has historically been absorbed into this logic. Vendors and consultancies package open source software into products and services that institutions can procure, with clear accountability structures.
Open protocols do not fit that model. They define how systems communicate and evolve, but they are not owned or governed through formal authority. Maintained by distributed communities, they operate through proposal processes, informal norms and voluntary adoption rather than contractual obligation.
When an institution procures a system built on an open protocol, it is not simply acquiring software. It is entering a coordination ecosystem governed by rules that will continue to evolve long after any contract is signed, through processes that the procurement office did not assess and toward outcomes that no single party controls.
The protocol that makes a system interoperable today will be revised. The security practices embedded in it will need to change as threats evolve. The compatibility assumptions that allow it to federate with other deployments will be renegotiated by a community of contributors who have no formal obligation to an operational timeline or compliance requirements.
This arrangement is still poorly understood in the public sector, particularly in procurement systems designed around vendors and deliverables rather than shared governance.
The Risks of Unmanaged Dependency
The case for open protocol infrastructure is strong, but adoption introduces its own risks. Technical robustness does not automatically translate into institutional readiness.
Exit options can narrow quickly. If the protocol evolves in a direction that no longer fits institutional requirements, the practical alternatives are limited. Forking a protocol that is already widely deployed means taking on long-term maintenance and gradually drifting away from the wider ecosystem. Walking away usually means returning to vendor-based solutions, bringing back the same dependencies digital sovereignty policies were meant to reduce.
Change can also arrive as operational surprise rather than managed evolution. Protocol governance is continuous. Security updates, specification revisions, and coordination shifts are normal features of healthy ecosystems. But if institutions are not following those processes, they might only notice the consequence of a particular direction when it urgently impacts them. What could have been handled through normal lifecycle planning turns into incident response.
Governance influence is rarely evenly distributed, though to exactly what degree varies significantly by protocol. Some have governance structures with strong safeguards against capture by any single actor. In protocols with weaker safeguards, development tends to be shaped by those who can afford to fund full-time engineering participation. A public institution entering such a governance ecosystem may find it already dominated by a small group of well-funded private actors.
Maintenance capacity can also be more limited than it appears. Key functions, particularly security response, may depend on a very small number of individuals. If those individuals move on or are unavailable during an incident, institutions have no contractual safeguards and may face response timelines that are incompatible with their operational requirements.
In essence, open protocols replace vendor dependency with ecosystem dependency. That dependency is structurally healthier because the governance processes shaping these systems are visible and participatory, but it still requires institutional competence, monitoring and strategic engagement. Public institutions are not limited to acting as customers with influence tied to purchasing power. They can observe, engage and, where appropriate, contribute to how the infrastructure they depend on evolves.
Building Institutional Capacity for Protocol Governance
The most productive response is to develop genuine institutional capacity to understand and track how protocol governance works, and to participate in it on the protocol’s own terms.
Participation is not control. It would be a mistake to treat engagement in protocol governance as a route to directing how a global technical community decides things. Governance is distributed by design, and the value of that distribution is precisely that no single actor can capture the infrastructure.
An institution that attends governance discussions, comments on proposals and tracks specification changes is not governing the protocol. It is informing its own planning and, where it has something useful to contribute, improving the quality of the collective decision.
When protocol foundations offer formal participation structures, such as Governmental Advisory Councils, public institutions should make use of them. These forums allow governments running large deployments to raise operational needs early while still respecting the distributed governance model most protocols rely on. In some cases, institutions may also second engineers or technical staff to protocol foundations or working groups, a practice already common in standardisation bodies such as ETSI and W3C.
Developing internal protocol literacy also changes how institutions manage their infrastructure. Teams that follow specification changes and community discussions gain early insight into how the systems they depend on are likely to evolve. Over time, a consistent presence also builds credibility within the ecosystem, increasing the likelihood that the needs of large public deployments are taken into account.
A procurement team with real protocol literacy can also assess the governance health of a protocol before committing to it. Not just the quality of the current specification, but the community’s track record on backwards compatibility, the concentration of influence among contributors, the quality of security coordination and the overall health of the maintenance work.
Making protocol risk visible at the moment dependency is created does not require complex new bureaucracy. It requires better questions during procurement and infrastructure planning. Where are decisions actually made? How does a proposal move from draft to adoption? How are breaking changes communicated, and with what notice? What happens if institutional requirements diverge from community direction?
Procurement criteria can then reflect that understanding. Vendors who actively contribute to protocol specifications, participate in security coordination and maintain implementations are better positioned to keep deployments aligned with protocol evolution over time. Procurement frameworks that treat upstream contribution as a resilience signal do not just favour better suppliers. They shift incentives across the whole ecosystem, rewarding vendors embedded in the health of the protocol rather than those treating it as a static dependency.
Institutionalising Participation: The Matrix Example
One of the clearest examples of an institution making this shift is the Direction interministérielle du numérique (DINUM), the French government’s digital directorate, which in 2025 became the first government in the world to join the Matrix.org Foundation as a formal member.
DINUM already operated the largest government deployment of Matrix through Tchap, the secure messaging platform used across the French public administration by hundreds of thousands of civil servants.
Joining the foundation did not grant DINUM control over Matrix, nor did it create a privileged position within the protocol’s governance structure. What it did was formalise France’s presence in the ecosystem behind the infrastructure it already depended on. French engineers and security teams had already been tracking Matrix Spec Changes, coordinating on security advisories and planning upgrades in line with upstream development. Membership made that engagement structural rather than personal. Reliance on a small number of individuals was reduced by embedding governance awareness within the institution itself.
Not every public institution will have the resources to sustain individual participation in protocol governance. Collective participation models offer a practical alternative. The Matrix for Public Sector forum, launched in October 2025 alongside DINUM’s foundation membership, brings together representatives from six EU Member States, the European Commission and other institutions to share knowledge, coordinate deployments and feed operational requirements into governance collectively. This lowers the threshold for meaningful participation.
France is not alone. Across Europe and beyond, governments are building at scale on open protocol infrastructure, with varying degrees of governance engagement. Germany operates a large public sector deployment of Matrix through BwMessenger, the secure messaging platform developed for the Bundeswehr. Several EU Member States, including Sweden, Luxembourg and the Netherlands, are piloting or deploying similar open protocol-based messaging and collaboration infrastructures.
Participation Is the Strategy
Open protocol adoption by governments will continue. The pressures behind it are structural: the political will to reduce dependency on digital infrastructure controlled by big tech companies outside their jurisdiction, legal requirements for cross-border interoperability, and the economic advantages of building infrastructure on open protocols rather than each institution developing its own proprietary stacks.
The question is whether the institutions involved understand the nature of that commitment. They are not simply buying a product. They are stepping into a governance process that existed before their deployment and will continue long after their contract ends.
The institutions that invest in that relationship – that send someone to the working group, contribute to the specification and treat the protocol community as a constituency rather than a supplier – will end up with something no procurement process can deliver: infrastructure that grows with them, not against them.







Nice post and definitely a trend to watch... note there are definitely protocols that haven't really seen a ton of adoption like the World Banks open contracting standard. That said I definitely like this trend and vision and want to help bring it about. Makes a lot of sense. I don't think purely open though will be the answer. To use an open source example and mathematical analogy, rather than purely open software the way of the future will involve clopen set like tools similar to the Apache foundations airflow tooling who's initial direction largely came out of Airbnb's workflow orchestration workflows