Who Should Pay For Source Code Availability? | Loris Cro's Blog

Loris Cro

Personal Website

About<br>Blog<br>Twitch<br>YouTube<br>GitHub<br>Codeberg

Who Should Pay For Source Code Availability?

August 09, 2026<br>30<br>min read • by<br>Loris Cro

The story of how I became Radicle-ized.

I have a project (Zine, a static site generator) that has 11 dependencies hosted across GitHub, Codeberg, and self-hosted Forgejo instances. Whenever GitHub or Codeberg is down, fresh builds of my project will fail.<br>While self-hosted Forgejo instances have significantly better uptime than GitHub, they are at greater risk of eventually going down for good and breaking my project permanently.<br>The most direct and practical solution to this problem is to fork/vendor everything.<br>Forking means moving all dependencies to the same host where Zine is. If you can clone the main project, you will also be able to clone all its dependencies.<br>Vendoring means taking it one step further: you commit all your dependencies’ source code into your own repo so the act of cloning the project gets you literally everything.<br>If practicality and maximum resilience are things you care a lot about, then you might prefer vendoring over forking.<br>Forking requires you to fork your entire dependency tree (i.e. your indirect dependencies as well), and also modify any non-leaf dependency to point at your own forks. Vendoring instead is extremely straightforward for users of the Zig toolchain.<br>For those who are not in the know, Zig 0.17.0-dev recently changed how dependency caching works: the global cache now stores packages as compressed archives, and each project has a local zig-pkg/ directory that contains the extracted files of the dependencies used by it. This makes vendoring trivial if that’s your goal: just check your zig-pkg/ directory into source control. (Otherwise, it’s recommended to add it to .gitignore.)<br>If you plan to make changes to your dependencies and care about making it easier to upstream them, then forking might be preferable to vendoring. Even if you don’t plan to send a pull request, it’s much easier to cherry-pick a commit in a fork than to do so from a vendored directory in an external project.<br>Forking/vendoring works, there’s no doubt there. But is it really the best we can do?<br>Languages that have a centralized package index (like npmjs.com or crates.io) don’t have to worry about these issues because they essentially have the forking strategy as a built-in feature (all source code gets ‘forked’ into a copy hosted by the centralized package index), but this approach really leaves me unsatisfied because it unnecessarily ties the solution to package management. Our aim should be to make source code reliably available always, not just when fetched from a package manager .<br>These topics have become more relevant as of late because of the instability of GitHub, but in reality the question is not “how can we make source code hosting reliable?”. We do know how to make code hosting reliable, if we really want to. The question is rather: how much should it cost, and who should pay for it?<br>As is often the case in our industry, we never wanted to face that question, and we’ve been happy to leech off big tech companies but, as always, eventually an answer to the question must be given and, when that happens, we’re quick to point the finger at the company, yelling “enshittification!” with righteous indignation.<br>And yeah, GitHub is without a doubt enshittifying, same as Discord and many other platforms before them; but for how long do we expect to continue consuming resources for free? The situation with GitHub is just showing us the cracks in a system that was always broken to begin with.<br>I don’t think that companies are without blame, and I’m sure that obfuscating the cost equation has its own dedicated chapter in plenty of unwritten playbooks, but it’s not the companies that should know better. It’s us. It’s our willful ignorance that creates a distortion that companies have to either embrace or exploit to be competitive.<br>So, is there a way to make source code reliably available in a way that balances out the cost equation?<br>I would argue that self-hosting a forge is not enough to balance the equation because it puts the entire cost of making source code available onto the creator of said software, but we already established that consumers of such code also have an interest in it being reliably available, which is what leads to forking and vendoring.<br>Forking and vendoring are in a sense a way of sharing the cost to keep source code available, but they’re both inefficient because forked/vendored code is not trivially discoverable and automatically usable as a mirror .<br>If somebody is interested in one of your dependencies outside the context of your project, their package manager won’t be able to automatically fetch it from your forked/vendored copy. Of course you might not be interested in shouldering this cost but, as things stand, that’s not really an option...