​El De Facto bajo Cuestionamiento

​Durante más de una década, GitHub ha sido el estándar absoluto. Sin embargo, los eventos recientes han demostrado que incluso los pilares más sólidos pueden tambalearse cuando la estrategia corporativa prioriza el "Hype" sobre la estabilidad operativa. Como ingenieros, debemos preguntarnos: ¿Es seguro mantener todos nuestros activos en un solo punto de fallo centralizado?

​🚩 1. La Cronología del Caos: Errores que no son "Solo Bugs"

​Lo ocurrido en abril de 2026 no fueron caídas menores, fueron fallos en la integridad del sistema:

  • ​Integridad del Código: El 23 de abril, un fallo en las Merge Queues provocó la pérdida irreversible de cambios en repositorios activos. En el desarrollo profesional, esto es el "pecado capital" de un sistema de control de versiones.
  • ​Buscador Ciego: El 27 de abril, la caída de Elastic Search dejó a millones de desarrolladores sin la capacidad de navegar por el código de forma interna.
  • ​Seguridad Perimetral: El reporte de un fallo crítico el 28 de abril puso en duda si la rapidez de las actualizaciones está sacrificando los protocolos de auditoría.

​📉 2. El Mito del 99% de Uptime

​GitHub reporta oficialmente una disponibilidad casi perfecta. No obstante, auditorías externas y reportes de la comunidad sugieren una realidad mucho más oscura: un uptime real cercano al 84%.

​Esta brecha entre el reporte oficial y la experiencia del usuario genera una pérdida de confianza técnica. Un sistema de misión crítica para empresas no puede permitirse una disponibilidad que se asemeje más a un entorno de pruebas que a uno de producción masiva.

​🤖 3. La Causa Raíz: ¿La IA es el Saboteador Interno?

​GitHub ha atribuido la inestabilidad a la carga exponencial generada por agentes y herramientas de Inteligencia Artificial.

  • ​Escalabilidad Insuficiente: A pesar de contar con la infraestructura de Azure, el crecimiento del uso de Copilot y agentes autónomos ha saturado los recursos de cómputo.
  • ​Cambio de Foco: Desde agosto de 2025, la falta de un CEO independiente y la absorción por la división Core AI de Microsoft sugieren que la prioridad ya no es el alojamiento de código, sino alimentar modelos de lenguaje.

​🏗️ 4. El Regreso a la Soberanía: Alternativas y Self-Hosting

​Como hemos discutido en el Manifiesto de la Web Autónoma, la dependencia de un solo proveedor es una vulnerabilidad estratégica.

  • ​Opciones Cloud: Plataformas como GitLab o Bitbucket ofrecen una gestión más tradicional y enfocada en el flujo de trabajo (CI/CD).
  • ​Opciones de Resiliencia: Codeberg y Sourcehut destacan por su minimalismo y enfoque en la privacidad.
  • ​Self-Hosting (La Puerta a la Independencia): Implementar instancias propias de Gitea o GitLab Self-Managed permite a las empresas recuperar el control absoluto de su código, eliminando el riesgo de "caídas globales" de terceros.

​🎯 5. Conclusión: ¿Migrar o Esperar?

​Para el desarrollador independiente, GitHub sigue siendo la red social del código. Pero para las empresas que gestionan infraestructuras críticas como ORMOQ, la recomendación es clara: Descentralizar.

​No se trata de abandonar GitHub, sino de implementar arquitecturas híbridas donde el código esté respaldado en infraestructuras soberanas. La nube no es el servidor de alguien más; es un compromiso de confianza que, hoy por hoy, GitHub está teniendo dificultades para cumplir.