El 28 de abril de 2026, Mitchell Hashimoto anunció que Ghostty, su emulador de terminal de código abierto, dejará GitHub. Es el usuario 1299 de GitHub. Se unió en febrero de 2008. Ha utilizado la plataforma casi todos los días durante más de 18 años. Nada de eso importó el día que escribió la publicación; ya había llevado un diario de interrupciones de “casi todos los días tienen una X”, y una falla de GitHub Actions el día del anuncio bloqueó sus revisiones de PR durante dos horas. Su veredicto fue directo: “Este ya no es un lugar para un trabajo serio si te bloquea durante horas al día, todos los días.”
Si desarrollas herramientas para desarrolladores, este es el anuncio que debes leer dos veces. Hashimoto no es un usuario casual de GitHub; cofundó HashiCorp sobre GitHub, ha lanzado Terraform, Vagrant, Vault, Consul y Boundary a través de ella, y es el usuario 1299 de GitHub. Cuando ese perfil de usuario abandona la plataforma de desarrollo dominante en la Tierra, la historia es más grande que un emulador de terminal eligiendo un nuevo hogar. Es una señal sobre la fiabilidad, la dependencia (lock-in) y lo que cuesta construir una herramienta de la que otros desarrolladores dependen cada día. Este artículo desglosa lo que dijo Hashimoto, lo que significa para cualquiera que entregue herramientas para desarrolladores, y los patrones que protegen tu propia pila de la misma trampa.
Para un contexto más amplio sobre cómo las herramientas para desarrolladores de la era de la IA están cambiando el flujo de trabajo nativo de GitHub, consulta cómo escribir archivos AGENTS.md y el uso de GitHub Copilot y la API de facturación para equipos. Para conocer la perspectiva de un equipo sobre cómo automatizar las brechas de fiabilidad de GitHub, consulta la descripción del bot de triaje Clawsweeper.
En resumen
- Mitchell Hashimoto anunció el 28 de abril de 2026 que Ghostty dejará GitHub por una forja aún sin nombre.
- Su razón: interrupciones crónicas de GitHub Actions y de la plataforma que documentó como “casi todos los días tienen una X” en un diario personal. El día del anuncio hubo una interrupción de Actions de dos horas que bloqueó las revisiones de PR.
- Mantuvo un espejo de Ghostty de solo lectura en GitHub y está migrando el desarrollo activo de forma incremental; sus otros proyectos se mantienen en GitHub por ahora.
- La historia importa menos por dónde aterrice Ghostty y más porque Hashimoto, usuario 1299 de GitHub, se fue por motivos de fiabilidad, no por motivos de características.
- Para los creadores de herramientas para desarrolladores, la lección es que la fiabilidad supera a las características una vez que tu herramienta se encuentra en la ruta crítica de alguien. El "teatro" de las páginas de estado y los tuits de “estamos investigando” no recuperan la confianza.
- Para los equipos de API en particular, el manual es la desvinculación: clientes agnósticos del proveedor, dependencias simuladas durante las interrupciones y rutas de migración que se ejercitan antes de necesitarlas. Apidog se basa en ese patrón.
Lo que dijo Hashimoto en la publicación
La publicación del anuncio es corta, lo cual es parte del mensaje. No hay manifiesto, ni ataque a Microsoft, ni promoción de una forja alternativa. Hashimoto presenta la cronología claramente: comenzó a llevar un diario de interrupciones de GitHub, el diario se llenó más rápido de lo que esperaba, y la mañana en que escribió la publicación, una falla de GitHub Actions le impidió revisar PRs durante dos horas. Concluyó que la plataforma ya no es lo suficientemente fiable para el tipo de trabajo que realiza en Ghostty.
Vale la pena precisar los números en torno al anuncio. El 27 de abril de 2026, el día antes de la publicación de Hashimoto, hubo una importante interrupción de GitHub que afectó a Actions, paquetes y la superficie de la API. El diario al que hace referencia en la publicación es anterior a esa interrupción; ha estado rastreando el patrón durante meses. Él enmarca la medida como algo que se ha planeado discretamente, no como una reacción a un solo mal día. La interrupción del 27 de abril influyó en el momento, no en la decisión.
También es explícito sobre los límites. Ghostty se va; sus otros proyectos se quedan en GitHub por ahora. El repositorio de Ghostty permanecerá como un espejo de solo lectura en la URL actual; una nueva forja albergará el desarrollo activo, incluyendo problemas, solicitudes de extracción (pull requests) e integración continua (CI). Está en conversaciones con múltiples proveedores, tanto comerciales como de código abierto (FOSS), y aún no se ha comprometido con un destino. La migración se implementará de forma incremental, no como un día de cambio total.
La omisión dice tanto como las palabras. Hashimoto no menciona características, precios ni la dirección del producto. La queja es que la superficie de la que dependía deja de responder durante horas, y un proyecto que entrega software no puede ejecutarse en un sustrato que no funciona.
Por qué el ángulo de la fiabilidad importa más que la migración
La mayoría de la cobertura del anuncio está haciendo la pregunta equivocada. La pregunta interesante no es dónde aterriza Ghostty; la pregunta interesante es cómo una plataforma con la profundidad de ingeniería de GitHub llegó al punto en que su segundo usuario OG más prominente se fue por motivos de fiabilidad. La segunda pregunta más interesante es qué dice eso sobre las herramientas que el resto de nosotros estamos construyendo.
Tres cosas hacen que este anuncio sea diferente de la típica publicación de “Me voy de X”.
- El usuario. Hashimoto no es un desarrollador nuevo; ha construido herramientas de infraestructura utilizadas por empresas de la lista Fortune 500. Cuando dice que GitHub no es fiable, la audiencia que recibe ese mensaje incluye a las personas que deciden dónde reside el código fuente de su empresa. Las listas de correo de los CTO ya estaban llenas de la publicación la mañana del 29 de abril.
- La razón. No se fue por Copilot, Microsoft, entrenamiento de IA, contratos con ICE, precios, o cualquiera de los temas habituales de partida. Se fue porque el servicio seguía fallando. Eso reduce la conversación al único eje que todos están de acuerdo en que importa: ¿funciona la herramienta cuando la necesitas?
- El tono. No hay ira. La publicación se lee como un análisis post-mortem escrito por alguien que se esforzó mucho por quedarse. La falta de dramatismo es lo que hace que impacte más fuerte que cualquier publicación más ruidosa. La gente le cree.
Para cualquiera que gestione una herramienta para desarrolladores, esa combinación es el sonido de tu peor escenario. Un usuario de larga trayectoria, sin agenda política, sin disputas públicas, solo una tranquila acumulación de entradas como “la cosa no funcionó hoy” hasta que la ecuación dejó de tener sentido. No hay una respuesta de relaciones públicas para un diario.
Qué significa esto si creas herramientas para desarrolladores
Si tu producto se encuentra en la ruta crítica de un desarrollador, el anuncio de Hashimoto es una prueba de estrés. Ejecútala contra tu propio servicio.
Pregunta uno: ¿qué fracción de tus usuarios podría escribir el mismo diario sobre ti?
Extrae los incidentes de los últimos 90 días de tu página de estado, además de las degradaciones no reportadas que tu equipo conoce pero la página de estado no. Mapea esto contra las horas de trabajo de tus 20 principales clientes. Cuenta cuántas de esas horas se perdieron esperándote. Si la respuesta es “más de cero por semana por usuario intensivo”, estás en la misma trayectoria.
Pregunta dos: ¿cuál es la segunda derivada de tu fiabilidad?
Una fiabilidad que se estanca está bien. Una fiabilidad que se degrada silenciosamente es la trampa. El diario de Hashimoto documentó un patrón, no un evento único. Si no tienes un presupuesto de errores por componente que alguien lea el lunes por la mañana, no puedes saber en qué dirección se mueven tus números.
Pregunta tres: ¿publicas lo suficiente para que los usuarios no necesiten un diario?
Los diarios existen porque los usuarios no confían en la señal pública. Tu página de estado debe estar "caliente", no "fría". Si una característica está degradada, márcala. Si una región es lenta, márcala. Si tu cola de segundo plano lleva 30 minutos de retraso, márcala. Los usuarios que pueden ver la verdad en tiempo real no empiezan diarios.
Pregunta cuatro: ¿eres fiable para el trabajo serio o para la demostración?
Un tiempo de actividad del 99.95% que agrupa todo el tiempo de inactividad en las horas de trabajo de los desarrolladores es peor que un tiempo de actividad del 99.9% distribuido uniformemente. Si tu carga de trabajo es una sesión de revisión de PR de cuatro horas, dos horas de interrupción en cualquier momento son irrelevantes; dos horas de interrupción durante esa sesión son toda la sesión. Mide la disponibilidad contra la curva de uso real del cliente, no la tuya.
La dependencia (lock-in) y el coste de “siempre GitHub”
La frase que Hashimoto usó sobre sí mismo es la más citada en la publicación: “Nunca fue una pregunta para mí dónde pondría mis proyectos: siempre GitHub.” Ese es el costo del hábito, y es el costo que la mayoría de los desarrolladores no valoran correctamente.
Cuando una única plataforma es el valor predeterminado para repositorios, problemas (issues), PRs, CI, distribución de paquetes, lanzamientos e identidad, la superficie de “dependencia (lock-in)” es mucho mayor que la superficie del “historial de git”. Puedes clonar un repositorio git a cualquier lugar; no puedes clonar un gestor de problemas, un historial de revisiones de PR, un hilo de discusiones, el almacén de secretos de GitHub Actions o el flujo de trabajo de revisión vinculado a CODEOWNERS con un solo comando. El costo de la migración tiene la forma de un iceberg.
Ese costo se agrava para los creadores de herramientas. Si tu herramienta para desarrolladores reside dentro de una GitHub Action, se distribuye a través del Marketplace, se autentica contra GitHub OAuth y envía lanzamientos a través de GitHub Packages, la fiabilidad de tu herramienta es un derivado de la fiabilidad de GitHub. Tu presupuesto de errores es una fracción del de ellos. Tus clientes experimentan tu tiempo de inactividad cuando utilizan tu herramienta, pero también experimentan tu tiempo de inactividad cuando GitHub se cae y tu herramienta deja de responder. La atribución de la culpa no siempre es precisa; la experiencia del cliente sí lo es.
El trabajo de desacoplamiento es poco glamuroso y es el trabajo. Haz que cada dependencia sea reemplazable. Trata a GitHub como un proveedor entre varios, no como infraestructura. Prueba la ruta alternativa trimestralmente. Migra las partes que se ajusten mejor a una forja diferente; mantén las partes que no. La línea de Hashimoto sobre la “migración incremental” es la forma correcta para todos, no solo para él.
Las alternativas de forja, brevemente
Los destinos candidatos para Ghostty son de conocimiento público en forma, si no en nombre. Las opciones creíbles a finales de abril de 2026:
- Forgejo. Bifurcación (hard fork) de Gitea, completamente de código abierto (FOSS), mantenido por la organización sin fines de lucro Codeberg e.V. La federación a través de ActivityPub está en la hoja de ruta y parcialmente implementada. La opción predeterminada para proyectos alineados con FOSS.
- Codeberg. Una instancia de Forgejo alojada y gestionada como una organización sin fines de lucro. Gratis para código abierto, aún no hay un equivalente de Actions a la escala de GitHub.
- GitLab. Fuerte CI/CD, paridad completa de características con GitHub en la mayoría de los flujos de trabajo, respaldo comercial. Elección controvertida para la comunidad FOSS dadas las recientes decisiones de licencias.
- Sourcehut. Flujo de trabajo basado en correo electrónico, minimalista, rápido. Audiencia de nicho, pero la audiencia que lo usa lo ama. Las políticas de Drew DeVault son una característica o un error dependiendo de tus prejuicios.
- Forgejo o Gitea autoalojado en hardware sin virtualizar. Máximo control, máxima responsabilidad operativa. La opción de “oscurecerse”.
- Radicle. Peer-to-peer, sin host central. Temprano pero el argumento de la federación es el más fuerte aquí. Probablemente demasiado temprano para un proyecto de cara al público.
Hashimoto explícitamente no se comprometió con ninguna. La señal en el silencio es que ninguna de las opciones es un reemplazo obvio para todo lo que hace GitHub, que es el punto: cuando una plataforma absorbe toda la pila, reemplazarla limpiamente es difícil por diseño.
La lección para los equipos de API
Si construyes APIs o herramientas de API en lugar de emuladores de terminal, el mismo patrón se aplica con los nombres cambiados. Reemplaza “GitHub Actions” por “la API ascendente de la que depende tu producto”. Reemplaza “problemas y PRs” por “la bandeja de entrada donde tus clientes te dicen que algo está mal”. La pregunta estructural es la misma: ¿cuánto del trabajo de tu cliente depende de un servicio que no controlas, y cómo te mantienes útil cuando ese servicio falla?
Tres patrones sobreviven al contacto con la realidad.
Simula todo de lo que dependes. Tus clientes deberían poder seguir construyendo cuando la API ascendente esté caída. Eso significa que la suite de pruebas, el bucle de desarrollo local y la tubería de CI necesitan un servidor simulado que devuelva respuestas realistas sin una llamada de red. Apidog ofrece esto como una característica de primera clase; las mismas definiciones de datos que utilizas para probar la API en vivo generan la simulación. El patrón es sencillo y el costo se paga una sola vez. Consulta la comparación con el ecosistema con forma de OpenAI en cómo usar la API GPT-5.5 para ver cómo es una historia de simulación multiproveedor en la práctica.
Prueba con múltiples proveedores. OpenAI, Anthropic, Mistral, DeepSeek, Google y xAI exponen puntos finales de finalización de chat con formas superpuestas. Si tu producto envuelve a cualquiera de ellos, la diferencia entre “estamos caídos porque OpenAI está caído” y “redirigimos transparentemente a un proveedor de respaldo” son dos días de trabajo de integración. Ejecuta tu suite de pruebas contra cada proveedor que soportas, no solo el principal. Las variables de entorno de Apidog hacen que el cambio sea una modificación de configuración de una sola línea.
Desacopla tu pipeline de lanzamiento de tu plataforma de alojamiento. Si tu CI reside completamente en GitHub Actions y GitHub Actions tiene una mala tarde, tu lanzamiento no llegará a ninguna parte. Reflejar la CI a un segundo ejecutor, o autoalojar al menos las rutas críticas, elimina el único punto de falla. El costo es real; la alternativa es no poder entregar mientras la página de estado de tu proveedor principal cambia de color.
Cómo es un flujo de trabajo al estilo Apidog para un trabajo de API resiliente
Concretamente, aquí tienes el patrón que la mayoría de los equipos utilizan para aislarse de las interrupciones del proveedor ascendente.
- Descarga Apidog y crea un proyecto por cada superficie de API ascendente de la que dependes.
- Define los esquemas de solicitud y respuesta una sola vez. Apidog genera un servidor simulado a partir del esquema para que el bucle de desarrollo nunca se bloquee en el servicio ascendente.
- Almacena las credenciales como secretos con alcance de entorno. La misma forma de solicitud se ejecuta contra
dev(simulado),staging(sandbox) yprod(en vivo) cambiando el entorno. - Escribe pruebas de contrato que se ejecuten en cada lanzamiento; las mismas pruebas se ejecutan contra cada proveedor que soportas, de modo que una regresión en el Proveedor A aparece antes de que los clientes la vean.
- Cuando una API ascendente esté degradada, cambia el entorno a simulado y sigue adelante. El producto sigue entregándose aunque el servicio ascendente no funcione.
Este patrón no es específico de Ghostty ni de la IA; es el patrón de API resiliente que ha dado sus frutos a cada equipo que lo adoptó antes de necesitarlo. La publicación de Hashimoto es el último recordatorio de que debes adoptarlo antes de necesitarlo, no después.
Lo que los desarrolladores están leyendo del anuncio
Las reacciones en las primeras 48 horas se dividen en varias categorías.
- El grupo de “bien por él”. Usuarios avanzados de GitHub de larga data que habían estado frustrados silenciosamente durante meses y vieron la publicación como un permiso para hacer públicas sus propias quejas. Muchos de ellos ya tenían un espejo en una segunda forja; la publicación los inclinó a hacer del espejo el primario.
- Los escépticos de “esto es solo una interrupción”. Personas que señalan que el tiempo de actividad general de GitHub es competitivo con las normas de la industria y que cualquier plataforma grande tiene días malos. No se equivocan en el número macro, pero les falta el punto de la segunda derivada: la tendencia, no el número absoluto, es lo que provocó a Hashimoto.
- Los pragmáticos de “salir de la plataforma es difícil, nos vemos en seis meses”. Ingenieros que han ejecutado una migración de forja y saben que el rastreador de problemas, el historial de PR y la superficie de CI es donde reside el costo de la migración. Tienen razón, y el plan de Hashimoto de “incremental, con un espejo de solo lectura” es la forma correcta para esa restricción.
- Los preocupados de “qué pasa con mis repos”. Mantenedores más pequeños que se preguntan si sus proyectos están expuestos al mismo riesgo. La respuesta es sí en forma, no en escala; una interrupción que le costaría a Hashimoto un día facturable en HashiCorp es un inconveniente menor para un proyecto de fin de semana. Tu cálculo de migración es diferente.
Las reacciones que importan no están en las redes sociales. Están dentro de las organizaciones de ingeniería que eligieron GitHub como sustrato para todo lo que entregan. Las conversaciones están ocurriendo en Slack ahora mismo: ¿cómo reducimos este riesgo, cómo se ve nuestra política interna sobre el reflejo en una segunda forja, y cuál es el plan de salida?
Conclusiones prácticas para tu propia pila
Una lista de verificación corta y con opiniones:
- Duplica tus repositorios activos a una segunda forja semanalmente. Forgejo y Codeberg son gratuitos para código abierto. El costo es un trabajo de CI; el valor es dormir durante la próxima interrupción de cuatro horas.
- Fija la dependencia. Si entregas una herramienta para desarrolladores que llama a las APIs de GitHub, trata al cliente de GitHub como un adaptador intercambiable, no como una importación estricta. Agrega un adaptador de Forgejo o GitLab detrás de la misma interfaz.
- Documenta el plan de contingencia manual. Cuando la tubería de lanzamiento automatizada no puede ejecutarse, ¿cuál es la ruta manual? Si no está documentada, la respuesta es “no podemos lanzar”, y esa respuesta es inaceptable para cualquier herramienta con clientes de pago.
- Audita de qué dependes. Lista cada servicio externo en la ruta crítica. Para cada uno, escribe la respuesta a “¿qué hacemos si esto está caído durante cuatro horas?” Presenta las brechas a la dirección.
- Vigila la segunda derivada. Si la frecuencia de incidentes aumenta mes a mes incluso en un servicio que aún cumple su SLA, planifica la migración antes de que sea forzada.
Para un ejemplo práctico específico de herramientas de API, la publicación sobre la construcción de flujos de trabajo duraderos que sobreviven a las interrupciones del proveedor describe el mismo patrón con código, utilizando DeepSeek y OpenAI como ejemplo de doble proveedor. Las formas cambian; el principio no.
Preguntas frecuentes
¿A dónde se muda Ghostty? Hashimoto no se comprometió con un destino en la publicación del anuncio. Dijo que las conversaciones están en curso con múltiples proveedores, tanto comerciales como de código abierto (FOSS), y que la migración será incremental, no un cambio único. El repositorio actual de Ghostty en GitHub permanecerá como un espejo de solo lectura para que los clones, enlaces y referencias existentes sigan funcionando.
¿Es GitHub tan poco fiable? Los números de tiempo de actividad de GitHub son competitivos con plataformas similares, pero la plataforma ha tenido varias interrupciones prolongadas en 2025 y 2026 que afectaron a Actions, Paquetes y la superficie de la API. La queja de Hashimoto es que el patrón de interrupciones parciales, incluso cuando cada una es corta, se acumula en múltiples horas de trabajo perdidas por semana para los usuarios en la ruta crítica.
¿Debería mover mis repositorios fuera de GitHub ahora? Duplicar los repositorios (mirroring) casi con toda seguridad vale la pena. Un trabajo de CI semanal que empuja a una segunda forja no cuesta esencialmente nada y te proporciona una copia de seguridad funcional la próxima vez que GitHub Actions esté inactivo durante unas horas. Si haces de la segunda forja la principal, depende de tu tolerancia al costo de migración en problemas, historial de PR y configuración de CI; para la mayoría de los equipos, ese costo aún no está justificado por la brecha de fiabilidad.
¿Afecta esto mi uso de GitHub Copilot o GitHub Actions? La publicación de Hashimoto no menciona específicamente ninguno de los dos productos, aunque la interrupción de Actions el día de la publicación fue el detonante inmediato. Copilot es una superficie de producto separada de la plataforma; su fiabilidad se rastrea por separado. Si tu equipo utiliza GitHub Copilot, los cambios de facturación relacionados están documentados en el uso de GitHub Copilot y la API de facturación para equipos.
¿Qué significa esto para las herramientas de desarrollo de la era de la IA que dependen de las APIs de GitHub? Las herramientas que envuelven la API de GitHub (bots de revisión, triaje de problemas, servidores MCP) heredan el perfil de fiabilidad de GitHub por diseño. La mitigación es la misma que para cualquier dependencia de terceros: caché agresivamente, fallar en abierto y simular el servicio ascendente en tu suite de pruebas. El patrón del servidor simulado de Apidog es una forma económica de hacer esto; la descripción del bot de triaje Clawsweeper cubre un ejemplo funcional.
¿Es esto una tendencia de “abandonar GitHub” o un caso aislado? Probablemente el comienzo de una tendencia, pero lenta. Migrar cualquier proyecto no trivial fuera de GitHub es un proyecto de varias semanas; pocos equipos lo hacen por diversión. La señal en la publicación de Hashimoto es que el equilibrio ha cambiado lo suficiente como para que uno de los usuarios más antiguos de la plataforma decidiera que vale la pena pagar el costo de la migración. Es probable que otros proyectos de alto perfil sigan este ejemplo en los próximos 12 meses.
¿Qué significa “creador de herramientas para desarrolladores” en este contexto? Cualquier persona que entregue software que otros desarrolladores utilizan como parte de su flujo de trabajo diario. Esto incluye casos obvios como terminales, editores y ejecutores de CI; también incluye clientes de API, herramientas de monitoreo, registros de paquetes y asistentes de codificación de IA. Si tu cliente es un desarrollador y tu herramienta se interpone entre ellos y la entrega de software, eres un creador de herramientas para desarrolladores, y las lecciones de fiabilidad de la publicación de Hashimoto se aplican directamente.