Ghostty deja GitHub: 65 incidentes en 2 meses y lección para founders

¿Qué pasó realmente con Mitchell Hashimoto y GitHub?

Mitchell Hashimoto, cofundador de HashiCorp y usuario #1299 de GitHub desde febrero de 2008, anunció el 28 de abril de 2026 que Ghostty abandona la plataforma tras 18 años. La razón no es económica ni ideológica: es puramente operativa. GitHub registró 65+ incidentes en solo dos meses (37 en febrero y 28 en marzo de 2026), con una disponibilidad del 90.21% en los últimos 90 días, muy por debajo del SLA prometido de 99.9%.

Hashimoto documentó durante un mes cada día en que los apagones de GitHub bloquearon su trabajo. En sus propias palabras: «Casi todos los días tienen una X». El día que escribió su anuncio, estuvo bloqueado durante ~2 horas para hacer revisiones de pull requests debido a un outage de GitHub Actions.

¿Por qué un cofundador de HashiCorp dice que GitHub ya no es para «trabajo serio»?

La declaración de Hashimoto es contundente: «GitHub ya no es un lugar para trabajo serio». Y viene de alguien que literalmente construyó su carrera sobre esta plataforma. En su publicación oficial, expresó: «Amo GitHub más de lo que una persona debería amar algo, y estoy furioso con eso».

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Los problemas específicos que cita incluyen:

Disponibilidad intermitente de repositorios, issues y GitHub Actions
Degradación del rendimiento en operaciones diarias
Un error de Elasticsearch el 27 de abril de 2026 que causó fallos críticos en pull requests
Inestabilidad creciente en CI/CD

Lo más revelador: Hashimoto aclaró que «no es un lugar divertido para mí estar más. Quiero trabajar y no puedo trabajar con GitHub». Cuando alguien con su trayectoria llega a ese punto, es una señal de alarma para todo el ecosistema.

¿Es solo Ghostty o hay un éxodo más grande?

La migración de Ghostty es parte de un movimiento más amplio. Proyectos clave como Zig, Strudel y Tenacity han anunciado o completado migraciones fuera de GitHub durante 2025-2026.

El caso de Zig es particularmente ilustrativo: completó su migración a Codeberg en 2025, citando abandono de herramientas críticas y priorización de IA sobre mantenimiento. De forma aún más drástica, la Zig Foundation cortó su dependencia financiera de GitHub Sponsors (que generaba $170,000 anuales), calificando esa dependencia como una «liability» estratégica.

Codeberg duplicó su base de usuarios en menos de un año hasta finales de 2025, señal clara de que desarrolladores buscan alternativas. Los factores concurrentes que reportan los desarrolladores incluyen: inestabilidad en CI/CD, cambios de producto frecuentes, ruido generado por Copilot e IA generativa, y liderazgo poco claro.

¿Qué tiene que ver Microsoft y la obsesión por IA en todo esto?

Hashimoto sugiere una conexión directa: las inestabilidades crecientes de GitHub coinciden con la obsesión de Microsoft por integrar IA forzadamente en sus productos. Esto ocurre mientras Microsoft ha admitido que Windows tiene problemas serios de calidad parcialmente causados por inyectar IA en demasiadas herramientas.

El patrón es claro: la infraestructura de confiabilidad está siendo sacrificada por características de IA. Para una plataforma que se convirtió en la infraestructura social del open source (donde vive no solo el código sino toda la comunidad), esto es crítico.

La paradoja del desarrollo open source: Git fue diseñado como sistema distribuido donde cualquiera puede tener una copia completa del repositorio, pero el mundo estandarizó en GitHub como servicio centralizado gigante. Ahora, proyectos están reevaluando si esa centralización es sostenible cuando el proveedor pierde confiabilidad.

¿Qué significa esto para tu startup?

Si tu startup depende de GitHub para repositorios, CI/CD, issues o gestión de comunidad, este caso es una lección crítica. La estabilidad operativa es una característica no negociable en infraestructura crítica, especialmente cuando afecta la capacidad de tu equipo de hacer ship de software diariamente.

Acción 1: Auditoría de dependencia única

Mapea todas las dependencias de tu startup en GitHub (repos, Actions, Issues, Packages, Sponsors)
Calcula el impacto económico de un outage de 24-48 horas en tu operación
Identifica qué componentes son críticos vs. convenientes

Acción 2: Plan de diversificación incremental

Evalúa alternativas como GitLab, Codeberg o Forgejo para repositorios críticos
Considera herramientas de CI/CD independientes (CircleCI, Buildkite, Jenkins) para pipelines esenciales
Implementa espejos de repositorios en múltiples plataformas (costo bajo, beneficio alto)
Documenta procedimientos de migración antes de necesitarlos

Acción 3: Negocia SLA reales

Si usas GitHub Enterprise, revisa el SLA contractual vs. la realidad operativa (90.21% vs. 99.9% prometido)
Exige compensaciones por downtime que afecte producción
Considera contratos con proveedores alternativos como respaldo

Hashimoto aclaró que «tenemos un plan pero también estoy en discusiones activas con múltiples proveedores (tanto comerciales como FOSS)». La migración será incremental para remover todas las dependencias de GitHub. Ese es el enfoque que deberías considerar: no un abandono impulsivo, sino una estrategia deliberada de reducción de riesgo.

Lecciones para founders hispanohablantes

Para startups en LATAM y España, este caso tiene matices adicionales:

Menos margen de error: Con equipos más pequeños y menos capital, un outage de 2 horas puede significar perder una ventana de fundraising o lanzamiento
Dependencia de herramientas globales: Muchas startups hispanas usan GitHub como estándar sin evaluar alternativas locales o europeas (como Codeberg en Alemania)
Oportunidad de diferenciación: Si tu startup ofrece infraestructura developer, la confiabilidad es tu principal argumento de venta frente a gigantes que priorizan IA sobre estabilidad

La realidad: cuando una plataforma se convierte en infraestructura crítica para toda una industria, su confiabilidad deja de ser opcional. Y cuando esa confianza se erosiona, afecta toda la cadena de suministro que se formó alrededor de la plataforma.