Why Does the Public Sector Keep Running SVN? Stability Is the Reference

After a presentation at a public agency, the division head closed the meeting with this:

"References matter to us. Why do we run SVN, you ask? Even when our own people say it's painful, we keep it because it's stable. Stability comes first. That is the reference."

It's the kind of remark whose weight is easy to miss in the moment when you're doing technical sales. You came to talk about how modern your product is, and the person across the table is explaining why they keep running a twenty-year-old version control system. But the more I turned it over on the way back, the more I thought it was the most accurate summary of public-sector IT decision-making I'd heard.

The real reason public agencies keep running SVN

Public agencies keep running SVN not out of laziness or ignorance, but because proven stability outranks every other value. It isn't that nobody in the organization knows Git. Their own developers complain. And still it stays, because twenty years without an incident carries more weight than any productivity a new tool can promise.

The math is rational once you look at the incentive structure. In a private company, a 20% productivity gain is an achievement. In the public sector, a single outage is an audit, a press release, possibly a parliamentary hearing. When the upside is capped and the downside is deep, the conservative choice isn't irrational. It's optimal.

Another remark from the same meeting completes the picture: "Because we're public sector, the SLA doesn't matter. Don't account for failures at all. Prepare countermeasures and present them." It sounds strange at first. An SLA that doesn't matter? But the meaning is this: probabilistic guarantees like 99.9% are useless here. What must exist is a document describing exactly what happens when things fail. Not compensation clauses but countermeasures. Not probabilities but procedures.

So what should a vendor actually do?

What a vendor should do in front of this structure is manufacture evidence of stability, not run feature demos. Writing down what we actually do:

First, we write the countermeasure documents before the feature roadmap. Recovery procedures per failure scenario, backup and restore paths, rollback steps. None of it is glamorous, but a public-sector champion needs it to get the internal review through. They don't adopt your product because they became a fan. They adopt it because it's a defensible choice.

Second, we accumulate certifications. We hold a GS Level 1 certification and are registered in the government procurement catalog, with ISO-related certifications in preparation. You can argue about whether certification proves quality. In public-sector adoption, that's not its job. Certification is the basis of accountability — it lets the person in charge say "we followed a verified process."

Third, we make the responsible party explicit. The problem with foreign open source isn't features; it's that when something breaks, nobody is obligated to show up. It's why I say directly in meetings that this is domestic, built on our own technology, and if there's a problem, I'm the owner and I take responsibility. Not bravado. It's an item the public-sector evaluator genuinely wants to verify.

Fourth, we push for a PoC. That division head ended with "we'll have to try it to know — our internal developers will review it." That's the correct order. Stability isn't proven by slides; it's proven by months of running in their environment. If you have no reference yet, all you can do is ask for the chance to build one, and that chance is the PoC.

When and how do you move off SVN?

The transition from SVN to a modern stack should move exactly as fast as stability gets proven, and no faster. A vendor pushing a big-bang cutover has failed to understand the public sector's incentive structure.

Start with one team, one system, and use the incident-free period itself as the argument for the next step. Six months without an incident becomes a line in an internal report, and that line gets the next team's adoption approved. It looks slow, but this is the only path that actually reaches the end. One small incident early on pushes the whole program back years, which is why the initial scope should be as conservative as you can stand.

For a vendor like us, the conclusion of this post is closer to self-discipline. Whenever I catch myself thinking "why is this organization so conservative" in a public-sector meeting, I go back to that division head's words. Stability is the reference. Our job is to pass that bar, not to argue with it.