Ghostty deja GitHub: lo que mis logs de uso dicen sobre la dependencia real de los devs en plataformas de Microsoft

¿Por qué seguimos llamando "comunidad open source" a algo que corre casi completamente sobre infraestructura de una empresa que compró ese espacio por 7.500 millones de dólares? Hace un par de semanas que me pregunto eso cada vez que hago git push origin main y automáticamente disparo un workflow de GitHub Actions, publico en GitHub Pages, genero un release en GitHub Releases y espero que el issue tracker de GitHub notifique a alguien. Todo en la misma plataforma. Todo bajo el mismo techo de Microsoft.

El trending de r/programming sobre Ghostty dejando GitHub llegó a 1110 puntos y abrió una discusión que la mayoría cerró demasiado rápido: "es su decisión", "GitHub igual es gratis para OSS", "nadie los obliga". Sí. Y nadie obligó a nadie a meter la cabeza en la misma bolsa para todo. Eso no lo hace menos arriesgado.

Ghostty leaving GitHub developer dependency: el mapa real del problema

Mitchell Hashimoto — el tipo que construyó Vagrant, Terraform y Packer antes de fundar HashiCorp — sabe leer una dependencia de infraestructura cuando la ve. La decisión de mover Ghostty fuera de GitHub no es un berrinche filosófico. Es alguien con historia suficiente como para reconocer el patrón antes de que duela.

Mi tesis es esta: Ghostty no está dejando GitHub. Está señalando que la industria entera del software open source construyó su cadena de herramientas sobre suelo ajeno, y que eso tiene un costo que rara vez aparece en los dashboards de productividad.

El problema no es Microsoft. El problema es la concentración. Cuando una sola plataforma controla simultáneamente el versionado de código, el CI/CD, la distribución de releases, el sistema de issues, la documentación pública y la identidad del proyecto — eso no es comodidad. Es dependencia sistémica disfrazada de conveniencia.

Y yo también caí. Revisé mis propios logs esta semana para cuantificarlo.

Lo que mis logs dicen: cuánto de mi stack corre sobre GitHub

Tengo cuatro proyectos activos en producción. Un SaaS en Next.js desplegado en Railway, dos librerías TypeScript y un conjunto de scripts de automatización que uso internamente. Los revisé uno por uno.

# Script que usé para auditar la dependencia por repositorio
# Cuenta cuántas "superficies" de GitHub usa cada proyecto

#!/bin/bash
# auditar-dependencia-github.sh

REPO=$1

echo "=== Auditando dependencia de GitHub para: $REPO ==="

