Mitchell Hashimoto: Ghostty, libghostty & chasing the human experience
HashiCorp co-founder Mitchell Hashimoto explains why he built Ghostty, how to make intimidating technical work tractable, and why the best developer tools optimize for a person’s experience instead of a benchmark or configuration surface.
After co-founding HashiCorp and taking it public, Mitchell Hashimoto returned to hands-on systems programming with Ghostty, a fast, native terminal emulator written around a reusable core.
The conversation ranges from passion and parenting to open-source compensation, project decomposition, maintainer judgment, AI-assisted development and the taste required to make powerful software feel humane.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What is your new normal after HashiCorp?
Parenting is now my primary day-to-day job. Ghostty, investing, advising, philanthropy and volunteer work are secondary to being a dad. Startup success changed the mechanics because I do not have to work full-time, even though I believe family would still have become the most important part of my life without that outcome.
Why do you place such a premium on passionate people?
I have always optimized for work I genuinely enjoy, rather than performing enthusiasm as a career tactic. Obsession creates learning and care: the garage-door repairer who cannot stop discussing springs will probably do excellent work. Life circumstances affect who can display that depth publicly, but in practice I would still hire the person who is unusually absorbed in the subject.
How do you judge the quality of a developer tool?
The ultimate benchmark is the human reaction. Performance, design, features and correctness are means to making the operator happy, not abstract ends. A one-percent benchmark win is irrelevant if both versions feel equally fast, and mathematically consistent padding loses to the layout people prefer. Software perfection is impossible; a delightful human experience is the more useful target.
Why build another terminal emulator?
After more than a decade in infrastructure automation, I no longer felt technically challenged. I deliberately chose the opposites of my daily work: desktop instead of server software, low-level systems work instead of managed memory, and graphics instead of API-driven input and output. A terminal happened to combine all three. Learning enough revealed trade-offs in existing terminals that I believed a fast, feature-rich and genuinely native cross-platform product could avoid.
What do you mean by technical philanthropy?
I will spend time programming because it is my passion, so I can direct that work toward a social benefit. A great many engineers use a terminal every day; making that experience better and giving it away can improve a small part of their working lives. It differs from donating money to technical projects because the contribution is the programming time itself.
Can open source become sustainable through donations?
True sustainability — funding even one person full-time at a competitive level — is an extremely high bar and is vital for foundational projects such as the kernel, FFmpeg or curl. Many smaller projects need a nearer goal: meaningful compensation and appreciation. Paying core contributors for several hours each month may help them justify time that otherwise competes with family, even when it cannot replace a salary.
How do you make a huge technical project tractable?
Break it into frequent moments of achievement. Get the project compiling, get tests running, then make something break so you know your change has an effect. A browser was made by people, and you are also a person; the work is difficult, not supernatural. To contribute, understand only the subsystem you need and let maintainers evaluate the wider ramifications rather than waiting to comprehend an entire codebase.
How do you decide what belongs in Ghostty?
Important design decisions and the roadmap are documented so requests can be evaluated against explicit trade-offs. A native KDE interface may not fit the Ghostty application’s scope, for example, while it fits the embeddable libghostty vision. Maintainers have to say no. I try to thank people for engaging, explain the constraint and offer an alternative, but a fun open-source project does not require tolerating abuse.
Why is libghostty as important as the application?
Long term, Ghostty can become a reference implementation for an embeddable terminal core. The macOS app already consumes that Zig core through a C API from Swift. Other developers can then spend nearly all their effort on a great platform-specific experience — such as an iOS SSH client — without reimplementing terminal emulation, while benefiting from modern protocol support maintained in one place.
What should DevTools founders optimize for?
Chase the human experience. The strongest marketing is a user finding enough joy in a product to tell someone else. That joy may require speed, reliability or sensible defaults, but it should be the driving force. Powerful tools become computer-friendly rather than human-friendly when they offload their complexity into dozens of flags, YAML keys and configuration steps that every user must reconstruct.
Links & references
This episode is brought to you by WorkOS.