Software
What open source guarantees, and the three things it does not
Published source answers who may read and change the code. It says nothing about who is checking it or who is paying for it.
Both approaches to open source software work. What differs is what they cost you, and the cost is what this sets out.
The difference in one place
- Licences govern rights to use, modify and redistribute, not quality.
- Visibility of code does not imply anyone has audited it.
- Critical infrastructure is often maintained by very few people.
The guarantee is a licence, not a promise
Open source means the source is available under terms permitting use, modification and redistribution, subject to conditions. Permissive licences allow reuse in closed products; copyleft licences require derived works to carry the same terms. That distinction determines how a project can be used commercially and is the main practical difference between families of licence.
Neither family says anything about whether the software is good, maintained or safe.
Many eyes is a hypothesis, not a mechanism
The argument that public code gets reviewed depends on someone actually reviewing it, which requires expertise, time and motivation. Serious flaws have persisted for years in extremely widely deployed open components, which is the empirical counterexample. Popularity concentrates review on a handful of projects and leaves the long tail unexamined.
Public code makes audit possible; it does not make audit happen.
The maintainer problem is structural
A great deal of commercial software depends on libraries maintained by one or two unpaid people in their spare time. Those maintainers carry security responsibility for code embedded in products earning money they never see. Burnout and abandonment are common, and an abandoned dependency is a security liability that keeps shipping.
The short version: funding initiatives exist and cover a small fraction of what is actually depended upon.
Supply chain risk moved to dependencies
Modern projects pull in hundreds of transitive dependencies, and each is a party you are implicitly trusting. Attacks have taken the form of compromised maintainer accounts, typosquatted package names and deliberately sabotaged releases. Pinning versions, verifying signatures and reviewing what a dependency actually pulls in are the standard mitigations.
A software bill of materials answers the question of what you are shipping, which most organisations could not previously answer at all.
Where openness genuinely helps
It removes the risk that a vendor disappearing takes the software with it, since anyone can continue it. It allows independent verification of claims, which matters most for cryptography and privacy tools where trust cannot be assumed. It permits forking when a project is taken in a direction its users reject, which has happened repeatedly and usefully.
In practice, and it allows a device to outlive its manufacturer, which is the practical benefit for ordinary owners.
Figures here are typical rather than guaranteed — check the spec sheet for your part.
Judging a project before relying on it
Look at commit frequency, how quickly security reports are handled, how many people have merge rights, and whether releases are signed. A single maintainer is not disqualifying and is a risk worth knowing about. Check whether the licence permits what you actually intend to do, particularly for anything redistributed.
Documentation quality is a reasonable proxy for whether anyone other than the author has ever successfully used it.
Side by side
| Consideration | What it means in practice |
|---|---|
| The guarantee is a licence, not a promise | Licences govern rights to use, modify and redistribute, not quality. |
| Many eyes is a hypothesis, not a mechanism | Visibility of code does not imply anyone has audited it. |
| The maintainer problem is structural | Critical infrastructure is often maintained by very few people. |
The takeaway
You are guaranteed the right to look. Whether anyone has looked is a separate question entirely.
Once you know what it is trading away, the design stops looking arbitrary.
Questions readers ask
Is open source more secure than closed source?
It is more auditable. Whether it is more secure depends on who audits it and how it is maintained, and the evidence is mixed in both directions.
Is free software the same as open source?
They overlap heavily and emphasise different things — one frames it as user freedom, the other as a development method. Most licences qualify under both definitions.
