What is open source, and why code anyone can read can be safer

Bitwarden, Signal, KeePassXC, VeraCrypt, Tails: most of the software covered in this site's Software category has one thing in common, being open source, and it's almost always presented as an advantage. The phrase comes up so often that it deserves an explanation of its own, with what it actually guarantees and what it leaves out.

Source code, a piece of software's recipe

Software is first written by humans, in a readable programming language: that's the source code, the equivalent of a detailed recipe, with its instructions, its choices, and often comments explaining them. For the computer to be able to run it, that code is then turned (compiled) into a binary program, a long string of machine instructions practically unreadable to a human.

Proprietary software only distributes that compiled program: you can use it, but not see how it really works inside. Open source software also publishes its source code, along with a license that explicitly allows anyone to read it, modify it, and redistribute their own versions.

Licenses, what actually makes something open source

Publishing code isn't enough to be open source: the license is what counts. Two broad families coexist:

• Permissive licenses (MIT, Apache) allow almost anything, including building the code into closed, commercial software
• So-called copyleft licenses (the GPL, the best known) require that a modified, redistributed version remain open source itself, under the same license

Code that's merely visible, but whose license forbids reusing or modifying it, isn't open source in the proper sense: it's then called "source available". You'll also come across the term "free software", from a tradition that emphasizes users' freedom rather than the practical advantages of the model. In practice, both terms almost always refer to the same software.

Why showing its code can make software safer

The security argument rests on an old idea in cryptography, stated as early as the 19th century by Auguste Kerckhoffs: a secure system shouldn't depend on keeping how it works secret, only on keeping its key secret (see the article on encryption). Encryption that only holds because nobody knows how it works almost always gives way the day someone figures it out.

Making code public has several concrete effects:

• Any researcher can check that the software does what it claims, without having to take a marketing page at its word (the case of Bitwarden)
• Independent audits become possible, and their findings verifiable in turn
• If the project is abandoned, others can pick it up: that's exactly what happened when TrueCrypt was abruptly discontinued, and VeraCrypt carried on from its already-audited code (see the article on VeraCrypt)

Visible doesn't mean checked

The idea that code read by enough people inevitably ends up free of flaws has a name in the field, "Linus's law", and it has been proven wrong several times, spectacularly. In 2014, the Heartbleed flaw was discovered in OpenSSL, an open source encryption library used by a large share of the world's web servers to display their HTTPS padlock. It had been in the code for about two years, in a project then maintained by a handful of developers, largely volunteers, with very few resources. Anyone could read the code; almost nobody really did.

The xz case, in 2024, is even more telling. A contributor spent nearly two years earning the trust of the exhausted maintainer of a small compression tool present in almost every Linux system, until becoming co-maintainer, before slipping in a backdoor targeting servers' remote connections. It was discovered almost by chance, just before being widely distributed, by an engineer puzzled that remote connections were taking half a second longer than usual. The same logic of patiently built trust shows up in the Drift Protocol hack, and the fragility of a project resting on a single person in the axios hack.

What really matters, beyond the label

Open source makes checking possible; it doesn't guarantee that checking happened. To judge an open source project, a few questions carry more weight than the label itself:

• Is the project actively maintained, with regular updates (see the article on updates)?
• Does it rest on a single person, or on a team and stable funding?
• Has it undergone published independent audits?
• Does the downloaded program really match the published code? Some projects, like Tor Browser, offer so-called reproducible builds, which let anyone recompile the code and get exactly the same file, proving nothing was added in between

Well-maintained open source software offers something no closed software can: the option of not having to trust blindly. Someone, somewhere, still has to actually take the time to look.