Intro
For the last 15+ years, I’ve worked as an advisor to organizations large and small, from big corporations to public broadcasters to start-ups, and these last few years primarily for foundations, NGOs and the public sector. One of the strong themes of this work has been the focus on public interest technology: As vaguely defined this space might be, I think it’s more than worth engaging with technologies that serve first and foremost the public interest, not shareholders.
So here I present to you a series of reflections on that space. It’s not a definite publication, not a final word: These are my thoughts as a practitioner in the space who comes at things from a governance / policy / power dynamics perspective. This is, in other words, an unapologetically opinionated document. Some of the ideas here are more universal, some might be a little more controversial. Everything that is included here has been useful at some point or another in discussions around the role of public interest tech, its funding and governance, the policies surrounding it.
This booklet is for policymakers, funders, public-sector leaders, civil society organizations, and technologists. It is meant as a conversation starter, not a definitive framework. Use it to ask better questions about who benefits, who governs, who pays, who maintains, and who is accountable.
Hopefully, some of it will be useful to you, too.
This is also available in PDF format. This is a living document and might change over time.
Definitions and framings
First up, what are we talking about when referring to public interest technology (short: PIT)? Most definitions refer to technologies serving “the public good.” As frustratingly vague that may be, this is what I will also be using, simply because I find it more useful to cast a wide net than to go too narrow and get lost in struggles about definitions.
For our purposes, Public Interest Technology is any (fully or partially) digital technology that serves the public good. More specifically, that prioritizes the public good over other (legitimate) purposes like shareholder value.
Please note that this does not specify:
- Who creates, operates or maintains the technology.
- For what other purpose they do so, for example for commercial or non-commercial reasons.
- Who pays for the technology (governments, users/consumers, businesses?) and how (usage fee, taxes, licenses?).
- What type of technology it is: An app, infrastructure, a protocol, a piece of hardware?
In many cases, none of these things matter; in most, only some matter, and then I’ll be calling them out as needed in the context.
Maybe most importantly, I do not want — nor dare — to define what “public good” means. This question can be highly contentious, but also easily can be a proxy for other, deeper questions of framing. Again, for our purposes I’m casting a wide net. That said, it is always, always, always worth not just asking is it good but rather whom is it good for? Who stands to profit?
If the answer is “the majority,” that’s certainly a starting point, but no more than that. If it’s something along the lines of “it helps balance out a former power imbalance,” things are getting much more interesting. If it leads away from zero-sum (or negative-sum) scenarios and towards positive-sum scenarios, all the better. In the meantime, I recommend getting comfortable with the ambiguity.
A note on some personal biases and beliefs
Since I already disclosed that this document reflects my personal opinions, here’s one: If a technology can contribute to reducing power and market concentration by shifting control and power away from big global corporations and into more decentralized, more open, more publicly governed structures, I’m likely to be in favor.
The rapidly expanding market consolidation we have seen over the last 15 years during the rise of big tech platforms leads to a concentration of both wealth and power in just a handful of companies who barely have any governance mechanisms in place to fetter the founders’ impulses. At the same time, many of these founders have garnered immense wealth, and started to put this wealth — and their technologies — to use for political influence. This is not good. In fact, I think it’s one of the core issues of our times that are keeping us, as a society, from addressing the big challenges we face.
7 core themes
This document is centered around seven guiding principles or themes, which I look at from various angles. I consider them the distillation of the core ideas here, so going forward, I recommend keeping these in mind.
1. Public interest tech is about power, not just purpose
Public interest tech is not just about purpose or outcomes, it is about who holds the power to define and shape the underlying technology and processes: Who writes the rules? Power and accountability for public interest tech should be in the hand of the public, through appropriate democratic mechanisms and institutions.
2. Infrastructure is the core metaphor
Infrastructure is the mental model that makes public interest technology legible. Not all public interest tech literally is infrastructure. But thinking in infrastructure terms helps clarify what kind of technology needs public funding, public governance, long-term maintenance, interoperability, standards, resilience, and accountability.
3. Incentives determine outcomes
In broad strokes, the way governments buy technology today does not align financial incentives (or procurement procedures) with desirable outcomes. To get to desired outcomes that align with overall strategic goals, we need to align incentive structures and procurement procedures.
4. The state must maintain enough capacity to govern and understand its technology
For too long, the state has been reducing in-house technological capacity (as well related areas, like design and research). Sometimes for political reasons, sometimes due to cost-cutting. For better outcomes — including increased resilience, sovereignty and long-term cost-efficiency — the state needs to build up the necessary capacities at the appropriate levels of government.
5. Procurement is strategy by other means
Procurement is one of the biggest levers for governments to make things happen. It is a core lever in how technology is bought, designed, deployed and maintained. Procurement needs to be aligned to support strategic goals, not undermine them, as today is often the case.
6. Digital services expose institutional flaws
Government digital services should not be thought of as a digital version of an analog process, not a digital translation. Due to the way digital services speed things up (and shorten feedback loops) they expose flaws, anachronisms or simply the illegibility of government structures and procedures to citizens and users. Rather than speeding up processes that citizens have a hard time using to begin with, the process of digital transformation offers a unique opportunity to reform the underlying processes and institutions. This is a big lift, but an effort with a potentially hugely disproportionate return on investment.
7. Public interest tech requires long-term stewardship
Like infrastructure, public interest tech should not live in short term tech development cycles. It should be thought of as an ongoing long-term effort that requires long-term care, maintenance and effort, both on the product side as well as the institutional side.
Incentives determine outcomes
The way incentives are structured in tech today are deeply, deeply flawed. In many dominant platform markets, we essentially reward extractive and exploitative behavior. We allow companies to externalize costs and negative consequences and to reap the benefits of their behavior. I don’t think this happens on purpose as such, though of course there are many who argue for exactly those structures, mostly under the umbrella term of “deregulation” and/or the much more harmless sounding “cutting bureaucracy.” (When a Musk or a Thiel argue for deregulation, or industry self-regulation, a free pass for extractive and exploitative behavior is what they are really asking for.)
Governments are often asked to step back, let private companies do their thing, then buy the resulting products — often at inflated prices. And more often than not, that is exactly what happens! However, this creates a terrible reward and incentive structure. Governments and administrations give up their agency to buy (often sub-par) software stacks and applications for inflated prices, while getting themselves locked-in to specific vendors. We see this happen all the time, all over the place. This is the opposite of how things should work.
Where governments buy from companies, we should reward best practices instead, i.e. align incentives with desired outcomes: Contributions to open source (which contribute to a stronger, healthier, positive-sum ecosystem). Open interfaces and standards (which allow mobility between vendors, i.e. they allow governments to switch things up, which contributes to healthy competition). Top-notch security practices and transparency.
Government procurement should prioritize these aspects whenever possible. Re-aligning incentive and reward structures won’t in itself fix all the issues, but it is an important step. As it stands, we often are literally paying companies to undermine strategic goals like digital sovereignty, security and resilience.
Who should be building the tech stack?
In the realm of digital technologies, we have an overwhelmingly strong narrative that industry knows how to do it and governments don’t. Historically, that argument has not been without merit: Many governments have been lagging behind sorely. That said, some decidedly have not. What Estonia and the UK have been building with their government digital services teams has been nothing if not impressive, and they have been doing so for many years, almost decades by now.
Industry, in the meantime, has no interest in ceding that ground to governments. (And of course we wouldn’t want governments to build everything, either. Unless you want to give up on the market-based economy completely, which personally I don’t, because I’ve not yet seen a convincing alternative proposal.) So the magic, it seems, is in the mix.
When it comes to the public interest sectors of tech, governments have a role to play. They might build things themselves, hire companies to build, or coordinate and regulate companies building things. In either case, they need a strong political mandate, significant budgets, and enough in-house capacity to at the very least understand well what it takes.
As a rule of thumb, the closer we get to the infrastructure level, the more governments should be involved. The more we get to the top-level service layers (apps, etc.), the better placed are companies. There are deviations from this very rough rule, and lots and lots of middle ground, but that’s my baseline.
Government digital services should be built much more in-house, I think. Some work can be outsourced. Governments should get a lot more involved in providing financial support to open source infrastructure as well, through procurement, commissioning, grants and other mechanisms. (Disclosure: I have been working for a long time with Germany’s Sovereign Tech Agency, who pioneer a lot of this work.) This isn’t just the right thing to do, it’s also a strategic imperative to increase resilience, strengthen sovereignty and reduce dependencies and costs.
The service layers could very well be built by the private sector and either just bought off the shelf or customized per government specs or built in-house. In those cases, I think it depends on how crucial they are. Again, as a rule of thumb: The more crucial, the more they should be built in-house. If possible, they should then also be made available to other public sector organizations so as to build up a pool of freely available, vetted, high quality software ecosystem.
Why do we need Public Interest Tech in the first place?
It might be worth taking a step back for a moment to zoom out. Why do we need Public Interest Technology in the first place? The answer to that is both complex and simple.
It’s complex, in that one can argue that requiring public interest tech is in itself a symptom of a larger market failure, that — theoretically, allegedly — the market should solve all technological needs and demand and supply should meet more or less perfectly, or as perfectly as any other system. To which the counter-argument is, of course, that this has never really quite worked, that government or other interventions were and will always be necessary, and the question is just how, or how much. In other words, it’s complex in that it is a litmus test for which general world view a person holds.
It’s also simple, if we leave the philosophical level for a moment. We need it because everyone benefits from infrastructure. Infrastructure is one of the rare examples where if it works well, there are basically no losers. Infrastructure is an example of positive-sum thinking: It allows for more parties to do more of whatever they want to do. (Exceptions apply, of course, but stay with me for a moment.)
Arguably the most popular examples for infrastructures are sewage and roads/bridges: Sewage, because it’s pretty much a pre-condition for life: Such a basic need to be solved that workarounds are barely imaginable in a modern society. Sewage is table stakes.
And roads/bridges, because they allow for other things to happen. They allow us to move both ourselves and our goods. By doing so they create a foundation for business and construction, for every type of economic engagement as well as the building of more infrastructure. Roads and bridges are empowering technologies.
Both examples share that they make for comparatively weak business models, which is why (in most countries) they are run by the government (often but not always indirectly through companies that do the work under government contracts).
So if that is the basic argument for infrastructure, then we can take a step towards public interest technology. The overlap with infrastructure is significant, but it’s often not widely discussed in those terms. This is, I think, mostly because especially digital public interest tech, which is what this document is about, is reasonably new. It’s often bundled up with consumer technology, basically because it involved computers or the internet, both of which carry associations of consumer electronics. Increasingly, though, the framing includes infrastructure thinking, which is good and necessary.
At the risk of gross oversimplification, big chunks of the internet run on open source software. Equally, big chunks of the technological system that at some point interface with the internet — so just about everything — run on or benefit from open source software. That right there is most definitely public interest technology. (Once more the disclosure that I’ve been working with Sovereign Tech Agency, a government program to finance maintenance and security work in that space.)
This is a no-brainer: These are roads and bridges, but maybe even more so as they are more widely available, in many cases more widely used, more central and foundational to tech stacks. Frankly, to stacks upon stacks of technology. To whole ecosystems of technology. Yet, maintenance is, in many cases, woefully under-funded, at great risk to everyone who uses a thing that in turn relies on this digital infrastructure. If this essay here was a more formal document I would wrap this up in crisper terminology, but this is what it boils down to: We need this — we all need this — and we need it to work: Reliably, securely, resiliently, always. So we need to make sure people get to put in the hours to keep this safe and working and to keep improving as well.
Also and especially since we just learned that new AI models are excellent at identifying and exploiting security risks, so the attack vectors for these types of infrastructure building blocks and systems just multiplied.
As we move up the stack from the more unambiguously infrastructure-type technology and venture more into the application layer of things (I’m hedging a little here, because the boundaries aren’t always super clear), things get a little more fuzzy. This is where the private sector might be better placed, or at least where services don’t necessarily need to be financed or provided by governments. They might still be public interest tech or even if they’re not, they might be de-facto infrastructure.
For example:
- Government digital services, like digital company registration, appointment booking, etc.: Absolutely public interest tech, absolutely infrastructure. No question.
- The German government ID/Passport verification app: Definitely public interest (at the domestic level), definitely infrastructure, even though it’s not widely used. Also, if I may be a little snarky here: Alas it’s not good software. To me, this seems to be a negative example of a government-backed monopoly with a use case but no business model. More and more we are forced to use it but it’s so much more finicky than it should be. Maybe here it would be better to invest in standards or protocols or open source software building blocks than commissioning a piece of software that just doesn’t deliver.
- Google Maps: To me, this is functionally infrastructure, because it’s extremely dominant and also other sectors build on top of it. But is it public interest tech? Unclear to me, because the value extraction happens primarily through one company (Alphabet/Google). So: Maybe? It certainly doesn’t need public funding. Does it need public oversight?
Looking at these, it becomes obvious that there is a spectrum, and it’s full of edge cases. If in doubt, I recommend casting a wide net rather than narrowing down.
In the end, there is much upside to having the best possible digital infrastructure, and to have it as much within the larger system of democratic governance and oversight. As with all infrastructure thinking, it’s about not being too prescriptive. Rather, to build and evolve with the potential for emergence in mind.
Power dynamics
Around digital infrastructure, we tend to see a power imbalance between governments and industry. This is both odd — after all, governments should theoretically be in charge — and often unacknowledged.
But for decades, the dominant narrative has been that the private sector innovates while governments are just burdensome regulators and/or buyers of last resort: If an important company can’t sell successfully on the free market, a government might step in as a buyer, but other than that the state should mostly get out of the way. Make space for the big, innovating private sector companies.
Mariana Mazzucato makes a compelling case (I’m paraphrasing) that the state’s lack of capacity to innovate is not just a myth, but a vastly misleading narrative because it minimizes the role of the state. That this in turn reduces policy ambitions and leaves the public sector — and the public — carrying the risk while private industry captures the rewards.
There is a middle layer that both contributes to this imbalance and benefits greatly from it, too: The big consultancies. These so-called Big Four + McKinsey wield tremendous power over how tech is made, bought and deployed, because they act as middlemen between state and businesses, and they regularly manage to insert themselves deeply into policy and strategy decisions.
As Mariana Mazzucato and Rosie Collington argue (again, I’m paraphrasing) this leads to even less in-house capacity for tech-related issues inside of governments. So with those consultancies involved, the tech gets build in the private sector, but even understanding and defining the requirements — all the meta — is outsourced, too. It’s the opposite of empowering, it further strengthens how dependent the public sector is from private companies.
So one necessary step towards more resilience and sovereignty in public digital infrastructure is to reduce these dependencies from both industry and consultancies, and to build up in-house capacity and expertise. In the long run this leads to both cost-savings and to better results.
Procurement and other levers
Governments have several levers to change things at scale. When it comes to digital infrastructure, the main ones are legislation and procurement.
Through legislation, governments can set the ground rules. This is powerful, but often perceived as a blunt instrument: A heavy-handed and lengthy approach that can politically contentious.
So while it may not always be politically desirable or plausible, it’s possible: A government could simply, to give an example, require that all software accounts for easy data mobility in and out of the system in order to minimize vendor lock-in. If data can move freely, customers can move from vendor to vendor if there are better services or conditions on offer. It’s a countermeasure to lock-in contracts and monopolistic tendencies.
Procurement is another powerful but hugely under-used lever. Through their procurement guidelines and rules, governments can significantly shape a market for more desirable outcomes.
Historically, this has not been done particularly well. Governments and administrations tend to be risk-averse, so by the time the software requirements and specs are signed-off on, they tend to be so bloated or out of date or just removed from reality that the software that gets bought is some type of lowest common denominator. The industry lobby also likes to support this status quo as it makes for comparatively easy and reliable business: The more cumbersome the procurement process, the more it favors the big incumbents. Smaller and more agile actors simply do not have the bandwidth or runway to participate in these lengthy, complex bureaucratic procurement processes.
So what we have seen for decades now is ill-conceived software requirements with mission creep and an out-of-date approach to software development baked into the process. While contemporary software development has long since moved to agile methodologies of short sprints and quick iterations to account for newly emerging challenges and to keep things flexible for longer, government procurement is often still stuck in the old waterfall approach which attempts to give an exact roadmap and schedule for what happens how and when, very much at the cost of the final results.
It doesn’t have to be that way. In fact, it shouldn’t be that way. Procurement guidelines and processes can evolve, and they should. They should include stated goals as well as methodologies, so they can shape the software and digital infrastructure they produce or favor.
What might that look like? For example (this is an incomplete list for illustrative purposes only):
Goals and intentions:
- Public money, public code: The software stack for the public sector should be published as open source, i.e. under appropriate open and free licenses.
- Minimize vendor lock-in: It should be build with data mobility built in, as appropriate per context, to minimize lock-in.
- Data minimization: Privacy and data protection should be baked in, too.
Methodologies and approaches:
- State of the art: Follow state of the art and best practice software development and design. For example, agile over waterfall.
- Users are more important than the organization: User-centric design trumps organizational design. This means that processes in the host organization might need to evolve along with the new software.
Procurement processes also should prioritize making things easier for smaller vendors to participate and apply in order to break the quasi-monopolies of the biggest software vendors. In practice, this means a more lightweight, multi-step application process in which the first step is easy and quick, and only qualified applications progress to the next, more detailed round. Governments and administrations should also build up their in-house capacity to be better able to understand and write the requirements for what is being procured, to reduce dependencies from the big consulting firms.
Procurement is notoriously hard. The underlying laws and codes desperately need to be reformed. This is not a trivial task: It’s notoriously hard, and lots of very smart people have been thinking about this with limited success. But we know from other countries that it is possible for governments to build or procure a state of the art tech stack. The UK with their GOV.UK program have demonstrated this well over a decade ago, as has Estonia. While it is undeniably a hard and complex challenge, there is no excuse not to tackle it as there is much at stake.
This tech stack, this digital public infrastructure, is one of the levers that elevates whole ecosystems. These are interventions that are not trivial, but they come with an outsized Return on Investment, and they tend to strengthen the very systems that need to function for a state to earn and defend its democratic legitimacy. A state that doesn’t deliver essential services loses its legitimacy and weakens democracy: These are the stakes we are talking about. This is not a convenience play, it is foundational.
Learning is key: Institutions need to adapt internally, too
As the old adage goes, perfect is the enemy of the good. This goes for technology as much as anything. (I hasten to add: For non-critical systems only! If things are critical infrastructure, the tolerance for failure must beb radically lower.)
What I mean is that especially in government-backed projects, projects are often over-planned and then under-executed. Or to put it differently: There is so much work put into anticipating risks that the projects fail to do their job out in the real world, where there are always unexpected influences or events.
In order to maximize institutional learning, it is imperative to gather experience in real-world contexts — while minimizing real risks to impacted communities. This is admittedly a tough balance to strike, but I think it’s essential. While we need proper planning, we also need exposure in order to learn and iterate.
The traditional waterfall/front-loaded approach to tech planning doesn’t account for this, which is why (broadly speaking) agile approaches have become the industry standard.
For public interest tech, we need to optimize for two outcomes simultaneously: These technologies need to do their job well and also institutional learning must be part of the process.
Here’s the part where it often falls flat, and for understandable reasons: The learning must not be restricted just to better deliver software or other government “products.” Especially when it comes to government digital services, this learning is what exposes structural flaws (more on that term in a moment!) and how to tackle them.
When I say flaws in this context, I mean that for citizens these interactions with various government administrative units and processes often are unintuitive: They simply don’t make sense to someone just wanting to get something done. However, these processes might still work exactly as intended or designed in the first place: Over and over, we see a disconnect between the way a state thinks (about responsibilities, roles, processes) and the way a person thinks (about who to talk to when trying to resolve an issue, or how to get a thing done).
This is simply a case of organizational logic head-butting with the reasonable expectations and logic of a person. Two legitimate positions that are at odds. No simple solution, no right or wrong.
Traditionally, the state logic won, simply because that is where the power resided: Citizens very simply needed to figure it out, to navigate the bureaucracy. This, of course, has tremendous implications. Groups without the knowledge, resources and time to navigate bureaucracy do not get to exercise their rights, to use government services as intended, because they effectively do not have the means to access them. Groups with the knowledge, resources and time do get the benefits. It’s massively discriminating, presumably without intent. This is widely recognized by now.
Over the last decade or two, the understanding of the role of a modern state has changed. Governments today understand themselves, to a large degree, to be service providers to their citizens (and others living in the country). There are degrees to this, but this is the general gist. Citizens aren’t considered beggars asking for breadcrumbs of government services, they are who the government is in service to. This is of course not just a foundation of democratic legitimacy, but also informed (in both thinking and language) by the idea of convenience in service delivery across contemporary society. If we can pay our dinner with our phones and order clothes to be shipped to our home with minimum friction, we collectively kind of expect similar frictionless service delivery from our governments.
That is, unless we interact with them, when in most countries it feels like traveling back in time. That’s not because there are no digital services or because things might require a signature on a piece of paper or a PDF. It’s because in many cases, digital services are just a thin layer on top of pre-existing processes and responsibilities. Even though government digital services look contemporary, they are still often largely a cosmetic layer on top of the same old underlying decision-making logic, the same bureaucracy we need to navigate.
This is what I mean when I say it is important to optimize for institutional learning: In order for public interest tech — and especially the subset of public interest tech that serves to deliver government digital services — to work, the administration also needs to rethink internal processes and workflows. This is much, much harder than building the tech stack or an app. It means administrative reform. Learning how people interact with services and the way their intuitions and expectations clash with existing structures is tremendously valuable information. It should guide how internal information flows and decision-making procedures need to be adapted to really deliver these services. Only if these services can be used easily — if they are accessible to all groups — does the state deliver on its mission, and earn its democratic legitimacy.
So for state actors building out their government digital services, it is key not just to learn about the process of building digital government products, but also about how they need to adapt the underlying structures to make them work for all citizens and users.
So what to do now?
We’ve touched on power dynamics, market failures as well as aligning procurement and institutional learning. Let’s get a little more specific, make things a little bit more actionable for the public sector and for policy makers.
There are concrete approaches that are likely to lead to better outcomes. By better, I mean that as a rule of thumb I assume the following priorities will lead to more desirable long-term results:
- Public interest
- Resilience
- Sovereignty
Where conflicts between these and other potential priorities arise, the trade-off should prioritize this list over others, including but not limited to: apparently simple turnkey solutions, proprietary or licensed software, shareholder value, and others.
Here are some concrete measures I recommend:
Heavily investing in open source (both the tech stack and the larger ecosystem) pays significantly towards resilience while simultaneously removing some of the ill-aligned commercial incentives. As a bonus, it reduces (technological, geopolitical) dependencies, and contributes to a positive-sum innovation and security cycle. Note: I cannot stress enough how much this is preferable to protectionist approaches that would force public sector buyers to just buy equally proprietary and restrictive software from domestic/European vendors.
Reforming procurement rules to align with these strategic priorities provides powerful leverage to align government procurement with government strategy rather than undermining it. This requires reform of both the goals and conditions of procurement as well as the processes: While one can help, for example, with prioritizing open source and interoperability, the other can help bring smaller actors that would otherwise be functionally excluded by the complexity and bureaucratic overhead of traditional procurement processes.
Public interest technology might require institutional reform. Depending on the context, public interest tech is not just about adding a thin veneer of digital on top of existing processes and responsibilities. For things to work well via digital channels, it might be necessary to rethink the underlying structures. The public interest technology may be just the occasion for reform rather than the goal itself.
Public sector institutions need in-house expertise and capacity. While it is entirely acceptable (and in many cases desirable) for governments to outsource work to the private sector, there needs to be enough expertise and capacity in-house to truly understand the needs, requirements and implications of technology-related decisions. To increase expertise and capacity, there are a range of possible actions including (but not limited to) hiring or up-skilling staff and setting them up for success with robust mandates; embedding in-house experts with their industry counterparts or vice versa for mutual learning; setting up or strengthening cross-government tech, design and innovation units that serve as public sector support that is outsourced, but more institutionally aligned; and increasing knowledge exchange between public sector institutions to grow the pool of shared, accessible and actionable knowledge.
Consolidate accountability in-house so that the decision-makers end up with the accountability. Nothing sets up tech projects for failure like accountability that is diffused downstream between external vendors and legal arrangements so that no one has to take actual accountability. Without skin in the game, there can be no real accountability.
Take the long view. Many of these proposed approaches take time and effort. However, they do have clear and positive pay-offs. They lead to more desirable outcomes, while in the long run also leading to cost-savings. And better service delivery across the public sector also strengthens the trust in democratic institutions and the state. Don’t optimize for the duration of the legislature. Instead, take the long view and invest the necessary time and effort to get to actually good results.
Individually, none of these measures are a silver bullet to solve all issues. However, together and over time they can make significant contributions to putting the public sector in a much, much better position to deliver towards public interest technology and to strengthen trust in public institutions while doing so.