GitHub se está hundiendo
(dbushell.com)- Desde la adquisición por parte de Microsoft, la disponibilidad (uptime) de GitHub se ha deteriorado de forma visible, e incluso su página oficial de estado muestra cifras preocupantes, mientras que páginas de estado no oficiales reflejan una situación aún más grave
- El abuso de Copilot y la avalancha de código de baja calidad generado por IA (slop) están llevando a GitHub a una situación de autoinfligirse un DDoS, mientras los bots y la economía de estrellas falsas dañan la confianza en la plataforma
- Git es un sistema distribuido de control de versiones de código abierto y funciona sin GitHub, por lo que hay que dejar de equiparar GitHub con Git mismo
- Existen varias forjas Git alternativas, como Codeberg, Tangled, Gitea, GitLab y Forgejo autohospedado, y la migración debería empezar de inmediato
- Varios desarrolladores reconocidos han publicado seguidamente textos anunciando su salida de GitHub, y reducir la dependencia de GitHub está emergiendo como un reto para todo el ecosistema
Razones para dejar GitHub
- GitHub ha recibido críticas porque, desde la adquisición de Microsoft, su tiempo de actividad y la experiencia de uso han empeorado; se considera que la página de estado con incidentes omitidos muestra una tendencia peor que la disponibilidad oficial
- El gráfico de GitHub’s Historic Uptime se usa como evidencia de que el promedio mensual de disponibilidad se volvió inestable después de la compra por Microsoft
- Tras adquirir GitHub, Microsoft amplió su familia de productos relacionada con Copilot, y GitHub está tan afectado por el “slop” que incluso publicó su propia actualización sobre problemas de disponibilidad
- Últimamente han seguido apareciendo textos sobre dejar GitHub o volver a pensar en cómo se desarrollaba antes de GitHub
Git ≠ GitHub
- GitHub se ha vuelto sinónimo de “gestión de código fuente”, pero demasiados usuarios aún no saben que Git no es GitHub
- Git y GitHub no son lo mismo, y la tecnología central de Git es de código abierto y distribuida, así que todos los repositorios son equivalentes y pueden funcionar sin un servicio centralizado
- Los servicios centralizados son producto de una conveniencia social; GitHub originalmente no era más que una herramienta complementaria útil, pero Microsoft lo convirtió en una deuda costosa
- El efecto de red es fuerte, pero la economía de estrellas falsas de GitHub no tiene valor, y la plataforma está inundada de bots y slop
- GitHub Actions forma parte de pipelines de CI excesivamente complejos. Buscar otras soluciones puede ser molesto, pero hay que preguntarse si realmente se puede confiar en la estabilidad de GitHub
- El barco se está hundiendo, así que aunque no se mueva todo de una sola vez, hay que empezar el proceso de migración de inmediato
Alternativas y formas de migrar
- La ruta de escape más cercana es mudarse a otra forja Git centralizada; basta con registrarse y hacer push del repositorio hacia un nuevo upstream
- Algunos servicios pueden automatizar la migración e incluso admitir la importación de issues, aunque también es posible optar por dejar los issues en GitHub tal como están
- Ninguna de las alternativas de abajo es perfecta; lo único que tienen en común es que no son GitHub
-
Alternativas de forjas Git centralizadas
- Codeberg — Proyecto sin fines de lucro y liderado por la comunidad, una alternativa segura con historial comprobado. Es la instancia principal de Forgejo
- Tangled — Startup en fase alfa; su integración con el AT protocol la hace una opción interesante. Vale la pena considerarla para proyectos personales pequeños
- Gitea — Ofrece hosting Git administrado en la nube y es el proyecto original de código abierto del que se separaron Codeberg/Forgejo
- GitLab — Es de nivel empresarial, pesado y algo confuso, pero puede encajar en la toma de decisiones dentro de una organización
- Bitbucket — No se recomienda, pero entra en la categoría de “cosas que no son GitHub”
- Game of Trees, Radicle, Sourcehut — Otras alternativas que requieren investigación por cuenta propia
-
Autohospedaje
- Organizaciones o personas pueden autohospedar una forja Git, y también operar actions y releases
- La opción recomendada para autohospedaje es Forgejo
- Hay discusiones sobre la federación entre instancias de Forgejo, y Tangled también publicó un texto sobre federación, pero no parece que vaya a materializarse pronto
- Si se necesita colaboración pública, se puede usar el método de hacer push de una copia a Codeberg
- Gitea y GitLab también ofrecen opciones autohospedadas, aunque GitLab es considerablemente más pesado
- No solo GitHub, sino también otras forjas son algo separado de Git mismo, y conviene evaluar si de verdad se necesitan las funciones adicionales de una forja
- Git puede usarse directamente solo con SSH
git clone user@192.168.1.67:/path/to/repo
- La forma de colaborar es un tema aparte, pero si Linux puede mantenerse intercambiando parches por listas de correo, es difícil afirmar que algo sea imposible solo por una cuestión de escala
- Las forjas Git centralizadas pueden ser un compromiso realista, pero siempre hay que contar con un plan de salida, teniendo presente que también podrían venirse abajo como GitHub
2 comentarios
Considerando las funciones que ofrece, es sorprendente que saque más del 99%.
Comentarios en Hacker News
Todos quieren echarle la culpa a esto a la adquisición por Microsoft o a la incompetencia, pero por lo que GitHub ha publicado parece bastante claro que, por culpa de la IA, la cantidad de código que se hace commit en GitHub aumentó 10 veces, y el impacto de eso se extendió a CI, Actions, recolección de código y todo lo demás
El autor señala cosas raras como MS Copilot como causa, pero da más la impresión de ser una lista de cosas que le desagradan que una relación causal
Mientras tanto, está ignorando al verdadero elefante en la habitación: la explosión de código causada por la IA
OpenAI lanzó GPT-3.5 en noviembre de 2022, en la práctica diciembre, y ese tipo de programación con modelos de lenguaje grandes/agentes que se describe no despegó de verdad hasta 2024, y en realidad se parece más a 2025
Entonces, ¿cómo se explica la mala disponibilidad durante unos 4 años después de la compra, antes de que empezara toda la conversación sobre IA?
Está bien subirse al tren de criticar a Microsoft, pero no hay que perder de vista al elefante en la habitación
Incluso si mañana aparece un reemplazo perfecto de GitHub, ¿qué impediría que millones de líneas de código generado por IA destruyan también la infraestructura de ese lugar?
El hosting centralizado de código parece que va a quedar casi muerto por culpa de la IA. Es parecido a lo que está pasando en redes sociales
10 años es mucho tiempo, y ahí están los resultados
GitHub Actions, Copilot, y esa búsqueda con IA fea que ni siquiera se puede desactivar. Hasta la migración a Azure
Microsoft logró arruinar los efectos de red, y las caídas fueron la gota que derramó el vaso
Tiene codebases enormes propias y unos 200 mil empleados
Sobre todo considerando que tomó conscientemente decisiones como hacer gratis los repositorios privados, esto difícilmente puede servir como excusa
Cada vez que GitHub se cae pienso: “seguro alguien actualizó el Windows Server donde corre GH y tuvo que reiniciar todo”
Estoy 99% seguro de que no es verdad, pero pensarlo me tranquiliza y además me da un poco de risa cada vez que hay una caída
Hoy intenté ver un repositorio en GitHub
Hice clic en el enlace de “xxx commits” para ver el historial de commits y me salió un mensaje diciendo que había caído en el secondary rate limit y que esperara
Yo sería la única persona viendo GitHub desde esta red, y además la conexión usa una IP dedicada, no CGN
Después de eso, la página carga normalmente
En la práctica, desde hace años es menos un rate limit y más una denegación por defecto, pero se niegan a cambiar el texto para que refleje la realidad
“GitLab: nivel enterprise significa que es voluminoso y confuso, pero le parece impresionante a tu jefe. Si para elegirlo se necesitan varias reuniones, entonces este es el indicado.”
Qué risa
La UI es demasiado compleja incluso para hacer las cosas más simples. Por ejemplo, para aprobar un MR básicamente tienes que pulsar un botón que en realidad es un menú, el diff es difícil de leer y la ‘To-do list’ incluye MRs que ya fueron mergeados. ¿Cómo se supone que eso sea una tarea accionable?
El problema de que los MRs ya fusionados sigan en la ‘To-do list’ fue reportado hace años y aun así no parece haber mucha prisa por mejorarlo
En cambio, me sorprende un poco el rechazo hacia Bitbucket. La UI es muy simple y clara, y la gente que se incorpora nueva también lo percibe así. Si usas Script Runner puedes hacer cosas bastante sorprendentes, y además maneja bien repositorios enormes
GitLab no es particularmente más voluminoso ni más confuso que GitHub
Tampoco diría que sea realmente software de nivel enterprise. Si quieres ver algo así, basta con mirar Jira o cualquier cosa hecha por Microsoft
Nosotros usamos GitLab autohospedado, y lo elegí porque tiene git y registro de contenedores
Si no usas mucho la UI web, la interfaz definitivamente puede sentirse confusa
Con 5 dólares al mes puedes hospedar un servidor y subir ahí varios proyectos
No va a tener un millón de estrellas en el repositorio, pero para mis necesidades funciona perfectamente y además puedo dar acceso a quien yo quiera
No estoy muy seguro de cómo hay que leer esa gráfica
Por un lado, sí podría ser que la disponibilidad empeoró por la compra de GitHub
Por otro, es sospechoso que antes de la adquisición la disponibilidad aparezca como 100.00%, y me pregunto si no será simplemente que la página de estado empezó a actualizarse mejor
Sé que recientemente GitHub sí ha tenido problemas de disponibilidad, pero en la gráfica el problema parece empezar en 2020 y no da la impresión de que se haya agravado muchísimo
Se siente como si al final fuera imposible dejar en paz a los principales repositorios de código abierto
Recuerdo cómo SourceForge se fue arruinando, y de verdad da pena ver que a GitHub le está pasando lo mismo
Como nota aparte, leí el URL como “dBus hell”. A todos nos ha pasado alguna vez
A menudo pienso en qué haría si yo dirigiera una empresa
De verdad me gustaría ver qué pasa si todas las revisiones de código se hicieran por correo electrónico
El repositorio podría estar en un servidor tipo VPS sencillo con acceso SSH solo para git, con un namespace de ramas
for-review/para el código en revisión, y el CI podría ser un bot que espere a que aparezcan ramas y marque en la ref con comentarios o tags si pasó o no. Incluso podría responder en el hilo de correo con los resultadosA la lista de correo, por supuesto, le pones un visor web de archivo para poder consultar revisiones antiguas. Ya existen muchas soluciones así, al final es solo HTML
El chat podría ser IRC y un bot se encargaría de archivar el canal. Es facilísimo
Todo el sistema podría correr en un servidor muy barato, salvo los runners de CI, que sí necesitarían hardware más potente
GitHub está sobrediseñado muy por encima de lo que realmente se necesita para operar un proyecto de software. Ahí está el kernel de Linux usando una simple lista de correo, y difícilmente se puede discutir que no sea uno de los proyectos de software más exitosos de la historia
Eso sí, el seguimiento de issues/bugs me da un poco más de miedo. Porque siento que si me pongo a improvisar una solución propia, terminaría dedicándole más tiempo a eso que al trabajo real de la empresa. Quizá tendría que convertirme en una empresa de software de seguimiento de bugs
Es decir, quiero poder ver exactamente a qué línea estaba pegado un comentario, cuándo cambió esa línea, y moverme hacia atrás y hacia adelante en ese contexto
El correo puede bastar como protocolo para intercambiar esos datos, pero no me parece que los clientes de correo sean una forma agradable de visualizarlo
Quizá también hace falta un sistema distribuido de revisión de código
Vivir en Europa del Este también tiene sus ventajas
Gracias a la zona horaria, casi nunca me doy cuenta de las grandes caídas de GitHub
También estoy satisfecho con lo generoso que sigue siendo con el hosting gratuito y con Actions
Desde que instalé Forgejo en un servidor casero, no he mirado atrás
El único problema es cuando quieres hospedar apps en cosas como DigitalOcean App Platform o Vercel, porque esas solo se conectan a GitHub
DigitalOcean App Platformsoporta despliegues no solo desde GitHub sino también desde GitLabEso sí, tiene que ser una instancia alojada en gitlab.com, no una instancia autohospedada de GitLab
Si ya desplegaste tu forge autohospedado, puedes usar gitlab.com como puente para conectarlo con DigitalOcean App Platform. Solo creas una cuenta en gitlab.com una vez y haces que tu forge autohospedado envíe una réplica a gitlab.com. En realidad casi ni necesitas usar GitLab
Aun así, no tiene sentido que DigitalOcean, siendo una empresa que vende IaaS/PaaS, no te deje conectarte a algo como Forgejo autohospedado corriendo en su propia infraestructura
De hecho, considerando que mucha gente quiere hospedar su propio forge, pero poca quiere configurarlo y operarlo manualmente, también es raro que DigitalOcean no tome Forgejo o alguna alternativa y ofrezca una opción semiadministrada de despliegue en un clic, con gran descuento tipo 20 dólares al año, y soporte de primera clase para conectarlo con App Platform
Yo uso DigitalOcean, pero solo para VPS
No conviene quedar atado a proveedores en estas capas intermedias; hay que mantener el control y apuntar a las capas de stack más universales que se pueda
Me pasé a Gitea hace años, antes del fork a Forgejo, y no me arrepiento
Cuando hace falta GitHub, he podido hacer que funcione espejando ahí los repositorios. Eso sí, sincronizar el código es una lata
GitHub la está pasando mal porque, debido a la programación potenciada por IA, la cantidad de commits aumentó 14 veces en el último año y esa velocidad todavía sigue acelerándose
Al sitio le está costando seguir el ritmo
La COO de GitHub lo confirmó aquí: https://x.com/kdaigle/status/2040164759836778878
La actividad de la plataforma está disparada. En 2025 hubo 1,000 millones de commits, pero ahora ya van en 275 millones por semana, así que incluso si el crecimiento se mantuviera solo lineal, este año irían a un ritmo de 14,000 millones. Y claro, no se va a quedar en lineal
GitHub Actions pasó de 500 millones de minutos por semana en 2023 a 1,000 millones por semana en 2025, y esta semana ya van 2,100 millones hasta ahora
Por eso están empujando fuertísimo más CPU, escalado de servicios y refuerzo de las funciones centrales de GitHub