Government Summit Speakers Call for Shared Investment in Open Source

Four contributors to the Government Summit at DrupalCon Rotterdam have called for changes in how public institutions procure, develop and fund the open-source software they depend on. Their written responses to The DropTimes following the summit on 28 September 2026 identify supplier contributions, shared development budgets and public investment as essential to maintaining open-source infrastructure. They argue that adopting publicly available software without helping sustain its development leaves governments dependent on resources they may do little to support.

Open-source software allows governments to use, inspect and modify code without the restrictions associated with proprietary licensing. It does not, however, eliminate the costs of security updates, accessibility improvements, infrastructure and continued development. Those responsibilities extend beyond individual government websites and the contracts through which they are delivered. The respondents describe how public buyers, government technology teams and funding institutions could take greater responsibility for the software ecosystems supporting public services.

The discussion concludes The DropTimes' four-part series examining digital sovereignty through the Government Summit. The first instalment examined the limitations of operating open-source alternatives alongside Microsoft 365, the second explored practical paths to digital sovereignty, and the third examined Drupal's contribution beyond the CMS. The final question concerns what happens after governments choose open source: who supports its maintainers, finances shared development and ensures the software remains usable over time?

Procurement That Pays for More Than Delivery

Bert Boerland, chair of Stichting Drupal Nederland, argues that software procurement must account for the responsibilities created by using shared infrastructure. Bert chaired the Government Summit's afternoon panel on whether local governments can build and sustain the digital commons they need. His response challenges procurement practices that continue to treat software licences as the principal unit of cost, even when the underlying code is freely available.

The analogy describes a problem that conventional delivery contracts do not necessarily address. A government may pay a supplier to develop a Drupal website without financing improvements to Drupal core or the contributed modules on which that website depends. Bert argues that procurement departments should ask suppliers what they will contribute upstream and require evidence of those contributions. Such requirements could encourage publicly funded improvements to benefit the wider community rather than remaining confined to individual projects.

Esmeralda Tijhoff, product owner at DICTU and a board member of Stichting Drupal Nederland, reports that Dutch public-sector tenders are beginning to reflect similar expectations. According to Esmeralda, government buyers increasingly request open-source solutions and evidence that prospective suppliers participate in the communities behind them. She regards this as progress, while arguing that changes in tender requirements must be accompanied by greater direct investment in open source.

Her observation identifies a distinction between a supplier's ability to implement software and its willingness to maintain the projects from which it benefits. However, the reported change in Dutch procurement remains Esmeralda's assessment; the supplied response does not identify particular tenders that establish how widely these requirements are being used. The distinction is important because a commitment to community participation can take different forms, from funding maintainers to contributing code, documentation and security fixes.

Mike Gifford, open standards and practices lead at CivicActions and a Drupal core accessibility maintainer, also identifies procurement as a means of sustaining open-source projects. Mike participated in the summit's morning panel on responsibility for open-source ecosystems and presented The Accessible Digital Commons: Aligning Government Procurement to Sustain Open Source. His response calls for governments to encourage companies to contribute to the projects they use, making upstream maintenance part of the value considered when awarding contracts.

The Drupal community already has guidance addressing this issue. On 24 October 2024, the Drupal Association published an open-source request-for-proposals guide and template encouraging buyers to examine suppliers' contributions and long-term support capabilities. Mike also points to the Drupal Certified Partner programme, which recognises companies contributing to Drupal's development and community.

These mechanisms offer ways to evaluate participation, but they are not government procurement rules. European public buyers must also comply with applicable requirements for transparency, proportionality and non-discriminatory competition. The practical challenge is to establish relevant, verifiable contribution expectations without making a particular industry certification the only route to a public contract. Procurement could then address not only delivery and support for an individual website but also the reusable improvements financed through public spending.

Governments as Contributors, Not Just Customers

Teun van der Vorm, general director of DICTU, argues that governments should not leave the sustainability of open-source projects entirely to suppliers or voluntary contributors. Teun delivered the Government Summit's opening keynote, The Struggle for Digital Sovereignty in Government, and participated in its morning discussion on responsibility for maintaining open-source ecosystems. His written response calls for governments to contribute working software components and provide financial support, including sponsorship.

