Le 22 juin 2026, Ludovic Courtès, mainteneur du projet Guix, publiait un billet de blog au titre sobre : « One year with Codeberg ». Derrière cette sobriété, le document le plus dense jamais écrit sur l’expérience « post-GitHub » d’un grand projet de logiciel libre.
Il y a un an, Guix a transféré l’intégralité de ses dépôts de code, de son suivi de tickets et de son flux de pull requests depuis GNU Savannah et le système Debbugs (basé sur les emails) vers Codeberg — une plateforme d’hébergement allemande à but non lucratif, tournant sous Forgejo. Un projet qui reçoit plus de 400 contributeurs par an, après plus de dix ans de workflow basé sur des patches par email, faisait un choix que beaucoup jugeaient « radical ». Les chiffres sont là.
Email vs web : un schisme silencieux
L’ancien workflow de Guix, vu d’aujourd’hui, ressemble à une pièce de musée : les rapports de bugs et les patches étaient envoyés par email, suivis par le système Debbugs écrit en Perl. Les contributeurs historiques, armés d’Emacs et d’un client mail en mode texte, y nageaient comme des poissons dans l’eau — pour eux, Debbugs, c’était quelques centaines de lignes de Perl posées sur l’email, standard fédéré et éprouvé, quand Forgejo et ses usines à clics alignaient des centaines de dépendances en Go, obèses et disgracieuses.
La communauté avait même construit un écosystème d’outillage autour du workflow email : mumi offrait une jolie interface web à Debbugs, un service de QA compilait automatiquement les séries de patches sur une branche Git temporaire. Migrer, c’était mettre tout ça à la poubelle.
Mais l’autre voix était tout aussi réelle. En janvier 2025, Steve George (Futurile) publiait les résultats de la première enquête utilisateurs et contributeurs de Guix : 900 réponses. Verdict limpide : pour une large part des contributeurs potentiels, le workflow par email constituait « un obstacle ». En clair, la jeune génération de hackers n’a peut-être jamais soumis un patch par email de sa vie — elle connaît le bouton « Pull Request » à la GitHub.
Ce schisme est le dilemme classique du logiciel libre : ce que les vétérans chérissent comme « minimaliste, fédéré, respectueux des standards », les nouveaux le vivent comme « barrière à l’entrée, lenteur, boîte noire — j’ai posté mon patch, est-ce que quelqu’un l’a seulement vu ? »
GCD : comment on décide sans dictateur bienveillant
Guix devait trancher deux questions : l’outil, et la méthode pour décider — car le projet n’a pas de BDFL (Benevolent Dictator for Life). En décembre 2024, la communauté a adopté le processus GCD (Guix Consensus Document) : le proposant doit collaborer avec tous pour atteindre le consensus ; un opposant ne peut pas juste dire « non », il doit formuler des exigences concrètes et des modifications. Au final, chacun exprime « soutien », « acceptation » ou « désapprobation ».
La proposition GCD 002, c’était la migration vers Codeberg. Déposée en février 2025, discutée pendant deux mois pleins — la durée maximale autorisée par le processus. Deux tiers des membres de l’équipe Guix ont pris part à la délibération : 72 % de « soutien », 28 % d’« acceptation », zéro « désapprobation ».
Le résultat est révélateur. Vingt-huit pour cent n’ont pas « soutenu » mais seulement « accepté » — ce qui signifie qu’une proportion significative des vieux contributeurs n’aimait pas la direction prise, sans pour autant que leur opposition soit assez forte pour bloquer. Courtès le reconnaît dans son billet : « Les discussions ont montré que de nombreux contributeurs de longue date étaient mal à l’aise face à une orientation perçue comme ‘web d’abord’, moins efficace que le workflow email. Abandonner l’infrastructure patiemment construite autour de l’email était aussi un crève-cœur. »
Mais la balance a penché. Courtès explique pourquoi : « La perspective de toucher une communauté plus large et d’améliorer l’expérience de développement pour la majorité a probablement été le moteur décisif de ce résultat positif. »
Un autre facteur a pesé, presque sans débat : le choix de Codeberg ne tenait pas seulement au fait que c’est du logiciel libre (Forgejo), mais aussi au fait que la plateforme est opérée par une association à but non lucratif, Codeberg e.V. Alignement naturel avec les valeurs de Guix — pas de société commerciale, pas de risque de découvrir un matin que les conditions d’utilisation ont changé.
Le jour J : la CI, angle mort du basculement
La migration a été progressive, comme le prévoyait le document de consensus. Le dépôt principal a basculé le 25 mai 2025, l’ancien dépôt Savannah restant en miroir. L’ancien trackeur de tickets et de patches est resté actif jusqu’au 1er janvier 2026.
Le basculement technique n’a pas été chaotique. Courtès salue la qualité de service de l’équipe et des bénévoles de Codeberg e.V. : « excellente », avec quelques downtimes mais « généralement courts et bien communiqués ».
Le plus gros caillou dans la chaussure, c’est un problème que personne n’avait suffisamment anticipé : l’intégration continue.
Sous l’ancien régime, le service QA (qa.guix.gnu.org) compilait automatiquement les patches sur une branche temporaire et testait. Après la migration vers Codeberg, la CI des PR n’a pas suivi. Pendant plusieurs mois, les relecteurs n’avaient aucun moyen automatique de savoir si une PR allait casser quelque chose — dans un projet qui reçoit plus de 500 PR par an, ce n’est tout simplement pas tenable.
Il a fallu attendre septembre 2025 pour que le projet déploie Cuirass (l’outil CI maison de Guix) sur pulls.ci.guix.gnu.org pour builder les PR. Courtès reconnaît que c’était « initialement un pis-aller » : une seule architecture (x86), loin de la couverture multi-architectures de l’ancienne QA. Mais un bénéfice inattendu est apparu : la visibilité immédiate du résultat — Cuirass poste le verdict de build directement sur la PR sous le pseudo guix-cuirass-bot. Les nouveaux contributeurs n’ont plus besoin d’aller fouiller les archives de la liste de diffusion pour savoir si leur patch compile.
Pour les irréductibles d’Emacs, bonne nouvelle : fj.el et Emacs-Forgejo, deux interfaces Emacs pour Forgejo, ont mûri rapidement cette année. Le workflow AGit (créer une PR par simple git push, sans fork préalable via l’interface web) a aussi conquis des adeptes.
Les chiffres : contribution stable, dette qui croît
C’est la partie la plus précieuse du billet. L’équipe Guix a fait un vrai travail statistique.
Premier enseignement : la migration n’a pas produit « l’effet Codeberg » espéré par certains — pas d’explosion du nombre de contributeurs. Un pic de nouveaux contributeurs a bien été observé en juin 2025, juste après la migration, mais la courbe de l’année suivante est à peu près parallèle à celle de l’année précédente. Guix attire régulièrement de nouveaux contributeurs. Codeberg n’a ni accéléré ni freiné cette dynamique.
Les volumes absolus restent impressionnants : plus de 500 PR soumises par mois. Le rythme de fusion est inférieur au rythme de soumission, d’où une accumulation continue. Actuellement, 639 PR sont ouvertes, soit 10 % du total historique (6 459). En comparaison, Nixpkgs affiche un taux d’ouverture de seulement 2,5 % (12 000 ouvertes pour 473 000 au total).
Courtès attribue cette accumulation à deux causes possibles : une friction excessive à la soumission, ou un retour CI insuffisant.
Le premier facteur de friction, c’est l’obligation de commits signés. Guix exige que chaque commit porte la signature d’un contributeur autorisé — pas de simple bouton « Merge » comme chez Nixpkgs et beaucoup d’autres. La personne qui intègre le code doit assumer personnellement la modification. C’est un arbitrage entre « sécurité de la chaîne d’approvisionnement logicielle » et « fluidité pour les développeurs », et Guix assume le premier terme : « C’est un compromis que nous sommes prêts à faire parce que nous tenons à la sécurité de la chaîne d’approvisionnement, mais nous devons encore voir si ce coût peut être réduit d’une manière ou d’une autre. »
Lobsters fait émerger les vrais problèmes
Sur Lobsters, le billet a recueilli 90 points et 38 commentaires. Au-delà des détails techniques, la discussion a mis en lumière des questions plus profondes.
« Ne remplacez pas le monopole de GitHub par celui de Codeberg. » FedericoSchonborn répond à un commentaire qui souhaitait que « Codeberg devienne le nouveau GitHub » : « Je préférerais voir plein de forges indépendantes communiquer entre elles via ForgeFed, plutôt que de tout déménager sur Codeberg. On n’a pas besoin d’un nouveau hub central du logiciel libre. » Le paradoxe est clair : fuir une plateforme centralisée pour atterrir sur un autre nœud central, c’est reproduire le même schéma. La fédération inter-forges est une sortie plus structurelle.
L’intégration de la chaîne d’outils reste le maillon faible. colonelpanic : « Depuis que je suis sur Codeberg, je me rends compte que quasiment rien ne supporte l’intégration Git générique — presque tout est GitHub / GitLab only. » Le problème ressurgit partout : CI tierce, hébergement statique, gestion de projet. La cause racine, c’est l’inertie de l’écosystème : quand tous les SaaS n’ont codé que l’OAuth GitHub et GitLab derrière leur bouton « Connect your repo », choisir une autre forge, c’est s’exclure de toute la chaîne d’outillage.
La stabilité, talon d’Achille persistant. ysun : « D’expérience, Codeberg a plus de pannes bizarres que GitHub — des push qui échouent aléatoirement, par exemple. » srtcd424 complète : « Je ne pense pas que Forgejo approche les capacités de scalabilité de GitHub aujourd’hui. Les gens de Codeberg font de leur mieux, mais il faut du temps. »
Aucun de ces problèmes n’est rédhibitoire. Mais le vrai coût de « l’alternative », ce n’est pas le jour de la migration. C’est de vivre ensuite chaque jour dans un monde où le support de l’écosystème est plus faible, la stabilité un cran en dessous, l’intégration moins riche. Guix, par sa compétence technique et sa volonté d’auto-héberger ses propres services, peut absorber ces coûts. La plupart des projets ne le peuvent pas.
Ce que la liberté coûte, et ce qu’elle achète
Ce qu’il faut retenir du billet de Guix, ce n’est pas une conclusion. Il ne tranche pas entre « succès » et « échec ». Ce qui compte, c’est la transparence du processus : un projet de logiciel libre sans BDFL, utilisant son propre mécanisme de décision par consensus, a mené une migration d’infrastructure impliquant plus de 400 personnes — puis a tout publié : données, défauts, controverses.
Courtès glisse en fin de billet une « nouvelle de dernière minute » : une PR pour déployer Forgejo sur Guix vient d’être soumise — « un déploiement de forge entièrement déclaratif, totalement reproductible : vous imaginez ? » C’est la forme ultime de la liberté à la Guix : ne pas seulement tourner sur une forge libre, mais donner à n’importe qui le moyen de déployer sa propre forge de manière déclarative. De la fuite de GitHub à l’infrastructure qui rend la fuite possible pour tous, Guix trace une ligne plus ambitieuse qu’un simple « déménagement ».
La fondation Guix a récemment voté pour devenir membre de soutien (sans droit de vote) de Codeberg e.V., en signe de gratitude et de solidarité. Un autre signal, peut-être : s’émanciper de GitHub exige de nouer une relation de long terme, avec un engagement continu en ressources, avec la plateforme d’accueil. Un simple déménagement ne suffit pas.
Cet article s’appuie sur des informations publiques et des discussions communautaires. Si vous avez une expérience directe sur ce sujet, vos corrections et compléments sont bienvenus.