In 2013, Oakland built RecordTrac, an open-source system for managing public records requests. It worked. Staff used it daily. Response times improved. The code was public, the data was portable, and the city controlled the system entirely.
Then it slowly died.
Not because the software was bad. Because Oakland didn't have the internal capacity to maintain it, and there was no external partner to fill the gap. When the original developers moved on, nobody picked it up. The system atrophied. Eventually the city went back to a vendor.
This story gets told as a cautionary tale about open source in government. But the lesson isn't that open source doesn't work for municipalities. It's that the support model was wrong — and for a long time, there wasn't a better one.
The two options that aren't enough
Municipal administrators have been choosing between two models for decades, and neither one is good enough.
Option 1: Vendor dependency. Pay a company to own and operate the system. Get ongoing support, automatic updates, and a phone number to call when something breaks. In return, give up control of your data, your configuration, and your ability to leave without a painful migration. The vendor sets the price, decides the roadmap, and holds the leverage at every renewal. This is the model most cities use — not because it's ideal, but because it's the only one that comes with a support contract.
Option 2: DIY open source. Deploy free software yourself. Get full control, full transparency, and zero licensing costs. In return, bear the entire maintenance burden with your three-person IT department that's already stretched across help desk tickets, network administration, and the city's aging phone system. This is the model that killed RecordTrac. It's the model that gives open source a shaky reputation in government — not because the software fails, but because the sustainability model does.
The choice between these two options isn't really a choice. It's a forced trade between control and capacity. You can own the system or you can keep it running. Most cities can't do both.
At least, they couldn't.
The third option
There's a model that doesn't require choosing between ownership and support. The municipality owns the infrastructure — the code, the data, the configuration — and partners with an organization that provides implementation, maintenance, and ongoing expertise.
The city keeps the blueprints. The partner keeps it running.
This isn't theoretical. It's how the world's most critical open-source infrastructure already operates. Linux — the operating system running over 96% of the world's top servers — isn't maintained by volunteers in their spare time. It's maintained by a foundation with corporate sponsors, paid contributors, and structured governance. Kubernetes, the system that powers most of the world's cloud infrastructure, is maintained by the Cloud Native Computing Foundation with contributions from every major technology company. The software is free and open. The support ecosystem is professional, funded, and accountable.
The pattern holds across every sector where failure isn't optional. The New York Stock Exchange runs critical systems on open-source platforms. The Department of Defense mandates that open-source software be evaluated on equal footing with proprietary alternatives — their reasoning is that transparency enables security, not undermines it. Hospital systems, the COVID vaccine development pipeline, Android on 72% of the world's mobile devices — all built on open-source foundations with professional support structures around them.
The higher the stakes, the more likely the infrastructure is open source. Not because it's free. Because it's auditable, adaptable, and not dependent on a single company's continued willingness to support it.
Municipal software should work the same way. And increasingly, it can.
What changed
For decades, the third option was realistic for the Linux Foundation but not for the City of Elgin. The expertise gap was too wide. A municipality might own the code in theory, but without someone who could read it, deploy it, and maintain it, ownership was meaningless.
Two things have changed that gap.
AI-assisted development has lowered the skill threshold. A technically capable city employee who couldn't have maintained a web application three years ago can now use AI tools to understand, configure, and adapt open-source systems. This doesn't mean every city clerk becomes a developer. It means the distance between “we need a full engineering team” and “we have a few technically capable staff” has narrowed dramatically. The person who understands your city's FOIA process better than anyone — the clerk who's been running it for fifteen years — can now participate in configuring the system that manages it, rather than submitting a support ticket to a vendor and waiting.
The partner model has matured. Organizations now exist that specialize in implementing, configuring, and maintaining open-source infrastructure for specific sectors. The model isn't “here's the code, good luck.” It's a structured partnership where the partner handles what the municipality can't — deployment, updates, security patching, technical troubleshooting — while the city retains ownership of the system, the data, and the ability to switch partners without losing either.
Together, these shifts make the third option viable for municipalities in a way it wasn't five years ago. The city doesn't need to hire a development team. It needs a partner who works for the city rather than the other way around — and staff who can engage with the system at the configuration level rather than being locked out of it entirely.
Why this matters more with AI
The third option is important for conventional municipal software — records management, permitting, agenda systems. It becomes critical when AI enters the picture.
When a vendor bundles AI features into a proprietary platform, the municipality gets convenience at the cost of control. The AI model is chosen by the vendor. The governance rules — what the AI can access, what decisions it can influence, how it handles sensitive information — are compiled into vendor code the city can't inspect. If the vendor's model produces biased output or makes an error that affects a resident, the city can't look inside to understand why. It can only file a support ticket and wait.
When AI infrastructure is open and the municipality owns it, the dynamic inverts. The city chooses which AI model to use — and switches when a better or cheaper one emerges. The governance rules are configurable and inspectable. The data stays under municipal control. When something goes wrong, the city can audit what happened. When something needs to change, the city can change it.
This isn't about rejecting vendors. Some vendor relationships are genuinely valuable — particularly those where the vendor is providing expertise the city doesn't have. The distinction is between a relationship where the municipality has options and one where it doesn't. A partner relationship preserves options. A dependency relationship, by design, removes them.
What the third option actually looks like
Practically, a municipality operating under the third model would have:
Open-source software at the core.
The system that manages records requests, routes permits, or processes council agendas is built on code anyone can inspect. The city can see exactly what the software does with residents' data — the same transparency standard applied to every other form of municipal infrastructure.
A support partner, not a landlord.
Implementation, configuration, maintenance, and training are provided by a partner organization. But the city owns the system. If the partner relationship ends, the city keeps everything — the code, the data, the configuration, the institutional knowledge built into the system. No export fees. No proprietary formats. No starting over.
Staff who can engage, not just consume.
The city clerk who knows every exception in the records retention policy can participate in configuring how the system handles those exceptions — directly, or by working with the partner. The configuration reflects how the city actually operates, not how a vendor's default template assumes it should.
Model independence.
If AI capabilities are part of the system, they connect through open interfaces. The city isn't locked to one AI provider any more than it's locked to one cloud host. If a better model is available next year, switching is a configuration change, not a migration project.
The ability to walk away.
This is the simplest test of any technology relationship. If the city decided tomorrow to change partners, change software, or bring everything in-house — could it? Under the vendor model, the answer is usually no, or at least not without significant cost and disruption. Under the third model, the answer is yes. The city owns what it built. That's the point.
The conversation that needs to happen
When municipal administrators evaluate technology options, the framing is almost always: build or buy? That binary made sense when building required a software engineering team and buying was the only way to get support.
The framing that fits the current moment is different: own or rent? And if you own, who helps you maintain it?
The vendor model is renting. It's often the right choice when a city has no other option. But “no other option” is becoming less true every year, and the cost of renting — measured in lost control, locked data, and dependency that deepens with every renewal — is becoming harder to justify as the alternatives mature.
Not a vendor. Not DIY. A partner for municipalities ready to own their infrastructure.
Dustin Good is the founder of CivicWork, Inc. and an at-large city councilmember in Elgin, Illinois. CivicWork builds open-source AI infrastructure for local government. Learn more at civicwork.ai.