Hashimoto's Second $400K Lands. Zig Runs on a Funding Model Nobody Else Uses.

What happened

Mitchell Hashimoto, HashiCorp co-founder and the developer behind Ghostty, announced a second $400,000 pledge to the Zig Software Foundation. The first pledge, made in early 2024, funded a year of full-time work for Andrew Kelley and a small contributor pool. This second tranche brings Hashimoto's personal contribution to the ZSF past $800,000 in under two years — more than any corporate sponsor on the foundation's books, by a wide margin.

The announcement is not couched as charity. Hashimoto is the primary author of Ghostty, a terminal emulator written end-to-end in Zig that has become the de facto lighthouse application for the language. He has a direct economic interest in Zig shipping incremental compilation, in the self-hosted x86_64 backend reaching parity with the LLVM path, and in the standard library stabilizing before he ships Ghostty 2.0. The pledge funds the work he needs done. He is, structurally, a customer paying for engineering — except the engineering happens in public and the artifact is a language, not a vendor deal.

What the first $400k bought is worth itemizing. Zig 0.13 shipped incremental compilation as an experimental flag. 0.14 collapsed the async/await design that had been blocking the standard library for two years and replaced it with a colorblind I/O abstraction. The self-hosted x86 backend went from "can compile hello world" to "can compile most of std." Andrew Kelley worked full-time. Jakub Konka, Loris Cro, and a rotating bench of contributors got paid. The ZSF's 2025 financials, published in May, show roughly 70% of operating expenditure went to compiler work and 30% to infrastructure and documentation. None of it went to a marketing team, because there isn't one.

Why it matters

Look at how every other notable systems-or-systems-adjacent language is funded and Zig stands alone in its category. Rust runs on a foundation backed by AWS, Google, Microsoft, Meta, Mozilla, and Huawei — a consortium where each seat is a million-dollar-a-year membership and the platinum members get a board seat that comes with strategic input. Go is a Google project; the toolchain decisions are made by Googlers paid by Google. Swift is Apple. TypeScript is Microsoft. Even Python, which is nominally community-governed, leans heavily on corporate sponsorship from Bloomberg, Meta, and Google flowing through the PSF.

The patron model — one wealthy individual covering core development out of personal capital — is essentially extinct in modern open source. It was the dominant model in scientific publishing and the arts for centuries (the Medicis didn't run a consortium), and it persisted in software for a while via the BDFL-with-a-day-job pattern. But once languages got expensive, the funding shifted to corporate consortia, which come with a tax: the consortium members have opinions about what the language should be. Rust's async story was shaped, in part, by what AWS needed for Tokio at scale. Go's generics shipped a decade late partly because Google's internal codebases didn't need them. Corporate money is never just money.

The cleanest argument for Hashimoto's model is that nobody on the Zig core team has to sit in a meeting with a platinum member's representative and explain why a roadmap item got deprioritized. The cleanest argument against it is that Andrew Kelley's project would be in serious trouble if Mitchell Hashimoto got hit by a bus or, more realistically, lost interest. The ZSF has other donors — Tigerbeetle, Bun, a long tail of individual contributors via GitHub Sponsors — but none at the eight-hundred-thousand-dollar tier. The diversification risk is real and the foundation hasn't seriously addressed it.

There's also the question of incentive alignment. Hashimoto wants Ghostty to ship. Ghostty needs a stable Zig. So the money flows toward stabilization work — incremental compilation, the self-hosted backend, the std rewrite — rather than toward speculative research projects. This is good for users who want to ship production code in Zig today. It is less good for the kind of long-horizon language experimentation that academic funding sometimes enables. The patron model picks a lane.

What this means for your stack

If you've been Zig-curious but waiting for specific milestones before adopting it for anything non-trivial, the runway just got materially longer. The 2026 roadmap published alongside the pledge commits to incremental compilation being default-on in 0.16, the self-hosted x86 backend hitting LLVM parity for release builds, and a stabilized std.Io interface that's been blocking shipping libraries for a year. That's roughly the milestone list senior engineers have been citing as the bar for considering Zig in production, and it's now backed by funded engineering hours rather than volunteer goodwill.

For anyone building developer tools in this space — terminal emulators, language servers, database engines, build systems — Ghostty's existence as a 50,000-line production codebase in Zig is a useful proof point. Tigerbeetle has been the other one, and its team has been buying Zig improvements through targeted contributions for years. The pattern of "a company that ships in Zig pays Zig core to fix things" is starting to look less like one-offs and more like a sustainable economic model, provided you have at least one well-funded user willing to play the role of patron.

The practical implication: if you're evaluating Zig versus Rust for a new project in 2026, the funding stability question — long the obvious reason to pick Rust — is closer than it used to be. Rust still has more seats at more tables, more library coverage, and a deeper hiring pool. But Zig now has a credible multi-year funding runway, a shipping flagship application, and a roadmap that isn't being negotiated with six corporate sponsors. The decision tree got harder.

Looking ahead

The interesting question isn't whether Hashimoto's pledge keeps Zig alive — it does, comfortably, through 2027. The interesting question is whether the patron model becomes a pattern. There are now a non-trivial number of wealthy individual developers who built businesses on a specific piece of open-source infrastructure and care, personally, about that infrastructure's trajectory. If even two or three of them follow Hashimoto's lead — picking a language or runtime they ship on and writing a seven-figure check directly to the maintainer — the funding map for niche systems languages looks very different in five years. Patronage is an old model. It might also be a new one.