# Who Should Pay For Source Code Availability? **URL:** \ **Category:** Media\ **Created:** [August 9, 2026, 1:37pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156 "2026-08-09T13:37:45Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![kristoff](https://ziggit.dev/user_avatar/ziggit.dev/kristoff/32/9_2.png) [@kristoff](https://ziggit.dev/u/kristoff)\ **Post date:** [August 9, 2026, 1:37pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/1 "2026-08-09T13:37:45Z")
> **[Who Should Pay For Source Code Availability?](https://kristoff.it/blog/source-code-availability/)** > > The story of how I became Radicle-ized. ---
**Author:** ![WeeBull](https://ziggit.dev/user_avatar/ziggit.dev/weebull/32/6828_2.png) [@WeeBull](https://ziggit.dev/u/WeeBull)\ **Post date:** [August 9, 2026, 3:56pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/2 "2026-08-09T15:56:17Z")
There was a saying back in the naughties that “The internet routes around damage”. Basically that high availability was a solved problem by having redundancy. Then everybody centralised everything. Feels like we’re realising that was a mistake. ---
**Author:** ![Sze](https://ziggit.dev/user_avatar/ziggit.dev/sze/32/496_2.png) [@Sze](https://ziggit.dev/u/Sze)\ **Post date:** [August 9, 2026, 5:07pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/3 "2026-08-09T17:07:41Z")
Maybe the new freenet could be an alternative p2p way to share code. Here two talks: Freenet Lives! And You Can Use It! [https://www.youtube.com/watch?v=3SxNBz1VTE0](https://www.youtube.com/watch?v=3SxNBz1VTE0) > **[Services Without Servers | Freenet](https://freenet.org/about/news/services-without-servers-video-talk/)** > The talk walks through four applications you can use now: River for group chat, with private rooms newly added; Delta for publishing; Atlas for discovery and search, in its first working version; and freenet-git, which supports clone, fetch and push over Freenet. * * * I haven’t tried it yet, but freenet seems more general purpose than just code hosting, for example with their Atlas app those repositories may be searchable/findable too. Freenet is written in rust but the contracts are compiled to wasm, so maybe we also could build a project that makes it easy to build zig-based projects that run on freenet. Then long-term we could maybe even build a zig specific decentralized package index, what if we had: search, comments, reviews, ratings, issues & collaboration, wikis, docs, maybe even forums, all as a decentralised app (or a few) on freenet (possibly assembled from multiple projects)? Maybe you could even have runnable examples, or interactive tutorials, if we can eventually ship a web build of the zig compiler. (Directly play/learn ziglings instead of its readme?) Also: > Founded in 2001, Freenet is a 501(c)(3) nonprofit organization dedicated to the development of open and democratic digital infrastructure. ---
**Author:** ![lalinsky](https://ziggit.dev/user_avatar/ziggit.dev/lalinsky/32/3720_2.png) [@lalinsky](https://ziggit.dev/u/lalinsky)\ **Post date:** [August 9, 2026, 5:50pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/4 "2026-08-09T17:50:19Z")
Before big corporation and things being centralized on GitHub, open source software was distributed through university FTP servers and these had mirrors by other universities or even companies. I don’t think a P2P system can be used for software distribution in general, and definitely not for development dependencies. There is a mismatch of incentives. People who want to download the software would have to keep running the publicly available service on their computer, that’s just not going to happen. And if you depend on large seed boxes mirroring the content, there are easier solutions. Stuff like the Go proxy model is better, in my opinion. For Go, it’s Google hosting it, but it could also be collaborative, just like Zig download mirrors are. Caching and proxying are much easier problems with more scalable solutions than anything P2P. ---
**Author:** ![wbrian](https://ziggit.dev/user_avatar/ziggit.dev/wbrian/32/4227_2.png) [@wbrian](https://ziggit.dev/u/wbrian)\ **Post date:** [August 9, 2026, 6:02pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/5 "2026-08-09T18:02:24Z")
> [@lalinsky](#): > > People who want to download the software would have to keep running the publicly available service on their computer, that’s just not going to happen. And if you depend on large seed boxes mirroring the content, there are easier solutions. Yeah, it’s a lot like BitTorrent in this sense. People may go through the trouble of downloading and running it to get something they want, but as soon as they have it, they are likely to shut it down. This is where blockchain technology may help with incentives, although I hesitate to even mention it for it’s much deserved horrible reputation, but it would fix the incentive problem with a decentralized approach if there was some reward for hosting. ---
**Author:** ![kristoff](https://ziggit.dev/user_avatar/ziggit.dev/kristoff/32/9_2.png) [@kristoff](https://ziggit.dev/u/kristoff)\ **Post date:** [August 9, 2026, 6:04pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/6 "2026-08-09T18:04:11Z")
> [@lalinsky](#): > > Stuff like the Go proxy model is better, in my opinion. It’s a centralized package registry with extra steps, and like all other package registries, it requires people to be on call for it to be highly available. You find it nice because you don’t have to pay for it. > [@lalinsky](#): > > For Go, it’s Google hosting it, but it could also be collaborative, just like Zig download mirrors are. That sounds to me like approaching a p2p network, or are you saying that community members would host full copies of the registry? I think that might be a bit too big for people to host comfortably, and that’s another nice thing about Radicle: you only seed what you care about. > [@lalinsky](#): > > There is a mismatch of incentives. People who want to download the software would have to keep running the publicly available service on their computer, that’s just not going to happen. This is the case for small solo-dev projects, but for projects that are big enough, like certainly Zig, but also smaller stuff like Zine, the author would just need to put a node on a VM to ensure their project is always available. And that would also apply to the project’s dependencies, which would give resilience to the smaller projects they depend on. That seems pretty well aligned in my opinion. ---
**Author:** ![lalinsky](https://ziggit.dev/user_avatar/ziggit.dev/lalinsky/32/3720_2.png) [@lalinsky](https://ziggit.dev/u/lalinsky)\ **Post date:** [August 9, 2026, 6:09pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/7 "2026-08-09T18:09:40Z")
> [@kristoff](#): > > You find it nice because you don’t have to pay for it. No, I like it because it’s a system I can run on my own. Whenever I was working for a company, we had caching mirror of all open source dependencies we used. And the Go model is as decentralized as one can imagine. The original source is distributed, and there is a built-in model for the proxying. So you can very easily host your mirror. ---
**Author:** ![lalinsky](https://ziggit.dev/user_avatar/ziggit.dev/lalinsky/32/3720_2.png) [@lalinsky](https://ziggit.dev/u/lalinsky)\ **Post date:** [August 9, 2026, 6:11pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/8 "2026-08-09T18:11:44Z")
Sorry for the multiple replies. > [@kristoff](#): > > are you saying that community members would host full copies of the registry Yes, I’m saying this. You have a bunch of companies, it’s trivial for them to run a caching proxy that hosts a few TB of data. They can afford it. If you have 10 such mirrors, you have a pretty resilient system. ---
**Author:** ![kristoff](https://ziggit.dev/user_avatar/ziggit.dev/kristoff/32/9_2.png) [@kristoff](https://ziggit.dev/u/kristoff)\ **Post date:** [August 9, 2026, 6:19pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/9 "2026-08-09T18:19:45Z")
From the perspective of a company running their own proxy (for their own use) that caches the packages that they depend on, I can see that making sense and I agree with the convenience/simplicity argument. From the other perspective, that companies should be open to host publicly accessible proxies for the community that cache non-trivial quantities of data, I’m not as sold, although it’s true that if there’s many of those, then we would have redundancy so no one instance would need be highly available… except that in this setup all instances would need to hold all the data because if one goes down and the other doesn’t have it, then your build might still fail. Similarly, the various instances would need to agree on which hash is a given package supposed to have and decide what to do with disagreements. I think this second approach really quickly ends up approximating a p2p network like Radicle once you decide to iron out all these details. Also the fact that multiple entities are involved starts making the trust problem much more realistic. Even if Google didn’t publish the log for their proxy, you could be reasonably confident that they’re not going to mess with the packages. Once you start having 5, 10, 100 different instances operated by different companies and individuals, you cannot ignore this aspect anymore. ---
**Author:** ![ieh3oh](https://ziggit.dev/letter_avatar_proxy/v4/letter/i/c5a1d2/32.png) [@ieh3oh](https://ziggit.dev/u/ieh3oh)\ **Post date:** [August 9, 2026, 6:55pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/10 "2026-08-09T18:55:07Z")
> 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`.) TIL Zig supports vendoring! ---
**Author:** ![g41797](https://ziggit.dev/user_avatar/ziggit.dev/g41797/32/3339_2.png) [@g41797](https://ziggit.dev/u/g41797)\ **Post date:** [August 9, 2026, 6:59pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/11 "2026-08-09T18:59:13Z")
Next stage will be [Package Managers are Evil](https://www.gingerbill.org/article/2025/09/08/package-managers-are-evil/) ---
**Author:** ![kristoff](https://ziggit.dev/user_avatar/ziggit.dev/kristoff/32/9_2.png) [@kristoff](https://ziggit.dev/u/kristoff)\ **Post date:** [August 9, 2026, 7:08pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/12 "2026-08-09T19:08:29Z")
Zig build always supported vendoring, all you had to do in the past was place the dep in your repo and then do `.path = "vendor/my-dep"` in your zon file. Now it’s just more convenient. ---
**Author:** ![kristoff](https://ziggit.dev/user_avatar/ziggit.dev/kristoff/32/9_2.png) [@kristoff](https://ziggit.dev/u/kristoff)\ **Post date:** [August 9, 2026, 7:09pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/13 "2026-08-09T19:09:43Z")
Quite the opposite, the whole argument of my post is that vendoring and forking is literally a suboptimal strategy. One that works, but that makes terribly inefficient usage of the redundancy those practices create, while something like Radicle exploits it for the benefit of everybody. ---
**Author:** ![splinterofchaos](https://ziggit.dev/user_avatar/ziggit.dev/splinterofchaos/32/9375_2.png) [@splinterofchaos](https://ziggit.dev/u/splinterofchaos)\ **Post date:** [August 9, 2026, 9:27pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/14 "2026-08-09T21:27:49Z")
> [@wbrian](#): > > This is where blockchain technology may help with incentives, although I hesitate to even mention it for it’s much deserved horrible reputation, but it would fix the incentive problem with a decentralized approach if there was some reward for hosting. I actually remember one project attempting to use blockchain to decentralize git: [GitHub - cjb/GitTorrent: A decentralization of GitHub using BitTorrent and Bitcoin · GitHub](https://github.com/cjb/GitTorrent) ---
**Author:** ![KilianHanich](https://ziggit.dev/user_avatar/ziggit.dev/kilianhanich/32/8254_2.png) [@KilianHanich](https://ziggit.dev/u/KilianHanich)\ **Post date:** [August 9, 2026, 10:18pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/15 "2026-08-09T22:18:28Z")
About fetching from radicle: I think this could be served by fetch plugins (see [#14294](https://github.com/ziglang/zig/issues/14294))? ---
**Author:** ![Plebosaur](https://ziggit.dev/user_avatar/ziggit.dev/plebosaur/32/6857_2.png) [@Plebosaur](https://ziggit.dev/u/Plebosaur)\ **Post date:** [August 9, 2026, 10:19pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/16 "2026-08-09T22:19:34Z")
DAMN I wish I knew that ---
**Author:** ![jeffective](https://ziggit.dev/user_avatar/ziggit.dev/jeffective/32/3116_2.png) [@jeffective](https://ziggit.dev/u/jeffective)\ **Post date:** [August 9, 2026, 10:58pm UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/17 "2026-08-09T22:58:19Z")
For those wanting more reading, the underlying concepts that contrast package managers include: - named data networks: [Named data networking - Wikipedia](https://en.wikipedia.org/wiki/Named_data_networking) - content addressable storage: [Content-addressable storage - Wikipedia](https://en.wikipedia.org/wiki/Content-addressable_storage) - content addressable networks: [Content-addressable network - Wikipedia](https://en.wikipedia.org/wiki/Content-addressable_network) The build.zig.zon file includes a hash of the desired content, which is a form of content-based addressing. The `rad clone rad:z3WukSjzicL8WaZHFALbBwb2r8W52` is demonstrating named data networking, asking the network for a piece of content and not necessarily requesting it from a specific location / host. A lot of discussion about modern package manager designs is moving towards content-based addressing / name data networking to address issues like dependency confusion attacks, uptime, reproducibility. ---
**Author:** ![xeubie](https://ziggit.dev/user_avatar/ziggit.dev/xeubie/32/4715_2.png) [@xeubie](https://ziggit.dev/u/xeubie)\ **Post date:** [August 10, 2026, 1:44am UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/18 "2026-08-10T01:44:54Z")
Making everyone share the load is nice in theory, but the nature of internet infrastructure doesn’t favor decentralized p2p most of the time. BitTorrent works well because it’s used to share static, non-updating files; high latency and the unavailability of less popular content are a tolerable part of its design. For frequently updated data, such as git repos or social network feeds, high latency is excruciating and data becoming unavailable because it’s unpopular is not tolerable. ---
**Author:** ![sbrow](https://ziggit.dev/user_avatar/ziggit.dev/sbrow/32/4970_2.png) [@sbrow](https://ziggit.dev/u/sbrow)\ **Post date:** [August 10, 2026, 3:32am UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/19 "2026-08-10T03:32:22Z")
I was never able to get radical to work properly, (I remember trying it twice on separate occasions). Is it finally ready? Granted I was trying to use it privately, but still. ---
**Author:** ![kristoff](https://ziggit.dev/user_avatar/ziggit.dev/kristoff/32/9_2.png) [@kristoff](https://ziggit.dev/u/kristoff)\ **Post date:** [August 10, 2026, 8:59am UTC](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156/21 "2026-08-10T08:59:04Z")
My point about suggesting to use Radicle is not as a “magic” way to avoid having to setup a self-hosted forge to host your open source work. As I mentioned in the post, the first thing I did when considering Radicle seriously, was to setup my own always-on node. The key difference is that, with a traditional forge, if you depend on somebody else’s code hosted on their forge, then when their node is down, your project won’t build, so you have an incentive to fork, but then your fork is only usable by you in your own project. And even then, when your server is down, fresh builds of your project will fail. Radicle essentially turns this setup into a self-healing network where one node going down (temporarily or permanently) can be compensated by leveraging somebody else’s fork of it. So I setup my own node for Zine and I will seed my dependencies entirely for selfish reasons (I want Zine to keep building), but in turn all my dependencies are made more resilient even for people that want them outside of the context of my project. In other words, my argument is that Radicle is similar to self-hosting, but yields significantly higher availability given the same number of nodes/self-hosted instances running. [Next page](https://ziggit.dev/t/who-should-pay-for-source-code-availability/17156.md?page=2)