Who Should Pay For Source Code Availability?
54 points by hugoarnal
54 points by hugoarnal
I found Radicle interesting at a high level, but I think there’s been some amount of reasonable-washing or astroturfing or something of it. I recall having a really strong negative association with the name, and looking back, it seems like Radicle is/was some kind of cryptocurrency project, which appears consistent with the funding / organization behind it. There appears to still be an actively-traded coin (though I’m by no means an expert in what the long term of these things look like) associated with the project, e.g. https://cryptoslate.com/coins/radicle/
I don’t think use cases like this aren’t potentially within the hypothetical value of digital currency or a public ledger, but given the project currently seems to really not want to mention it any more, yet continues to be funded by a crypto company… doesn’t escape my “there’s a long con here” detector that seems almost universally accurate when it comes to blockchain-backed tech used in this way.
I don't know about the full history of Radicle, but nowadays it seems that the ownership of the development of the network belongs to a Swiss non-profit.
A lot of this really doesn't sit right with me, because I keep finding links back to the crypto company every time I dig more into this. It sounds like that link is talking about "Radicle Garden" (radicle.garden) which is a separate entity from Radworks which is the main crypto-company entity (and also funding DRIPS, which is a crypto-heavy token-issuing project).
The Radicle main site (radicle.dev) FAQ page mentions "The project is maintainer led and has been funded by grants from Radworks. Radworks intends to offer services built on top of Radicle, but has no influence over the Radicle project."
However, I see this same service mentioned on the Radworks website. For example, on this page which mentions: "$RAD is the native token of the Radworks Network, used as the primary means to coordinate all actors, govern the treasury, and (later this year will) reward infrastructure providers to the Radicle Network." and "The Radicle Garden provides storage and retrieval services for the Radicle Network. Soon, a decentralized offering will be built and the RAD token will be used to reward seed nodes that provide these services. "
It offers a link to read more about that, which takes me to this governance thread.
It's interesting that this seems to be some kind of open-governance system using a cryptocurrency. But this project still feels extremely "not crypto" washed, and like there's going to be an eventual rug-pull or crypto-incentive or token-issuance scam down the road.
I think you're over-indexing on the crypto stuff. Radicle as an idea is solid as-is.
Yes, it's possible that the crypto affiliation ends up playing a role in the future, but the way I see is that people who are used to working on decentralized networks (i.e. crypto stuff) happened to stumble upon an idea that uses those same techniques and that is intrinsically useful (e.g. doesn't require a speculation frenzy in order for it to be useful).
I'm a complete crypto skeptic myself, but reading old threads on HN about Radicle I found very shortsighted the reactions that some people had.
I think we all have a lot to learn from the design of Radicle (clearly, given how miserable people are becoming on GitHub, and how expensive centralized package registries are), and if the boring crypto shit ends up happening, you can always fork either the tooling (to support a subset of the network protocol), or fork the protocol as well. Chances are that I and many other would follow you :^)
My concern mostly lies with not seeing this as a cost worth paying. If the entity pushing forward development (and in the case of a decentralized thing, with de facto control over the "main network" which is effectively centralized by e.g. protocol agreement and software distribution control) is at core incentivized by creating software which indirectly pumps their coin, as they seem to be, there's two likely outcomes: either the software is developed towards those incentives, maybe being good-enough to use for a while, but still prioritizing that end goal and becoming more problematic over time, or eventually it's abandoned or completely enshittified.
Ultimately I can't see how that's worth the cost of using a much more complex, less finished, less certain technology, in pursuit of an idea of decentralization. I don't see how it ends up without being pseudo-centralized, just with a bunch of VC (or crypto, or whatever) money burned on engineering effort to make it needlessly complex.
I think you're not appreciating the core superpower that decentralization offers: there is no de facto control. The network is made up of many individuals, independently choosing to run a node, and choosing which version of that node to run, and choosing which fork (or perhaps alternate implementation of the protocol) of that software to run.
It would be completely impractical, and trivially defeatable, for this project to enshittify. That's the key benefit that makes it worth paying the complexity cost of decentralization. The vast majority of the people who constitute the network would have to be convinced to be on board.
Also, beyond that, worst comes to worst, you just pack up your git repo and go elsewhere. All your metadata is in there.
The sticking point for me is, I think, mostly cynicism - both at how bad things can get before it crosses the threshold into being actionable for most people (hello, GitHub), but also the crypto industry and things that spawn out of it at large. It's hard to be optimistic, but I'd love to be wrong!
I do wonder if I'm missing part of the point of the protocol, too, that's limiting my perspective of this to (again, common with crypto-world stuff) "what we already had, with more complexity." My understanding was largely that Radicle is a gossip protocol for nodes hosting accessible Git repository copies, plus some signing/identity stuff stored in-repo and issues / PRs / etc. stored in Git objects. The latter is definitely super useful (+/- being potentially hard to work with without tooling that knows how to read those object types), but it's an orthogonal concern. The decentralization scheme, in my understanding of how it works practically, gets stuck on the same two issues: for a new node / end-client not part of the network, which pool of nodes do I start talking to; and, to ensure I receive unmodified software, which signatures do I trust? For most open source projects, I don't see how that's significantly different than what Git's design already provides - "the mirror list from the website" and "the commit signing key(s) that we publish" is just a different spelling of what, as far as I can tell, is in Radicle: "the node pool you can find with these bootstrap nodes that are likely to be up" and "the signing keys we publish on our website."
Excited to see a Zig implementation of the protocol though! I think multiple viably-usable implementations would go a long way towards keeping the ecosystem healthy and prevent some of the potential stuff I'd be worried about there, for sure (and I think it's where some other stuff i.e. Matrix, could have done better)
Not having read the entire post, so maybe it is addressed: why centralise the network around any given functionality? In this case, version control?
It seems to me what we really want is distributed hosting in general. My feeling is that what we really want, is some kind of base layer on top of which we can host various stuff: backups, websites (except not over HTTP), or git repositories. Maybe have a "darknet" version of that base layer, depending on the needs, or even make darknet the default.
The idea I'm having is that distributed systems are more useful when more people use it. Especially the privacy enhancing kind. So it would seem to me it would be best to separate that layer from the high-level functionality, to make sure it isn't confined to one niche.
But I do understand the need to have a niche in the first place. Which means building the base layer and at least one application on top of it to get it started. That's not the vibe I'm getting around radicle however, am I mistaken?
Development of Radicle today is funded by the Better Internet Foundation. The foundation is non-profit and bound to its statutes by Swiss law. The governmental body to oversee the foundation is the Eidgenössische Stiftungsaufsicht (if there ever is "a long con", please file your complaint there). You may obtain further details from the commercial register of Kanton Zug.
The non-profit's own documents show that it's largely a crypto funding / advocacy entity:
[Q1-Q4] Administer RAD allocations for Radworks Orgs (and their Contributors), if desired by Org. [Q1] Create a template market integrity policy in light of novel regulatory crypto trading regulation such as the Markets in Crypto-Assets Regulation (MiCA) to support Ecosystem contributors’ compliance efforts.
Yes, the foundation itself is AFAIK largely funded using cryptocurrency. But that does not imply that you need to own cryptocurrency to use Radicle. There is no technological dependency. And there won't be. If you don't believe that, and are fearful that somehow the open source codebase will be tied to a cryptocurrency, then don't use Radicle. (And consider just leaving the project alone.) Or if you like the idea, fork it.
I would have far less of an issue if there was more transparency in the relationship and how governance is or is not linked. If the idea is that whomever holds the RAD cryptocurrency has eventual control, that doesn't change both the day-to-day (who actually owns the distribution channels, domain names, etc.), nor that it's just capitalism with extra steps - because I can just go buy out "enough" coins, presumably, to have meaningful control.
I don't have any real issue with a cryptocurrency project, I just don't like that it's trying to gain velocity by trying to obscure what it is.
Indeed, it was web3-related, not sure about current state (snapshots from 2019 also mention IPFS, which IIRC is also blockchain-related)
https://web.archive.org/web/20220119172340/https://radicle.xyz/
(please note their domain change from xyz -> dev, but it's the same with redirect)
Since 2023-04 Radicle neither depends on nor integrates with IPFS or any blockchain. There is a gossip protocol that nodes use to notify each other about changes to repositories, and if a node is interested in fetching changes, it establishes a connection and uses Git to replicate.
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.
This is some serious revisionist history of the open source movement. Historically, and currently, most of the largest open source projects like GNU, Python, Perl, Lua, Linux, etc. distribute their software either through self-hosted FTP servers or mirror lists, largely supported by a mix of mosly academia, nonprofits, and hobbyists, with some corporate mirrors. Github is not the be-all end-all of source code availability, it's just one popular choice in 2026. It's not "leeching off big tech companies", it's using the free service that microsoft views as an important business strategy to provide as a gateway to get people hooked on their enterprise product and gather LLM training data.
When it comes to hosting the development of software (i.e. git repos), the "largest" open source projects are still a small fraction of the total free hosting that is happening on GitHub, so your point IMO is kinda moot.
I've spent essentially all my life hosting my open source projects on GitHub and for the longest time I never paid a penny for it. And alongside me many other developers have done the same, and now people armed with LLMs are consuming orders of magnitude more free resources than ever before.
In the context of GitHub, it's me and countless other open source developers who have mainly leeched off big tech.
That said, some of the largest open source projects do "leech off" big tech, just not when it comes to hosting git repositories. From "Things I’ve learned serving on the board of the Python Software Foundation", emphasis mine:
PyPI’s numbers are staggering. Today there are 570,000 projects consisting of 12,035,133 files, serving 1.9 billion downloads a day (that number from PyPI Stats). Bandwidth for these downloads is donated by Fastly, a PSF Visionary Sponsor who recently signed a five year agreement to continue this service.
(This was a big deal—prior to that agreement there was concern over what would happen if Fastly ever decided to end that sponsorship.)
Unless you believe that this also is revisionism.
It's not "leeching off big tech companies", it's using the free service that microsoft views as an important business strategy to provide as a gateway to get people hooked on their enterprise product and gather LLM training data.
This attitude where you don't realize that you are also part of the problem is precisely what I meant to call out in the post. It shouldn't matter to you what is Microsoft's business strategy when you decide how you want to conduct your life. And if you do get influenced (like I did, as mentioned above), then it's on you, not on them.
I'm a bit weirded out by the use of "forking" to mean "mirroring".
Every user gets their own Git namespace.
When you seed (≈mirror) you get to decide whose user's namespaces you are willing to replicate. The default minimum is to only replicate the namespaces of the delegates (≈maintainers/contributors/owners) of the repository and of the set of users you "follow". And finally you can also opt in to replicate everyone's namespace that you hear about.
Well it's both. Your "fork" (seed would be the correct terminology) acts as a mirror for the other branches, but then you can create branches of your own, like you would normally do in your fork.
It's a fork if you add your own commits on top. If the purpose is being able to fetch dependencies while some external forgejo instances are down, as is described in the first part of the article, what you need is a reliable cache or mirror. When it names npm and crates.io, it also calls their code a fork. It's not a fork, it's the upstream code in a reliable host!
what you need is a reliable cache or mirror.
Yes that's also what Radicle is. It's both a way for you to collaborate and a way to mirror other versions of the same repository, including, crucially, the one maintained by the owner(s) of the repository, which in Radicle lingo is the "canonical".
The Radicle docs explain this concept really well, I recommend you check them out.
self-hosted Forgejo instances have significantly better uptime than GitHub
This is a remarkable claim. Do you have data to back it up?
I'm not even sure how you'd measure it. Uptime of a self-hosted instance probably depends on who's hosting it – their skills, dedication, response time, etc. – and how much traffic the instance gets. You'd have to correct for all this to measure accurately.
It doesn't really take much because most self-hosted Forgejo instances only host one person's projects and so the host sees very little traffic compared to GitHub.
Whenever my CI fails for network reasons, it's either GitHub or Codeberg that are down, it has never happened to me that one of my other dependencies were the cause.
A self-hosted Forgejo that hosts a popular repo would be the fairer test.
Even fairer would be a self-hosted Forgejo that has open registration and provides free CI.
Suddenly the site might start seeing traffic, and with that, need to make changes to adapt, and with that, bouts of unavailability.
My point is not to "be fair" to GitHub, but to paint a realistic picture of what I and other people in a similar position have experienced. Most of the time, in my experience, when you depend on a self-hosted Forgejo, it's a small one.
Also if you start going into the "hosting platform" territory, then it's not self-hosted anymore.
And in any case we already know an example of this: it's Codeberg, which does have downtime, but most definitely doesn't count as a "self-hosted Forgejo".
It takes some effort to keep it updated. These complex software packages have security issues. If you run a year old instance, your chance of it getting hacked is extremely high. You also need backups and many other things, if you want to compare apples to apples.
For clarity I meant to say that it doesn't take much for a self-hosted Forgejo to have better uptime than GitHub, given that normally they don't get a lot of traffic.
Radicle supports Issues and Patches (aka Pull Requests in GitHub lingo) in a very interesting manner: there is no centralized (nor federated) web server that hosts those, because they are stored in the Git repository itself as (CRDT-enabled) Git objects that can be re-synced when you announce your changes to the network (run git push in concrete terms).
I'm wondering how well the CRDTs work in practice, and how much of a maintaince cost is involved in manual resolution or clarification (if causality or concurrency issues are common).
It's also interesting how access/discoverability is not enabled by default for non-radicle clients, but the owner of a node can enable it.
Git remotes are already reasonably decentralized. Issues and PRs are not hard to self host, especially if the design decision is to not require the entire git repo in a web viewer.
I just don’t see p2p to be that compelling. I think the entire concept of a code forge needs rethought. I’m far more compelled to use a constellation of mini services
Example: https://pr.pico.sh — a patchbin service that supports issues and code contributions, no git repo required. Disclaimer: this is my project.
I self-host Darcs primary repos (with mirrors on freely available repos since I don’t have enough hubris to think my uptime is flawless), but Darcs doesn’t have branches/channels; without those, there is no need for a daemon/service meaning a Darcs repo can be self-hosted by putting a HTTP(S) web server in front of a folder which keeps the costs (& security threats) to a minimum, which I like. A lot of complaints of self-hosting is the cost of the forge & it being crawled to death by following links to expensive processes. Some files are hosted as text/plain but the best way to read the source is to just clone it locally. Even with that I have gotten both pull requests & emailed patches since a centralized node isn’t required—especially with Patch Theory allowing patches to commute so no single need most resolve conflicts.
I would like to see P2P become more popular, and thought it would as home internet connections got faster, but I've not yet seen that.
Being aware of the costs involved in a system, and how different parties will end up shouldering such costs, is another constraint that will open the door to new designs of a radically superior quality.
I wish this blog post attempted to estimate the costs, quantitatively.
Serving git repos does cost. Even if you spread the cost across all developers, there is still a cost.
How much disk/CPU/RAM/network/power/battery would it end up costing a typical Radicle user? Disk storage, maybe zero, if users only serve repos that they already have on disk.
I'm sure there will be some "super-seeders" on seed boxes. How many do we need? How much do they cost?
Once that's figured out, how does it compare to the costs of a centralised forge like GitHub?
Is it actually cheaper overall? We might think it must be, because it uses otherwise idle resources, but the costs of distributing trust/architecture has its own coordination costs.
Finally, once we have these figures, are users willing to shoulder this cost, compared to the alternative?
none of the other alternatives that I’ve mentioned in this post, or that I know of, come even remotely close to how cost-effective Radicle could be when aiming for high availability.
High availability is just one relevant factor. Other big ones are latency and CI. Is there "folding @ home" for CI?