Teun's position places responsibility on the institutions that depend on the software. Commercial contracts can finance development and operation, but they do not automatically support the wider projects on which government applications rely. Public-sector contribution would mean allocating resources for work that benefits users beyond the department commissioning it. His warning is direct: open-source software cannot remain sustainable indefinitely without support from those who use it.

DICTU provides a documented example of government participation in Drupal development. On 23 January 2026, the Dutch government IT service provider published details of its Generieke Basis Website, an open-source website generator designed to provide reusable foundations for central government websites. According to DICTU, nine internal teams developed components covering areas including content structures, user roles, security and accessibility. The organisation said that components were available publicly for reuse, while DICTU retained responsibility for maintenance and quality assurance.

The arrangement illustrates how government institutions can move beyond purchasing software and become participants in its development. Publicly available components can be reused by other departments or suppliers, reducing the need to commission equivalent functionality repeatedly. DICTU's published account also makes clear that contribution does not remove operational responsibility: the organisation must continue reviewing changes and maintaining the shared platform.

Esmeralda identifies the DICTU web team as an example of the approach she believes governments should adopt more widely.

For Esmeralda, government participation must also extend beyond the visible applications that departments commission. Proprietary and open-source systems alike depend on libraries and packages maintained by people who may receive little financial support from their users. Those underlying dependencies require security fixes, compatibility updates and continued technical attention, regardless of whether the organisations relying on them interact directly with their maintainers.

She argues that governments should sponsor contributors or become contributors themselves. Her response links that responsibility to the principle of Public Money, Public Code, which advocates making publicly funded software available for public reuse. Publishing code is only one part of the arrangement. Institutions must also decide how the software will be maintained and whether their teams have the resources to participate in its continued development.

Sharing Development and Maintenance Costs

Bert also calls for governments to pool budgets instead of separately financing equivalent modules across multiple projects. His proposal addresses the duplication that can arise when agencies commission similar functionality without coordinating requirements or contributing improvements to shared software. Joint investment could allow public institutions to finance common components once and distribute the benefits across several implementations. That approach, however, also requires decisions about ownership, priorities and maintenance responsibilities.

LocalGov Drupal provides an established example of shared government software development. At the Rotterdam Government Summit, representatives described a project that had grown from two councils sharing a Drupal codebase to approximately 70 councils collaborating on development, funding and maintenance. The initiative allows participating local authorities in the United Kingdom and Ireland to use and improve common Drupal components while retaining responsibility for their own websites and services.

The project is run and funded through the Open Digital Co-operative, whose membership includes participating councils and suppliers. Members elect a board responsible for financial sustainability and strategic direction. LocalGov Drupal also publishes a Supplier Code of Practice setting expectations for contributions, reuse and collaboration. These arrangements provide a practical governance structure for the shared development Bert advocates, although they do not establish that every participating council achieves identical cost savings.

Shared development also creates organisational challenges. Esmeralda and Rikkert Steenbergen addressed these in their DrupalCon Rotterdam session, When the Roadmap Is a Battleground: Building a Shared Drupal Platform for Government, scheduled for 29 September 2026. The published session description examined how DICTU reconciles different government stakeholders' requirements while developing a common platform.

According to the session description, DICTU's Government Drupal Platform uses more than 30 Drupal recipes and can provision government-branded websites in under ten minutes. Recipes package configuration and functionality for reuse across Drupal installations, reducing the need to repeat common setup work. The advertised provisioning time is a project claim rather than an independently verified benchmark. More significantly for shared development, the session outlined conflicts that arise when changes requested by one organisation affect the requirements of another.

These examples show why pooling development resources requires more than publishing a shared code repository. Participating institutions must decide which features belong in the common platform, how changes are approved and who remains responsible after implementation. A project that reduces duplicated development can still become difficult to sustain if maintenance depends on a small number of contributors without predictable funding.

