Mitchell Hashimoto says GitHub's outages and workflow failures have made the platform unsuitable for Ghostty's active development.
Ghostty, a modern GPU-accelerated terminal emulator developed by Mitchell Hashimoto, is transitioning its active development away from GitHub due to ongoing reliability issues that have disrupted daily workflows.
Hashimoto announced the decision in an emotional post titled "Ghostty Is Leaving GitHub," stating that the project will gradually eliminate its dependency on GitHub while maintaining the current repository as a read-only mirror. Further details about the new hosting platform will be provided in the coming months, as discussions continue with both commercial and open-source providers.
This decision is significant given Hashimoto's background. He is best known as the co-founder of HashiCorp (departed in 2023), the infrastructure automation company behind widely used tools such as Terraform, Vault, Consul, Nomad, Packer, and Vagrant, which are the de facto standard in DevOps circles today.
In his post, Hashimoto describes the decision as personally difficult rather than a result of casual dissatisfaction. He notes that he used the platform daily for over 18 years, which makes the current decision even harder.
"I'm GitHub user 1299, joined Feb 2008. Since then, I've opened GitHub every single day. Every day, multiple times per day, for over 18 years. Over half my life. A handful of exceptions in there (I'd love to see the data), but I can't imagine more than a week per year."
Hashimoto states he has recently been publicly critical of GitHub due to daily service failures. He kept a journal over the past month, marking each day when a GitHub outage negatively impacted his work, and notes that almost every day was affected.
"For the past month I've kept a journal where I put an "X" next to every date where a GitHub outage has negatively impacted my ability to work. Almost every day has an X. 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".
According to Hashimoto, however, the issue is not with Git itself. He clarifies that the problem lies in the surrounding GitHub infrastructure, including issues, pull requests, GitHub Actions, and related collaboration workflows. For Ghostty, these failures have impacted both maintainers and the broader open-source community, prompting the decision to move away.
However, it is hard not to notice the strong disappointment in his words regarding the popular developer platform.
"It's not a fun place for me to be anymore. I want to be there but it doesn't want me to be there. I want to get work done and it doesn't want me to get work done. I want to ship software and it doesn't want me to ship software. I want it to be better, but I also want to code. And I can't code with GitHub anymore. I'm sorry. After 18 years, I've got to go."
Importantly, Ghostty will not be removed from GitHub immediately. The migration will occur incrementally, and the current GitHub repository will remain available as a read-only mirror. Hashimoto notes that his personal projects and other work will stay on GitHub for now, with Ghostty prioritized due to the significant impact of reliability issues.
What have been your experiences with GitHub - both positive and negative? Do you recommend any alternatives?
(Score: 4, Interesting) by JoeMerchant on Sunday May 03, @01:49PM
Years back, I switched to co-hosting my active projects on both GitHub and GitLab - but GitLab kind of flaked out on me...
Yesterday, I co-hosted about a dozen projects to Codeberg, it couldn't have been simpler or easier to do... the push response times are a tick longer than GitHub's but still very solidly reliable - for 24 hours, at least.
The great thing about git? I also have all these projects mirrored to my own NAS, so when all the remotes flake out, I still have personally controlled copies, not only on the dev machines but also in a central location that I back up once every few years... Experience says that the local NAS will die more often than GitHub flakes out, but as they say: past performance is no guaranteee of future returns... It's really nice to have choices.
🌻🌻🌻🌻 [google.com]
(Score: 1, Troll) by VLM on Sunday May 03, @02:59PM (4 children)
Just use gitlab. Either the public one or a private deployed edition.
The problem github has is a lot of people on salary with nothing to do because the product was "done" a long time ago. So you end up with your primary interaction is DEI hires sending whiny emails that you still use "master" as a git branch name or you don't have a code of conduct in your public repos. Meanwhile it has a competency crisis (for related reasons) so its not up all the time anymore. It's extremely lame.
Gitlab hosted locally works well and I ran a mostly-kinda air gapped one for many years. Its hard to justify the efforts to self host gitlab if even gitea does more than I actually needed.
Gitlab the public free repo is alright. Their idea of the featureset and price that will result in subscription revenue doesn't match most users obviously generated by a corporate team LOL. I subscribed for like one year and the few features were not worth it to me at the time.
Its a difficult problem space. Here's a protocol originally designed to be decentralized how can we add features to centralize it (for profit)? And everyone's idea of good features is different. I don't really need yet another ticketing system if we already have like five at work, so adding one to a git system is annoying, yet for others its a huge feature. Or adding corporate project manager features, or adding wiki/docs features, or adding CI/CD features, etc. Its all little stuff that most people don't want but a few people really want badly.
(Score: 2, Interesting) by JoeMerchant on Sunday May 03, @03:37PM (2 children)
Curious, did you ever try Jenkins? If so, how does it compare with GitLab local hosted?
I was in the process of converting a 6 year accretion of build scripts (I liken the process to the growth of a coral reef), into a Jenkins based build server when a (much) better offer came along for me so I gave my 2.5 weeks' notice and left them soul searching about how they probably should try to re-hire the guy who built those scripts and (quite justifiably) rage-quit over being severely underpaid for his level - hired as an intern, he easily stepped out to 2x the compensation and the company, after a year of searching for somebody cheaper, had hired me at 2.5x what he used to make...
🌻🌻🌻🌻 [google.com]
(Score: 2, Funny) by VLM on Sunday May 03, @03:47PM (1 child)
Oh yeah back in the old days thats all we had for "CI/CD" before it even had the cool name.
Cross platform pretty fun stuff.
Aside from high stakes "CI/CD" stuff back in the day we used it to lint and run unit tests. You could git commit code that didn't pass company lint standards or company unit tests, but you'd get made fun of if Jenkins failed and the whole team got emailed about the failure.
(Score: 2, Informative) by JoeMerchant on Sunday May 03, @04:06PM
The thing I liked best about Jenkins (at the time) was the setting where it would tell you about NEW warnings in the build, and let the old ones slide. It seemed much harder back then to address compile warnings, often an unwarranted amount of pointless busy-work just to shut up the compiler about something that didn't matter.
🌻🌻🌻🌻 [google.com]
(Score: 5, Insightful) by ikanreed on Sunday May 03, @04:33PM
No see, they won the master/main thing, and now you're the one whining about something pointless and irrelevant, but unlike them you don't even have an excuse to be offended. You're just a whining baby.
(Score: -1, Troll) by Anonymous Coward on Sunday May 03, @11:27PM
Good! Can we stop the insanity now? GIT is an over-engineered POS. Let's go back to SVN.
(Score: 2) by jb on Monday May 04, @08:43AM (2 children)
Why on earth would a terminal emulator, of all things, need GPU acceleration?!
(Score: 2) by suxen on Monday May 04, @12:35PM
I thought the same thing. Then I tried kitty. Now I start salivating every time I open a terminal, open terminals just to look at them. So pretty
(Score: 3, Funny) by rleigh on Tuesday May 05, @05:47AM
Because you can have all of your presentation layer in a single uniform buffer object (UBO), your cell properties in other UBOs, fonts in a texture, cell grid as a vertex buffer and index buffer, and then render the entire screen in a single renderpass. It's fast and efficient on modern hardware, and all you typically need to do each frame is update the presentation layer in response to updates to the data layer. Even the cell properties can be static unless changed, and accessed via an index, so the data storage is about as optimal as it can get. You've offloaded every aspect of rendering to the GPU, leaving the CPU to do real work, and issue a few buffer updates every now and again. It's not necessarily power-inefficient either, since you only need to re-render if there is a change to display.