El 22 de junio de 2026, Ludovic Courtès, maintainer de Guix, publicó una entrada en el blog con un título que no podía ser más sobrio: «One year with Codeberg». Pero el contenido pesa mucho más de lo que sugiere esa contención: es la retrospectiva más completa y transparente del mayor experimento de «huida de GitHub» realizado hasta ahora en la comunidad del software libre.
Hace un año, Guix trasladó todos sus repositorios de código, el seguimiento de incidencias y el flujo de Pull Requests desde GNU Savannah y el vetusto sistema Debbugs —basado en correo electrónico— a Codeberg, una plataforma de alojamiento alemana sin ánimo de lucro que funciona sobre Forgejo. Un proyecto con más de 400 personas enviando código cada año, después de más de una década con un flujo de trabajo basado en parches por correo, tomó una decisión que muchos consideraron «radical». Ahora tenemos los datos.
Correo vs. web: una fractura que no se ve desde fuera
El antiguo flujo de trabajo de Guix, visto desde 2026, parece una excavación arqueológica: los informes de error y los parches se enviaban por correo y los rastreaba un sistema escrito en Perl llamado Debbugs. Los contribuyentes del núcleo duro, usando Emacs y clientes de correo de primer nivel, se manejaban en ese ecosistema como pez en el agua. Para ellos, Debbugs —unos cientos de líneas de Perl sobre el correo, un estándar federal probado durante décadas— era impecable, mientras que una forja web como Forgejo, con sus cientos de dependencias en Go, era pura grasa innecesaria.
La comunidad incluso había construido todo un andamiaje auxiliar alrededor del flujo de correo: mumi dotaba a Debbugs de una interfaz web resultona, y el servicio QA compilaba automáticamente las series de parches en ramas Git temporales para probarlos. La migración significaba tirar todo eso a la basura.
Pero al otro lado la historia era igual de real. En enero de 2025, Steve George (Futurile) publicó los resultados de la primera encuesta de usuarios y contribuyentes de Guix, con 900 respuestas. La conclusión fue directa: para una gran cantidad de contribuyentes potenciales, el flujo de trabajo por correo era «una barrera». Dicho sin rodeos: la nueva generación de hackers probablemente no ha enviado un parche por correo en su vida; lo que conocen es el botón de PR al estilo GitHub.
Esta fractura es el dilema clásico del movimiento del software libre: lo que los veteranos aprecian como «minimalista, federado y conforme a estándares», los recién llegados lo ven como «barrera de entrada, tiempos de respuesta lentos y la duda eterna de si alguien ha leído mi parche».
Consenso GCD: cómo decide un proyecto sin dictador
Guix se enfrentaba a dos problemas: la elección de herramienta y el mecanismo de decisión, porque el proyecto no tiene un «dictador benevolente» (BDFL). En diciembre de 2024, la comunidad aprobó el proceso de Documentos de Consenso de Guix (GCD): quien propone debe colaborar con todos para alcanzar el consenso, los participantes no pueden limitarse a «oponerse», tienen que presentar objeciones concretas y sugerir modificaciones. Las posturas finales son «apoyo», «aceptación» o «desacuerdo».
La propuesta GCD 002 fue la migración a Codeberg. Presentada en febrero de 2025, se debatió durante dos meses completos: el plazo máximo que permite el proceso. Dos tercios de los miembros del equipo Guix participaron en la deliberación: un 72% votó «apoyo», un 28% «aceptación» y nadie mostró «desacuerdo».
El resultado es revelador. Que un 28% se limitara a «aceptar» en lugar de «apoyar» indica que una proporción considerable de contribuyentes veteranos no estaba a favor, pero tampoco lo suficiente como para bloquear. El blog de Courtès lo admite: «El debate mostró que muchos colaboradores de largo recorrido se sentían incómodos con el giro hacia una dirección percibida como ‘web-first’ y, en comparación con el flujo de correo, menos eficiente. Abandonar la infraestructura cuidadosamente construida durante años alrededor del correo también dolía».
Pero la balanza se inclinó por una razón que el propio Courtès explicita: «La expectativa de llegar a una comunidad más amplia y mejorar la experiencia de desarrollo para la mayoría fue probablemente el motor clave de este resultado positivo».
Hubo además un factor que apenas generó controversia: elegir Codeberg no era solo elegir software libre (Forgejo), sino también una entidad sin ánimo de lucro, Codeberg e.V. Y eso encaja de forma natural con los valores de Guix: sin intereses comerciales de por medio, sin el miedo a despertarse un día y descubrir que han cambiado los términos de servicio.
El switch: la CI rota fue el mayor tropiezo
Según el plan del documento de consenso, la migración fue gradual. El repositorio principal se migró el 25 de mayo de 2025, manteniendo el antiguo repositorio de Savannah como espejo. Los viejos trackers de incidencias y parches siguieron funcionando hasta el 1 de enero de 2026.
El proceso de cambio en sí no tuvo grandes sobresaltos. Courtès califica el servicio del personal y los voluntarios de Codeberg e.V. como «excelente», con caídas puntuales pero «generalmente breves y con comunicación clara».
El gran tropiezo vino de algo que no se anticipó lo suficiente: la integración continua.
El antiguo servicio QA de la era del correo (qa.guix.gnu.org) aplicaba automáticamente los parches en ramas temporales y los compilaba para probarlos. Tras la migración a Codeberg, la CI de los PR no se activó a tiempo. Durante meses, los revisores tuvieron que evaluar a ojo si un PR iba a romper algo: en un proyecto con más de 500 PR al año, eso es sencillamente insostenible.
No fue hasta septiembre de 2025 cuando el proyecto desplegó Cuirass (la herramienta de CI desarrollada por el propio Guix) en pulls.ci.guix.gnu.org para encargarse de las compilaciones de los PR. Courtès reconoce con franqueza que esto «inicialmente se consideró una solución provisional»: actualmente solo compila para una arquitectura (x86), lejos de la cobertura multiarquitectura del antiguo QA. Pero trajo una ventaja inesperada: la visibilidad inmediata. Cuirass responde directamente en el PR como guix-cuirass-bot indicando si la compilación ha tenido éxito o ha fallado. Los nuevos contribuyentes ya no necesitan rebuscar en la lista de correo para encontrar los resultados de las pruebas.
Para los desarrolladores que no se bajan de Emacs, la buena noticia es que fj.el y Emacs-Forgejo, dos interfaces para Emacs, han madurado rápidamente este año. El flujo AGit (crear PR directamente con git push, sin necesidad de hacer fork en la web) también ha ganado usuarios.
Hablan los datos: mismos contribuyentes, más atascos
Esta es la parte más valiosa de todo el artículo. El equipo de Guix ha hecho un trabajo estadístico sólido.
La conclusión principal: la migración no trajo el «efecto Codeberg» que algunos esperaban, en forma de explosión de nuevos contribuyentes. En junio de 2025 (recién completada la migración) sí se registró un pico, pero la tendencia de crecimiento durante el año siguiente es similar a la del año anterior. Guix atrae nuevos contribuyentes de forma constante; Codeberg no ha acelerado ese proceso… pero tampoco lo ha frenado.
Las cifras absolutas siguen siendo impresionantes: más de 500 PR al mes. La tasa de fusión es ligeramente inferior a la de envío, así que la acumulación crece. Actualmente hay 639 PR abiertos, un 10% del total histórico (6.459). En comparación, en Nixpkgs los PR abiertos representan solo el 2,5% (12.000 abiertos de 473.000 históricos).
Courtès atribuye el atasco a dos posibles causas: demasiada fricción al enviar o insuficiente feedback de CI.
El mayor punto de fricción es la exigencia de commits firmados. Guix requiere que cada commit esté firmado por un committer autorizado, nada de pulsar un botón de «Merge» como en Nixpkgs y otros muchos proyectos. Esto implica que quien integra código debe responder realmente por los cambios, sin esconderse. Es la eterna tensión entre «seguridad de la cadena de suministro del software» y «comodidad para el desarrollador». Guix eligió lo primero: «Es una renuncia que asumimos voluntariamente, porque nos importa proteger la cadena de suministro del software, pero aún tenemos que ver si este coste se puede mitigar de alguna manera».
Las preguntas de fondo que explotaron en Lobsters
En Lobsters, la entrada obtuvo 90 puntos y 38 comentarios. Más allá de los detalles técnicos, la discusión sacó a la luz cuestiones más profundas.
«No cambiéis el monopolio de GitHub por el de Codeberg». FedericoSchonborn respondió a un comentario que deseaba que «Codeberg se convierta en el nuevo GitHub»: «Prefiero ver muchas forjas independientes comunicándose entre sí mediante ForgeFed, en lugar de mudarlo todo a Codeberg. No necesitamos un nuevo nodo central del open source». Esto apunta a una paradoja: huir de una plataforma centralizada para caer en otro nodo central es no haber cambiado nada. El camino de fondo es impulsar la interoperabilidad federada entre forjas.
La integración con el ecosistema de herramientas sigue siendo el talón de Aquiles. El usuario colonelpanic señaló: «Desde que empecé a usar Codeberg, me he dado cuenta de que casi nada soporta una integración genérica con Git: todo es solo GitHub o GitLab». El problema se repite en CI de terceros, alojamiento estático, sistemas de gestión de proyectos… La raíz es la inercia del ecosistema: cuando todos los SaaS esconden detrás del botón «Conectar tu repositorio» solo los flujos OAuth de GitHub y GitLab, elegir otra plataforma significa quedarte fuera de toda la cadena de herramientas.
La estabilidad aún está a otro nivel. El usuario ysun escribió: «Según mi experiencia, Codeberg tiene más fallos extraños que GitHub; por ejemplo, el push falla aleatoriamente». Otro usuario, srtcd424, añadió: «No creo que Forgejo pueda acercarse a la capacidad de escalado de GitHub actualmente. La gente de Codeberg lo está dando todo, pero necesitan tiempo».
Nada de esto es letal. Pero el verdadero coste de «la alternativa» no es la ingeniería del día de la migración —que puede ser irrelevante—, sino vivir cada día siguiente en un mundo donde el soporte del ecosistema es más débil, la estabilidad es un grado menor y las integraciones son más escasas. Guix puede soportar esos costes porque tiene capacidad técnica de sobra y voluntad de construirse su propia infraestructura. La mayoría de los proyectos, no.
Lo que cuesta el software libre… y lo que compra
Lo más valioso del artículo de Guix no es la conclusión —no ofrece un veredicto simple de «éxito» o «fracaso»—, sino la transparencia del proceso. Un proyecto de software libre sin BDFL, usando su propio mecanismo de decisión por consenso, completó una migración de infraestructura que afectaba a más de 400 personas y luego publicó todos los datos, defectos y controversias.
Hacia el final, Courtès menciona una «noticia de última hora»: se acaba de enviar un PR para desplegar Forgejo sobre Guix: «configuración puramente declarativa, despliegue de forja completamente reproducible, ¿os lo imagináis?». Esto apunta a la forma definitiva de la libertad según Guix: no solo funcionar sobre una forja de software libre, sino permitir que cualquiera despliegue su propia forja de forma declarativa con Guix. De huir de GitHub a convertirse en la infraestructura de la alternativa. Guix está recorriendo un camino más largo que una simple «mudanza».
La Guix Foundation votó recientemente hacerse miembro de apoyo (sin voto) de Codeberg e.V., como forma de agradecimiento y respaldo. Quizás sea otra señal: huir de GitHub exige construir relaciones de largo plazo con la plataforma de destino, con inversión continua de recursos. Una mudanza no basta.
Este artículo se basa en información pública y discusiones de la comunidad. Si tienes conocimiento directo sobre este tema, no dudes en señalar cualquier imprecisión.