Why Government Founded Software should be Open Source

Ben Ferrum
4 min readApr 6, 2021



Why every government founded software project should be Open Source?

Let’s see the strongest arguments:

  • Public Good: What is government money? It is redistributed taxpayer money, so if a citizen is paying for something, they should be able to at least see it, and even better, get it and reuse it.
  • Free to Copy: Open Source Code is copyable and duplicatable for free, and one government founded software project could pave the way for a startup.
  • Transparency & Trust: Spending money and transparently showing the results is a good way to build trust (and maintain accountability on multiple levels)
  • Security: Turning an existing project into an OS one could have some hiccups if the security is not looked after; however, in the long term, open-source software is more secure because more eyes are on it, and the maintainers have a better incentive structure to create higher quality secure code, because of the public accountability. (RISC-V, Linux, Android etc.…)
  • Reusability: Even if a long drawn government project fails, pieces of the produced OS code could spear millions of taxpayer money on later ventures because they don’t have to reinvent the wheel every time.
  • Maintenance: If a project is successful long term maintenance with government-paid code curators and community maintenance organizers should be easily solved to push it to an even higher level. A lot of OS project go on for decades without any founding. Therefore a little taxpayer money could provide enormous benefit given the leverage potential of any software.
  • Scalability: If a project is important and useful for the public, more and more people will use it, which will cause more and more pressure on the developers. However, if a citizen is allowed to propose changes (or pay/ask someone to propose them), it could help to close circuit a lot of problems and close out the slow-reacting bureaucracy. (Linux 10000+ maintainers https://github.com/torvalds/linux/blob/master/MAINTAINERS)
  • Interoperability: What is the best way to connect 2 systems? In my humble, honest opinion, if the 2 devs who are maintaining the 2 systems could see each other’s system’s code, that could speed up the process a lot. Regarding the government that founded the project, everything should be implemented only once correctly, so one project could reuse the other code and a starting point. Not to mention the potential learnings to see how and why a previously build system operates.
  • Critical Systems? This is a bit tricky because of the government officials risk aversion, otherwise technically feasible. If a car (or cars) could run on Open Source Linux, any other critical system can, even ones involving human lives.

X-Road Use case

X-Road is an open-source government founded software originating from Estonia. It is used in various form in 15+ countries (and 23+ in the consultation phase at the moment). Check out the full map of countries for up-to-date information.

The system is a data exchange layer for population registry, business registry, e-auth, tax administration, energy and healthcare services.

If those countries above willing to use open source for all those topics, I am having a tough time coming up with any counter-argument.

How to change an existing government founded project into open source to ensure long-term improvements and maintenance?

Ensure that you have a clear, defined, strong enough vision for the project, which is worth being excited about. Improving the tax system is good; curing cancer is better ;)

Before the code made open source, make sure the code is in a state which would not cause a public outcry, shake it into shape patch the security holes.

Communicate with the stakeholders, and address the concerns.

Release the code to the wild, and make the current developers the maintainers of the codebase.

If you want to create a for-profit business side for long term sustainability, create consultancy services for your project. On top of that, also charge for the extra features, which you don’t want to do pro-bono, but align with your vision.

Organise the community, which will become the talent pipeline.

Always have a list of best first issues.

Include the OS contribution into the hiring process.

If the project had built a strong enough community, the project could live along even when the funding is drying up if there is a strong enough vision for the project as we advance.


Thanks to Michael and Patrick for thought-provoking discussions!