What "Open Source" Doesn't Guarantee You
The licence tells you what you're allowed to do, not what will actually happen to the project
Contents
I’ve built a fair chunk of my homelab on open source software, and the project that taught me the most about what that label actually promises was one I watched go quiet — commits slowing from weekly to yearly to nothing, issues piling up unanswered, a security report sitting open for over a year with no response, while the README still proudly said “open source” at the top the entire time. Nothing about that description was false. Open source describes a licence, and a licence is a legal permission structure, not a commitment about maintenance, security response, or a future. Once you separate those two things, a lot of decisions about what to actually run in production get clearer, and a lot of naive “it’s open source, so it’s fine” reasoning stops holding up.
What the Licence Actually Guarantees
An open source licence — MIT, Apache 2.0, GPL, and dozens of others recognised by the Open Source Initiative — guarantees you specific legal rights: to read the source code, to modify it, to redistribute it, sometimes with conditions (the GPL family requires derivative works to stay open under the same licence; permissive licences like MIT mostly don’t). That’s the entire guarantee. It says nothing about whether anyone is currently working on the project, whether a security vulnerability reported today will ever be triaged, or whether the maintainer who wrote it five years ago as a weekend project still has any interest in it, any time for it, or is even still reachable at the email address in the commit history.
This matters because “open source” gets used colloquially as a stand-in for a cluster of other qualities — trustworthy, actively maintained, peer-reviewed, secure — that the licence itself does absolutely nothing to guarantee. Those qualities can be true of an open source project, and very often are, but they’re true because of the specific community and maintainers around that specific project, not because of anything the licence text requires. A closed-source product from a company with a dedicated security team and an SLA can easily have better real-world security response than an open source project maintained by one unpaid volunteer in their spare time, even though only one of the two lets you read the code. The licence and the quality of stewardship are genuinely independent variables, and conflating them is the single most common mistake I see in “just use the open source alternative” advice.
The Bus Factor Problem, Named Honestly
A huge amount of foundational open source infrastructure is maintained by a strikingly small number of people, often one, often unpaid, often doing it alongside a full-time unrelated job. The term for this in the industry is “bus factor” — how many people would need to disappear (the euphemism involves a bus) before a project has nobody left who understands it well enough to keep it going. For plenty of widely-used libraries sitting quietly in the dependency tree of software you rely on daily, that number is one. This isn’t a hypothetical concern; it’s a documented, recurring pattern, and it’s exactly the situation the 2021 Log4Shell vulnerability exposed at scale — a piece of infrastructure embedded in an enormous share of enterprise Java software, maintained by a small volunteer team without the resources a vulnerability of that severity actually demanded, discovered by the wider world only once it was already being exploited.
| |
That second command is worth actually running against your own dependency tree occasionally, because the honest, slightly uncomfortable answer for a meaningful fraction of the packages your build depends on transitively is “one person, whose contact details might be years stale.” None of this means the software is bad — plenty of single-maintainer projects are excellent and stable specifically because they’re small and well-scoped enough for one competent person to actually maintain properly — but it does mean “many eyes make bugs shallow,” the classic argument for open source security, is only true where many eyes are actually looking, and for most dependencies in most trees, they aren’t.
Security Through Transparency Is Real, But Conditional
The genuine security advantage of open source is real: anyone can read the code, anyone can audit it, and a determined researcher or a paid security firm absolutely can and does find vulnerabilities in popular open source projects through direct code review, something far harder to do against closed-source software without the source in hand. This advantage is conditional on someone actually doing that reading, though, and popularity is a poor proxy for how much genuine security review a project has received — plenty of extremely widely deployed open source components had gone years between meaningful security audits before a high-profile vulnerability finally forced one, precisely because “it’s popular, surely someone’s checked” is exactly the assumption that let the gap persist. Formal, funded security audits of critical open source infrastructure (the kind the Open Source Technology Improvement Fund and similar bodies fund) are a relatively recent, still-patchy response to recognising that popularity alone was never actually delivering the “many eyes” promise by itself.
What Actually Correlates With a Safer Bet
None of this is an argument against open source — it’s the majority of what I run at home and I’d choose it again for almost everything — but the criteria for picking a specific project should be about the project’s actual health signals, not the licence badge. Recent commit activity, a responsive issue tracker with maintainers who actually close things, more than one regular contributor rather than a single name across every commit, a documented security disclosure process, and (for anything security-critical) evidence of a real third-party audit are all far better predictors of whether a project will still be maintained and patched in two years than the specific licence it ships under. A project with a corporate backer or foundation (the CNCF, the Apache Software Foundation, a company that depends on it commercially) tends to have more institutional resilience against the bus factor than a solo hobby project, though it introduces its own separate risk of a company changing the licence terms later — which has happened publicly and repeatedly in recent years as companies relicensed previously open projects once the free-rider dynamic stopped suiting their commercial interests.
When a Company Changes the Rules Midway
The licence also doesn’t guarantee the terms stay the same forever, and several well-known infrastructure projects have demonstrated this publicly in recent years: a company builds an open source project, a cloud provider packages and resells it as a managed service without contributing meaningfully back, and the original company — reasonably, from its own commercial perspective, if disappointingly from the community’s — relicenses future versions under stricter, non-OSI-approved terms specifically to close off that resale path. The code that was already released under the original open licence stays under that licence permanently; that part genuinely can’t be revoked retroactively. What changes is every future release, which is why these moments reliably produce a fork — a new project maintained by the community from the last openly licensed version, continuing under the original terms, sometimes gaining enough momentum to become the de facto standard in its own right.
This is worth knowing before adopting anything specifically because a licence change of this kind is functionally a maintenance discontinuity even though the software itself doesn’t change on the day it happens — you’re choosing, from that point on, between staying on the now-differently-licensed original (accepting new terms you may not have agreed to when you first adopted it) or migrating to a fork that may be earlier in its own maintenance lifecycle and hasn’t yet proven it can sustain the bus-factor problem any better than the project it split from. Neither choice is obviously wrong, but pretending the choice isn’t there — treating the original project’s licence as a fixed, permanent fact rather than a policy a company can and does change — is exactly the naive assumption this whole piece is arguing against.
Forking as the Actual Escape Valve
The reason any of this remains survivable, rather than an existential threat every time it happens, is that the open licence on already-released code is the one guarantee that genuinely can’t be taken back — anyone can legally take the last openly licensed version, fork it, and keep maintaining it independently of whatever the original maintainer or company decides to do next. This is the concrete, load-bearing difference between open source and merely “source available” or “free to use” software: a licence change or a maintainer disappearing is a real disruption, but it isn’t a dead end, because the community always retains the legal right to keep the last free version alive themselves. Whether they actually do — whether enough contributors show up, whether a foundation steps in to coordinate it, whether the fork attracts the corporate backing needed to sustain it — is a separate, genuinely uncertain question, but the legal door stays open in a way it simply doesn’t for proprietary software whose vendor decides to discontinue it.
Troubleshooting: Vetting a Dependency Before You Rely on It
Before adopting anything into a homelab stack or a production system, check the commit history for actual recent activity rather than trusting a star count, which measures popularity and tells you nothing about maintenance. Check the issue tracker specifically for how security reports are handled — a project with a clear SECURITY.md and a track record of timely fixes is a materially better bet than one where security issues sit in the general bug queue unanswered for months. If the project is a single-maintainer dependency sitting deep in your build, consider whether you’d notice if it stopped being maintained at all, and whether pinning a known-good version with a documented review cadence is a more honest posture than assuming upstream will keep patching it indefinitely. None of this is paranoia; it’s the same diligence you’d apply to any other supplier, applied to the fact that “free and open” doesn’t exempt a dependency from needing exactly that diligence. It’s also worth checking whether a project has already been through a licence change or a contentious fork in its history — that history is public, usually well documented in the project’s own issue tracker or a linked blog post from whichever side initiated the split, and it tells you directly whether the governance model has already been tested under pressure once, and how it held up, rather than leaving you to guess how it might.
Is It Worth Understanding This?
Yes, particularly because the alternative — treating “open source” as a synonym for “safe” — leads directly to exactly the kind of dependency-chain surprise that Log4Shell demonstrated at global scale. The licence gives you the right to read, fork, and fix the code yourself if you have to, which is genuinely valuable and is the real, durable guarantee open source provides. What it doesn’t give you is someone else doing that maintenance work for free indefinitely, and treating those as the same promise is where the risk actually lives. For a related look at what a legal framework promises versus what a system actually does day to day, what a TLS handshake is actually saying covers the same “read the actual guarantee, not the popular summary of it” lesson from a cryptographic angle, and open source is the largest act of generosity in history is the fuller case for why, despite all of this, it’s still worth building on.
Related Content
