Mitchell Hashimoto é o GitHub user #1299. Entrou em fevereiro de 2008, quando a plataforma ainda era praticamente uma startup. Criou o Vagrant lá. Cofundou a HashiCorp, empresa por trás do Terraform, Vault e Consul — ferramentas que rodam em praticamente toda empresa que se leva a sério no mundo DevOps. O cara visitou o GitHub todos os dias por 18 anos consecutivos.

E na última segunda-feira, ele publicou um post dizendo que vai embora.

Não é drama. Não é birra. É um desenvolvedor que documenta, com dados, que o GitHub trava tanto que ele não consegue mais trabalhar.

O Diário dos Outages

Hashimoto manteve um diário. Literalmente. Cada dia em que um outage do GitHub impediu seu trabalho, ele marcava com um “X”. O resultado? “Quase todo dia tem um X.”

Os números oficiais confirmam a frustração. Segundo os próprios relatórios de disponibilidade do GitHub, a plataforma registrou 37 incidentes em fevereiro de 2026 e 28 em março. São 65 incidentes em dois meses. Mais de um por dia.

E não estamos falando de micro-interrupções invisíveis. Em 3 de março, 40% das requisições ao github.com falharam. 43% das chamadas à API retornaram erro. Em 5 de março, 95% dos workflows do GitHub Actions não conseguiram iniciar em menos de 5 minutos, e 10% falharam completamente com erro de infraestrutura.

Em fevereiro, o cluster de banco de dados responsável por autenticação e gerenciamento de usuários ficou sobrecarregado, derrubando github.com, a API, Actions, operações Git e até o Copilot.

Hashimoto resumiu: “Eu quero entregar software e a plataforma não me deixa entregar software.”

O Estopim: 27 de Abril

O post já estava escrito há mais de uma semana quando, em 27 de abril de 2026, o GitHub sofreu mais um outage significativo — desta vez envolvendo problemas com Elasticsearch que impediram pull requests de serem completados.

Para Hashimoto, foi a confirmação final. Não a causa — ele já havia tomado a decisão meses antes — mas o ponto que tirou qualquer dúvida restante.

“GitHub não é mais um lugar para trabalho sério se te bloqueia por horas todo dia”, escreveu ele.

A frase circulou rápido. Mitchell Hashimoto dizendo que o GitHub não serve mais para trabalho sério tem um peso enorme. Esse não é um dev random reclamando no Twitter. É um dos nomes mais respeitados do ecossistema open source, que literalmente ajudou a construir as ferramentas de infraestrutura que metade da indústria usa.

O Que Está Quebrando no GitHub?

Quando a InfoQ investigou as causas raiz, o próprio GitHub reconheceu os problemas. Os principais fatores:

Esse último ponto é particularmente irônico. O GitHub investiu pesado no Copilot e na integração com IA, mas os próprios workflows gerados por essas ferramentas estão sobrecarregando a plataforma. O GitHub reconheceu que precisa se projetar para 30x a escala atual, e que o principal driver desse crescimento são os “agentic development workflows” — agentes de IA que fazem commits, abrem PRs e rodam Actions automaticamente.

Ou seja: o GitHub está caindo porque a Microsoft empurrou IA em tudo, e agora a infraestrutura não aguenta o tráfego que a própria IA gera. Tem uma poesia trágica nisso.

Ghostty: O Projeto que Vai Embora

Para quem não conhece, o Ghostty é um emulador de terminal criado por Hashimoto como projeto pessoal desde 2021. Não é um terminal qualquer — é uma aplicação nativa (SwiftUI no macOS, GTK no Linux) com aceleração por GPU, renderização via OpenGL/Metal e um parser de terminal otimizado com instruções SIMD específicas por CPU.

A arquitetura é multi-threaded: threads dedicadas para leitura, escrita e renderização por terminal aberto. O core é uma biblioteca cross-platform chamada libghostty, com ABI compatível com C, que pode ser embarcada em outras aplicações.

Em termos técnicos, o Ghostty compete com Kitty, Alacritty e WezTerm, mas com a filosofia de ser verdadeiramente nativo em cada plataforma — não um wrapper Electron ou uma janela OpenGL com UI customizada, mas uma aplicação que respeita as convenções do sistema operacional onde roda.

O projeto cresceu rápido e tem uma comunidade ativa. E agora, vai sair do GitHub.

Para Onde o Ghostty Está Indo?

Hashimoto está em conversas com múltiplos provedores, tanto comerciais quanto open source. As alternativas mais prováveis, baseadas no que ele mencionou e no que a comunidade está discutindo:

Codeberg — Uma organização sem fins lucrativos sediada na Alemanha que roda o Forgejo, um fork comunitário do Gitea. É a escolha “ética” — sem rastreamento, sem IA treinando no seu código, sem motivação de lucro. O CodeInsider já cobriu esse movimento quando o GitHub anunciou que usaria código para treinar IA.

GitLab — A opção corporativa. Self-hosted ou SaaS, com CI/CD integrado que é genuinamente bom. Mas vem com sua própria complexidade e tem seus próprios problemas de escala.

Forgejo auto-hospedado — Para quem quer controle total. O Forgejo v14.0, lançado em janeiro de 2026, trouxe filtros inline para issues e PRs, substituiu o editor Monaco pelo CodeMirror, e continua tornando a UI funcional sem JavaScript.

Tangled — Um projeto novo que apareceu no Hacker News justamente nesta semana, propondo uma federação de forges. A ideia é que múltiplas instâncias de hospedagem de código possam se comunicar entre si, como acontece com o Mastodon no mundo das redes sociais.

