Matthew Saunders Calls for Open-Source Funding to Move From Values to Budgets

Governments and companies that rely on open source should turn broad support for shared digital infrastructure into maintenance budgets, Matthew Saunders, AI Ambassador at amazee.io, said in an interview with The DropTimes after OSPOs for Good at UN Open Source Week 2026.

Matthew took part in the OSPOs for Good discussions during UN Open Source Week 2026, held at the United Nations Headquarters in New York from 22–26 June 2026. The interview continues The DropTimes’ planned five-part Open Source Week series examining how public institutions, companies, and open-source communities approach shared digital infrastructure. Additional interviews will be published as responses are finalised.

The conversation connects open-source maintenance funding with Drupal AI governance, human editorial review, content provenance, privacy, and collaboration practices that can make open-source participation easier for neurodivergent contributors.

Funding Open-Source Infrastructure

TDT [1]: At OSPOs for Good during UN Open Source Week, you asked whether governments and companies that depend on open source as critical infrastructure have an obligation to fund its long-term maintenance. What prompted that question?

Matthew Saunders: Honestly, it had been building for most of the week. Speaker after speaker made the roads-and-bridges comparison. They were making the case that open source is infrastructure, treat it like infrastructure. Every time I heard it I kept waiting for someone to follow it to its logical conclusion. Nobody did. The comparison kept getting made and then dropped.

Part of it is personal. I have been building on open source since 1999. Drupal specifically since around 2006. The tools I have depended on my entire career were built and maintained largely by volunteers, by people who cared deeply about the commons. I have watched projects go undermaintained, watched burnout claim maintainers, watched organisations extract enormous value from those projects without contributing anything back.

I have worked inside large enterprises long enough to know that the culture of reciprocity varies enormously. Some organisations take it seriously. Many treat open source as a free input and never think much further than that. The default posture across the industry is consumption without contribution, and nobody in those organisations is being malicious — they just have not been asked to think about it.

So when Adriana Groh from the Sovereign Tech Agency said we have built something extraordinary over twenty years and we are getting close to a point where losing it is actually possible — that landed. I wanted to put a direct question to a room that included people with actual institutional weight, not just people who already agree with me. The question is easy to nod along to in the abstract. It gets harder when you ask what the funding model actually looks like in practice.

TDT [2]: Several speakers compared open source to public infrastructure such as roads and bridges. Where does that analogy help the funding conversation, and where does it fall short?

Matthew Saunders: It helps because it shifts the frame. Most people inside organisations think about open source as a licensing question: free versus paid. The roads-and-bridges comparison reframes it as an infrastructure question, and infrastructure carries different obligations. You do not expect volunteers to fill potholes. You expect collective investment, maintenance budgets, and accountability when things break. The moment you accept that framing, the question of funding open-source maintenance stops being a niche concern and becomes a straightforward policy conversation.

You May Like

Interview

Niels de Feyter: Why Drupal 7 Upgrades Need More Than a Migration Plan

Interview

Niels de Feyter: Why Drupal 7 Upgrades Need More Than a Migration Plan

Where it falls short is visibility. A pothole is obvious. A vulnerable dependency buried four layers deep in a software supply chain is not. When the Jeju Air crash happened, the investigation was immediate and public. When the XZ Utils backdoor was discovered in 2024 — a deliberate, sophisticated attack on a critical open-source library that had been maintained essentially by one person — most of the people whose systems depended on it had no idea it existed until the story broke. The harm from failing open-source infrastructure is real but diffuse, and diffuse harm is hard to fund against.

The other limitation is ownership. With roads, the question of who is responsible is settled. The government, by jurisdiction. With open-source infrastructure, the answer is genuinely unclear. A project might be used by thousands of organisations across dozens of countries, maintained by a handful of people with no formal relationship to any of them. The roads analogy points toward collective obligation without telling you who exactly is obligated or how to structure it. That work is still largely ahead of us.

TDT [3]: You identified yourself at OSPOs for Good as someone who has worked in open source since 1999, mostly in Drupal, and currently works with amazee.io on hosting and AI. How has that background shaped your view of what institutions owe the projects they depend on?

Matthew Saunders: I came up through organisations that were not well-resourced. WESTAF was a nonprofit. Vintage Digital was a small agency. The early Drupal community was people solving their own problems and sharing the solutions because that was the culture. You contributed because that was how the thing worked, and because you understood that your ability to build anything depended on the people who had come before you doing the same.

