Some of the governments I've spoken to are in open disputes with their software vendor. Unpaid bills, lawyers involved, and a national system that nobody is allowed to touch while it all gets argued out.
They didn't set out to become open source advocates. They were forced into it.
The short answer: for national systems like identity and civil registration, open source digital public goods usually win on cost, speed and control, because there's no licence fee and no single vendor holding the keys. Proprietary can still be right when an existing system works well and has done for years. The real risk isn't proprietary software itself. It's lock-in: when you can't change supplier, move your data or fix things without one company's permission.
Key facts:
- Plan International's research before OpenCRVS found existing digital CRVS software was typically subject to vendor lock-in, hard to use and rarely interoperable (OpenCRVS)
- DPI can legitimately be built with proprietary software, as long as it follows open specifications (CDPI)
- The Asian Development Bank frames the trade-off as high licensing costs and switching costs versus lower lifetime costs and multi-vendor competition (ADB)
What does vendor lock-in actually look like?
It rarely starts badly. A vendor wins a tender, builds the system, and it works. Then, a few years in, the pattern shows up:
- Every change request is priced by the one company that can do it
- The data sits in formats only that vendor's tools can read
- The licence renewal arrives with a number nobody budgeted for
- The team that understood the system has moved on, and the knowledge left with them
By then, switching looks more expensive than paying. So governments pay. Until they can't, and that's when the disputes start.
I've been pulled into plenty of these conversations. The phrase that comes up, more often than you'd think, is "held to ransom".
Open source vs proprietary side by side
| Proprietary | Open source DPG | |
|---|---|---|
| Licence fee | Usually, often recurring | None |
| Who can implement | The vendor, or its approved partners | Any trained systems integrator |
| Who can support it | Usually the vendor alone | Local teams, regional partners or global firms |
| Your data | Can be locked in vendor formats | Must be extractable (a DPG Standard requirement) |
| Code visibility | Closed | Open for anyone to inspect |
| Switching cost | High | Low: change your partner, keep the system |
The last row is the one that matters. With a DPG, if your implementation partner disappoints you, you change partners. The system stays.
Is open source secure enough for national systems?
This is the second question I get, right after "how can it be free?"
The honest answer is that security comes from how software is built and tested, not whether the code is visible. Good DPGs build security in from the start and test it independently. OpenCRVS, for example, has every release penetration tested by an independent, CREST-certified firm.
And open code has a trick closed code can't match: anyone, including your own security team, can check it.
The bigger risk, in my experience, is the deployment. More on that in what happens after go-live.
When is proprietary the right call?
This is where I'll disagree with some of my open source friends.
If a proprietary system has worked well for decades, the data is clean, the costs are sensible and the vendor behaves, don't move for moving's sake. Migration carries real risk, and "it's open source" isn't a business case on its own.
The case for switching gets strong when:
- Costs keep rising and you can't benchmark them
- You can't get your own data out cleanly
- The system can't talk to your new ID, payments or data exchange rails
- You're already in dispute with the vendor
If two or more of those are true, you're not really choosing a technology any more. You're choosing an exit.
How do governments get out of lock-in?
Carefully, and in this order:
- Secure your data. Get a full, documented export before anything else happens.
- Run in parallel. Stand up the new system alongside the old one, starting with a pilot region.
- Migrate in stages. Move records and workflows in batches, checking as you go.
- Build local capacity. Train your own people and a local partner, so you're never this dependent again.
A pilot on a DPG can be live in around three months. That's often faster than the renegotiation you were dreading.
Why governments still hesitate
For most governments, procurement is the real obstacle. Many ministries, especially in frontier and emerging markets, simply aren't set up to procure open source. Their tender templates assume a licence, a vendor and a long contract.
That's changing, slowly. Development funders are often the ones pushing it, because they've seen what lock-in costs.
Frequently asked questions
Is open source software safe for government use? Yes, when it's built with security by design and independently tested. Open code also means your own team can inspect it.
What is vendor lock-in? When you can't change supplier, move your data or change your system without one vendor's permission and pricing.
Can governments switch from proprietary to open source? Yes. The safest route is data export first, then a parallel pilot, then staged migration.
Is open source always cheaper? There's no licence fee, but you still pay for implementation and support. Over the lifetime of a system it's usually cheaper, mainly because you can change partners. See is open source government software really free?
Sources
- Our story, OpenCRVS
- DPG and DPI, Centre for Digital Public Infrastructure
- Roundtable deck on DPG-based approaches, Asian Development Bank
- Security, OpenCRVS documentation
Stuck with a vendor and weighing your options? Let's talk.
