Ghostty Deja GitHub: Implicaciones para Creadores de Herramientas de Desarrollo

El 28 de abril de 2026, Mitchell Hashimoto anunció que Ghostty, su emulador de terminal de código abierto, dejará GitHub. Hashimoto es el usuario 1299 de GitHub, se unió en febrero de 2008 y usó la plataforma casi todos los días durante más de 18 años. Pero el día del anuncio, una falla de GitHub Actions bloqueó sus revisiones de PR durante dos horas. Su conclusión fue directa: “Este ya no es un lugar para un trabajo serio si te bloquea durante horas al día, todos los días.”

Prueba Apidog hoy

Si desarrollas herramientas para desarrolladores, este anuncio merece una lectura operativa, no solo anecdótica. Hashimoto no es un usuario casual: cofundó HashiCorp sobre GitHub y lanzó Terraform, Vagrant, Vault, Consul y Boundary usando esa plataforma. Cuando un perfil así migra por fiabilidad, el problema no es solo “qué forja usará Ghostty”, sino cómo diseñar tu propia pila para no quedar bloqueado por un proveedor crítico.

Para contexto adicional sobre flujos de trabajo de desarrollo en la era de la IA, consulta cómo escribir archivos AGENTS.md, el uso de GitHub Copilot y la API de facturación para equipos y 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.
• La razón principal fue la fiabilidad: interrupciones recurrentes de GitHub Actions y de la plataforma, documentadas por él en un diario donde “casi todos los días tienen una X”.
• El día del anuncio, una interrupción de Actions bloqueó sus revisiones de PR durante dos horas.
• El repositorio de Ghostty en GitHub seguirá como espejo de solo lectura.
• El desarrollo activo migrará de forma incremental a otra forja.
• Sus otros proyectos seguirán en GitHub por ahora.
• La lección para equipos de herramientas de desarrollo y APIs: desacopla proveedores, simula dependencias externas y prueba rutas de migración antes de necesitarlas.
• Apidog sigue ese patrón para flujos de trabajo de APIs: definición, pruebas, mocks y entornos separados.

Lo que dijo Hashimoto

La publicación del anuncio es breve y clara. No es un manifiesto contra Microsoft ni una promoción de otra forja. Hashimoto explica tres hechos:

1. Empezó a registrar interrupciones de GitHub.
2. El registro se llenó más rápido de lo esperado.
3. Una falla de GitHub Actions bloqueó su trabajo el mismo día en que escribió la publicación.

La interrupción del 27 de abril de 2026 afectó Actions, paquetes y la superficie de la API. Según Hashimoto, el diario ya existía antes de ese incidente, por lo que la decisión no fue una reacción a un solo mal día. La interrupción influyó en el momento del anuncio, no en el motivo de fondo.

También aclaró el alcance:

• Ghostty migra.
• Sus otros proyectos permanecen en GitHub por ahora.
• El repositorio de Ghostty seguirá disponible como espejo de solo lectura.
• Issues, PRs y CI se moverán a una nueva forja.
• La migración será incremental.

La parte importante: no se fue por características, precios o dirección de producto. Se fue porque la plataforma dejó de ser lo suficientemente fiable para su flujo de trabajo.

Por qué la fiabilidad importa más que la migración

La pregunta útil no es “¿a dónde se va Ghostty?”. La pregunta útil es:

¿Qué pasa cuando una herramienta crítica deja de funcionar durante las horas en que tus usuarios más productivos la necesitan?

Para equipos que construyen herramientas de desarrollo, hay tres señales relevantes.

1. El usuario que se va importa

Hashimoto ha construido herramientas de infraestructura usadas en empresas grandes. Su opinión sobre fiabilidad llega a personas que toman decisiones sobre dónde alojar código, CI, issues y lanzamientos.

2. La razón es difícil de rebatir

No se trata de una discusión ideológica. La queja es operativa:

“No puedo trabajar porque la plataforma no responde.”

Si tus usuarios empiezan a medir interrupciones por su cuenta, tu página de estado ya perdió autoridad.

3. El tono es de post-mortem

La publicación no es agresiva. Parece escrita por alguien que intentó quedarse y concluyó que el coste operativo ya no compensaba.

Para un producto de desarrollo, ese es el peor escenario: un usuario experto que se va sin drama, con datos y sin necesidad de exagerar.

Cómo evaluar si tu herramienta está en la misma trayectoria

Si tu producto está en la ruta crítica de otros desarrolladores, ejecuta esta revisión.

Paso 1: calcula horas perdidas por cliente

No mires solo disponibilidad global. Cruza incidentes con horas reales de uso.

Ejemplo de tabla mínima:

