Ghostty Leaves GitHub: When 25K Stars Aren't Enough to Stay

What Happened

Mitchell Hashimoto — the co-founder of HashiCorp who brought the world Terraform, Vagrant, and Vault — announced that Ghostty, his GPU-accelerated terminal emulator written in Zig, is leaving GitHub. The project, which accumulated over 25,000 stars and became one of the most-watched terminal emulators in the open-source ecosystem, will migrate to a self-hosted forge.

Ghostty isn't leaving GitHub because GitHub did something wrong — it's leaving because GitHub's model of how software gets built doesn't match how Ghostty actually gets built. The decision, laid out in a detailed blog post on mitchellh.com, walks through specific technical pain points that compounded over months of active development. This isn't a rage-quit or a political statement. It's an engineering decision dressed in engineering reasoning.

The announcement landed on Hacker News with a score exceeding 2,000 points, making it one of the highest-scoring posts of the week — a signal that this resonates far beyond the terminal emulator niche.

Why It Matters

### The Platform Assumption Problem

GitHub was built for a world where most open-source projects follow a recognizable pattern: clone, `npm install` or `pip install`, run tests in GitHub Actions, review diffs in the web UI, merge. That works brilliantly for the vast majority of projects. But Ghostty sits at an intersection of constraints that makes GitHub's defaults actively painful.

Ghostty is written in Zig — a language GitHub's syntax highlighting, code navigation, and CI templates barely acknowledge. It targets GPU rendering pipelines across macOS, Linux (Wayland and X11), and has platform-specific compilation requirements that don't map cleanly to GitHub Actions' container model. The project uses a Nix-based build system for reproducibility. When your language, build system, and target platforms are all outside GitHub's mainstream assumptions, you're not using GitHub — you're fighting it.

Hashimoto has been characteristically specific about the friction points. Code review on GitHub works well for line-by-line changes to text files. It works poorly when you need to review changes that span GPU shader code, platform-specific rendering backends, and Zig's comptime metaprogramming — all in the same PR. The web-based review UI becomes a bottleneck rather than an accelerant.

### The CI Lock-in Tax

GitHub Actions, for all its convenience, creates a subtle form of lock-in that projects don't feel until they try to leave. Ghostty's CI needs are non-trivial: cross-compilation for multiple platforms, GPU-related testing, Zig's evolving toolchain requirements. Every workaround for Actions' limitations — custom runners, matrix build hacks, caching gymnastics — is technical debt denominated in a proprietary YAML dialect.

A self-hosted forge lets the project run CI that matches its actual build topology. No more shaping the build to fit the CI; the CI shapes itself to the build. For a project at Ghostty's complexity level, that's not a luxury — it's a prerequisite for velocity.

### The Discoverability Trade-off

Here's where the decision gets genuinely interesting. GitHub is, functionally, the discoverability layer for open source — 25,000 stars represent not just approval but a distribution channel that no self-hosted forge can replicate. Hashimoto knows this. He built HashiCorp's entire open-source strategy on GitHub's network effects. Walking away from that with eyes open says something about how severe the workflow friction has become.

The bet is that Ghostty has already crossed the discoverability threshold. The project has a dedicated community, its own website, package manager presence, and enough momentum that people will follow it to a new forge. That's probably true for Ghostty. It would not be true for most projects.

What This Means for Your Stack

### If You're a Ghostty User

The terminal emulator itself isn't changing. Releases will still ship through the same channels. What changes is where you file issues, submit patches, and follow development. Expect a transition period where some links break, some CI badges go stale, and the contribution workflow needs re-learning. If you're a casual user who just installs releases, you won't notice. If you're a contributor, budget time to learn the new forge's review workflow.

### If You Maintain a Non-Mainstream Project

Ghostty's departure is worth studying as a decision framework, not as a recommendation. The key variables: How much of your build complexity is GitHub-shaped vs. problem-shaped? How much contributor friction does the platform introduce vs. remove? And critically — have you crossed the discoverability threshold where your community will follow you?

For most projects, the honest answer is that GitHub's network effects still outweigh its workflow costs. The projects that should consider leaving are those where the gap between "how we want to build" and "how GitHub lets us build" consumes meaningful engineering time every week. That's a smaller set than the Hacker News discourse might suggest.

### The Zig Ecosystem Signal

Ghostty is one of the highest-profile Zig projects in existence. Its departure from GitHub sends a specific signal about how well GitHub supports the Zig ecosystem. If the Zig compiler itself (which is also on GitHub) eventually makes a similar move, that would mark a real inflection point. For now, this is a data point, not a trend — but it's a data point from someone whose opinion on developer tooling infrastructure carries unusual weight.

Looking Ahead

The era of GitHub as the unchallenged default is slowly fracturing — not because of a single competitor, but because the definition of "software project" has diversified past what any single platform optimizes for. GPU computing, novel languages, reproducible builds, and cross-platform native code all push against GitHub's web-app-centric assumptions. Ghostty won't be the last high-profile project to leave, but the next ones will face the same math: the forge you choose is a tax you pay on every contributor interaction, and switching that tax from GitHub's rate to a self-hosted rate only makes sense when you've outgrown what the platform gives you for free. Mitchell Hashimoto has done that math, and for Ghostty, the answer is clear. For your project, do the math yourself before following the crowd.