Governments around the world spend billions each year on proprietary software—systems locked behind vendor contracts, opaque codebases, and renewal fees that grow like clockwork. Open source software promises an alternative: transparent, adaptable, and free from vendor lock-in. On paper, it sounds like exactly what public institutions need.

But the reality is far messier. Despite decades of advocacy and a growing number of success stories, open source adoption in government remains uneven, slow, and often misunderstood. The barriers aren't primarily technical. They're structural, institutional, and deeply embedded in how governments buy, build, and maintain technology.

Understanding why open source struggles in government contexts—and where it thrives—requires looking beyond the code itself. It means examining procurement rules designed for a different era, workforce constraints that undermine sustainability, and the few models that have managed to bridge the gap between open source ideals and public-sector realities.

Government procurement is designed to manage risk, ensure fairness, and prevent corruption. These are worthy goals. But the mechanisms built to achieve them—competitive bidding, vendor evaluation matrices, multi-year contracts—were designed around purchasing products, not adopting collaborative software ecosystems. Open source doesn't fit neatly into the boxes that procurement officers are trained to check.

When a government agency issues a request for proposals, evaluators typically score responses on criteria like company size, past performance on similar contracts, and warranty terms. Open source projects, often maintained by distributed communities or small nonprofits, struggle to compete on these dimensions. A proprietary vendor with a polished sales team and a track record of government contracts will almost always score higher, even if the underlying technology is inferior or more expensive over time.

There's also a subtler problem: open source software is often free to acquire but requires investment in implementation, customization, and integration. Procurement systems are better at authorizing large upfront purchases than ongoing service arrangements. The result is a structural bias—not against open source in principle, but against the shape of investment it requires. Buying a product is straightforward. Funding a capability is not.

Some jurisdictions have tried to address this through open source mandates or "consider open source first" policies. These help, but they often lack enforcement mechanisms. Without changing the underlying procurement infrastructure—evaluation criteria, contract templates, spending authorities—policy mandates tend to produce compliance theater rather than genuine shifts in how technology decisions get made.

Takeaway

The biggest obstacle to open source in government isn't skepticism about the technology—it's that procurement systems are optimized for buying products, not building capabilities. Changing outcomes requires changing the rules, not just the rhetoric.

Open source advocates sometimes undersell a critical truth: free software isn't free to operate. Every system needs patching, security monitoring, version upgrades, and adaptation as requirements change. In the private sector, companies with strong engineering teams handle this routinely. In government, internal technical capacity is often thin, underfunded, or focused entirely on keeping legacy systems alive.

This creates a dangerous pattern. An agency adopts an open source tool—perhaps a content management system, a data platform, or a citizen-facing application. Initial deployment goes well. But within a year or two, the system drifts behind the upstream project. Security patches go unapplied. Custom modifications make upgrades risky. The team that championed the adoption moves on or gets reassigned. What was once a promising alternative becomes another piece of technical debt.

The maintenance challenge is compounded by government pay scales and hiring constraints. Retaining developers who can contribute to and maintain open source systems requires competing with private-sector salaries. Many agencies can't. So they end up hiring contractors to manage open source systems—which sometimes costs as much as the proprietary alternative would have, while adding coordination overhead and reducing institutional knowledge.

None of this means open source is a bad choice for government. It means that adoption without a maintenance strategy is a recipe for disappointment. The question isn't whether to use open source. It's whether the organization has a realistic plan for sustaining it over the five, ten, or twenty years that government systems typically need to operate.

Takeaway

Adopting open source without building the capacity to maintain it is like buying a house you can't afford to heat. The real cost of any technology isn't acquisition—it's the sustained investment required to keep it healthy over time.

Despite these challenges, some governments have found ways to make open source work—not by ignoring the obstacles, but by designing around them. The most successful approaches share a few common features: shared investment, dedicated capacity, and institutional structures that treat open source as infrastructure rather than a one-time project.

Collaborative models are among the most promising. When multiple government agencies pool resources to develop and maintain a shared open source platform, the economics shift dramatically. Italy's public software catalog, France's investment in interministerial open source units, and the U.S. Digital Service's promotion of shared code repositories all demonstrate that collective action can solve the maintenance problem that defeats individual agencies. No single city needs a full-time team maintaining its permitting software. But fifty cities sharing one platform can sustain a robust team together.

Another pattern that works is the creation of dedicated digital service teams within government—groups like the UK's Government Digital Service or Canada's Canadian Digital Service. These teams build internal engineering capacity that can evaluate, deploy, and maintain open source tools. They also serve as institutional advocates who understand both the technology and the procurement landscape well enough to navigate the gap between them.

A third approach involves structured partnerships between government and open source communities. Rather than simply downloading software and hoping for the best, agencies that invest in upstream contributions, sponsor community maintenance, or fund dedicated support contracts get far better outcomes. The key insight is that open source is a relationship, not a transaction. Governments that treat it as a community to participate in—rather than a product to consume—consistently report stronger results.

Takeaway

Open source succeeds in government when institutions stop treating it like a cheaper product and start treating it like shared infrastructure—investing collectively, building internal capacity, and participating in the communities that sustain it.

Open source in government is neither a silver bullet nor a lost cause. It's a fundamentally different model of building and maintaining public technology—one that requires equally different institutional structures to support it.

The governments getting this right aren't the ones with the strongest mandates or the most enthusiastic champions. They're the ones that have aligned their procurement rules, workforce strategies, and collaboration models with how open source actually works. They've moved beyond asking should we use open source and started asking how do we build the organizational capacity to sustain it.

That shift—from product thinking to infrastructure thinking—is where the real democratic potential of open source lies. Not in saving money, but in building public technology that governments and citizens can genuinely own.