# Verificar GitHub Actions
if [ -d ".github/workflows" ]; then
  WORKFLOWS=$(ls .github/workflows/*.yml 2>/dev/null | wc -l)
  echo "[CI/CD] GitHub Actions activos: $WORKFLOWS workflows"
fi

# Verificar GitHub Pages
if git remote -v | grep -q "github.io\|gh-pages"; then
  echo "[DOCS] GitHub Pages: activo"
fi

# Verificar referencias a GitHub Releases en scripts
RELEASE_REFS=$(grep -r "github.com/releases\|gh release\|GITHUB_TOKEN" . \
  --include="*.yml" --include="*.sh" --include="*.ts" | wc -l)
echo "[RELEASES] Referencias a GitHub Releases: $RELEASE_REFS"

# Verificar dependencias que se descargan desde GitHub
GH_DEPS=$(grep -r "github.com" package.json package-lock.json 2>/dev/null | \
  grep -v "devDependencies\|homepage\|repository" | wc -l)
echo "[DEPS] Dependencias que referencian GitHub: $GH_DEPS"

echo ""
echo "Superficie total de GitHub en este repo:"
echo "  CI: $WORKFLOWS workflows"
echo "  Releases: $RELEASE_REFS referencias"
echo "  Deps externas: $GH_DEPS"

Los resultados concretos, sin embellecerlos:

• Proyecto SaaS (Next.js + Railway): 3 workflows de Actions (deploy preview, lint, tests), releases publicados vía gh release create, issues como tracker principal del equipo. Si mañana GitHub cae o cambia sus términos de Actions, el pipeline de deploy se detiene.
• Librería TypeScript 1: CI en Actions, distribución vía npm pero el tag de release que dispara el publish vive en GitHub Releases. Dependencia cruzada.
• Librería TypeScript 2: Idéntico. Más GitHub Pages para la documentación generada con TypeDoc.
• Scripts internos: Sin CI formal, pero el README tiene badges de GitHub y los binarios de herramientas que uso los bajo desde GitHub Releases de terceros.

Contando superficies únicas de GitHub en mi stack: CI/CD, releases, issues, pages, identidad de proyecto (stars/forks como señal social), y autenticación OAuth en un par de integraciones. Seis superficies. Seis puntos de falla concentrados en un mismo proveedor.

Cuando lo vi escrito así, me acordé de cuando en la UBA me explicaron qué es un single point of failure. Llegué a esa clase directo del trabajo, traje puesto, y el profesor dibujó un grafo donde un solo nodo conectaba todo. "Si ese nodo cae, ¿qué pasa?". La respuesta obvia. Aparentemente no tan obvia cuando ese nodo viene con una UI bonita y Actions gratis para proyectos OSS.

Los errores más comunes al evaluar esta dependencia

Error 1: Confundir "gratis" con "sin costo". GitHub Actions tiene tier gratuito generoso para OSS. Eso no significa costo cero. El costo es el lock-in: cuando necesitás algo que Actions no soporta bien, o cuando GitHub cambia los límites (lo hizo en 2023 con el storage de Packages), la migración no es un sed -i. Es reescribir pipelines enteros.

Error 2: Asumir que el código en git está "fuera" de GitHub. El código en sí, sí. Los workflows, las GitHub Actions de terceros que usás, las referencias a $GITHUB_TOKEN, los secrets configurados en la UI — eso no se mueve con un git clone. Lo aprendí cuando quise replicar un pipeline en un runner local para debugging: tardé cuatro horas en entender que tres de mis Actions del marketplace no tenían equivalente portable.

Error 3: Subestimar el costo de migrar issues. Hice la prueba la semana pasada. Exporté los issues de uno de mis repos con la GitHub CLI:

# Exportar issues de GitHub a JSON para auditar el costo de migración
gh issue list --repo juanchi/mi-proyecto \
  --state all \
  --limit 1000 \
  --json number,title,body,labels,comments,createdAt \
  > issues-export.json

# Ver cuántos tienen comentarios con referencias cruzadas a PRs o commits
jq '[.[] | select(.comments > 0)] | length' issues-export.json
# Resultado: 47 de 89 issues tienen comentarios con referencias a PRs
# Esas referencias son URLs de GitHub. En otra plataforma, son texto muerto.

47 de 89 issues con contexto cruzado que se vuelve texto muerto al migrar. No es insuperable. Pero tampoco es el clic que todos imaginan cuando dicen "total, el código es portable".

Error 4: Ignorar la dependencia social. Stars, forks, contributors — son señales de credibilidad en el ecosistema. Si Ghostty migra a Forgejo o Codeberg, pierde esa acumulación de señal social instantáneamente. No porque el proyecto sea peor: porque el ecosistema entrenó a todos para leer esas métricas en GitHub. Eso también es dependencia. La más silenciosa.

Este tipo de concentración silenciosa es el mismo patrón que analicé cuando simulé la migración desde mi stack a OpenAI en Amazon Bedrock: los números parecen prolijos hasta que empezás a contar las superficies de integración que no aparecen en el pricing page.

FAQ: preguntas frecuentes sobre Ghostty, GitHub y dependencia de plataforma

¿Por qué Ghostty específicamente decidió dejar GitHub? La razón pública de Mitchell Hashimoto apunta a control sobre la infraestructura del proyecto y a no depender de una plataforma que puede cambiar sus políticas en cualquier momento. Ghostty tiene un ciclo de desarrollo particular — releases deliberados, comunidad muy curada — y GitHub no es neutral en cómo presenta y distribuye eso. La decisión es coherente con quién es Hashimoto: alguien que construyó HashiCorp viendo de cerca cómo la infraestructura de terceros puede convertirse en una variable de negocio que no controlás.

¿Qué plataformas alternativas a GitHub existen realmente para OSS? Las opciones maduras son Forgejo (fork activo de Gitea, autohosteado), Codeberg (instancia pública de Forgejo), GitLab (self-hosted o SaaS), y SourceHut (minimalista, sin JavaScript en el frontend). Cada una tiene tradeoffs distintos. Codeberg es la más accesible para proyectos OSS que no quieren gestionar infraestructura. GitLab self-hosted es la más completa pero también la más cara de operar. Ninguna tiene la red social de GitHub.

¿Cuánto tiempo lleva migrar un proyecto activo de GitHub a otra plataforma? Depende del nivel de integración. Para un proyecto simple con CI básico y pocos issues: un fin de semana. Para un proyecto con pipelines complejos, Actions del marketplace, GitHub Pages, Releases automatizados y una comunidad activa en los issues: calculá semanas de trabajo real, más el costo de comunicar el cambio a todos los que tienen el repo como referencia. Las referencias cruzadas en issues y PRs son el mayor pain: no migran limpiamente a ninguna plataforma.

¿GitHub Actions es reemplazable sin demasiado drama? Técnicamente sí: Woodpecker CI, Forgejo Actions (compatible con la sintaxis de GitHub), GitLab CI/CD, y Drone son alternativas viables. En la práctica, el ecosistema de Actions del marketplace — especialmente las acciones de terceros que usás sin pensar — no tiene equivalente directo en todos los casos. El formato YAML es similar, pero las acciones específicas (actions/cache, actions/setup-node, integraciones con servicios cloud) necesitan reemplazo manual. No es imposible. Es trabajo que nadie presupuestó.

¿Esto aplica solo a proyectos OSS o también a equipos de empresas? Aplica igual o más a equipos de empresas. En OSS, en el peor caso perdés visibilidad y la migración es dolorosa pero posible. En un equipo corporativo que metió todo en GitHub Enterprise — código, CI, issues, wikis, dependabot, code scanning — una decisión de licenciamiento o un cambio de precios de Microsoft puede convertirse en un evento de riesgo operativo. Yo como Arquitecto de Software evalúo esto como parte del diseño de sistemas: ¿qué pasa si este proveedor cambia sus términos mañana? Si la respuesta es "catástrofe", hay un problema de arquitectura, no solo de preferencia de herramientas.

¿Vale la pena migrar si GitHub sigue siendo "gratis" para OSS? La pregunta correcta no es si vale la pena migrar, sino qué decisiones de diseño tomás hoy que hacen más difícil o más fácil migrar mañana. No necesitás salir de GitHub para reducir la dependencia. Podés: usar runners self-hosted para CI crítico, mantener una copia espejo en otro git host, documentar en un formato portable (no GitHub Wiki), y evitar dependencias de Actions del marketplace que no tengan equivalente fuera de GitHub. La diversificación parcial es más realista que la migración total para la mayoría de los proyectos.

Lo que haría diferente: mi postura concreta

No me voy de GitHub mañana. Sería deshonesto decir lo contrario — tengo proyectos activos, un equipo que trabaja en esa plataforma, y el costo de migración hoy no se justifica. Pero Ghostty me obligó a hacer algo que no había hecho: auditar la superficie real de dependencia y documentarla.

Lo que sí cambié esta semana: activé un mirror automático hacia un Forgejo autohosteado en Railway para los dos repos más críticos. No como alternativa operativa completa, sino como músculo de migración. Que el espejo exista me fuerza a mantener los workflows menos acoplados a APIs específicas de GitHub.

# Configurar mirror automático de GitHub a Forgejo autohosteado
# Esto va en un workflow de GitHub Actions (sí, la ironía)

# .github/workflows/mirror-a-forgejo.yml
name: Mirror a Forgejo

on:
  push:
    branches: ['**']
  delete: {}

jobs:
  mirror:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Historia completa, no solo último commit

      - name: Push al mirror de Forgejo
        run: |
          # Usar deploy key configurada como secret en GitHub
          git remote add forgejo-mirror \
            "https://${{ secrets.FORGEJO_USER }}:${{ secrets.FORGEJO_TOKEN }}@mi-forgejo.railway.app/juanchi/${{ github.event.repository.name }}.git"
          git push forgejo-mirror --all --force
          git push forgejo-mirror --tags --force

El workflow vive en GitHub Actions. Es paradójico. Pero si mañana necesito invertir la relación — empujar desde Forgejo y mantener GitHub como mirror — el setup ya existe. El costo de ese día cae de semanas a horas.

Lo incómodo es que esta conversación debería haber pasado hace cinco años, no cuando un proyecto con 1110 upvotes en r/programming lo pone en la agenda. La misma concentración silenciosa que analicé al revisar qué pasa cuando un agente borra producción aplica acá: el riesgo no es el evento catastrófico obvio, es la dependencia que normalizaste tanto que dejaste de verla como riesgo.

Ghostty no está haciendo nada radical. Está haciendo lo que deberíamos haber hecho todos: preguntarse cuánto poder le dimos a una plataforma que no controlamos, y decidir con los ojos abiertos si ese tradeoff vale.

Yo decidí que el mirror vale. El pipeline completo puede esperar. Pero el músculo de migración, no.

¿Auditaste alguna vez la superficie real de GitHub en tus proyectos? El número que encontrés probablemente te incomode. Contame en los comentarios o en los issues del repo — sí, todavía en GitHub, por ahora.