When I moved into larger organisations, that context travelled with me even when the culture around me did not share it. I have worked on platforms serving hundreds of thousands of people across dozens of countries, running on open-source foundations. The scale of that dependency is not abstract to me — I built on top of it every day. I know exactly what it would cost to replace those foundations with proprietary alternatives, and the number is not small.

What I think institutions owe is proportional to what they extract.

If your organisation's digital infrastructure runs on open source, and for most organisations it does (whether they know it or not) then you have a stake in whether that infrastructure remains healthy. That is not charity. It is enlightened self-interest that most organisations have not yet gotten around to acting on.

The Drupal community specifically taught me something I have never forgotten: the health of a project is a function of the health of its community. Code is the output. The people, the norms, the willingness to show up and contribute — that's the actual asset. Institutions that consume without contributing are not just freeloading. They are quietly degrading the thing they depend on.

Drupal AI Governance and Human Review

TDT [4]: Your Drupal.org profile describes your work around Drupal AI, inclusive design, accessibility, and enterprise transformation. What should responsible AI adoption look like for Drupal teams serving public-sector or regulated organisations?

Matthew Saunders: Start with governance, not capability. The temptation in most organisations is to lead with what the technology can do. Those demos are compelling! The time savings are real! The pressure to move fast is genuine! But in public-sector and regulated contexts, the question that matters is not "can we do this?" It is "who is accountable when something goes wrong?"

That means building human oversight into the workflow from the beginning, not bolting it on afterwards. Drupal already has the architecture for this — editorial roles, content moderation, publishing workflows, revision history. When AI is introduced into those workflows, the governance layer should extend naturally. A model can draft. A human approves. That is not a constraint on what AI can do. It is the system working as it should.

Data residency and privacy are non-negotiable in regulated environments. Where is the model? Where does the prompt go? Who can see it? In healthcare, in government, in any context where the data is sensitive, those questions need answers before the first integration goes into production, not after. The organisations that skip this step are building liability they have not accounted for.

The third thing I would say is: be specific about what the AI is allowed to be confident about. In a clinical context, a wrong answer is not a minor inconvenience. In a government portal, a hallucinated policy is a real harm to a real person. The content model in Drupal is the constraint. The AI should answer from what has been published, structured, and approved. It should never come from the full weight of its training data. That boundary needs to be designed deliberately.

Responsible adoption is slower than irresponsible adoption.

TDT [5]: A Drupal AI webinar profile says your work helps organisations adopt AI in ways that respect privacy, transparency, and human decision-making. What should Drupal teams protect first when AI becomes part of content, editorial, and operational workflows?

Matthew Saunders: Human judgment at the point of publication. Everything else can be augmented, accelerated, or automated to some degree, but the decision that something is ready to go in front of an audience should stay with a person. That's the line I would defend before any other.

The reason is practical as much as principled. AI systems are confident by design. They do not naturally surface uncertainty or flag the edges of what they know. In a content workflow, that confidence can move things through a pipeline faster than anyone intended, past the review steps that exist for good reasons. 

The editorial workflow in Drupal is not bureaucracy. It is the mechanism by which an organisation stands behind what it publishes. Protect it.

The second thing to protect is provenance. Content needs to carry a record of how it was produced — what was human-authored, what was AI-assisted, what was AI-generated and then reviewed. Not because that information always needs to be public, but because without it you cannot audit, you cannot correct, and you cannot be accountable. Drupal's revision history is the foundation for this. The discipline is making sure AI contributions are captured in that record, not laundered through it.

The third is the data you send to the model. Most teams do not think carefully enough about what is in the prompt before they send it. In a Drupal context, that might mean unpublished content, user data, internal editorial notes, information that was never meant to leave the organisation. Once it has left, you don't control it. Know what you are sending and to which model, running in which infrastructure, under what terms. That conversation needs to happen before the integration is built, not after.

Neurodivergent Participation and AI Support

TDT [6]: You have publicly connected your work with neurodiversity and inclusion. What should open-source communities change in their collaboration practices to make participation easier for neurodivergent contributors?

Matthew Saunders: Start by auditing where contribution actually happens. Most open-source communities say they are welcoming, and most of them mean it. But the default collaboration infrastructure are synchronous meetings, real-time IRC or Slack channels, in-person sprints, that make up unwritten norms that take years to learn. This evolved around a particular kind of participant. Someone who can decode social cues quickly, who thrives in fast-moving conversation, who can absorb unstated expectations and adapt on the fly. That is not everyone.