Incidente	Duración	Componente	Clientes afectados	Horas de trabajo bloqueadas
CI degradado	2 h	Builds	12	24 h
API lenta	45 min	API pública	8	6 h
Login caído	30 min	Auth	20	10 h

Si tus usuarios intensivos pierden tiempo todas las semanas, tienes un problema aunque tu SLA agregado se vea bien.

Paso 2: mide tendencia, no solo uptime

Un 99.9% estable puede ser aceptable. Un 99.95% que empeora mes a mes puede ser una alerta.

Mide por componente:

componente: ci
slo: 99.9%
presupuesto_error_mensual: 43.2 min
incidentes_mes_actual: 68 min
estado: excedido
tendencia: peor que mes anterior

Si no tienes presupuesto de error por componente, no sabes si tu fiabilidad mejora o empeora.

Paso 3: publica degradaciones parciales

Una página de estado útil no debe limitarse a “operativo” o “caído”.

Publica estados como:

• Builds con retraso.
• API con latencia elevada.
• Webhooks en cola.
• Región degradada.
• Autenticación intermitente.

Los usuarios empiezan diarios privados cuando la señal pública no coincide con su experiencia.

Paso 4: mide disponibilidad contra la curva de uso del cliente

Dos horas de caída a las 03:00 pueden ser irrelevantes para algunos equipos. Dos horas durante revisión de PR, despliegue o release pueden bloquear todo el flujo.

Mide fiabilidad así:

disponibilidad_global = tiempo_ok / tiempo_total

disponibilidad_ponderada =
  tiempo_ok_durante_uso_real / tiempo_total_durante_uso_real

Para herramientas de desarrollo, la segunda métrica suele ser más honesta.

El coste real del “siempre GitHub”

Hashimoto escribió que para él “nunca fue una pregunta” dónde poner sus proyectos: siempre GitHub.

Ese hábito tiene coste.

Git es portable, pero el flujo de trabajo completo no lo es. Puedes clonar un repositorio, pero no migras con un solo comando:

• Issues.
• PRs.
• Reviews.
• Comentarios.
• Discusiones.
• Secrets.
• Workflows de GitHub Actions.
• Packages.
• Releases.
• CODEOWNERS.
• Permisos.
• OAuth apps.
• Integraciones del Marketplace.

El lock-in no está solo en el código. Está en todo lo que rodea al código.

Patrón práctico: trata GitHub como proveedor, no como infraestructura única

Si tu herramienta depende de GitHub, pon una capa de abstracción desde el inicio.

Ejemplo simple en TypeScript:

interface ForgeClient {
  getPullRequest(repo: string, id: number): Promise<PullRequest>;
  listIssues(repo: string): Promise<Issue[]>;
  createComment(repo: string, issueId: number, body: string): Promise<void>;
}

class GitHubClient implements ForgeClient {
  async getPullRequest(repo: string, id: number) {
    // llamada a GitHub API
  }

  async listIssues(repo: string) {
    // llamada a GitHub API
  }

  async createComment(repo: string, issueId: number, body: string) {
    // llamada a GitHub API
  }
}

class ForgejoClient implements ForgeClient {
  async getPullRequest(repo: string, id: number) {
    // llamada a Forgejo API
  }

  async listIssues(repo: string) {
    // llamada a Forgejo API
  }

  async createComment(repo: string, issueId: number, body: string) {
    // llamada a Forgejo API
  }
}

Luego selecciona el proveedor por configuración:

function createForgeClient(provider: string): ForgeClient {
  switch (provider) {
    case "github":
      return new GitHubClient();
    case "forgejo":
      return new ForgejoClient();
    default:
      throw new Error(`Proveedor no soportado: ${provider}`);
  }
}

El objetivo no es soportar todas las forjas desde el día uno. El objetivo es no acoplar todo tu producto a una API específica.

Alternativas de forja mencionadas en el debate

Hashimoto no anunció destino. Las alternativas creíbles a finales de abril de 2026 incluyen:

• Forgejo: hard fork de Gitea, FOSS, mantenido por Codeberg e.V. La federación vía ActivityPub está en la hoja de ruta y parcialmente implementada.
• Codeberg: instancia gestionada de Forgejo, sin fines de lucro y gratuita para proyectos de código abierto.
• GitLab: CI/CD fuerte, amplia paridad funcional con GitHub y respaldo comercial.
• Sourcehut: flujo basado en correo, minimalista y rápido.
• Forgejo o Gitea autoalojado: máximo control, mayor carga operativa.
• Radicle: enfoque peer-to-peer sin host central, aún temprano para muchos proyectos públicos.

