What Open Source Changes About Trust

Section 01The promise and what it actually guarantees

When a piece of software is open source, its source code is publicly available — anyone, in principle, can read exactly what the program does before it runs on their machine. That is a genuine and important thing. It is also, taken alone, much weaker than it sounds.

Compare it to the alternative. With proprietary software, you receive a compiled binary: instructions the processor can run, but that no human reads comfortably. The source code that produced it stays locked inside a company. You are trusting that company's word — their privacy policy, their security claims, their good intentions — and you have no independent means of checking any of it. Open source breaks that monopoly on inspection. The Free Software Foundation ↗ and the Open Source Initiative ↗ have each argued, in different registers, that this inspectability is foundational — not a feature, but a precondition for any meaningful trust.

So far, so good. The problem is the gap between "can be read" and "has been read."

Section 02Inspectability is not the same as inspection

Hundreds of thousands of open-source projects exist. The great majority are maintained by one person, or a tiny team, working in their spare time. The code is public, and the number of people who have actually audited it is often: zero. The OpenSSL library — critical infrastructure that encrypted a large fraction of internet traffic — ran for years with a security flaw called Heartbleed, undiscovered despite the code being open the entire time. When the bug came to light in 2014, it emerged that this foundational piece of software had been maintained by a remarkably small group of volunteers. The code was readable; it had simply not been read carefully enough.

This is not an argument against open source. It is an argument for being precise about what openness provides. Openness creates the possibility of trust through verification. It does not create verification automatically.

What does create verification? Attention — specifically, sustained, expert attention. Some projects attract it. The Linux kernel is read, tested, and argued over by thousands of engineers whose employers depend on it. Mozilla's Firefox has a large paid engineering team and independent security researchers probing it constantly. The Apache Software Foundation ↗ maintains governance structures specifically designed to ensure projects have multiple reviewers and cannot be controlled by a single contributor. For these projects, the theory of open-source trust mostly holds: the code is open, and it genuinely has been examined.

The Linux kernel is read, tested, and argued over by thousands of engineers whose employers depend on it.

For a small utility you found on a code-hosting platform last Tuesday, the honest answer is different.

Section 03What you can actually rely on — and what you cannot

Here is a useful way to think about it. Open source gives you three things that proprietary software does not:

The right to look. You or someone you hire can inspect the code. Specialised auditors, academics, and security firms do exactly this — sometimes voluntarily, sometimes funded by organisations with an interest in the answer. When an audit happens, it means something real.

The ability to act on what you find. If a flaw is found, anyone can patch it. In a proprietary product, a discovered vulnerability goes back to the vendor, who may or may not act on it, on their own timeline. With open source, a fix can come from anywhere.

A public record. The history of changes is visible. You can see who wrote what, when, and — in healthy projects — why. Unusual changes stand out. Accidental or deliberate back-doors are harder to hide permanently when the entire change history is public and diffed by many eyes.

What open source does not give you: a guarantee that anyone responsible has looked at this specific project, or that a back-door isn't sitting quietly in a dependency three layers down. The 2020 SolarWinds attack was not an open-source project, but the supply-chain logic it exposed applies here too — modern software is built from layers of components, and the weakest link can be anywhere in that stack.

Section 04Trust, distributed

The honest conclusion is that open source shifts trust from a single opaque vendor to a distributed, inspectable process — but only if that process is actually happening. For well-resourced, widely-used projects, it usually is, and the trust is well-founded. For smaller projects, you are extending something closer to provisional trust: the code could be checked, no obvious red flags have emerged, and the community would likely notice something egregious.

That is still a better position than handing trust to a company with no obligation to show you anything. But "better than the alternative" and "fully verified" are not the same thing — and conflating them is where confident claims about open-source security often quietly go wrong.