Imagine you’re in the middle of a sprint. Your CI pipeline is green. Your feature is almost ready to ship. Then, out of nowhere, your build breaks. Not because of a bug you introduced, but because a dependency you’ve never even thought about vanished. The repository is gone. 404. No warning. No explanation. Just a blank page where your code used to be.
That’s exactly what happened to the SVGO (SVG Optimizer) repository this week. The maintainer flipped the switch from public to private. And just like that, thousands of projects, from small side hustles to Fortune 500 apps, lost access to a critical piece of their supply chain.
Open source isn’t about trust. It’s about leverage. And the moment you rely on a single GitHub repo, you’ve built a liability, not a tool.
SVGO is not some obscure library. It’s the go-to tool for optimizing SVG files. If you’ve ever uploaded an SVG to a website, chances are it passed through SVGO. It’s a silent workhorse, running in the background of build pipelines everywhere. And now, it’s gone.
One commenter on the GitHub thread captured the absurdity perfectly: “Well umm linking to a private repo isn’t much use now is it? You just get the 404 Not Found. So what was SVGO anyway?”
That’s the kicker. Most developers don’t even know which dependencies are critical until they disappear. We all trust the system. We assume that because a repo is open source, it will always be there. But the license only guarantees you the right to view and modify the code. It does not guarantee the code’s availability. The platform—GitHub, in this case—is the gatekeeper. And the maintainer is the landlord.
The paradox of open source is that its freedom is locked inside a centralized cage. The license is open. The repository is not.
This isn’t a conspiracy. It’s a structural flaw. The entire open source ecosystem is built on a fragile foundation of individual goodwill and corporate platforms. One personal crisis, one policy change, one ransom note, and your build pipeline is dead. The SVGO situation is a wake-up call, but it’s not the first. Remember the left-pad incident? The npm package that was unpublished and broke thousands of projects? Same story, different decade.
So what’s the solution? More licensing? No. The license is fine. The problem is distribution. The code is legally open, but physically locked away. The real answer is decentralized archiving. Services like Software Heritage exist precisely to solve this problem: they snapshot open source repositories, independent of the hosting platform. The last snapshot of SVGO was taken on May 7, 2026. That’s just days before it went private. If you’re lucky, you can still access it. But the window is closing.
We need to rethink our relationship with open source. We treat it as a utility, like water from a tap. But the tap is privately owned. The moment someone turns it off, we’re left thirsty.
Stop trusting GitHub. Start archiving. Fork what you need. Host it yourself. Because the only open source you can rely on is the one you control.
SVGO is a warning. But it’s also an opportunity. The opportunity to build a more resilient supply chain, one where the code is truly free—not just in license, but in access. The next time you add a dependency, ask yourself: “If this repo vanished tomorrow, could I survive?” If the answer is no, you have work to do.
Don’t wait for the next 404. The house of cards is already trembling.
FAQ
Q: Isn't this just an isolated incident? Most open source projects are fine.
A: Exactly. That's the problem. You don't know which one will disappear next. SVGO was a critical tool for SVGs. One maintainer's decision broke thousands of builds. It's not isolated; it's systemic. The same vulnerability exists for every single dependency you pull from a centralized platform.
Q: What should I do right now to protect my projects?
A: Fork critical dependencies into your own organization's repo. Better yet, archive them to a service like Software Heritage or a self-hosted Git server. Don't rely on a single point of failure. Treat every external dependency as a potential vanishing point and build redundancy into your supply chain.
Q: Isn't this overblown? The code is still available under the open source license, someone can re-upload.
A: Sure, but the 'someone' is you. The moment you need to react, you've already lost time. The real issue is that centralization creates a false sense of security. The license protects your rights, not your availability. In the time it takes someone to re-upload, your production pipeline is broken. Proactive archiving is the only way to guarantee uptime.