The original post argues that while git itself is distributed, GitHub has absorbed issues, PRs, reviews, Actions, Discussions, Projects, Releases, and wikis into a proprietary layer with no export format. Over fifteen years, the parts of software development that actually matter to a project's continuity have migrated out of .git/ and into a single vendor's SaaS, inverting git's founding promise.
The editorial frames this as a structural rather than moral problem: a distributed system whose collaboration layer is centralized is functionally centralized. It notes the stakes became legible in 2026 with Copilot trained on freely-pushed public code, Actions as de facto CI, and gh as the de facto CLI — all running inside one vendor's web app with no export format.
Roughly half the 101-comment thread argued the title rather than the premise, taking the position that GitHub is good, the UI works, and nobody is forced to adopt Actions or Projects. This camp treats the centralization as a voluntary trade-off developers continue to choose because the alternatives are worse, not as a structural problem with git's model.
A blog post titled *GitHub and the crime against software* hit 206 points on Hacker News, and the comment thread did the thing HN does when a polemic lands: half the room conceded the premise, the other half argued the title. The argument itself is not new. The author's claim is that GitHub has quietly inverted git's founding promise — a distributed version control system where every clone is a full peer — into a centralized SaaS where the repository is the least important artifact on the platform.
The specifics are familiar to anyone who has tried to migrate a non-trivial project off GitHub. The code itself moves cleanly: `git remote set-url`, push, done. Everything else — issues, pull request history, review threads, Discussions, Projects, Actions workflows, Releases binaries, wiki pages, repository insights, branch protection rules, CODEOWNERS enforcement, secrets, deploy keys, the issue/PR numbers your changelog references — is GitHub-proprietary surface area that does not exist anywhere in `.git/`. Git is distributed; GitHub is not, and over fifteen years the GitHub layer has quietly absorbed the parts of software development that actually matter to a project's continuity.
The post arrives in a year where the stakes finally became legible. Copilot is no longer a side project — it's a flagship product trained on the corpus that public GitHub users pushed for free. GitHub Actions minutes are the de facto CI standard. `gh` is the de facto CLI. The Microsoft acquisition is seven years old. And the parts of the developer workflow that used to be email-and-mailing-list — patches, reviews, release coordination — now run inside a single vendor's web app with no export format.
The usual rebuttal is: *fine, but GitHub is good, the UI works, network effects are real, and nobody is forcing you to use Actions.* All true. None of it engages the actual argument, which is structural rather than moral. A distributed system whose participants all voluntarily centralize on one provider is operationally indistinguishable from a centralized system — the distribution is theoretical. When AWS us-east-1 goes down, half the internet goes down. When GitHub has an incident — and it has had several multi-hour ones this year alone — a meaningful fraction of global software development stops, because CI stops, because PR review stops, because the issue tracker that the on-call rotation depends on stops.
Compare the alternatives the ecosystem actually has. SourceHut keeps everything plain-text and email-driven; its issue tracker is literally a mailing list with a web view, which means a project's entire history is portable as an mbox file. Gitea and Forgejo are self-hostable and federate via ActivityPub in recent builds — a Forgejo issue can, in principle, be opened from a Mastodon account. Codeberg runs Forgejo for a non-trivial slice of European open source. GitLab self-hosted still exists and still works. None of these have GitHub's network effect, and that is precisely the point: the network effect is the lock-in, and the lock-in is the product.
The Copilot training question sharpens this. Every public push to GitHub between roughly 2018 and 2022 became training data for a commercial product whose weights are closed and whose revenue does not flow back to the contributors. The legal question is unsettled — the *Doe v. GitHub* class action narrowed considerably on appeal — but the practical question is settled: if you pushed an MIT-licensed repo to GitHub in 2020, a paying Copilot user in 2026 can have your code suggested to them with the attribution stripped, and that is working as intended. The license you chose did not contemplate this use because the use did not exist when the license was written. The platform did contemplate it.
The community reaction on HN split along a predictable axis. The pragmatists pointed out that GitHub's tooling is genuinely better than the alternatives, that issue tracker UX matters, and that asking developers to coordinate over `git send-email` in 2026 is a cosplay of a workflow nobody under forty has used. The systems-thinkers pointed out that *good UX is exactly how lock-in is delivered* — nobody gets locked into a bad product. The most-upvoted reply was a one-liner: "git is distributed, GitHub is the centralization layer we agreed to pretend wasn't there."
The useful framing is not *leave GitHub* — that's neither realistic nor, for most teams, correct. The useful framing is treat the repo as the only durable artifact and treat everything else as rented infrastructure with a non-zero eviction probability. Concretely, three things follow.
First, your CI should be portable. If your `.github/workflows/` directory is the only definition of how your software gets built, your build system is owned by Microsoft. A `Makefile`, a `justfile`, a `Dockerfile`, or a `dagger` pipeline that runs identically on a laptop, on Actions, on a self-hosted runner, and on GitLab CI is worth the upfront effort. Actions YAML is acceptable as a thin wrapper that calls into something else; it is not acceptable as the substrate.
Second, your release artifacts should not live exclusively in GitHub Releases. The number of OSS projects whose installation instructions are `curl -L https://github.com/...releases/download/...` is uncountable, and every one of them is a single ToS decision away from going dark. Mirror to your own object storage, to a package registry you control, or to a registry that federates. The marginal cost is a few dollars a month and a CI step. The marginal benefit is that your users can install your software the day after GitHub deprecates your account.
Third, archive your issues and PRs. The `gh` CLI can export them as JSON; there are open-source tools that render that JSON back into something human-readable. Doing this once a quarter takes ten minutes and means that the design discussion that led to your most important architectural decision is not stored exclusively on a server you don't own. The repository is the code; the discussion around the code is the institutional memory, and right now you are renting your institutional memory month-to-month.
None of this is an argument that GitHub is going away — it is the dominant code-hosting platform on earth and that is not going to change in 2026, or 2027, or probably 2030. The argument is narrower: git was designed so that no single host could become a single point of failure, and the ecosystem has spent fifteen years collectively undoing that design because the UX of the centralized version was better. That tradeoff was probably correct at the time. It is worth re-examining now, because the platform's incentives have changed — it is no longer a code-hosting company, it is an AI company that hosts code as a side effect — and the cost of being wrong is no longer a migration headache but a structural one.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.