La señal importante es que ninguna opción reemplaza todo GitHub de forma perfecta. Esa es precisamente la consecuencia de concentrar repositorios, CI, issues, paquetes, identidad y releases en una sola plataforma.

Lección para equipos de API

Si trabajas con APIs, cambia los nombres:

• “GitHub Actions” → “API ascendente de la que depende tu producto”.
• “Issues y PRs” → “canales donde tus clientes reportan problemas”.
• “Forja” → “proveedor externo crítico”.

La pregunta es la misma:

¿Qué puede seguir haciendo tu equipo cuando un servicio que no controlas falla durante cuatro horas?

Tres patrones ayudan.

1. Simula todo proveedor crítico

Tus tests y tu desarrollo local no deberían depender siempre de una llamada real a red.

Flujo recomendado:

1. Define el contrato de la API.
2. Genera un mock server.
3. Ejecuta tests contra el mock en local.
4. Ejecuta tests de contrato contra el proveedor real en CI.
5. Cambia de entorno sin modificar código.

Ejemplo de configuración:

API_ENV=mock
API_BASE_URL=http://localhost:4010
API_KEY=test

Para staging:

API_ENV=staging
API_BASE_URL=https://sandbox.provider.com
API_KEY=${STAGING_API_KEY}

Para producción:

API_ENV=prod
API_BASE_URL=https://api.provider.com
API_KEY=${PROD_API_KEY}

Apidog permite definir APIs, generar mocks y reutilizar esas definiciones para pruebas. Para un ejemplo de ecosistema multiproveedor, consulta cómo usar la API GPT-5.5.

2. Prueba contra múltiples proveedores

Si tu producto depende de modelos o APIs con formas similares, evita diseñar solo para uno.

Ejemplo conceptual:

interface ChatProvider {
  complete(input: ChatRequest): Promise<ChatResponse>;
}

class OpenAIProvider implements ChatProvider {
  async complete(input: ChatRequest) {
    // llamada a OpenAI
  }
}

class AnthropicProvider implements ChatProvider {
  async complete(input: ChatRequest) {
    // llamada a Anthropic
  }
}

class FallbackChatProvider implements ChatProvider {
  constructor(
    private primary: ChatProvider,
    private fallback: ChatProvider
  ) {}

  async complete(input: ChatRequest) {
    try {
      return await this.primary.complete(input);
    } catch (error) {
      return await this.fallback.complete(input);
    }
  }
}

El fallback no debe improvisarse durante un incidente. Debe estar probado antes.

3. Desacopla el pipeline de release

Si tu release depende 100% de GitHub Actions, una caída de Actions bloquea tu entrega.

Opciones prácticas:

• Replica el pipeline crítico en otro runner.
• Mantén un flujo manual documentado.
• Autoaloja jobs críticos.
• Publica artefactos en más de un destino.
• Prueba el flujo alternativo cada trimestre.

Ejemplo de checklist para release manual:

[ ] Ejecutar tests localmente
[ ] Construir artefactos
[ ] Firmar release
[ ] Publicar paquete
[ ] Crear tag
[ ] Actualizar changelog
[ ] Notificar canal interno

Si este procedimiento no existe, tu plan real durante una caída es esperar.

Flujo de trabajo resiliente con Apidog

Un flujo práctico para equipos de API:

1. Descarga Apidog.
2. Crea un proyecto por cada API ascendente crítica.
3. Define esquemas de request y response una sola vez.
4. Genera mocks desde esos esquemas.
5. Crea entornos separados: dev, mock, staging, prod.
6. Guarda credenciales como secretos por entorno.
7. Escribe pruebas de contrato.
8. Ejecuta las mismas pruebas contra mock, sandbox y proveedor real.
9. Documenta cómo cambiar de proveedor o entorno durante una degradación.

Ejemplo de estructura de entornos:

dev
  base_url = http://localhost:4010
  auth = none

staging
  base_url = https://sandbox.api.example.com
  auth = staging_secret

prod
  base_url = https://api.example.com
  auth = prod_secret

El punto no es eliminar dependencias externas. El punto es que tu equipo pueda seguir desarrollando, probando y entregando aunque una dependencia falle.

Qué están leyendo los desarrolladores del anuncio

Las reacciones se agrupan así:

• “Bien por él”: usuarios avanzados que ya estaban frustrados con interrupciones y ven el anuncio como validación.
• “Es solo una interrupción”: desarrolladores que comparan uptime agregado y recuerdan que toda plataforma grande tiene incidentes.
• “Migrar es difícil”: equipos que entienden que mover issues, PRs y CI cuesta más que clonar un repositorio.
• “¿Qué pasa con mis repos?”: mantenedores pequeños que evalúan si el riesgo aplica a su escala.