The single highest-impact change is documentation. Not just technical documentation but let's build out process documentation. We need to know how decisions get made and how a patch goes from idea to commit. What the norms are around disagreement. What "good enough to merge" looks like. When that knowledge lives only in people's heads, or in conversations that happened years ago in channels that are no longer searchable, the barrier to entry is not a skills gap. It is an access gap. Neurodivergent contributors, and frankly many non-neurodivergent ones, hit that wall and conclude the community is not for them.

Asynchronous-first communication removes a category of barrier entirely. Not every discussion needs to happen in real time. Written communication gives people time to process, to compose a response that reflects what they actually think, to participate without the cognitive overhead of managing a live social environment simultaneously. The communities I have seen do this well produce better decisions, not just more accessible ones.

Code of conduct contacts and clear escalation paths matter more than most communities realise. For someone who has spent a lifetime navigating social environments that were not designed for them, the absence of a clear and trusted process for raising concerns is not a minor inconvenience. It is a reason not to invest.

The last thing I would say is: stop treating neurodivergent contributors as edge cases to accommodate. The same traits that make neurotypical environments difficult — pattern recognition, deep focus, directness, a low tolerance for process that does not make sense — are often significant strengths in open-source work. The question is whether the community is structured to make use of them.

TDT [7]: AI is often sold as a productivity tool. How can it also function as a support or accommodation tool without becoming surveillance, pressure, or a replacement for human support?

Matthew Saunders: The distinction that matters most is who controls it. An AI tool that helps me manage my own attention, structure my own thinking, or communicate in ways that work better for me — and where I decide what it does, what it sees, and when it runs — is an accommodation. An AI tool that monitors my output, flags when my productivity drops, or generates reports for my manager is surveillance with a productivity label on it. The technology can be identical but the power relationship is completely different.

An AI tool that monitors my output, flags when my productivity drops, or generates reports for my manager is surveillance with a productivity label on it.

I have used AI this way myself. As someone who is late-diagnosed autistic with ADHD and dyslexia, there are real friction points in how I work — processing written information quickly, keeping track of threads across a long document, getting words from my head onto a page in a form other people can follow. AI genuinely helps with some of that. But it helps because I chose it, I control it, and nobody else has access to what I do with it.

The pressure problem is subtler and worth naming directly. When AI tools are introduced as productivity accelerators (and they usually are) the implicit message is that output should increase. For neurodivergent workers who have spent careers developing workarounds just to hit the baseline everyone else takes for granted, "now you can do even more" is not a relief. It is a new ceiling to fall short of. Accommodation means reducing friction to reach your actual capacity. It shouldn't mean raising the bar.

The replacement question is where I get most direct. Human support: managers who understand their teams, colleagues who notice when someone is struggling, reasonable adjustments that reflect a person's actual situation cannot be automated. AI can help a person navigate a system but it can't replace a workplace culture that takes inclusion seriously. Organisations that reach for AI tools as a substitute for that culture are not solving the problem. They are buying something that looks like a solution from a distance.

The test I would apply is simple: does the person the tool is supposed to help have genuine control over it? If yes, it might be an accommodation. If someone else controls it, it is something else.

From Values to Budgets

TDT [8]: If governments, OSPOs, funders, and open-source communities could take one concrete step together before the next UN Open Source Week, what should it be?

Matthew Saunders: Agree on a number.

Not a framework. Not a set of principles. Not a working group to develop recommendations for a future working group. The number is specifically, what percentage of an organisation's technology budget should flow back into the open-source infrastructure that budget depends on.

The reason is that everyone agrees open source is critical infrastructure. Everyone agrees it is underfunded. Everyone agrees the current model: where a small number of maintainers carry an enormous and growing burden while large institutions extract value without contributing is not sustainable. Then I see the conversation move on. I think because agreeing that something is a problem is comfortable and agreeing on what to do about it isn't.

A number forces the conversation to become real. It surfaces who is willing to act and who is not. It gives OSPOs something to take back to their CFOs. It gives funders a benchmark against which their own contributions can be measured. It gives open-source communities a basis for advocating to the institutions that depend on them rather than simply hoping those institutions eventually figure it out.

I am not precious about what the number is. Half a percent of technology spend directed to the open-source projects an organisation materially depends on would represent a significant shift from the current baseline for most large organisations. The Drupal Association, the Linux Foundation, the Apache Software Foundation have a maintenance burden they carry. Compared with the economic value they enable in a company, that is not a difficult case to make once actual figures are put next to it.

The step is to stop treating this as a values conversation and start treating it as a budget conversation.

Values conversations produce endorsements. Budget conversations produce cheques.