필사 모드: The founder who went back to the terminal: Hashimoto on Ghostty, Zig, and open source with "no obligation"
English- Introduction — a successful founder back at the metal
- Why a terminal — sharpening skills gone dull
- The Zig bet and what it costs
- Open source with no obligation — principle and privilege
- Closing — the terminal, the most invisible tool
- References
Introduction — a successful founder back at the metal
Mitchell Hashimoto needs little introduction. Vagrant, Packer, Consul, Terraform, Vault, Nomad, Waypoint — a large slice of the last decade's infrastructure tooling came from him, and he cofounded HashiCorp. So what is he doing now? Building a terminal emulator, in Zig, a language that has not yet reached 1.0. In a recent interview (on alexalejandre.com) he lays out why, and he is unusually candid about it.
This piece, grounded in that interview, looks at three things: why a successful founder went back to low-level code, what the Zig bet actually costs, and the blunt — for some readers, uncomfortable — position he takes on open-source maintenance. At the end I hold his work up against a theme this blog covered recently: that good tools are invisible, and a terminal is about as invisible as tools get.
Why a terminal — sharpening skills gone dull
His motivation reads more like curiosity than ambition. He wanted to sharpen technical skills that had, in his telling, grown dull from neglect — specifically in three areas: pre-AI GPU programming, desktop and single-node systems programming, and learning Zig. A terminal emulator happened to touch all three at once.
There is a striking admission here: after fifteen years building CLIs, he did not actually understand how a terminal emulator worked. Ghostty started small. His plan, in his words, was to "have it build itself, then throw it away" — an experiment to run vim and a compiler inside. Then he showed friends on Discord, some of them actually wanted to keep using it, and a long private beta turned the throwaway into a real project.
Honesty requires a caveat here: this is not a choice everyone can make. Pouring years into low-level open source that earns nothing is far easier once you already have financial freedom. He mentions working only about three hours a day right now, with a six-week-old at home. That freedom is the backdrop to the "no obligation" philosophy discussed below, and it belongs in any fair reading of his stance.
The Zig bet and what it costs
Zig is pre-1.0. That sounds exciting; in practice it means breaking changes. He notes that 0.15 changed "the writer interface and thus anything printing anything" — meaning essentially every code path that prints got disrupted. The telling part is that he frames this as praise, not complaint: the new API, he says, is simply much better.
His case for Zig is about direction, not stability. He likes that Andrew Kelley, Zig's BDFL, "isn't backing down from changes he feels are necessary." The obsession with compile speed is part of the appeal: he can build all of libghostty effectively instantly, and by his account "Andrew still thinks these milliseconds are too slow." A language that removes features to compile faster, rather than only adding them, is to him a feature in itself.
His stance on Rust follows from that. He says he does not like the Rust culture, adding, "I also don't like soccer" — a deliberately flip way of saying a preference needs no justification. His warmest words for Zig are that he respects it for being "unapologetically weird." He likes that languages lack features other languages have, because, he says, "these constraints breed creativity and culture."
My own read: this is a genuine bet, and it echoes his early adoption of Go. Choosing a pre-1.0 language has real costs — every release hands you migration homework. He calls that homework a good thing, but it is still a maintenance tax he has chosen to pay.
Open source with no obligation — principle and privilege
The most contentious part of the interview is about maintenance, and his position is blunt: an open-source maintainer owes users nothing. The grounding is the license itself — "The first line in OS licenses is 'as is, no warranty'," and that, he says, is the agreement. Want stronger guarantees? Pay for software. Only a vendor-customer relationship, in his framing, entitles you to make demands; open source does not.
He does not use this only defensively. It is also a tool for protecting vision. If he only ever worked through user issues, he says, "you'd get stable, stagnant software." He once closed three or four separate feature requests at once, because a single better-designed feature could solve all of them — choosing one coherent design over implementing each user's ask literally.
His view on forks has the same root. He says he has "always believed there should be way more forks, both personal and maintained ones." What makes this more than a slogan is the architecture: Ghostty wraps the whole terminal as a library, libghostty, with the app on top. When a project is cleanly a library, users can wrap or fork it their own way instead of petitioning upstream. For "no obligation" not to curdle into indifference, you have to hand users a surface to help themselves — library-first design is that surface.
Still, I would add a caveat. "No obligation" is right in principle, but the position from which you can say it comfortably is not evenly distributed. For a beloved project like Ghostty, maintained by someone who does not need the income, the sentence is liberating. For a maintainer shouldering a library some company depends on, caught between burnout and guilt, the same sentence is closer to an ideal they cannot reach. His principle is sound; the freedom to live by it is not equally shared.
Closing — the terminal, the most invisible tool
A terminal is a tool among tools. A good one sits in front of you all day and never asks to be noticed. This blog recently covered gingerBill's "Good Tools Are Invisible" (that piece), and few things fit the argument better than a terminal. Hashimoto's design philosophy rhymes with it. He separates feature-rich from bloated: a feature you never use only costs a little disk and RAM and never runs — in his words, "a free feature." And he stresses that terminal applications compose well, so that better terminals lead to better automation and scriptability.
What I take from a successful founder going back to the metal is the posture, not the conclusions. He admitted he did not understand something after building on top of it for fifteen years; he bet on direction over stability; and on the burden of maintenance he stated a principle rather than something merely pleasant to hear. You need not agree with all of it. But few people say this plainly what they are building and what they have signed up to carry, and that clarity is the part worth keeping.
References
현재 단락 (1/19)
Mitchell Hashimoto needs little introduction. Vagrant, Packer, Consul, Terraform, Vault, Nomad, Wayp...