Por qué devs dejan GitHub por Codeberg

GitHub sigue siendo el lugar donde vive gran parte del software moderno. Ahí están proyectos grandes, equipos pequeños, forks, issues, pull requests y una cantidad enorme de automatizaciones. Pero cada vez más desarrolladores están mirando hacia otro lado. No porque GitHub haya dejado de funcionar, sino porque la dependencia de una sola plataforma ya no se siente cómoda para todos.

El cambio no es solo ideológico. Hay equipos que quieren más control sobre su código, otros quieren bajar costos, otros quieren evitar que sus datos y sus flujos de trabajo queden atados a decisiones de una empresa. En ese contexto, Codeberg y las alternativas autohospedadas empiezan a sonar menos raras y más prácticas.

Qué está empujando a la gente fuera de GitHub

La primera razón es sencilla: centralizar todo en un proveedor te deja expuesto a sus reglas. Si GitHub cambia precios, límites, políticas de uso o funciones disponibles, tú no tienes mucho margen. Eso afecta tanto a proyectos personales como a equipos que ya dependen de CI/CD, issues y automatizaciones para trabajar todos los días.

La segunda razón es el costo, aunque no siempre aparece como una factura directa. Muchas organizaciones pagan con tiempo de administración, con límites de almacenamiento, con minutos de CI, con integraciones de terceros y con el costo oculto de adaptar sus procesos a una plataforma cerrada. Cuando sumas todo, la “gratuitidad” de GitHub deja de verse tan simple.

La tercera razón es la privacidad. No hace falta pensar en espionaje para entender el problema. Basta con asumir que una plataforma centralizada ve patrones de actividad, metadatos de repositorios, relaciones entre colaboradores y hábitos de trabajo. Para algunos equipos eso no es aceptable, sobre todo si manejan código sensible, clientes corporativos o proyectos que prefieren mantener un perfil bajo.

Dependencia de plataforma y riesgo operativo

Si tu organización vive dentro de GitHub, cualquier incidente te afecta más de lo que parece. No solo hablamos de caídas del servicio. También entran en juego cambios de API, limitaciones de automatización, revisiones de seguridad y decisiones de producto que pueden mover el piso de un día para otro.

Un ejemplo claro es cuando un equipo tiene pipelines, bots y revisiones automáticas conectadas a una sola cuenta o a una sola organización. Migrar después es más caro que diseñar una salida desde el principio. Por eso, muchas personas están empezando a pensar en portabilidad como un requisito, no como un plan B.

Comunidad, ética y control

En el mundo open source, la conversación también tiene una capa política. Hay desarrolladores que prefieren plataformas cooperativas o federadas porque encajan mejor con la idea de infraestructura compartida. Codeberg, por ejemplo, no es una empresa que busca maximizar extracción de datos o venderte un ecosistema cerrado. Está construido alrededor de una fundación y del software libre.

Eso no significa que GitHub sea “malo” y lo demás sea perfecto. Significa que tu elección de plataforma también dice algo sobre cómo quieres que funcione tu trabajo. Si valoras la autonomía, la transparencia y la capacidad de salir sin dolor, la conversación cambia rápido.

Codeberg: qué ofrece y por qué atrae

Codeberg se volvió una opción real para quienes quieren alojar repositorios Git sin depender de Microsoft. Está basado en Forgejo, un fork comunitario de Gitea, y apunta a un modelo más pequeño, más transparente y más alineado con el software libre. No intenta ganar por volumen de features ni por marketing agresivo.

Para muchos desarrolladores, eso es suficiente. Necesitan repositorios, issues, pull requests, wiki, webhooks y una interfaz razonable. Si además quieren una plataforma con menos presión comercial y más control comunitario, Codeberg encaja bien.

La gran ventaja no es solo técnica. Es de filosofía operativa. Codeberg no te obliga a pensar en “qué producto nuevo lanzó la empresa” sino en si la herramienta resuelve tu flujo de trabajo. Y para equipos pequeños o proyectos open source, eso pesa bastante.

