On April 29, 2026, Mitchell Hashimoto announced he was moving Ghostty off GitHub. His phrasing — "GitHub is no longer a place for serious work if it just blocks you out for hours per day, every day" — landed on the front page of Hacker News via The Register and stayed there. The departure itself isn't the story. The departure plus the four other threads on the same front page that week — about a federated-forge protocol, a security audit of GitHub's leading alternative, the Dutch government's Forgejo-based code platform, and Armin Ronacher's long essay on what came before GitHub — those, taken together, are the story. Five threads, one shape.
Hashimoto is not a casual user. He is HashiCorp's co-founder; he is the developer behind Ghostty, the terminal emulator he has been working on since leaving HashiCorp; and as he put it in his own post, he is "GitHub user 1299, joined Feb 2008." He is, in the phrase he used to introduce his journal, the kind of person who "doom scroll[s] GitHub issues since before that was a word." If GitHub still feels like home for anyone, it would be him.
His description of the past month is what makes the post unusual. He kept a journal of dates, putting an "X" next to every day a GitHub outage had blocked him from doing work. "Almost every day has an 'X'," he wrote. "On the day I am writing this post, I've been unable to do any PR review for ~2 hours because there is a GitHub Actions outage." The Register noted that the post itself appeared just before an April 28 incident in which pull requests stopped completing because of an Elasticsearch failure. The official excuse circulating around the thread — that GitHub is straining under a flood of vibe-coded projects — got the obvious counter from one commenter: "if you've built a public SaaS before you know the job is not to host the software, it's to put rails around people taking it down. They've had since 2008 to build those rails, and they're just now hitting places that take the service down on the regular." Whether the surge story is the real cause or the convenient one, the customer-side argument lands either way.
The closing line of his post is what gives the piece its weight: "I want to ship software and it doesn't want me to ship software."
This is not the rhetoric of a writer with strong views on software freedom. It is the rhetoric of someone who has just realized that the platform under his work has stopped being a platform and started being a problem.
The same week, four more threads
On April 28, Armin Ronacher published Before GitHub, an essay tracing his own pre-GitHub project life — SourceForge, his own Trac installation, Subversion repositories on infrastructure he ran himself, the Pocoo collective he ran with Georg Brandl. The piece is gentle and careful, and the central observation is one that any developer who's been in the field for more than fifteen years can confirm in their own bones. "Subversion in particular made this 'running your own forge' natural. It was centralized: you needed a server, and somebody had to operate it... When Mercurial and Git arrived, they were philosophically the opposite. Both were distributed. ... In principle, those distributed version control systems should have reduced the need for a single center. But despite all of this, GitHub became the center. That is one of the great ironies of modern Open Source. The distributed version control system won, and then the world standardized on one enormous centralized service for hosting it."
That same week, the team at Tangled published their argument for why open source needs a federation of forges. Their proposal is technical: pair git for code transfer with the AT protocol for the social fabric of issues and pull requests, so that a developer on one server can open a PR against a repo on a completely different server, the way email federates today. "Centralized systems always crumble; it's the emails, gits, and IRCs that stand the test of time," the post observes. The post is short. The 384-comment HN thread does the surrounding work — the trade-offs, the comparisons against ActivityPub-based alternatives, the cost of social fragmentation — and the post links to ForgeFed for the ActivityPub side.
On April 29, the Dutch government soft-launched code.overheid.nl — "a government-wide code platform for publishing and developing open-source software," fully self-hosted on Forgejo, framed as "a European, sovereign alternative to GitHub and GitLab." The platform is initiated by the Open Source Program Office at the Ministry of the Interior and Kingdom Relations. This is not a hobbyist statement. It is the moment a sovereign government writes off the social-infrastructure assumption that GitHub will always be there.
And on the day before Ronacher's essay, Julien Voisin (jvoisin) at dustri.org published a security write-up of Forgejo — the Gitea fork that Codeberg hosts, and that Fedora has now adopted as its primary forge. Voisin's results are not gentle. "It took me one evening after work to find a good amount of vulnerabilities," he writes — SSRF, missing CSP and Trusted Types, JavaScript templating issues, authentication problems across OAuth2/OTP/sessions/recovery, low-hanging DoS, information leaks, TOCTOU bugs — and chained some of them into "a full-blown RCE, some secrets leaks, a bunch of persistent account access, a handful of OAuth2 privesc." He chose a "carrot disclosure" — publishing a redacted exploit output as evidence rather than reporting individual bugs through Forgejo's security policy — because "the codebase (not their fault though, they inherited the gitea/gogs ones)" has "systemic issues" that won't be fixed by playing whack-a-mole.
The comment thread on Voisin's piece converges on the obvious corollary. The alternative forges are not ready. The alternative forges are projects with five-figure star counts, small maintainer teams, codebases inherited from a decade of patchwork development. Forgejo is not GitHub-with-the-ethics-fixed. Forgejo is a different product at a different stage of its lifecycle, with different gaps.
What GitHub actually became
Read these five pieces side by side and the question they're collectively asking starts to come into focus. It isn't "is GitHub broken?" — Hashimoto's journal answers that. It isn't "are there alternatives?" — Tangled, Codeberg, Forgejo, code.overheid.nl, Sourcehut, GitLab self-hosted, all answer that. The question they're asking is: what was GitHub, exactly, and what would we lose if it stopped being it?
Ronacher's essay is the most generous attempt to answer. "GitHub was, and continues to be, a tremendous gift to Open Source," he writes. "It made creating a project easy and it made discovering projects easy. It made contributing understandable to people who had never subscribed to a development mailing list in their life. It gave projects issue trackers, pull requests, release pages, wikis, organization pages, API access, webhooks, and later CI." But the underappreciated piece, in his telling, was archival. "GitHub became a library. It became an index of a huge part of the software commons because even abandoned projects remained findable. You could find forks, and old issues and discussions all stayed online. For all the complaints one can make about centralization, that centralization also created discoverable memory."
That archival role wasn't designed. It was a side-effect of being the center long enough that everything ended up there. Ronacher quotes his own earlier work to make the parallel point: in the pre-GitHub world he lived in, some of his old packages are "technically still on PyPI, but the actual packages are gone. The metadata points to my old server, and that server has long stopped serving those files." That's what the world before GitHub looked like at scale. "A personal domain expired, a VPS was shut down, a developer passed away, and with them went the services they paid for. The web was once full of little software homes, and many of them are gone."
This is the part of the GitHub critique that the "just leave" faction doesn't account for. Leaving GitHub is technically easy — git push --mirror and you're done. Leaving the social infrastructure that made GitHub the default place to find a project, the place to verify that an npm package corresponds to a real maintainer with a real history, the place that a billion of trusted publishing handshakes flow through — that's not a git push. That's an institution.
It's worth being concrete about what does and doesn't move when a project actually leaves:
| What | Moves with git push --mirror
|
Alternative path | What's lost |
|---|---|---|---|
| Code, branches, tags | yes | — | — |
| Binary release artifacts | no | API export | re-upload manually at the new host |
| Issues | no | API + import | comment threads partially lost |
| Pull requests | no | API | review-archive history lost |
| Wiki | yes (separate <repo>.wiki.git clone) |
— | — |
.github/workflows/ configs |
yes (the YAML moves) | — | runner and secret bindings have to be re-bound |
| Trusted-publishing handshakes | no | — | re-register on PyPI, npm, and the other registries |
| Stars, forks, watchers | no | — | lost |
| Discussions, design threads | no | partially via API | most of it lost |
| Social graph around the project | no | — | lost |
Code moves. Trust, reputation, and the conversation around the work do not. That's the part the move surfaces.
What's actually breaking
The visible artifact is outages. "Almost every day has an 'X'," in Hashimoto's accounting. The GitHub statuses tracker, cited in the Hacker News thread by one commenter, was registering uptime down around 86% over a recent window. The user-facing symptoms are well-known by now: PR review dies for a couple of hours; the Actions queue piles up; somebody posts the latest status-page incident; a thread runs.
But the deeper change Ronacher names is more important. "People are tired of the instability, the product churn, the Copilot AI noise, the unclear leadership, and the feeling that the platform is no longer primarily designed for the community that made it valuable." GitHub didn't break in a single visible way. It drifted from being a developer tool with a community wrapped around it into being a generative-AI front-end with a developer tool wrapped around that. Hashimoto's frustration, read carefully, isn't about uptime as an SLA number. It's about a service that has stopped acting as if its job is to let him ship software.
Ronacher puts it more directly: "the site has no leadership! It's a miracle that things are going as well as they are."
The hardest part of the current moment is that the alternatives are not, individually, ready. Voisin's audit makes that point with painful concreteness on the Forgejo side — and Forgejo is the one with the most institutional momentum, hosted by Codeberg, adopted by Fedora, and chosen by the Dutch government for code.overheid.nl. The alternatives have inherited a decade of accumulated patchwork from upstream codebases. They are run by smaller teams. The Tangled federation is, by their own admission, a pitch. The Dutch platform is explicitly "a pilot using Forgejo," and "not all government organisations can use the platform yet." There is no drop-in replacement waiting on the shelf for the next person who decides to leave.
For someone making that calculation today, the ladder of alternatives currently looks roughly like this:
| Alternative | Built on | Hosted by | Maturity | Notes |
|---|---|---|---|---|
| Codeberg | Forgejo (Gitea fork) | Codeberg e.V., a German nonprofit | stable production; Voisin's audit findings still open | free for open source, resource caps |
| GitLab self-hosted | GitLab CE | you run it | very mature | full GitHub analog; heavy to operate |
| Sourcehut | Drew DeVault's own stack | sr.ht (paid) or self-hosted | stable, minimalist | mailing-list-style PR flow, not GitHub-shape |
| Tangled | git + AT protocol | federated across servers | proposal stage | PRs across servers from different hosts |
| code.overheid.nl | Forgejo | Dutch Ministry of the Interior | pilot, limited audience | the sovereign-funded forge model |
None of these is "GitHub minus the part you don't like." Each is a different product, on a different lifecycle, with its own gaps.
The cost of dispersion
Ronacher names the thing that "just leave" arguments tend to wave past: "Going back to many forges, many servers, many small homes, and many independent communities will increase decentralization, and in many ways it will force systems to adapt. ... It can also make the web forget again. ... Issues, reviews, design discussions, release notes, security advisories, and old tarballs are fragile. They disappear much more easily than we like to admit. Mailing lists, which carried a lot of this in earlier years, have not kept up with the needs of today, and are largely a user experience disaster."
This is the warm-critical part of the argument. Dispersion is good for autonomy. It is also bad for memory. The web that came before GitHub had more autonomy and more loss. Some of that loss was in code; more of it was in the social context around the code — who wrote what, why, in response to which discussion, with which trade-offs. None of that is portable in a git push --mirror. None of it federates cleanly through a forge protocol that hasn't been written yet.
What the five pieces from this past stretch ask, collectively, is what we'd want next. Tangled's answer is technical — federate the social fabric the way email is federated, and let projects choose their hosts. The Dutch government's answer is institutional — a sovereign-funded forge for civic software, run by the Ministry of the Interior, which can't be sold and can't be repositioned. Voisin's answer is critical — until the alternatives are audited at scale, they cannot inherit the trust GitHub accidentally accumulated. Hashimoto's answer is practical — Ghostty leaves, the read-only mirror stays, the personal projects stay, the day-job code goes somewhere new.
Ronacher's answer is the largest. "What I would like to see is some public, boring, well-funded archive for Open Source software. Something with the power of an endowment or public funding to keep it afloat. Something whose job is not to win the developer productivity market but just to make sure that the most important things we create do not disappear."
This is the right ask. It is also the hardest of the asks because it is the one with no obvious bidder. Open-source archival is uneconomical. The closest things we have — the Internet Archive's Software Collection, the various academic mirroring projects — are chronically underfunded relative to the cultural weight they carry. The Dutch effort is the kind of model that could scale. It would take more of them.
What we owe each other
Open source is, as Ronacher writes, more than where the code lives. For most of the past two decades, it was where a lot of the community lived too — the maintainers you trusted, the discoveries that came from the issue-tracker browsing of someone two time zones away. Those things happened on top of GitHub because GitHub was where the social infrastructure had ended up. The fact that they happened anywhere is what made open source feel inclusive. Five pieces from this stretch on the front page of HN are not announcing the end of that. They are announcing the beginning of an honest conversation about what comes after — for the first time including people who built the largest projects on GitHub and the institutions that keep critical software running.
The question now is what we keep when the center moves. The answer is not going to be one platform. It is going to be a public archive, a federated forge protocol, a few sovereign-funded forges, several commercial alternatives that compete on uptime and developer experience, and many smaller homes that come and go the way they did before. Some of what we built on top of GitHub will not survive the move.
Hashimoto's read-only mirror of Ghostty on GitHub is a small, careful gesture toward exactly that. He is leaving a toothbrush at the old apartment. He is also keeping the locks on his new place changed. The question he is asking, in moving, is the question the rest of us will be asked too — perhaps not this year, but soon enough that it is worth thinking about now: what would you take with you, if your project's home stopped being one?
Top comments (0)