On June 22, 2026, Guix project maintainer Ludovic Courtès published a blog post with an understated title: “One year with Codeberg.” But the content carries far more weight than the title’s restraint suggests — this is the most complete retrospective yet of the largest, most transparent “escape from GitHub” experiment in the free software community.
One year ago, Guix moved its entire code repositories, issue tracker, and pull request workflow from GNU Savannah and the email-based Debbugs system to Codeberg — a German nonprofit hosting platform running Forgejo. A project with over 400 people submitting code annually, after more than a decade of email-patch workflows, made a choice many considered “radical.” Now the data is in.
Email vs. Web: An Invisible Schism
Guix’s old workflow, viewed from today, looks almost like an archaeological site: bug reports and patches were sent via email, tracked by the Perl-written Debbugs system. Core contributors thrived in this system using Emacs and sophisticated email clients — for them, Debbugs’ few hundred lines of Perl were built on email, a battle-tested federated standard, while Forgejo, a web forge with hundreds of Go dependencies, was bloated beyond reason.
The community had even built a sophisticated set of auxiliary tools around the email workflow: mumi gave Debbugs a nice web interface, and a QA service would automatically apply patch series to a Git branch and compile-test them. Migration meant scrapping all of these tools.
But the other side’s voice was equally real. In January 2025, Steve George (Futurile) published the results of Guix’s first user and contributor survey, with 900 participants. The conclusion was direct: for a large number of potential contributors, the email workflow was “a barrier.” Put bluntly, a younger generation of hackers may never have submitted a patch via email — what they know is the GitHub-style PR button.
This schism is the classic dilemma of the free software movement: what veterans treasure as “minimalist, federated, standards-compliant” looks to newcomers like “high barrier, slow response, I have no idea if anyone even looked at my patch.”
GCD Consensus: How a BDFL-Free Project Makes Decisions
Guix faced two layers of problems: tool selection, and decision-making mechanism — the project has no “benevolent dictator for life” (BDFL). In December 2024, the community adopted the Guix Consensus Document (GCD) process: the proposer must collaborate with everyone to reach consensus; participants cannot simply “oppose” but must raise specific requirements and suggested modifications. Ultimately, they can express “support,” “accept,” or “disapprove.”
GCD 002 was the migration to Codeberg. Submitted in February 2025, it was discussed for a full two months — the maximum time the process allows. Two-thirds of the Guix team members participated in deliberation: 72% expressed “support,” 28% “accept,” and zero “disapprove.” The proposal took effect in early May 2025.
This result is interesting. Twenty-eight percent merely “accepted” rather than “supported,” indicating a significant proportion of long-time contributors didn’t like the direction, but not strongly enough to veto. Courtès’s blog reveals: “The discussion showed that many long-time contributors were uneasy about moving to a direction primarily perceived as ‘web-first’ and less efficient compared to the email workflow. Leaving behind infrastructure lovingly built around the email workflow over the years was also a source of sadness.”
But the reason the scale ultimately tipped is also clearly stated: “The expectation of reaching a broader community and improving the development experience for the majority was likely the key motivation that drove this positive outcome.”
One factor that drew almost no controversy: choosing Codeberg not only because it’s free software (Forgejo), but because it’s operated by the nonprofit Codeberg e.V. This aligns naturally with Guix’s values — no commercial entity entanglements, no waking up one day to find the terms of service changed.
The Cutover: CI Was the Biggest Pitfall
Per the consensus document’s plan, migration was gradual. The main repository was migrated on May 25, 2025, with the original Savannah repository retained as a mirror. The old issue and patch trackers continued operating until January 1, 2026, when they were formally shut down.
The cutover itself didn’t go badly. Courtès rated the service quality of Codeberg e.V. staff and volunteers as “very good,” with occasional downtime but “usually brief and with clear communication.”
The biggest pitfall came from something insufficiently foreseen: continuous integration.
The email-era QA service (qa.guix.gnu.org) had automatically applied patches to temporary branches and compile-tested them. After migrating to Codeberg, CI for PRs didn’t follow in time. For several months, reviewers could only judge by intuition whether a PR would break things — in a project with 500+ PRs a year, this was fundamentally unsustainable.
It wasn’t until September 2025 that the project deployed Cuirass (Guix’s own CI tool) on pulls.ci.guix.gnu.org to pick up PR builds. Courtès was candid that this was “initially seen as a stopgap”: it currently only builds a single architecture (x86), falling short of the original QA’s multi-architecture coverage. But one unexpected upside was the “instant visibility” of feedback — Cuirass, posting as guix-cuirass-bot, replies directly on PRs with build success/failure; newcomers no longer need to hunt through mailing lists for test results.
For those developers who can’t live without Emacs, the good news is that fj.el and Emacs-Forgejo, two Emacs interfaces, matured rapidly over the year. The AGit workflow (creating PRs directly via git push, without first forking the repo on the web) also won a significant user base.
By the Numbers: Contributors Didn’t Drop, but the Backlog Grows
This is the most valuable part of the entire blog post. The Guix team did solid data work.
The headline: the migration did not produce the “Codeberg effect” some had hoped for — there was no explosion in contributor numbers. June 2025 (just after migration) did see a small spike in new and total contributors, but the year since has followed roughly the same growth trend as the year before migration. Guix has been steadily attracting new contributors; Codeberg neither accelerated nor decelerated this process.
But the absolute numbers are still substantial: over 500 PRs are submitted per month. The merge rate slightly trails the submission rate, causing a steadily growing backlog. There are currently 639 open PRs, representing 10% of the historical total (6,459 PRs). For comparison, Nixpkgs’ open PR ratio is only 2.5% (12K open / 473K historical total).
Courtès attributes the backlog to two possible factors: excessive submission friction or insufficient CI feedback.
The biggest friction point: the signed-commit requirement. Guix requires every commit to be signed by an authorized committer — unlike Nixpkgs and many other projects where you just click “Merge.” This means the person merging code must genuinely take responsibility for the changes, with no ability to hide. This is a trade-off between “software supply chain security” and “developer convenience” — Guix chose the former: “This is a trade-off we’re willing to make, because we care about securing the software supply chain, but we still need to see whether this cost can be mitigated in some way.”
The Real Questions Blown Open on Lobsters
The Lobsters post scored 90 points with 38 comments. Beyond technical details, the community discussion surfaced several deeper questions.
“Don’t replace the GitHub monopoly with a Codeberg monopoly.” User FedericoSchonborn, replying to a comment hoping “Codeberg becomes the new GitHub,” wrote: “I’d rather see many independent code forges communicating with each other via ForgeFed, rather than moving everything to Codeberg. We don’t need a new open-source central node.” This points to a paradox: escaping a centralized platform by jumping to another central node changes nothing. Pushing for federated interoperability between forges is the more fundamental solution.
Toolchain integration remains the weak spot. User colonelpanic noted: “Since starting to use Codeberg, I’ve found that almost nothing properly supports generic Git integration — almost everything is GitHub / GitLab only.” This problem repeatedly surfaces across third-party CI, static hosting, project management systems, and more. The root cause is ecosystem inertia — when every SaaS’s “Connect your repo” button only has OAuth flows for GitHub and GitLab written behind it, choosing another platform means being abandoned by the entire toolchain.
Stability still has a gap. User ysun wrote: “From my experience, Codeberg has more weird glitches than GitHub, like pushes randomly failing.” Another user, srtcd424, added: “I don’t think Forgejo can currently approach GitHub’s scaling capability. The Codeberg folks are trying hard, but it takes time.”
None of these are fatal. The real cost of an “alternative” is living every subsequent day in a world with weaker ecosystem support, lower stability, and fewer integrations — the one-day migration effort is negligible by comparison. Guix, with sufficient technical capacity and willingness to build its own infrastructure, can bear these costs — but most projects can’t.
The Price of Free Software, and What It Buys
What makes Guix’s article worth remembering isn’t the conclusion — it doesn’t offer a simple “success” or “failure” judgment. It’s the transparency of the process. A BDFL-free free software project, using a consensus decision mechanism it designed itself, completed an infrastructure migration involving 400+ people, then publicly disclosed the data, flaws, and controversies.
Courtès mentioned “breaking news” at the end: a PR for deploying Forgejo on Guix had just been submitted — “a purely declarative configuration, fully reproducible forge deployment — can you imagine?” This points to the ultimate form of Guix-style freedom: not just running on a free software forge, but enabling anyone to declaratively deploy their own forge using Guix. From escaping GitHub to becoming infrastructure for alternatives, Guix is walking a path that goes well beyond “moving house.”
The Guix Foundation recently voted to become a supporting (non-voting) member of Codeberg e.V., as a way to express gratitude and support. This may be another signal: escaping GitHub requires building sustained, resource-invested long-term relationships with alternative platforms. One move is never enough.
This article draws on publicly available information and community discussions. If you have deeper first-hand experience with this topic, corrections and additions are welcome.