Lo que sí hace bien

Codeberg cubre lo esencial para muchos proyectos:

• Repositorios Git públicos y privados.
• Issues y pull requests.
• Wikis y documentación básica.
• Integración con webhooks y automatización.
• Una experiencia parecida a lo que ya conoces si vienes de GitHub o GitLab.

Si tu proyecto no depende de funciones muy específicas de GitHub, la transición puede ser bastante limpia. Además, al estar basado en Forgejo, comparte una lógica familiar para quienes ya administraron instancias tipo Gitea.

Lo que todavía puede costarte

No todo es ventaja. Migrar a Codeberg puede implicar perder algunas comodidades del ecosistema GitHub, sobre todo en integraciones muy extendidas. Por ejemplo, si tu equipo usa Actions de forma intensiva, marketplace de apps, dependencias muy acopladas o flujos de revisión que dependen de herramientas propietarias, tendrás que rearmar parte del proceso.

También hay un tema de adopción. GitHub tiene masa crítica. Eso significa que todo el mundo ya sabe cómo entrar, hacer un fork, abrir un issue o mirar un README. En plataformas más pequeñas, tú puedes terminar explicando más cosas a colaboradores nuevos.

Self-hosting: la opción con más control y más trabajo

Autohospedar tu forge de código es la alternativa más radical y, para algunos equipos, la más lógica. Si montas tu propia instancia de Forgejo, Gitea o GitLab, controlas datos, backups, políticas de acceso, retención y actualizaciones. No dependes de los cambios de una plataforma externa para seguir trabajando.

Pero ese control tiene costo. No solo económico, también operativo. Tú te encargas de la seguridad, del uptime, de las copias de respaldo, de la recuperación ante fallos y de que la instancia no se rompa después de una actualización. Si el equipo es pequeño, eso puede ser demasiado.

La pregunta correcta no es si self-hosting es mejor. La pregunta es si necesitas ese nivel de control y si tienes el tiempo para sostenerlo. Para algunas empresas, sí. Para otras, no vale la pena mover a todo el equipo.

Cuándo tiene sentido autohospedar

Autohospedar suele tener sentido cuando:

1. Manejas código sensible o regulado y necesitas controlar dónde vive la información.
2. Tienes un equipo con capacidad real de administración de sistemas.
3. Quieres evitar depender de políticas externas o de cambios de precio.
4. Necesitas personalizar flujos de trabajo, permisos o integraciones a tu medida.
5. Buscas soberanía tecnológica para una organización, no solo para un repo.

Si tu caso no entra en varias de esas categorías, probablemente te convenga más una plataforma gestionada pero menos centralizada que GitHub.

Qué debes mirar antes de migrar

Antes de salir corriendo a montar tu propia instancia, revisa estos puntos:

• Backups automáticos y pruebas de restauración.
• Autenticación: SSO, LDAP o OIDC según tu entorno.
• Tamaño de repositorios y almacenamiento de artefactos.
• Soporte para webhooks, CI y runners.
• Política de actualizaciones y ventana de mantenimiento.
• Documentación para colaboradores externos.

Si alguna de esas piezas no está clara, la migración puede terminar en fricción diaria. Y esa fricción suele aparecer justo cuando el equipo ya no tiene ganas de seguir afinando infraestructura.

Comparación práctica: GitHub, Codeberg y self-hosting

No todo se reduce a “gratis versus pagado”. Lo que cambia de verdad es quién manda sobre la plataforma, cuánto trabajo operativo asumes y qué tan fácil es salir si mañana decides cambiar otra vez.

GitHub sigue ganando en adopción. Si tu prioridad es atraer contribuyentes rápido y no complicar el onboarding, sigue siendo muy fuerte. Pero si tu prioridad es autonomía, Codeberg y self-hosting te dan una salida más sana a largo plazo.