Bert raised a related concern in a separate Rotterdam session, Sovereignty, Governance and Cost: Can FAIR Fix Drupal's Distribution?. The published session description questioned the concentration of responsibility for Drupal's software distribution infrastructure and explored whether federated approaches could address governance and cost concerns. The session proposed a discussion rather than an established replacement for existing infrastructure. Its relevance to public investment lies in the continuing resources required to distribute and maintain the software on which governments depend.

Who Funds the Infrastructure Everyone Depends On?

Mike argues that maintenance is becoming increasingly important as governments rely on open-source systems for critical digital services. His response identifies security, accessibility, performance, environmental sustainability and usability as continuing responsibilities. None can be guaranteed solely through the initial delivery of an application. Each requires investment as vulnerabilities emerge, standards change and software evolves.

Mike also warns that artificial intelligence is increasing the capabilities of both those improving digital systems and those attempting to exploit them. He regards this as another reason for governments to strengthen maintenance investment. His assessment does not establish that AI has caused a measurable increase in attacks against government Drupal installations, but it reflects his broader concern that public digital infrastructure must be supported throughout its operational life.

His Government Summit presentation connected the maintenance problem with digital accessibility. The official programme described a session examining accessibility shortcomings across European government websites using Lighthouse scan data, alongside the role of procurement and project management in supporting accessible open-source software. The session framed accessibility as an ongoing public-service responsibility rather than a feature to be addressed only during website delivery.

Mike identifies Germany's Sovereign Tech Fund as an example of public investment in essential open-source infrastructure. Operated by the Sovereign Tech Agency, the programme supports foundational software components whose maintenance and security affect users across multiple sectors. Its approach differs from commissioning an application for a particular government department because the resulting improvements can benefit a much wider range of organisations.

That distinction reinforces Esmeralda's concern about the less visible dependencies supporting government technology. Libraries, development tools and infrastructure components may be essential even when public agencies do not interact directly with their maintainers. Financing that work can strengthen the reliability of several software systems at once. It also raises questions about which projects are considered critical, how funding priorities are established and whether support continues beyond an initial award.

A subsequent European development has provided a concrete example of the coordinated funding Mike advocates. On 27 October 2026, the Digital Commons European Digital Infrastructure Consortium announced that its members had adopted a 2026–2027 implementation strategy that includes an EU Sovereign Tech Fund pilot. Led by the Sovereign Tech Agency within the consortium, the pilot is intended to commission maintenance of essential open-source components and test an investment model involving participating countries.

The decision connects the concerns raised at Rotterdam with an emerging public funding mechanism, but the distinction between approval and implementation remains important. The announcement does not establish a permanent European maintenance fund or demonstrate the pilot's results. It does show that participating governments have identified the continuity and security of shared software as responsibilities requiring coordinated resources.

From Open-Source Adoption to Shared Responsibility

The four respondents identify different responsibilities within the same open-source ecosystem. Bert calls for procurement departments to reward upstream contributions and reduce duplicated development spending. Teun argues that governments should contribute software and financial resources directly. Esmeralda emphasises institutional participation and support for maintainers throughout the software supply chain, while Mike connects maintenance investment with the quality and reliability of public digital services.

Their proposals do not depend on one funding mechanism. Government buyers could require relevant and verifiable contribution commitments from suppliers, public-sector teams could maintain reusable components, and institutions could pool budgets for common development. Dedicated funding programmes could address foundational software whose importance extends beyond any individual contract. The examples from DICTU and LocalGov Drupal demonstrate existing forms of collaboration, while the European pilot represents a newer attempt to coordinate maintenance funding across borders.

The remaining question is how consistently these responsibilities become part of public-sector practice. Procurement rules must be workable and transparent, shared development requires governance, and infrastructure funding must account for maintenance after initial delivery. For governments pursuing digital sovereignty, access to open-source code provides freedom to inspect, adapt and replace software, but exercising that freedom depends on the continued availability of maintained systems and capable contributors. The Rotterdam responses suggest that sustaining those capabilities must become part of how governments plan and finance their digital infrastructure.