Ghostty está deixando o GitHub
(mitchellh.com)- As falhas recorrentes no GitHub chegaram a um ponto em que realmente bloqueiam revisões de PR e o trabalho do dia a dia, expondo a dependência de issues, PRs e Actions, algo que não é resolvido apenas por repositórios Git distribuídos
- Durante o último mês, problemas no GitHub afetaram o trabalho quase todos os dias e, no dia em que o texto foi escrito, uma falha no GitHub Actions bloqueou revisões de PR por cerca de 2 horas
- O destino da migração ainda não foi definido, e há planos de reduzir gradualmente a dependência do GitHub enquanto são avaliados vários serviços comerciais e provedores FOSS
- Um espelho somente leitura será mantido na URL atual, e essa mudança será aplicada primeiro apenas ao Ghostty; outros projetos pessoais permanecerão no GitHub por enquanto
- A decisão não surgiu às pressas por causa da grande interrupção de 27 de abril de 2026, mas vem sendo discutida há meses, e um retorno só será possível quando houver melhorias reais confirmadas
Motivo da mudança
- O Ghostty decidiu sair do GitHub e entende que as interrupções recorrentes chegaram a um nível que bloqueia o trabalho de forma concreta
- Foi mantido um registro separado dos dias em que falhas no GitHub afetaram o trabalho no último mês, e foi informado que os problemas ocorreram em quase todos os dias
- Mesmo no dia em que o texto estava sendo escrito, não foi possível revisar PRs por cerca de 2 horas por causa de uma falha no GitHub Actions
- A questão central está na infraestrutura ao redor, como issues, PRs e Actions, e foi enfatizado que o simples fato de o Git ser distribuído não resolve isso
- Como o trabalho ficava bloqueado por várias horas por dia, concluiu-se que já não dá para considerar o GitHub um ambiente de trabalho sério
Plano e escopo
- O destino da migração do Ghostty ainda não foi definido, e as conversas seguem com vários serviços comerciais e provedores FOSS
- O plano é remover a dependência do GitHub gradualmente, sem cortar tudo de uma vez
- A ideia é manter um espelho somente leitura no GitHub na URL atual
- Essa mudança será aplicada primeiro apenas ao Ghostty, enquanto projetos pessoais e outros trabalhos permanecerão no GitHub por enquanto
- Como o Ghostty é o projeto com maior impacto para ele, para os mantenedores e para a comunidade open source, o foco desta mudança também está nele
Contexto adicional
- Embora o momento coincida com a grande interrupção de 27 de abril de 2026, o plano de sair do GitHub já vinha sendo discutido há meses, e a decisão final só foi tomada nesta semana
- O texto principal foi escrito antes da grande falha do Elasticsearch, e a falha do dia mencionada no texto era uma interrupção separada
- Se o GitHub realmente melhorar, pode haver um retorno algum dia, mas a condição para voltar não são palavras ou promessas, e sim resultados concretos e melhorias reais
3 comentários
Quem já tinha migrado para outro lugar (como o Codeberg) provavelmente vai se convencer ainda mais, vendo esse caso, de que fez muito bem em se mudar.
Mitchell Hashimoto escreveu até nos comentários do HN que isso realmente o fez chorar, então fui ver
https://x.com/mitchellh/status/2049213597419774026
Ele entrou no GitHub em fevereiro de 2008 como usuário número 1299.
Parece que o GitHub realmente tem tido muitos problemas ultimamente. Há algumas horas também foi postado Há uma indisponibilidade em andamento no GitHub.
Comentários do Hacker News
mitchellh: eu literalmente chorei escrevendo esse post, sem exagero
O GitHub não era só um SaaS para mim, significava muito mais, então a relação acabou ficando profunda a ponto de não ser muito saudável
Depois de conversar de forma intermitente por alguns meses, nas últimas semanas a discussão ficou séria, e eu tomei a decisão final há poucos dias; só agora, publicando o texto com minhas próprias mãos, isso parece real demais
Alguém pode rir disso, mas eu realmente me importo com o GitHub e espero que ele encontre seu caminho de novo
Sou o usuário 22723 do GitHub, e considerando que hoje existem algo em torno de 180 milhões de contas, dá para dizer que estive junto desde praticamente o começo
Do meu ponto de vista, o GitHub só pode melhorar se as pessoas que se importam permanecerem para torná-lo melhor
Quando saí do Heroku, uns 6 anos atrás, depois de quase 10 anos usando satisfeito, nunca mais abri o dashboard, e acabei sentindo que a Salesforce realmente o destruiu
Mas com o GitHub eu não consigo ir embora assim
Ele ficou bagunçado ao mesmo tempo em que passou por agentic coding e um crescimento explosivo, mas isso me parece diferente de uma ruína no estilo Heroku/Salesforce
Em vez de explicar tudo só com mais IA para programação ou com uma Microsoft maligna, parece mais plausível que a escala e o próprio terreno sob os pés dos desenvolvedores tenham mudado
Espero que ele faça um trabalho bom o suficiente para dar vontade de voltar, e não há nada de bobo em ter sentimentos fortes por algo que está no centro da vida de desenvolvedores
Essa sensação de querer trabalhar e ser atrapalhado, de querer fazer deploy de software e sentir que o serviço não quer que isso aconteça, pega em cheio
Esse sentimento não é algo exclusivo do GitHub; a web em geral hoje parece estar ficando mais frouxa e de pior qualidade
Tem interrupção o tempo todo, bug, aresta irritante na UI e funcionalidade inacabada demais, a ponto de eu não saber mais o que está acontecendo
Obrigado por fazer ergonomic software para pessoas
É uma metáfora para algo que, aos olhos dos outros, pode parecer banal, mas para a pessoa envolve afeto e memórias acumuladas ao longo de muito tempo
https://knowyourmeme.com/memes/spool-of-wire-guy
Na vida há coisas de que gostamos e que amamos, e é natural ficar triste quando o lado que eu apoiava piora
Eu também não zombaria disso, e fico com raiva de quem zomba
Dito isso, sinceramente não estou otimista de que o GitHub vá encontrar o caminho
Foi bem impressionante ver o GitHub desmoronando como organização
Falam de incorporação à Microsoft, realocação de recursos para o Copilot, estrutura organizacional, vibe coding e várias outras explicações, mas seja qual for a razão, é difícil negar que há um problema sério
O histórico mostrado pela página de status não oficial também é bem terrível
Eu gostaria de ouvir a visão de dentro, mas no momento parece um navio afundando que segue em frente por inércia, e num momento em que toda a indústria de software está balançando, só a inércia não parece suficiente para sustentá-lo
Está sendo operado do jeito típico de serviços que foram adquiridos por uma empresa grande
No começo fica tudo bem, depois vai piorando aos poucos, até desabar, e tudo vira jogo de números
Microsoft, Oracle, VMware, CA, Salesforce: há muitos casos parecidos, e equipes realmente boas em lidar com M&A são raríssimas
https://onlineornot.com/uptime-calculator/87.25
Acho que, quando cresce demais sem liderança decente, uma hora desmorona
Na prática, a situação parece ainda pior
Antes mesmo da aquisição, houve uma época em que usar o GitHub parecia jogar cara ou coroa para saber se o site funcionaria direito naquele dia
Ele teve sucesso porque estava no lugar certo na hora certa; no fundo, sempre foi um sistema improvisado e remendado
Eu entendo o afeto sincero que Hashimoto tem pelo GitHub e pelo mundo open source
Mas acho que, se ele tivesse tido só um pouco mais daquela postura à la Richard Stallman de ver software não livre como algo intrinsecamente suspeito e antiético, teria sofrido menos com isso
O GitHub era, em 2008 e continua sendo agora, software não livre rodando no servidor de outra pessoa, sob as regras de outra pessoa, e operado no fim das contas para beneficiar o dono
Eu também usei por muito tempo, e muitas vezes tive de usar por causa do trabalho, mas nunca tive apego emocional
Sempre me incomodou o fato de ele ser construído sobre o git, que é free software, e ainda assim estruturalmente tentar prender o usuário à plataforma
Eu não conseguiria amar um software que exige conta de e-mail e aceitar termos de uso, e que nem funciona no Irã por causa das leis de sanções dos EUA
Então fico feliz, sem qualquer hesitação, com o Ghostty saindo do GitHub
No KDE, quase nunca consideramos seriamente o GitHub; operávamos nossa própria git infra e depois trabalhamos com o Gnome e o GitLab para trazer para a Community edition os recursos realmente necessários da Enterprise Edition
Nos últimos 16 anos, acho que tivemos exatamente uma interrupção de git que durou várias horas
Basta olhar se vale ou não o meu tempo e o meu dinheiro
Pode haver muito desgaste emocional, como em aumentos de preço da Netflix ou em discussões sobre games, mas se não vale a pena, é só ir embora
Claro, eu entendo que se crie uma conexão emocional, como acontece com lembranças dos primeiros tempos da computação
Estou achando cada vez mais sensata a ideia de embutir coisas como issue tracker dentro do próprio git repo
Acho que esse sofrimento vem de não enxergar até o fim o problema do closed source software
Depois que vendeu a Hashicorp, perdi muito do respeito que tinha
Num thread antigo do Mitchell no X criticando o GitHub, vi respostas dizendo que o GitHub deveria contratá-lo como CEO, e achei que fazia bastante sentido
Um líder capaz de virar um navio desses não pode ser só um gerente; precisa ser alguém com convicção forte, capacidade de execução e poder de atrair talentos ao mesmo tempo
No fim, acho que vai surgir um novo GitHub, e se acertar o timing como o OpenClaw ou o antigo GitHub acertaram na era de SVN e SourceForge, pode crescer rápido
Já parece haver muitas tentativas mirando esse espaço
E ainda assim, olhando para o serviço principal, sinto que ainda não existe uma boa UI, especialmente para projetos complexos
Já o jujutsu parece bem promissor na direção geral, mas ainda não tem um forge decente
Código, wiki e issues são distribuídos praticamente como uma única ferramenta
Talvez volte a se alinhar se a IA realmente substituir o desenvolvimento de software do jeito que executivos de big tech querem, mas no momento as pessoas querem um git remote estável, e o que recebem é um host instável misturado com recursos meia-boca de vibe coding
O maior motivo para todo mundo correr para o GitHub é que ele facilita colaboração em issues e PRs sem depender de cada forge self-hosted permitir cadastro aberto, e isso dá para resolver sem concentrar todo o código numa infraestrutura única em decadência
Provavelmente é difícil isso virar realidade, mas seria ótimo se acontecesse
Tenho bastante curiosidade sobre como o ecossistema de desenvolvedores vai mudar daqui a 5 anos e sobre como o GitHub estará daqui a 5 anos
Quase não abro a web do GitHub; uso muito o github cli
Só com o gh já resolvo quase tudo, o Actions roda no GitHub, e os agentes trazem os resultados, leem issues e corrigem código, então o fluxo de trabalho inteiro já está mudando
Se tantas pessoas concordam com a ideia de que o GitHub deixou de ser um lugar agradável e passa a sensação de impedir o trabalho e o deploy, Redmond precisa reagir com força
Se esse sentimento realmente se espalhar em grande escala, pode ser um golpe duríssimo para a Microsoft
Há 8 anos ela gastou quase US$ 8 bilhões para colocar desenvolvedores no centro da estratégia, e também gastou US$ 2 bilhões no Minecraft para amarrar até a camada mais jovem de futuros desenvolvedores
Ela já perdeu o espaço de OS e de servidores; se perder também os desenvolvedores, pode acabar num caminho parecido com o da Xerox do século 21
A Microsoft pode não estar dominando jogos, mobile ou IA, ou até ter grandes chances de perder nesses mercados, mas ainda prende uma quantidade enorme de trabalhadores de escritório comuns para quem Word e Excel bastam
Tem gente demais que não liga para tecnologia, mas está presa ao Office
O fato de uma das habilidades práticas que o Claude aprendeu cedo ter sido escrever
.docxmostra isso bemO problema não é o próprio Git, e sim a infraestrutura em cima dele, como issues, PRs e Actions
Minha sugestão é: mesmo migrando para outro forge, vale usar git-bug junto
Ele armazena issues, PRs e afins no próprio git, em refs especiais em vez de branches, e ainda suporta sincronização bidirecional com vários provedores
Outros VCS como o fossil também guardam issues junto do repo; acho que faz sentido, porque issues são parte do contexto que dá significado ao código, como documentação
Quando tudo fica dentro do repo, realmente fica mais prático
Mas agora que praticamente tudo pode ser manipulado junto por um LLM coding agent quase sem restrições, fica ainda mais difícil limitar o escopo de acesso
Pelo que sei, esse segundo ponto está sendo trabalhado em algo na linha de uma web UI, mas até lá você inevitavelmente precisa de alguma infraestrutura pública para permitir que usuários comuns abram issues
No meu projeto, uso isso em https://github.com/stryan/materia, e funciona bem para centralizar o repositório e as issues
Mas, para entradas aleatórias de usuários, continuo usando o GitHub Discussions como um pseudo bug tracker
Se for bug, eu adiciono no git-bug e sincronizo com GitHub issues para ficar visível publicamente, mas essa abordagem não funciona tão bem para grandes volumes de bug reports de usuários
Ironicamente, tirei essa ideia de workflow do ghostty e do mise: ambos primeiro recebem bugs em discussion e só criam uma issue etiquetada quando ela é realmente acionável
Ótima dica
Fico me perguntando qual é a principal causa por trás da grande queda de qualidade do GitHub
Há quem diga que código gerado por IA degradou a qualidade da codebase, e há quem diga que, depois da aquisição pela Microsoft, se espalhou uma cultura de engenharia ruim
Talvez seja uma mistura das duas coisas em algum grau
https://news.ycombinator.com/item?id=45517173
https://github.blog/news-insights/company-news/an-update-on-github-availability/
Parece o resultado da mistura de cultura e infraestrutura da Microsoft, e agora a qualidade lembra a de outros serviços da empresa
E, acrescentando: os binários do dotnet CLI são hospedados de forma tão instável que meu CI quebra com frequência, então precisei re-hospedá-los eu mesmo
Continuam acontecendo incidentes do tipo em que a página de Pull Request mostra resultados incompletos, e os dados não sumiram, mas enquanto o índice do Elasticsearch está sendo reconstruído a lista não aparece direito até a reindexação terminar
Ele disse que nos próximos meses vai compartilhar com mais detalhes para onde o projeto Ghostty será movido, então isso também pode soar como trocar um problema em que GitHub Issues ou PRs ficam indisponíveis às vezes ao longo do dia por um estado de indisponibilidade por meses
A decisão parece um pouco emocional e tomada às pressas, e não me parece necessariamente a melhor coisa para ele, para o Ghostty ou para a comunidade
No mínimo, eu gostaria que já houvesse um caminho de backup preparado antes de fazer a mudança