Open Source Misconceptions Debunked for Government
Open Source is free like a puppy is an overused metaphor, and still the most generally approachable one I know.
Someone hands you a puppy and tells you it’s free. This is true. It is the best kind of technically true. No one sends an invoice. Three weeks later, you’re standing in a bathroom that used to have a door, or holding your favorite book which used to have a spine, and you understand that “free” was describing the acquisition, not the relationship.
I’ve given some version of that line to rooms full of people for years now. It always gets a laugh, and then, a few minutes later, someone asks the question that tells me the laugh didn’t land quite deep enough: But if we don’t pay for it, who do we call when it breaks?
That question contains much of what governments misunderstand about open source. I want to share a few specifics, because the misunderstandings are reasonable inferences from a procurement worldview that was built for a different kind of thing.
Open source is not free like sunshine.
Sunshine arrives whether or not you do anything to deserve it. Open source arrives because people wrote it, review it, patch it, and answer a 2 a.m. security report. It is only the licence which costs nothing.
Integration, upgrades, security response, and the in-house expertise to do any of that well cost a great deal. Black Duck’s annual audit work has found open source making up more than three quarters of the code in the applications they examine. Your systems are already built with a large amount of open source software. The only open question is whether you are caring for the puppy or just hoping it doesn’t chew through anything load-bearing.
When an organization treats open source as a line-item saving, it tends to underfund the deployment, skip the expertise, and then act surprised when the software decays. That isn’t an indictment of open source. It’s an indictment of the understanding of the maintenance, security and operationalization of software and the budget model constraints.
There is no supplier.
This may be the misconception I see most often, and it does the most damage. Procurement frameworks are built around a counterparty: someone who signs a contract, carries a warranty, and can be held to a service level. Regulators reach for the same shape. When evaluating open source software, they go looking for a manufacturer and find a volunteer in a small town who has been maintaining a parsing library since 2003, for no money, on evenings.
The Cyber Resilience Act articulates this distinction. Early drafts nearly swept volunteer maintainers into obligations designed for commercial manufacturers. Many open source contributors and organisations pushed back hard, and the final text introduced the open-source software steward, a lighter-touch role for the foundations and organisations that support projects without selling them. That’s a real improvement. It’s also a sign of how instinctively policy reaches for a software supplier-shaped hole.
Which brings me back to who do we call? The honest answer is: you call yourselves. Or a vendor you pay to support the software. Or, best of all, the people on your own staff who already know the maintainers because they’ve been contributing upstream for years. Open source doesn’t remove accountability. It relocates it, and when the model is working well, it relocates a healthy portion of it to you.
What about liability if we share our own code?
This is the question justice administrations ask most anxiously, and I understand why. Courts and ministries live in a world where a mistake becomes a headline, an appeal, or an inquiry. I’m not a lawyer, and you should talk to yours. But the shape of the answer is less frightening than people expect.
Open source licences almost universally disclaim warranty: the code is provided as is. The revised EU Product Liability Directive excludes free and open-source software developed or supplied outside of a commercial activity. The CRA likewise focuses its obligations on software placed on the market in the course of commercial activity. Publishing the code you wrote to run your own case management system is not the same act as selling a product.
The real liability exposure, in my experience, runs the other way. It’s the code you are running that you can’t inventory. Most organisations cannot accurately describe the software running on their own systems. That’s not a legal abstraction. That’s the thing that wakes people up when the next great vulnerability arrives. (e.g. Log4Shell, PHP2Shell and so many others)
The licence is the floor, not the building.
Here is how I describe open source to people meeting it for the first time. Start with a licence, the legal grant that makes sharing possible. Add transparent and ongoing collaborative development. Add a social contract: the norms of reciprocity, the expectation that you contribute back, the etiquette of a good bug report. Add governance: who decides, how decisions are appealed, who holds the keys. Put all four together and you get something I’d call trusted open source.
Governments tend to fixate on the first term. Licence compliance is legible to lawyers and auditors, so it gets attention. But trademarks, contributor agreements, foundation charters, and who holds commit rights determine control far more than whether a project uses Apache or the GPL. If you want to know whether you can depend on a project, read its governance documents before you read its licence.
And, once we are talking about publishing licensed code it must be said that publishing alone isn’t “Open Sourcing”, and it is not participating.
I’ve watched well-meaning administrations push a repository to a public forge, write a press release about openness, and walk away. Six months later the repository has no maintainers, no issues answered, no releases. That isn’t open source in any sense that matters. It’s abandonware with a licence file.
Communities do not form spontaneously around empty repositories. They form around people who show up consistently, review patches, explain decisions, and treat outsiders as collaborators. That is work, and it has to be funded and incorporated in someone’s job description.
Visibility is not security, and it isn’t insecurity either.
Two folk beliefs circulate in government, often in the same building. One says that because anyone can read the code, many eyes will catch the bugs. The other says that because anyone can read the code, attackers will find the holes. Both treat visibility as the variable that matters.
Visibility isn’t the key metric. Maintainer capacity is. Log4Shell, PHP2Shell and the xz backdoor were not failures of openness; they were failures of attention, the changing nature of securing against an AI assisted RedTeam, and critical infrastructure resting on a handful of exhausted people. Proprietary software has the same structural weaknesses. You just aren’t allowed to look.
For a risk-averse, heavily regulated institution, this is actually good news. With open source, you can look. You can audit, you can build from source, you can produce a software bill of materials, you can verify provenance. Those are the tools that let you meet strict requirements on security, privacy, and reliability with evidence instead of a vendor’s assurance letter. Risk aversion, properly understood, is an argument for openness, not against it.
The community is not a free labour pool.
Public institutions are some of the largest consumers of open source on the planet and some of the smallest contributors. They file demands, request features, and occasionally send a security questionnaire to a volunteer. Very rarely do they send an engineer.
To be fair, money alone doesn’t fix this. Grants tied to shiny new features, or delivered without any understanding of how a project governs itself, can distort a project as much as they help it. Germany’s Sovereign Tech Agency is interesting precisely because it funds the unglamorous work: maintenance, security hardening, documentation. That’s the work that keeps the puppy from eating the door.
The better model is recognizing that open source depends on contributors. You, your organisation, and your vendors are those contributors, or you should be. Put a line in the budget to engage with the projects you depend on. Build trust through consistency, which means showing up next year and the year after, not just during a crisis.
Open source is not sovereignty. It’s the precondition for it.
This one is uncomfortable, because I believe in the sovereignty argument. Open source gives a state the right to read, modify, fork, and run software without anyone’s permission. That is enormously valuable.
But a right is not a capacity. If you can’t staff a fork, you can’t exercise it. If the foundation holding the trademark sits in another jurisdiction, if the build infrastructure runs on a hyperscaler, if the three people who understand the codebase all work for one company, then your autonomy is more theoretical than you’d like. Invest in the skills and resources you need to actually be sovereign. Otherwise you’ve just swapped one dependency for another, with better marketing.
So, back to the puppy.
Nobody sensible refuses to get a dog because dogs require care. They budget for the vet, they train the dog, they build a routine, and they get years of loyalty in return. Open source is the same bargain. Participate as an act of operational resilience. Allocate resources to support the software you depend on. It benefits everyone, and your own organisation foremost.
The technology was never the hard part. The relationship is. Start acting like you’re in one.
P.S. On the research behind the argument:
Almost every misconception above is a problem political scientists have already named. Mancur Olson’s The Logic of Collective Action explains why large groups of beneficiaries underprovide the goods they all depend on; governments consuming open source without contributing is free riding in its textbook form. Elinor Ostrom’s Governing the Commons shows that commons don’t inevitably collapse, but they survive only with clear boundaries, monitoring, graduated sanctions, and participants who help set the rules. “Licence plus collaboration plus social contract plus governance” is, more or less, an open source restatement of her design principles. And Luciano Floridi’s work on digital sovereignty frames sovereignty as control over data, software, standards, and infrastructure, which is exactly why the right to fork is necessary but not sufficient.
We in open source keep learning these lessons from scratch. There is a body of scholarship that could save us some of the more expensive experiments.
Further reading: Nadia Eghbal’s Roads and Bridges, the Cyber Resilience Act, the revised Product Liability Directive, the Sovereign Tech Agency, Black Duck’s Open Source Security and Risk Analysis, and, because it remains the most honest diagram of our industry, xkcd 2347.
Sarah Novotny has worked in open source community governance for two decades, including Kubernetes, OpenTelemetry, NGINX, and MySQL. She currently lives in Dublin and is studying at Trinity College.