GitHub pierde proyectos clave: qué hacer con tu startup en 2026

¿Por qué proyectos clave están abandonando GitHub en 2026?

Codeberg duplicó su base de usuarios en menos de un año hasta finales de 2025, una señal clara de que desarrolladores y maintainers están buscando alternativas. Proyectos como Zig, Ghostty (de Mitchell Hashimoto), Strudel y Tenacity han anunciado o completado migraciones fuera de GitHub durante 2025-2026.

Para founders que construyen sobre infraestructura open source, esto no es solo drama de comunidad: es una señal de alerta sobre dependencia de plataforma y continuidad del supply chain técnico.

¿Cómo era el open source antes de GitHub?

Antes de 2008, cada proyecto era responsable de su propia infraestructura. Desarrolladores como Armin Ronacher (creador de Flask) operaban sus propios servidores con Trac, Subversion, mailing lists y tarballs. El colectivo Pocoo compartía costos de servidor y mantenimiento entre varios proyectos.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Esta autonomía tenía un costo: cuando un dominio expiraba, un VPS se apagaba o un maintainer fallecía, el código y su contexto social (issues, discusiones, releases) desaparecían. Muchos proyectos tempranos de Python siguen técnicamente en PyPI, pero los paquetes reales ya no están disponibles porque los servidores originales dejaron de existir.

GitHub resolvió esto accidentalmente: se convirtió en el archivo centralizado del software commons. Incluso proyectos abandonados permanecían encontrables, con forks, issues históricos y discusiones preservadas.

La ironía de los sistemas distribuidos

Git fue diseñado como sistema de control de versiones distribuido: cualquiera puede tener una copia completa del repositorio, con su propio historial y branches. En teoría, esto debería haber eliminado la necesidad de un centro único.

La realidad fue lo opuesto: el mundo estandarizó en un servicio centralizado enorme para hospedar estos repositorios distribuidos. GitHub se volvió la infraestructura social del open source, no solo donde vivía el código, sino donde vivía la comunidad.

El problema de las micro-dependencias

GitHub, combinado con npm y sistemas similares, hizo que publicar y consumir código fuera casi sin fricción. El resultado: el número de proyectos explotó, y con él, el gráfico de dependencias.

En el mundo pre-GitHub, agregar una dependencia requería reflexión. Tenías que entender de dónde venía, quién la mantenía, si el servidor estaría disponible cuando hicieras build. Esta fricción implícita forzaba comportamiento diferente: mucho vendoring (copiar código directamente en tu tree) y dependencias más grandes y estables.

Con el modelo npm-style, el gráfico de paquetes puede crecer más rápido que la capacidad de cualquiera para razonar sobre él. GitHub compensaba esto proporcionando visibilidad: podías ver el repositorio, el maintainer, issues recientes, si otros proyectos lo usaban. Era parte del sistema de confianza.

Cuando la confianza en GitHub se erosiona, el problema no se aísla al hosting de código: afecta toda la cultura de supply chain que se formó alrededor.

¿Qué está pasando con GitHub actualmente?

Desarrolladores reportan fatiga por inestabilidad en CI/CD, cambios de producto frecuentes, ruido de Copilot e IA generativa, y liderazgo poco claro. GitHub se encuentra en medio de la revolución de coding agentic, lo que genera presión enorme, pero muchos sienten que la plataforma ya no está diseñada principalmente para la comunidad que la hizo valiosa.

El anuncio de Mitchell Hashimoto de que Ghostty migraría fuera de GitHub fue una señal fuerte. Zig ya había migrado completamente a Codeberg en 2025, citando abandono de herramientas críticas y priorización de IA sobre mantenimiento. Proyectos como Strudel y Tenacity siguieron a Codeberg.

Para founders, la pregunta no es si GitHub desaparecerá mañana (no lo hará), sino qué pasa cuando la plataforma que hospeda tu supply chain técnico cambia de prioridades.

¿Qué significa esto para tu startup?

Si tu startup depende de paquetes open source hospedados en GitHub, necesitas evaluar riesgos de dependencia de plataforma. Aquí hay acciones concretas:

Audita tus dependencias críticas: Identifica qué paquetes son esenciales para tu producto y verifica si tienen mirrors en otras plataformas (GitLab, Codeberg, self-hosted). Si un paquete crítico solo existe en GitHub, es un punto único de fallo.
Implementa mirrors redundantes: Para dependencias críticas, configura mirrors en al menos una plataforma alternativa. Codeberg ofrece herramientas de migración que copian repositorios, wikis, issues y releases desde GitHub. Mantener un mirror no cuesta mucho y te da opción de fallback.
Considera self-hosting para código propio: Si tu startup tiene IP crítica, evalúa instancias self-hosted de GitLab o Forgejo. Equipos en LATAM ya optan por esto para control de datos locales y cumplimiento de regulaciones de privacidad. No necesitas migrar todo: empieza con repositorios más sensibles.
Documenta tu supply chain: Crea un inventario de dependencias con maintainer, plataforma, última actualización y alternativas disponibles. Esto no es solo para seguridad: es para continuidad de negocio.
Participa en la comunidad: Si dependes de un proyecto crítico, considera contribuir o incluso patrocinar al maintainer. La relación directa reduce riesgo más que cualquier herramienta técnica.

Alternativas a GitHub en 2026

El ecosistema tiene opciones maduras:

Codeberg: Instancia de Forgejo (fork de Gitea) sin fines de lucro en Alemania. Duplicó usuarios en 2025. Interfaz similar a GitHub, enfoque en software libre y transparencia.
GitLab: Popular para self-hosting, especialmente en empresas que necesitan control total. Comunidades hispanohablantes en LATAM lo usan para cumplimiento de regulaciones locales.
SourceHut: Minimalista, basado en mailing lists y patches. Para equipos que prefieren workflows más tradicionales.
Forgejo: Fork de Gitea mantenido por la comunidad. Ligero, self-hostable, compatible con GitHub.

La dispersión tiene costos: aumenta autonomía pero también riesgo de pérdida. Issues, reviews, discusiones de diseño y releases son frágiles. Por eso la comunidad necesita archivos públicos bien financiados, no atados al modelo de negocio de una compañía.

El camino forward

GitHub escribió un capítulo remarkable del open source. Si ese capítulo termina, el siguiente debe aprender de él y de lo que vino antes. El mundo pre-GitHub tenía más autonomía y más pérdida. Probablemente nos movamos hacia allá temporalmente.

Para founders: no esperes que GitHub permanezca saludable para siempre. Construye redundancia ahora, mientras es fácil. Tu future self te lo agradecerá cuando la próxima decisión corporativa afecte tu supply chain.