Am 22. Juni 2026 veröffentlichte Guix-Maintainer Ludovic Courtès einen Blogbeitrag mit dem schlichten Titel »One year with Codeberg«. Doch das Gewicht des Inhalts übertrifft die Zurückhaltung des Titels bei Weitem – es ist die bislang umfangreichste und transparenteste Retrospektive eines »GitHub-Exodus« in der Freien-Software-Community.
Vor einem Jahr verlagerte Guix sämtliche Code-Repositories, das Issue-Tracking und den Pull-Request-Prozess von GNU Savannah und dem E-Mail-basierten Debbugs-System zu Codeberg – einer in Deutschland ansässigen, als gemeinnütziger Verein betriebenen Forgejo-Instanz. Ein Projekt mit jährlich über 400 Code-Einreichern vollzog nach mehr als einem Jahrzehnt E-Mail-Patch-Workflow einen Schritt, den viele als »radikal« betrachteten. Jetzt liegen die Daten vor.
E-Mail vs. Web: Ein unterschätzter Graben
Guix’ alter Workflow mutet aus heutiger Sicht fast archäologisch an: Bug-Reports und Patches gingen per E-Mail ein und wurden vom in Perl geschriebenen Debbugs-System verwaltet. Die Kernbeitragenden, die mit Emacs und hochentwickelten E-Mail-Clients in diesem Ökosystem perfekt zurechtkamen, betrachteten die paar hundert Zeilen Perl-Code von Debbugs als solides Fundament auf Basis des bewährten, föderierten E-Mail-Standards – während Forgejo als Web-Schmiede mit Hunderten von Go-Abhängigkeiten als unverhältnismäßig aufgebläht erschien.
Die Community hatte rund um den E-Mail-Workflow sogar ein ausgefeiltes Hilfsökosystem gestrickt: mumi setzte eine ansprechende Weboberfläche auf Debbugs, ein QA-Dienst baute Patch-Serien automatisch in temporäre Git-Branches ein und testete sie. Die Migration würde all diese Werkzeuge obsolet machen.
Doch die andere Seite meldete sich ebenso deutlich zu Wort. Im Januar 2025 veröffentlichte Steve George (Futurile) die erste Guix-Nutzer- und Beitragenden-Umfrage mit 900 Teilnehmern. Das Fazit war eindeutig: Für zahlreiche potenzielle Beitragende stellt der E-Mail-Workflow »eine Hürde« dar. Anders gesagt: Die jüngere Hacker-Generation hat möglicherweise noch nie einen Patch per E-Mail eingereicht – sie kennt den GitHub-artigen PR-Button.
Dieser Graben ist das klassische Dilemma der Freien-Software-Bewegung: Was Veteranen als »minimalistisch, föderiert und standardkonform« schätzen, liest sich für Neueinsteiger als »hohe Einstiegshürde, langsame Reaktion, nie sicher, ob mein Patch überhaupt jemand anschaut«.
GCD-Konsens: Wie ein Projekt ohne Diktator entscheidet
Guix stand vor zwei Herausforderungen: der Werkzeugauswahl und dem Entscheidungsmechanismus – denn das Projekt hat keinen »wohlwollenden Diktator« (BDFL). Im Dezember 2024 verabschiedete die Community das Guix Consensus Document (GCD)-Verfahren: Der Vorschlagende muss mit allen Beteiligten einen Konsens erarbeiten; Teilnehmer können nicht einfach »ablehnen«, sondern müssen konkrete Anforderungen und Änderungsvorschläge benennen. Am Ende darf jeder »Unterstützung«, »Annahme« oder »Missbilligung« ausdrücken.
GCD 002 war der Vorschlag zur Migration zu Codeberg. Eingereicht im Februar 2025, wurde er über die maximal zulässigen zwei Monate diskutiert. Zwei Drittel der Guix-Teammitglieder beteiligten sich: 72 % sprachen »Unterstützung« aus, 28 % »Annahme«, null Personen »Missbilligung«. Anfang Mai 2025 trat der Vorschlag offiziell in Kraft.
Dieses Ergebnis ist bemerkenswert. 28 % gaben lediglich »Annahme« statt »Unterstützung«, was bedeutet, dass ein erheblicher Anteil der langjährigen Beitragenden diesen Kurs nicht mochte, aber auch nicht stark genug, um ihn zu blockieren. Courtès’ Blogbeitrag gibt Einblick: »Die Diskussion zeigte, dass viele langjährige Beitragende Unbehagen gegenüber der Hinwendung zu einer als ›Web-zuerst‹ wahrgenommenen Richtung empfanden, die gegenüber dem E-Mail-Workflow als weniger effizient galt. Der Abschied von der über Jahre sorgfältig aufgebauten Infrastruktur rund um den E-Mail-Workflow schmerzte ebenfalls.«
Doch warum kippte die Waage trotzdem? Der Blog nennt den Grund deutlich: »Die Erwartung, eine breitere Community zu erreichen und die Entwicklungserfahrung für die Mehrheit zu verbessern, war wohl der entscheidende Hebel für dieses positive Ergebnis.«
Ein weiterer, fast unkontroverser Faktor: Die Wahl fiel auf Codeberg nicht nur, weil es Freie Software ist (Forgejo), sondern weil es vom gemeinnützigen Verein Codeberg e.V. betrieben wird. Dies deckt sich nahtlos mit Guix’ Werten – keine Interessenkonflikte mit kommerziellen Unternehmen, keine Angst, eines Morgens aufzuwachen und geänderte Nutzungsbedingungen vorzufinden.
Der Umzug: CI-Ausfall als größte Falle
Gemäß dem Konsensdokument verlief die Migration schrittweise. Das Haupt-Repository wurde am 25. Mai 2025 umgezogen, das alte Savannah-Repository blieb als Spiegel erhalten. Die alten Issue- und Patch-Tracker liefen noch bis zum 1. Januar 2026 weiter.
Der Umzug selbst verlief ohne größere Pannen. Courtès lobte die »ausgezeichnete« Servicequalität der Codeberg-Mitarbeiter und Freiwilligen; gelegentliche Ausfallzeiten seien »in der Regel kurz und klar kommuniziert« gewesen.
Die größte Falle war ein nicht ausreichend antizipiertes Problem: die Continuous Integration.
Der bisherige QA-Dienst der E-Mail-Ära (qa.guix.gnu.org) baute Patches automatisch in temporäre Branches ein und testete sie. Nach der Migration zu Codeberg fehlte diese CI für Pull Requests monatelang. Reviewer mussten rein manuell beurteilen, ob ein PR etwas kaputt machen würde – bei einem Projekt mit über 500 PRs pro Jahr schlicht untragbar.
Erst im September 2025 wurde auf pulls.ci.guix.gnu.org Cuirass (Guix’ selbst entwickeltes CI-Werkzeug) für PR-Builds eingerichtet. Courtès räumt ein, dies sei »anfangs als Übergangslösung betrachtet« worden: Derzeit wird nur eine einzige Architektur (x86) gebaut, was hinter der Multi-Architektur-Abdeckung der alten QA zurückbleibt. Ein unerwarteter Vorteil war jedoch die »unmittelbare Sichtbarkeit« des Feedbacks – Cuirass antwortet als guix-cuirass-bot direkt unter dem PR, Neueinsteiger müssen nicht mehr in E-Mail-Listen nach Testergebnissen suchen.
Für die Emacs-unverzichtbaren Entwickler gibt es gute Nachrichten: fj.el und Emacs-Forgejo, zwei Emacs-Schnittstellen, sind im Laufe des Jahres schnell gereift. Auch der AGit-Workflow (PR-Erstellung direkt per git push ohne vorheriges Forken im Web) gewann viele Nutzer.
Die Daten: Beitragende stabil, Rückstau wächst
Dies ist der wertvollste Teil des gesamten Blogbeitrags. Das Guix-Team hat solide Daten erhoben.
Das Fazit vorweg: Die Migration brachte nicht den von manchen erhofften »Codeberg-Effekt« – ein explosionsartiger Anstieg der Beitragendenzahlen blieb aus. Im Juni 2025 (unmittelbar nach der Migration) gab es zwar eine kleine Spitze bei Neu- und Gesamtbeitragenden, doch der Trend im darauffolgenden Jahr verlief ungefähr wie im Jahr zuvor. Guix zieht kontinuierlich neue Beitragende an; Codeberg hat diesen Prozess weder beschleunigt noch gebremst.
Dennoch sind die absoluten Zahlen beachtlich: Monatlich gehen über 500 PRs ein. Die Merge-Rate liegt leicht unter der Einreichungsrate, sodass der Rückstau stetig wächst. Aktuell sind 639 PRs offen – 10 % aller jemals eingereichten PRs (6.459). Zum Vergleich: Bei Nixpkgs beträgt der Anteil offener PRs nur 2,5 % (12.000 offen / 473.000 historisch).
Courtès führt den Rückstau auf zwei mögliche Faktoren zurück: zu hohe Einreichungsreibung oder unzureichendes CI-Feedback.
Der größte Reibungspunkt ist die Signaturanforderung für Commits. Guix verlangt, dass jeder Commit von einem autorisierten Committer signiert sein muss – anders als bei vielen Projekten wie Nixpkgs, wo ein Klick auf »Merge« genügt. Das bedeutet: Wer Code einpflegt, muss wirklich für die Änderung geradestehen und kann nicht anonym bleiben. Es ist ein Trade-off zwischen »Software-Lieferkettensicherheit« und »Entwicklerkomfort« – Guix hat sich für Ersteres entschieden: »Das ist ein Trade-off, den wir bereit sind einzugehen, weil uns die Sicherheit der Software-Lieferkette am Herzen liegt, aber wir müssen noch prüfen, ob diese Kosten auf irgendeine Weise abgemildert werden können.«
Die wahren Fragen, die Lobsters aufwarf
Auf Lobsters erhielt der Blogbeitrag 90 Punkte und 38 Kommentare. Jenseits technischer Details brachte die Diskussion tiefere Probleme ans Licht.
»Codeberg-Monopol statt GitHub-Monopol – das kann es nicht sein.« Nutzer FedericoSchonborn antwortete auf den Kommentar »Hoffentlich wird Codeberg das neue GitHub«: »Ich würde lieber viele unabhängige Code-Schmieden sehen, die über ForgeFed miteinander kommunizieren, als dass alles zu Codeberg wandert. Wir brauchen keinen neuen zentralen Open-Source-Knotenpunkt.« Dies deutet auf ein Paradoxon hin: Vom zentralisierten Plattform-Monopol zu fliehen, nur um auf einem anderen zentralen Knoten zu landen, ändert im Grunde nichts. Föderierte Interoperabilität zwischen Schmieden voranzutreiben, wäre der grundsätzlichere Ausweg.
»Toolchain-Integration bleibt die Achillesferse.« Nutzer colonelpanic merkte an: »Seit ich Codeberg benutze, ist mir aufgefallen, dass fast nichts generische Git-Integration wirklich unterstützt – fast alles ist GitHub / GitLab only.« Dieses Problem wiederholt sich in Szenarien mit Drittanbieter-CI, statischem Hosting, Projektmanagementsystemen und ähnlichem. Die Wurzel ist die Trägheit des Ökosystems: Wenn hinter jedem »Connect your repo«-Button in jeder SaaS nur GitHub- und GitLab-OAuth-Flows implementiert sind, bedeutet die Wahl einer anderen Plattform, von der gesamten Toolchain abgeschnitten zu sein.
»Stabilität hat noch Luft nach oben.« Nutzer ysun schrieb: »Meiner Erfahrung nach hat Codeberg mehr seltsame Ausfälle als GitHub, zum Beispiel scheitern Pushs zufällig.« Ein anderer Nutzer, srtcd424, ergänzte: »Ich glaube nicht, dass Forgejo derzeit an die Skalierungsfähigkeit von GitHub heranreicht. Die Codeberg-Leute geben ihr Bestes, aber es braucht Zeit.«
Nichts davon ist tödlich. Die wahren Kosten der »Alternative« bestehen darin, fortan jeden Tag in einer Welt mit schwächerer Ökosystem-Unterstützung, geringerer Stabilität und weniger Integrationen zu leben – der Aufwand des Migrationstages selbst ist dagegen vernachlässigbar. Guix kann diese Kosten tragen, weil das Projekt über genügend technische Kompetenz und den Willen zum Eigenbau von Infrastruktur verfügt – die meisten Projekte können das nicht.
Was Freie Software kostet – und was man dafür bekommt
Was diesen Guix-Beitrag am meisten erinnernswert macht, ist nicht das Fazit – er liefert kein simples »Erfolg«- oder »Misserfolg«-Urteil. Sondern die Transparenz des Prozesses. Ein Freie-Software-Projekt ohne BDFL hat mit seinem selbst entworfenen Konsensmechanismus eine über 400 Personen umfassende Infrastrukturmigration vollzogen und veröffentlicht anschließend alle Daten, Schwächen und Kontroversen.
Courtès erwähnte zum Schluss eine »Breaking News«: Ein PR zur Bereitstellung von Forgejo auf Guix wurde gerade eingereicht – »rein deklarative Konfiguration, vollständig reproduzierbare Schmieden-Bereitstellung – kann man sich das vorstellen?« Dies deutet auf die finale Form der Guix’schen Freiheit: nicht nur auf einer Freie-Software-Schmiede zu laufen, sondern es jedem zu ermöglichen, seine eigene Schmiede deklarativ mit Guix bereitzustellen. Vom Verlassen GitHubs bis zur eigenen Rolle als Infrastrukturbaustein für Alternativen – Guix geht einen Weg, der weiter reicht als ein bloßer »Umzug«.
Die Guix Foundation hat kürzlich dafür gestimmt, unterstützendes (nicht stimmberechtigtes) Mitglied des Codeberg e.V. zu werden – als Geste des Danks und der Unterstützung. Vielleicht ein weiteres Signal: Dem GitHub-Exodus muss eine langfristige, ressourcenschonende Beziehung zur Alternativplattform folgen. Ein einmaliger Umzug reicht bei Weitem nicht.
Das Material dieses Artikels stammt aus öffentlichen Informationen und Community-Diskussionen. Wenn Sie tiefere praktische Erfahrung zu diesem Thema haben, sind Hinweise auf Unzulänglichkeiten willkommen.