La conversación importante ocurre dentro de equipos de ingeniería:

• ¿Tenemos espejo de repositorios?
• ¿Podemos lanzar si GitHub Actions cae?
• ¿Tenemos backup de issues?
• ¿Qué integraciones dependen exclusivamente de GitHub?
• ¿Cuál es nuestro plan de salida?

Checklist para reducir dependencia de una sola plataforma

Usa esta lista como punto de partida.

Repositorios

• [ ] Crear espejo en una segunda forja.
• [ ] Automatizar sincronización semanal o diaria.
• [ ] Verificar que los tags también se sincronicen.
• [ ] Documentar cómo cambiar el remoto principal.

Ejemplo:

git remote add backup [e-mail]:org/repo.git
git push backup main --tags

CI/CD

• [ ] Identificar jobs críticos.
• [ ] Separar build, test y publish.
• [ ] Replicar jobs críticos fuera de GitHub Actions.
• [ ] Documentar release manual.
• [ ] Probar el flujo alternativo.

APIs externas

• [ ] Listar proveedores en ruta crítica.
• [ ] Definir mocks para cada API.
• [ ] Añadir timeouts explícitos.
• [ ] Añadir retries con backoff.
• [ ] Añadir fallback cuando tenga sentido.

Ejemplo de timeout:

const controller = new AbortController();

const timeout = setTimeout(() => {
  controller.abort();
}, 5000);

try {
  const response = await fetch(url, {
    signal: controller.signal,
  });

  return await response.json();
} finally {
  clearTimeout(timeout);
}

Observabilidad

• [ ] Medir errores por componente.
• [ ] Medir latencia por proveedor.
• [ ] Separar incidentes internos de incidentes de terceros.
• [ ] Publicar degradaciones parciales.
• [ ] Revisar tendencia mensual.

Producto

• [ ] Mostrar mensajes claros cuando un proveedor externo falla.
• [ ] Permitir modo degradado.
• [ ] Evitar que una falla externa bloquee todo el flujo.
• [ ] Cachear datos no críticos.
• [ ] Diseñar integraciones como adaptadores reemplazables.

Para un ejemplo aplicado a herramientas de API y proveedores de IA, consulta la construcción de flujos de trabajo duraderos que sobreviven a las interrupciones del proveedor.

Preguntas frecuentes

¿A dónde se muda Ghostty?

Hashimoto no anunció destino. Dijo que está conversando con múltiples proveedores, comerciales y FOSS, y que la migración será incremental. El repositorio actual en GitHub seguirá como espejo de solo lectura.

¿GitHub es tan poco fiable?

GitHub mantiene números de disponibilidad competitivos frente a plataformas similares. El punto de Hashimoto no es solo el uptime agregado, sino el patrón de interrupciones parciales que bloquean trabajo real durante horas.

¿Debería sacar mis repositorios de GitHub ahora?

No necesariamente. Pero duplicarlos en una segunda forja es una medida barata y útil. Para muchos equipos, el primer paso no es migrar por completo, sino tener una copia funcional y un plan probado.

¿Esto afecta GitHub Copilot o GitHub Actions?

La publicación no se centra en Copilot. El detonante inmediato fue una interrupción de GitHub Actions. Si tu equipo usa Copilot y necesita entender cambios de facturación, revisa el uso de GitHub Copilot y la API de facturación para equipos.

¿Qué significa esto para herramientas de IA que dependen de GitHub?

Bots de revisión, triage de issues, servidores MCP e integraciones similares heredan parte de la fiabilidad de GitHub. Mitigaciones básicas:

• Cachear respuestas.
• Fallar en abierto cuando sea posible.
• Simular GitHub en tests.
• Separar lógica de negocio del cliente de GitHub.
• Preparar adaptadores para otras forjas.

La descripción del bot de triaje Clawsweeper muestra un ejemplo de este tipo de integración.

¿Es una tendencia de “abandonar GitHub”?

Probablemente será lenta. Migrar un proyecto no trivial fuera de GitHub implica mover mucho más que código. Pero el anuncio cambia la conversación: si un usuario histórico decide que el coste de migrar es menor que el coste de seguir bloqueado, otros equipos empezarán a hacer el mismo cálculo.

¿Qué significa “creador de herramientas para desarrolladores”?

Cualquier persona que construye software usado por otros desarrolladores para entregar software. Incluye:

• Terminales.
• Editores.
• CI/CD.
• Clientes de API.
• Herramientas de monitoreo.
• Registros de paquetes.
• Bots de revisión.
• Asistentes de IA.
• Plataformas de documentación.

Si tu herramienta está en la ruta crítica de un desarrollador, la fiabilidad no es una característica más. Es el producto.