Guix、「GitHub離れ」から1年——Codebergは自由ソフトウェアの旗艦を支えられるか
2026年6月22日、GuixプロジェクトのメンテナーであるLudovic Courtèsがブログを投稿した。タイトルは控えめだ——「One year with Codeberg」。だが中身の重みは、その地味なタイトルをはるかに超える。これは現在、自由ソフトウェアコミュニティにおいて最大規模かつ最も透明な「GitHub脱出」実験の、完全な振り返りだからだ。
1年前、Guixはすべてのコードリポジトリ、Issueトラッカー、Pull Requestのワークフローを、GNU SavannahとメールベースのDebbugsシステムからCodeberg——Forgejoを稼働させるドイツの非営利ホスティングプラットフォーム——へと移行した。毎年400人以上がコードを投稿するプロジェクトが、十数年にわたるメールパッチのワークフローを手放し、多くの人にとって「過激」と思える選択をした。そして今、データが出そろった。
メール vs Web——外部からは見えにくい分裂
Guixの旧ワークフローは、今日の目で見ればほとんど考古学の現場だ。バグ報告とパッチはメールで送られ、Perlで書かれたDebbugsがそれを追跡する。コアコントリビューターたちはEmacsと高機能メールクライアントを使いこなし、この仕組みを手足のように操っていた。彼らに言わせれば、Debbugsの数百行のPerlコードは、メールという長年鍛え抜かれた連合標準の上に立っている。一方ForgejoのようなWeb forgeは、Goの依存関係が何百何千と連なり、膨れ上がって見苦しい。
コミュニティはメールワークフローを支える精緻な補助装置まで育て上げていた。mumiはDebbugsに美しいWebインターフェースをかぶせ、QAサービスはパッチシリーズを自動的にGitブランチへ打ち込み、コンパイルとテストを走らせる。移行とは、これらの道具をすべて捨てることを意味した。
だが、もう一方の声も同じくらいリアルだった。2025年1月、Steve George（Futurile）がGuixの初のユーザー・コントリビューター調査結果を公開し、900人が回答した。結論は率直そのもの——多数の潜在的コントリビューターにとって、メールワークフローは「障壁」だった。要するに、若い世代のハッカーはメールでパッチを送った経験すらないかもしれない。彼らが知っているのはGitHub式の「PRボタン」なのだ。
この分裂は、自由ソフトウェア運動の古典的なジレンマだ。古参が大切にする「ミニマルで、連合的で、標準に準拠した」方式は、新人の目には「参入障壁が高く、反応が遅く、自分のパッチが誰かに見られているのかどうかすらわからない」と映る。
GCD合意——独裁者なきプロジェクトの意思決定
Guixは二つのレイヤーの問題に直面していた。ツールの選択、そして意思決定のメカニズムだ。このプロジェクトには「慈悲深き独裁者」（BDFL）がいない。2024年12月、コミュニティはGuix Consensus Document（GCD）プロセスを承認した。提案者は全員と協力して合意に達しなければならず、参加者は単純に「反対」することはできず、具体的な要求と修正提案を示す義務がある。最終的に表明できる立場は「支持」「受諾」「不支持」の三つだ。
GCD 002号提案がCodebergへの移行だった。2025年2月に提出され、まるまる2か月議論された——これはプロセスが許容する最長の期間だ。Guixチームメンバーの3分の2が審議に参加し、72％が「支持」、28％が「受諾」、0人が「不支持」だった。2025年5月初旬、提案は正式に発効した。
この結果は興味深い。28％の人が「支持」ではなく「受諾」にとどまったということは、かなりの割合の古参コントリビューターがこの方向性を好まなかったが、拒否権を発動するほどではなかったことを意味する。Courtèsのブログはこう暴露している：「議論から明らかになったのは、長期コントリビューターの多くが、主に『Webファースト』と受け止められている方向性に移行すること、そしてそれがメールワークフローよりも非効率と感じられることへの不安だ。長年メールワークフローを支えるために丹念に築き上げたインフラを捨てる惜しさもあった。」
だが、天秤が最終的に傾いた理由もはっきり書かれている：「より広いコミュニティとの接点を持ち、大多数の開発体験を改善するという期待が、この肯定的な結果を後押しした主要因だろう。」
もう一つ、ほとんど論争にならなかった要素がある。Codebergが選ばれたのは、自由ソフトウェア（Forgejo）であることだけでなく、非営利組織Codeberg e.V.によって運営されているからだ。これはGuixの価値観と自然に一致する——商業企業の利害が絡まず、ある朝目覚めたら利用規約が書き換えられていた、という心配がない。
切り替えの現場——CIの断絶が最大の落とし穴
合意文書の計画では、移行は段階的だった。メインリポジトリは2025年5月25日に移行完了、旧Savannahリポジトリはミラーとして保持。旧Issueとパッチトラッカーは2026年1月1日まで稼働し続け、その後正式に閉鎖された。
切り替えプロセス自体に大きな混乱は起きなかった。CourtèsはCodeberg e.V.のスタッフとボランティアのサービス品質を「非常に良い」と評価し、ダウンタイムは時折あったが「通常短時間で、明快なコミュニケーションがあった」としている。
最大の落とし穴は、十分に予見されていなかった問題——継続的インテグレーション（CI）だった。
かつてメール時代のQAサービス（qa.guix.gnu.org）は、パッチを自動的に一時ブランチに打ち込み、コンパイルテストを走らせていた。Codeberg移行後、PRのCIはすぐには追いつかなかった。数か月もの間、レビュアーは人の手でPRが何かを壊さないか判断するしかなかった——年間500以上のPRが飛び交うプロジェクトで、これは持続不可能だ。
2025年9月になってようやく、プロジェクトはpulls.ci.guix.gnu.org上にCuirass（Guixが自前開発したCIツール）を配備し、PRのビルドを受け持たせた。Courtèsはこれが「当初は間に合わせの策と見なされていた」と率直に認める。現在は単一アーキテクチャ（x86）しかビルドしておらず、旧QAのマルチアーキテクチャカバレッジには及ばない。だが、思いがけない利得があった。フィードバックの「即時可視性」だ。Cuirassはguix-cuirass-botとしてPRに直接ビルドの成否を返信する。新人はもはやメーリングリストを漁ってテスト結果を探す必要がない。
Emacsを手放せない開発者たちにとっての朗報は、fj.elとEmacs-Forgejoという二つのEmacsインターフェースがこの1年で急速に成熟したことだ。AGitワークフロー（git pushで直接PRを作成し、Webで先にリポジトリをforkする必要がない）も多くのユーザーを獲得した。
データが語ること——コントリビューターは減らず、されど滞留は増える
これがブログ全体で最も価値ある部分だ。Guixチームは手堅いデータ統計をとった。
まず結論から：移行は一部の人が期待した「Codeberg効果」——コントリビューター数の爆発的増加——をもたらさなかった。2025年6月（移行直後）に新規コントリビューターと総コントリビューター数の小さなピークはあったが、その後1年の増加傾向は移行前1年とおおむね同程度だ。Guixは一貫して新規コントリビューターを引きつけてきており、Codebergはそのペースを加速も減速もさせなかった。
だが絶対数は依然として見事だ。毎月500以上のPRが提出されている。マージ速度は提出速度をわずかに下回り、滞留は増加の一途をたどる。現在639のオープンPRがあり、これは過去の総PR数（6459）の10％にあたる。比較として、NixpkgsのオープンPR比率はわずか2.5％（1.2万オープン／47.3万総数）だ。
Courtèsは滞留の原因として、PR提出の摩擦の高さか、CIフィードバックの不足かの二つを挙げる。
最大の摩擦点は署名付きコミット要件だ。Guixはすべてのコミットが権限あるコミッターによって署名されなければならないと定めている——Nixpkgsなど多くのプロジェクトのように「Merge」ボタンをポチっと押すだけでは済まない。つまり、コードをマージする人間は本当にその変更に責任を負わなければならず、匿名でいられない。これは「ソフトウェアサプライチェーンのセキュリティ」と「開発者の利便性」のトレードオフであり、Guixは前者を選んだ：「これは私たちが喜んで受け入れるトレードオフだ。ソフトウェアサプライチェーンの安全を守ることを重視しているからだ。しかし、このコストが何らかの形で緩和できるかどうかも、まだ見極める必要がある。」
Lobstersで噴出した本質的な問い
Lobstersでこのブログは90ポイント、38コメントを集めた。技術的な細部を離れ、コミュニティの議論はより深い問題をいくつか噴出させた。
「GitHub独占をCodeberg独占に置き換えるな」。 ユーザーFedericoSchonbornは「Codebergが新しいGitHubになってほしい」というコメントへの返信でこう書いた：「私はすべてをCodebergに移すよりも、むしろ多数の独立したコードフォージがForgeFedを通じて相互通信する姿を見たい。新しいオープンソースの中央ノードは必要ない。」これはパラドックスを突いている。集中型プラットフォームからの脱出が、単に別の中央ノードへの引っ越しに終わったら、何も変わっていない。フォージ間の連合相互運用を推進することこそが、より根本的な出口なのだ。
ツールチェーン統合は依然として弱点。 ユーザーcolonelpanicはこう指摘する：「Codebergを使い始めてから気づいたのは、一般的なGit統合を本当にサポートしているものがほとんどないことだ——ほぼすべてがGitHub／GitLab専用だ。」この問題はサードパーティCI、静的ホスティング、プロジェクト管理システムなど、さまざまな場面で繰り返される。根本にはエコシステムの慣性がある——あらゆるSaaSの「Connect your repo」ボタンの背後にGitHubとGitLabのOAuthフローしか書かれていないとき、他のプラットフォームを選ぶことはツールチェーン全体から見放されることを意味する。
安定性にはまだ差がある。 ユーザーysunはこう書く：「私の経験では、CodebergはGitHubより奇妙な障害が多い。たとえばpushがランダムに失敗する。」別のユーザーsrtcd424は補足する：「ForgejoがGitHubのスケーラビリティに近づけるとは、現時点では思わない。Codebergの人たちは最善を尽くしているが、時間がかかる。」
これらは致命的ではない。「代替案」の本当のコストとは、移行したその日以降、毎日、エコシステムのサポートが一段弱く、安定性が一段劣り、統合が一段少ない世界で生き続けることだ——移行当日の作業量など、むしろ無視できるほど小さい。Guixは十分な技術力と自前インフラを構築する意志があるから、これらのコストを負担できる。しかし大多数のプロジェクトには負えない。
自由ソフトウェアの代償と、それが買い取ったもの
Guixのこの記事が最も記憶に値するのは、結論ではない——単純な「成功」か「失敗」かの判断を、これは下していない。記憶に値するのはプロセスの透明性だ。BDFLのいない自由ソフトウェアプロジェクトが、自ら設計した合意形成メカニズムを用いて、400人以上が関わるインフラ移行を完遂し、そのデータ、欠陥、論争のすべてを公開した。
Courtèsは結びで「速報」に触れている。Guix上にForgejoをデプロイするPRがつい先ほど提出されたのだ——「純粋に宣言的な設定、完全に再現可能なフォージのデプロイ、想像できるか？」これはGuix的自由の最終形態を指し示している。自由ソフトウェアのフォージの上で走らせるだけでなく、誰もがGuixを使って自分のフォージを宣言的にデプロイできるようにすること。GitHubからの脱出から、自らが代替インフラの基盤になることへ——Guixが歩んでいるのは「引っ越し」よりもはるかに遠い道だ。
Guix Foundationは最近の投票で、感謝と支援の印としてCodeberg e.V.のサポーティング（非投票）メンバーとなった。これもおそらく一つのシグナルだ。GitHub脱出には、代替プラットフォームとの継続的にリソースを投じる長期的関係が必要であり、一度の引っ越しではまったく足りない。
本記事の素材は公開情報とコミュニティの議論に基づいています。このトピックについてより深い直接経験をお持ちの方は、ぜひ文中の不足点をご指摘ください。