La comparación también cambia según el tipo de proyecto. Un proyecto open source pequeño puede vivir muy bien en Codeberg. Una empresa con compliance fuerte quizá necesite self-hosting. Un startup que quiere velocidad puede seguir en GitHub mientras diseña una estrategia de portabilidad para no quedar atrapada.

Cómo migrar sin romper el trabajo del equipo

La migración no debería ser un salto al vacío. Si tienes un repositorio activo, con issues, documentación y automatizaciones, mover todo de golpe es una receta para perder tiempo. Lo mejor es hacerlo por fases y con un plan claro.

Empieza por inventariar lo que realmente usas. Muchas veces el repo parece simple, pero detrás hay webhooks, bots, dependencias de CI y enlaces en documentación externa. Si no haces ese mapa, la migración te va a explotar en la cara cuando alguien intente abrir un PR o disparar un pipeline.

Plan de migración recomendado

1. Haz un inventario de repositorios, ramas, issues, etiquetas, releases y automatizaciones.
2. Define qué se migra y qué se archiva. No todo merece pasar al nuevo sistema.
3. Prueba con un proyecto pequeño antes de mover el principal.
4. Actualiza documentación pública, README y guías internas.
5. Asegura redirecciones, avisos y una ventana de convivencia entre plataformas.
6. Revisa accesos, llaves SSH, tokens y secretos de CI.
7. Valida backups y restauración antes de declarar la migración terminada.

Si usas Git, la parte de código suele ser la más fácil. Lo difícil es el ecosistema alrededor: issues, referencias cruzadas, automatización y costumbre del equipo. Ahí es donde más tiempo se va.

Un ejemplo realista de decisión

Imagina una organización pequeña en Ecuador con tres desarrolladores, dos repos públicos y un proyecto interno. Si todo vive en GitHub, el costo inicial es cero, pero el equipo depende de una plataforma externa para issues, PRs y despliegues. Si pasan a Codeberg, reducen dependencia y mantienen una experiencia similar. Si además autohospedan, ganan control total, pero alguien tiene que administrar backups, actualizaciones y seguridad.

No hay una respuesta universal. La decisión correcta depende de cuánta operación estás dispuesto a absorber. En equipos pequeños, esa variable pesa más que cualquier slogan.

Qué dice esta tendencia sobre el futuro del desarrollo

La salida de GitHub no significa que GitHub vaya a desaparecer. Significa que la conversación cambió. Antes, la pregunta era dónde era más cómodo subir código. Ahora también importa quién controla la infraestructura, qué pasa con tus datos y qué tan fácil es moverte si cambian las condiciones.

Eso afecta a toda la cadena de herramientas. Si una plataforma concentra demasiadas funciones, también concentra demasiado poder. Y cuando eso pasa, aparecen alternativas federadas, comunidades más pequeñas y proyectos que prefieren una relación más directa con su infraestructura.

Para ti, la lectura práctica es esta: no asumas que tu repositorio principal debe vivir para siempre en el mismo lugar. Diseña para poder salir. Incluso si nunca te vas, tener esa opción te evita quedar atrapado.

La señal más clara

La señal más clara no es una migración masiva de un día para otro. Es que cada vez más equipos se hacen preguntas que antes casi nadie hacía: quién aloja el código, quién ve los metadatos, quién decide el roadmap de la herramienta y cuánto cuesta realmente seguir ahí.

Cuando esas preguntas entran en la conversación, GitHub deja de ser el default automático. Y eso ya cambió la forma en que muchos equipos piensan su stack.

Tabla resumen

Fuentes útiles para revisar detalles técnicos y modelos de software:

• Documentación oficial de Forgejo: https://forgejo.org/docs/latest/
• Documentación oficial de Gitea: https://docs.gitea.com/
• Codeberg, información del proyecto: https://codeberg.org/