Hashimoto planeja uma migração incremental. O repositório atual no GitHub vai continuar como mirror read-only. Seus projetos pessoais ficam no GitHub por enquanto — só o Ghostty está se mudando.

O Efeito Dominó

O Ghostty não é o primeiro projeto a sair do GitHub em 2026. O Strudel, uma plataforma de live coding musical, já migrou. O Tenacity, fork do Audacity, também. E o movimento ganha força cada vez que o GitHub cai.

Armin Ronacher, criador do Flask e do Jinja2, publicou um ensaio chamado “Before GitHub” no mesmo dia do anúncio de Hashimoto. Nele, ele reflete sobre como era o desenvolvimento open source antes do GitHub centralizar tudo — quando projetos rodavam em infraestrutura própria com Trac, Subversion e mailing lists.

O ponto de Ronacher não é nostalgia. É um alerta: o GitHub funcionou como um arquivo público acidental do open source. Issues, discussões, release artifacts — tudo isso vive lá. Se projetos migram para plataformas menores ou auto-hospedadas, esse contexto pode se perder.

“Uma dependência não era apenas um nome de pacote. Era um projeto com uma história, um site, um mantenedor.”

Ronacher defende a criação de “um arquivo público, chato e bem financiado para software Open Source” — algo que preserve a memória cultural do desenvolvimento independente de qualquer empresa.

O Problema Real: Concentração

Vamos ser diretos. O problema não é o GitHub ser ruim. O problema é o GitHub ser o único.

Quando 90%+ dos projetos open source do mundo estão em uma plataforma, qualquer instabilidade se torna um evento de nível industrial. Desenvolvedores não conseguem fazer code review. CI/CD pipelines param. Deploys atrasam. E não existe failover — não dá para “trocar para o backup” quando o GitHub cai, porque não tem backup.

A aquisição pela Microsoft em 2018 já gerou preocupações. A integração forçada do Copilot adicionou mais. Mas foi a degradação da confiabilidade que transformou preocupação em ação.

Isso me lembra do que aconteceu com o SourceForge nos anos 2000. Era a plataforma dominante para open source, até que começou a injetar adware nos downloads e a degradar a experiência. A migração para o GitHub levou anos, mas aconteceu. E o SourceForge nunca se recuperou.

O GitHub em 2026 não está injetando malware, claro. Mas a lição é a mesma: nenhuma plataforma é permanente. A confiança, uma vez perdida, é muito difícil de recuperar.

O Que Fazer Se Você Depende do GitHub

Se você mantém projetos no GitHub — e estatisticamente, você mantém — vale a pena pensar em redundância. Não precisa migrar tudo amanhã, mas considere:

1. Mirrors automáticos — Configure um mirror do seu repositório no Codeberg, GitLab ou um Forgejo self-hosted. O git é descentralizado por design; use isso a seu favor.
2. CI/CD independente — Se você depende 100% do GitHub Actions, qualquer outage paralisa seu pipeline. Considere alternativas como Woodpecker CI ou GitLab CI rodando em infraestrutura própria.
3. Backup de issues e PRs — O código é fácil de espelhar, mas issues, discussions e PRs não são. Ferramentas como gh CLI permitem exportar esses dados. Faça isso regularmente.
4. Documentação fora do GitHub — Se sua documentação vive apenas no GitHub Wiki ou no README, considere hospedar em um domínio próprio. O Hugo, Jekyll ou MkDocs com deploy no Cloudflare Pages ou Vercel resolve isso em uma tarde.

# Exemplo: mirror automático para Codeberg
git remote add codeberg https://codeberg.org/seu-usuario/seu-repo.git
git push codeberg --mirror

# Automatize com um cron job
echo "0 */6 * * * cd /path/to/repo && git push codeberg --mirror" | crontab -

Os Números que o GitHub Não Quer que Você Veja

Vou compilar aqui os dados mais relevantes dos relatórios de disponibilidade de fevereiro e março de 2026:

Para contextualizar: “three nines” (99.9%) de uptime significa ~8.7 horas de downtime por ano. O GitHub não conseguiu manter nem isso. Na prática, muitos desenvolvedores reportaram que o uptime efetivo ficou abaixo de 99% em algumas semanas — o que significa horas de indisponibilidade por semana.

O Que Esperar Daqui para Frente

Hashimoto deixou a porta aberta: ele volta se o GitHub mostrar “resultados reais e melhorias, não palavras e promessas”. Mas não parece otimista.

O GitHub já publicou posts reconhecendo os problemas e prometendo melhorias arquiteturais. Fala em desacoplar serviços, melhorar o gerenciamento de carga e redesenhar para escala 30x. Tudo isso leva tempo — estamos falando de anos de refatoração em uma plataforma que processa bilhões de requisições por dia.

Enquanto isso, a cada outage, mais projetos consideram a saída. E a cada projeto que sai, o GitHub perde um pouco do efeito de rede que o tornou dominante.

Não acho que o GitHub vai “morrer”. Ainda é a plataforma mais conveniente, com o maior ecossistema, e a maioria dos devs não vai migrar tão cedo. Mas a era em que o GitHub era sinônimo de open source está acabando. E Mitchell Hashimoto, user #1299, acabou de puxar a cortina.

Fonte de inspiração: Ghostty is leaving GitHub por Mitchell Hashimoto, Before GitHub por Armin Ronacher