I have read most of what has been published about Matt Corallo telling Bitcoin projects to leave GitHub after the Rust-Lightning repository got caught in a Microsoft-owned platform decision. The pattern across the coverage is uncannily uniform. Same outrage beat. Same "centralization bad" closer. Same screenshot of the same tweet, cropped the same way. Same complete absence of the part of the argument that would actually let a reader decide whether to act on the recommendation.
I am writing this because the story matters more than the coverage of it suggests, and the coverage of it is doing a specific kind of damage — it is converting a precise technical and governance argument into a vibe. The vibe is correct. The argument underneath the vibe is what determines whether you should be moving your Bitcoin-adjacent code repository this quarter, next year, or never. I want to talk about what the coverage is doing wrong, what it is leaving out, and what I think the honest framing actually is.
What They All Get Wrong
The shared error is structural and it goes like this: the coverage treats "leave GitHub" as a binary recommendation. Stay or go. Microsoft bad, decentralization good. Apply to your repo immediately.
That is not what was actually argued. The argument from a maintainer in Corallo's position — someone running a reference Lightning implementation that hundreds of downstream projects depend on — is closer to a risk-weighted custody question than a moral one. And the conventional coverage cannot even see the risk-weighting layer because it is reaching for the same template every crypto outlet reaches for when a Big Tech platform does something to a crypto project. Outrage. Centralization. Self-host. End scene.
There are three specific failures in how this gets written.
First, the coverage almost never quantifies the dependency graph. Rust-Lightning is not a side project. It is the substrate underneath a meaningful slice of non-custodial Lightning tooling — the kind of thing where if you are running a Lightning node, a wallet, or any payment layer on top of Bitcoin, you are statistically likely to have it somewhere in your stack three levels down. "Should the project move" is a question with a different answer for a maintainer with 12,000 reverse-dependents than it is for your weekend Rust crate with 19 stars. Nobody writing the coverage seems to know which case Rust-Lightning is. So they default to the abstract case and lose the actual one.
Second, the coverage treats GitHub as monolithic. GitHub is hosting, version control mirroring, code review tooling, CI integration, issue tracker, identity/SSO layer, and discoverability surface — six different products being conflated into one. A project can move the canonical git remote off GitHub in a weekend. Moving the issue tracker, the code review workflow, and the contributor identity graph is a multi-quarter project that costs maintainer-hours measured in the hundreds. The coverage skips this entirely. Move means move, in the conventional read. In practice it means six separate migrations, each with its own failure mode.
Third — and this is the part that bothers me most — the coverage almost never engages with what the alternatives actually are. Codeberg. Self-hosted Forgejo. Sourcehut. Radicle. Tor-hidden git remotes. Each has a maturity curve, a sustainability story, a moderation posture, and an attack surface that is materially different from GitHub's. Telling a Bitcoin project to "leave GitHub" without naming where to land is the technical-recommendation equivalent of telling someone to "leave the exchange" without specifying whether you mean a hardware wallet, a multisig, or a piece of paper in a safe. The coverage does the first part — leave! — and treats the second part as homework for the reader.
What Is Almost Always Missing
What is missing is the specificity of the threat model.
When Corallo argued that Bitcoin projects should be planning their exit, he was not making a generic "Microsoft might do something one day" argument. He was making a specific argument about a specific class of decisions that a specific category of platform-owner is structurally incentivized to make under specific kinds of regulatory or commercial pressure. Strip the specificity and the argument collapses into a meme. The coverage has done exactly that.
Here is the threat model that the coverage should be naming but does not. A Bitcoin Lightning implementation is, in 2026, increasingly indistinguishable in regulatory taxonomy from "money transmission software" in the eyes of multiple agencies. If you write code that helps people move value without an intermediary, you are sitting somewhere on a continuum that ends, at one extreme, in OFAC-style sanctions on the code itself — the Tornado Cash precedent. The relevant question is not "will Microsoft randomly nuke a Bitcoin repo" — they have very little commercial reason to do so on a Tuesday. The relevant question is what they would do on the Tuesday when a regulator writes them a letter naming a specific repository.
The coverage does not engage with this because the threat model is uncomfortable to write out plainly. It involves saying: there is a non-zero probability that within the planning horizon of a serious project, a sanctioned-entity designation or a court order or an industry-wide guidance memo will result in the platform you host on being legally required to take action against you, with very little notice, with no appeal path that matters at your time-resolution, and with the loss of the contributor history, the issue tracker, the PR history, and the discoverability that you spent years accumulating.
That is the argument. It is not "Microsoft bad". It is custody risk applied to source code.
What is also missing is the cost-side of the equation. Migrating off GitHub today, voluntarily, with a working canonical mirror already in place, with a public communication plan, with a contributor-onboarding flow that does not rely on the GitHub identity graph — that is a cost the project pays once, on its own schedule, with its reputation intact. Migrating off GitHub the day after a repo gets disabled, with no warning, with a fragmented contributor diaspora trying to figure out where to reassemble — that is a cost an order of magnitude higher, paid under duress, with the project's continuity in actual question. The coverage frames the migration cost as "annoying" without ever doing the comparison against the alternative cost. Both are real. Only one is on the maintainer's schedule.
What I Would Say Instead
I think the honest framing is custodial risk, and I think the analytical move is to treat your code hosting decision the same way you would treat your coin storage decision. Bitcoin people already have the vocabulary for this. They are just not applying it to the layer where the source code lives.
When you hold BTC on Coinbase Custody or Fidelity Digital Assets or Anchorage Digital, you are making a deliberate, specific trade. You are getting auditable controls and insurance and operational maturity. You are giving up the property that nobody can stop the transfer. The trade can be the right one — for a treasury that legally cannot self-custody, for a fund whose LPs require a qualified custodian, for an estate with operational complexity that a Ledger or a Trezor or a GridPlus Lattice1 cannot reasonably handle. There are cases where the qualified custodian is the correct answer. The Bitcoin community has done the work to enumerate which cases those are. Nobody who actually understands custody calls Coinbase Custody "bad". They call it appropriate-for-some-contexts and not-appropriate-for-others.
GitHub is the Coinbase Custody of source code hosting. That is the framing. It is operationally mature, it is the default that gets you the broadest contributor reach, it has good uptime, it has acceptable security posture, and it can be required by law to act against you on roughly the timescale of an email. For a startup building a SaaS product on top of a managed database in the same Microsoft cloud, the qualified-custodian trade is fine — your whole stack is already custodied. The cost of GitHub disappearing is the same shape as the cost of any other vendor disappearing, and you would handle it the same way.
For a Bitcoin protocol-layer project — which is what Rust-Lightning is — the trade is different. The whole point of the project is to produce code that nobody can stop from being used. If the platform hosting the canonical repository can be compelled to act against you, then the substrate of your codebase has a different sovereignty class than the codebase itself. You are running a self-custody project on a custodial substrate. That mismatch is what Corallo was naming.
So my framing is: the question is not "should you leave GitHub". The question is whether your project's reason-for-existing is the kind that survives a hostile-takedown event on the hosting layer. If your project is something the world would shrug at losing for three weeks while you redeploy, GitHub is fine. If your project is something where three weeks of downtime would mean a fork war, contributor diaspora, or the legitimation of an unfriendly fork that did not lose its history — then you should be running, today, on a mirror that you control, with a contributor identity story that does not assume the GitHub OAuth graph exists, with a release-signing workflow whose chain of trust starts somewhere other than github.com.
Watch four things to update this view: (1) whether any major-protocol Bitcoin project actually completes a canonical migration off GitHub in the next twelve months, not announces it, completes it; (2) whether Codeberg, Radicle, or a Bitcoin-aligned self-hosted Forgejo instance crosses the threshold of operational maturity that makes it a real default rather than a martyrdom statement; (3) whether any regulator names a specific code repository in an enforcement action, the way Tornado Cash's smart contracts were named; (4) whether the cost of running your own forge — measured in maintainer-hours per quarter, not in dollars — comes down enough that a small project can do it without a full-time devops person. The first project that does all four well stops being a cautionary tale and becomes the playbook.
FAQ
What did Matt Corallo actually argue regarding GitHub and Bitcoin projects?
The substance of his argument was that Bitcoin protocol-layer projects should treat the hosting decision as a sovereignty question rather than a convenience question, and that the Rust-Lightning incident illustrated how a platform owned by a regulated entity can act against a project on a timescale the project cannot respond to. The popular version of the argument — "leave GitHub" — is the conclusion. The reasoning that gets you there is custody-risk thinking applied to source code, not generic anti-Microsoft sentiment.
Why does the dependency graph of a project change the answer to "should you move"?
Because the cost of a hostile takedown scales with how many downstream projects depend on the canonical location of your code. A project with 19 reverse-dependents loses three weeks of velocity. A project that sits underneath a meaningful slice of Lightning tooling loses three weeks of an entire ecosystem's velocity, plus the risk that the diaspora reassembles around a fork the original maintainers do not control. Same incident, very different blast radii. The recommendation should weight accordingly.
Is moving the git remote the same as moving the project?
No, and conflating the two is one of the most common errors in the coverage. GitHub bundles version control hosting, issue tracking, code review tooling, CI integration, contributor identity, and discoverability into a single product. Moving the canonical git remote takes a weekend. Moving the issue tracker without losing history, rebuilding the code review workflow, and severing the contributor identity dependency on GitHub OAuth is a multi-quarter migration. Anyone telling you the move is trivial has not done one.
What are the actual alternatives a Bitcoin project can move to?
The practical shortlist is Codeberg, a self-hosted Forgejo instance, Sourcehut, or Radicle for the peer-to-peer version control case. Each has a distinct maturity curve, moderation posture, and sustainability story. Codeberg is the closest drop-in replacement for the GitHub workflow. Self-hosted Forgejo gives you the most control and the most operational cost. Radicle is the most sovereignty-pure and the least familiar to drive-by contributors. Pick based on whose problem your project is actually trying to solve.
Does the qualified-custodian analogy for hosting actually hold up?
I think it does, and the test is whether the trade-offs map cleanly. Custodians like Coinbase Custody, Fidelity Digital Assets, and Anchorage Digital give you operational maturity, insurance, and auditable controls in exchange for the property that no third party can stop the transfer. GitHub gives you contributor reach, uptime, and tooling maturity in exchange for the property that no third party can stop access to the canonical repository. Same structural trade, different layer of the stack. The analogy holds as long as you read it carefully.
When is staying on GitHub the correct decision for a Bitcoin-adjacent project?
When the project's reason for existing does not depend on being unstoppable. A wallet UI, a charting tool, a documentation site, a developer portal, a piece of analytics tooling — these are projects where a hosting-level takedown is a vendor incident, not an existential one. The same maintainer can sensibly run their charting tool on GitHub and their protocol implementation on a self-hosted Forgejo mirror. The decision is per-project and it tracks the sovereignty class of the code, not a blanket position on the platform.
What is the specific signal that would tell me the migration is happening for real?
Completion, not announcement. A major Bitcoin protocol-layer project closing the GitHub issue tracker, redirecting the canonical remote, severing the OAuth-based contributor identity dependency, and continuing to merge external pull requests for ninety days from the new location. That is the bar. Anything short of that is a mirror plus a press release, which is a useful resilience posture but not the migration the coverage keeps anticipating.