Git for Government?

We are living in a time of intense debate about transparency, accountability, and trust in government.

That is true internationally. It is true in many democracies. And it is also true here in Norway.

Many would say it is overdue that the Norwegian Parliament has now unanimously decided to explore a lobby register to strengthen transparency around influence and advocacy. The proposed register is intended to show who meets politicians, what issue is being discussed, and whom the lobbyist represents, both for Parliament and for government. That decision says something important: transparency is no longer a peripheral governance issue. It is becoming part of the democratic core.

That is one reason I have found myself thinking about a question that may sound unusual at first:

What would happen if we treated the development of public policy a little more like open source development?

Not because laws are software. They are not.

But because open source communities have spent decades developing methods for transparent collaboration, version control, review, accountability, and structured contribution at scale. I think public institutions have something to learn from that.

Git As A Method

Git is usually described as a version-control system for software development. That is true, but incomplete.

What makes Git powerful is not only that it tracks changes in code. It also creates a visible history of how something evolves over time. It shows what changed, when it changed, who proposed the change, and how the final version emerged.

In that sense, Git is not just a tool. It is a method for structured change.

Platforms such as GitHub and GitLab matter for the same reason. They do not only host code. They make the lifecycle of contribution, revision, disagreement, and iteration visible. They preserve traceability while allowing many people to contribute.

That raises an interesting question:

What if some of the same logic was applied more seriously to the development of public documents, white papers, consultation processes, and maybe even parts of legislative work?

Public Documents Also Have A Lifecycle

In Norway, white papers to Parliament, policy processes, consultation rounds, and public reports often shape future laws, reforms, and national priorities.

These are important documents. But the process around them is often much harder to inspect than it needs to be.

You may see the final version. You may see a hearing note. You may see a summary of input.

But you rarely see the full chain of structured change in a way that is intuitive and transparent.

As Norway now moves through the Vendepunkt process, which is intended to help shape a new white paper on development policy in spring 2027, this becomes especially interesting for me. If this is a genuine moment of strategic rethinking, then process matters as much as outcome.

How are ideas introduced? How are they revised? Who contributes? What gets accepted, rejected, or rewritten?

These are not marginal questions. They are part of democratic legitimacy.

What Open Source Already Solved

This is where I think public institutions have something important to learn from open source.

For decades, open communities have built not only software, but methods for collective work. They have developed norms for review, transparent contribution, issue tracking, maintainership, governance, and long-term stewardship. These systems are not perfect, but they are often much better than public institutions at making change visible and inspectable.

That is a remarkable achievement.

Some of the best practical methods for transparency and collaborative revision have not come from government or diplomacy. They have come from open source contributors.

This Is Not About Turning Parliament Into GitHub

To be clear, I am not arguing that governments should simply move lawmaking onto GitHub and call it modernization.

Public policy is more complex than software. Democracy requires legitimacy, representation, and sometimes confidentiality in ways that software development does not.

But that is not the point.

The point is that open source has developed a mature methodology for traceable, collaborative change. Public institutions should be asking whether some of those methods can be adapted to strengthen transparency and accountability in the way we develop public policy.

Version history. Structured review. Clear contribution trails. Transparent change logs. Better documentation of how a final text emerged.

These are not radical ideas. In many ways, they are overdue.

Transparency Needs Infrastructure

One of the deepest lessons from the open movement is that transparency is not only a value. It is also an infrastructure problem.

If you want people to understand how decisions evolve, you need systems that make that evolution visible. If you want meaningful contribution, you need structures that make participation possible. If you want accountability, you need traceability.

That is true for software. And I believe it is increasingly true for government.

A Democratic Opportunity

I do not think the future of government lies in pretending that software culture and democratic institutions are the same thing.

But I do think there is a democratic opportunity in learning from the parts of open source methodology that are clearly stronger than many current public processes when it comes to transparency, traceability, and collaborative revision.

If public institutions want more trust, they should not only communicate better. They should make process easier to inspect.

If they want more legitimacy, they should not only invite consultation. They should make visible how consultation actually changes the text.

And if they want accountability, they should recognize that accountability becomes much stronger when the history of change is part of the system itself.

Maybe the question is not whether government documents should be written like code.

Maybe the more useful question is this:

What would democracy look like if we took version history, transparency, and contribution as seriously in public policy as open source communities already do in software?