GitHubを離れてForgejoに移る理由

2026年5月13日原文(jorijn.com)

概要

GitHub から Forgejo への移行理由の詳細説明
オランダ政府 も同様にForgejoを採用した背景
GitHubの AI重視方針 ・ データ利用 ・ 法的リスク の問題点
Forgejo と GitLab の比較と選定理由
今後の運用・移行計画の概要

GitHubからForgejoへの移行理由

GitHubの障害が主因ではなく、 運用主体の所有権 と データ主権 の確保が主目的
オランダ内務省も同様の理由で code.overheid.nl （Forgejo自営インスタンス）を2026年4月27日にソフトローンチ
プロジェクトマネージャーBoris Van Hoytema氏の「 法的要件 として自らが所有する場所でソースコードを公開する必要があった」発言
Forgejoは 完全なオープンソース であり、 デジタル自治 に必要な自由を提供
自身のコードも同様に code.jorijn.com （Forgejo v15 LTS、NUC上で堅牢に運用）へ移行
- 一部リポジトリはすでに移行済み、残りも順次移行予定
- 移行完了後、 GitHubの公開リポジトリはアーカイブ化 し新URLを案内

GitHubの現状と課題

2025年5月〜2026年4月の間に 257件のインシデント、うち 48件が重大障害
- CTOによる「AIワークフローの増加で 30倍の容量拡張 が必要」との謝罪
2025年8月、 GitHub独自のCEOが不在 となり、Microsoft CoreAI部門に吸収
- 以降は MicrosoftのAI組織 の一部として運営されている実態
2026年4月24日より、 CopilotユーザーのインタラクションデータがAI学習にデフォルト利用
- ユーザーごとにオプトアウト必要、 リポジトリ単位での制御不可
- プライベートリポジトリでも編集時のスニペット・コンテキストは収集対象
- Copilot Business/Enterpriseのみデータ保護契約で除外

法的リスクとデータ主権

GitHub/Microsoft は米国企業であり、 FISA 702条 や CLOUD Act の適用範囲内
- データの物理的な保存場所に関係なく、 米国法の管轄下
- 2024年10月のEUデータレジデンシー発表は「 安心感」であり「 解決策」ではない
- Microsoft弁護士による「EU内データも米国政府によるアクセスを保証できない」証言

オランダ政府のForgejo採用と背景

「Open, tenzij」政策（2020年施行）： 公費開発ソフトは原則オープンソース
code.overheid.nl は、政府が 完全にコントロール可能な公開場所 としてForgejoを選択
欧州委員会（code.europa.eu）、ドイツ（openCode）は GitLab を採用
- オランダはあえてForgejoを選択し、「 完全なオープンソース」「 商用ベンダー依存の回避」を重視
Forgejoの 開発ロードマップ が政府方針と一致

ForgejoとGitLabの比較・選定理由

GitLab はオープンコアモデルで、 主要機能は有償Enterprise版 に限定
Forgejo は2024年8月から GPLv3+ （コピーレフト）へとライセンス変更
- Giteaからのフォーク理由も「商用企業による支配回避」
Forgejoは Codeberg e.V. （ベルリン登記の非営利団体）管理
- 年次予算も会員投票で決定、透明性とガバナンス重視
v15 LTS （2026年4月リリース）は100回目のリリース、2027年7月まで長期サポート
- Actionsも必要な成熟度に到達（エフェメラルランナー、OIDC、再利用可能ワークフロー等）

今後の運用・移行計画

code.jorijn.com でForgejo v15 LTSを運用、KVM分離・週次再構築のActionsランナー導入
GitHub上の公開リポジトリは順次 アーカイブ化 し、新Forgejoへのリンクを案内
長期的には 完全な自営Forgejo運用 を目指す方針

まとめ：自営Forgejoへの移行の意義

所有権・データ主権 の確保が最大の動機
AI機能強化路線 や 法的リスク への懸念
オランダ政府の選択や欧州の動向と論理的整合性
Forgejo のライセンス・ガバナンス・機能成熟度による安心感
今後も 自営・独立運用 を継続する計画

Hackerたちの意見

みんなGitHubから離れていって、gitの本来の精神を忘れてる気がする。gitは常に分散型であるべきだったのに、周りのツールがGitHubに集中しちゃったのが問題なんだよね。GitHubは使いやすくて、スケールも良くて、ちゃんとメンテナンスされてたからさ。自動同期されるミラーがGitHubに残っててほしいな。何年もプロジェクトを見てきたけど、自己ホスティングしたりニッチなところに行ったりして、GitHubのミラーが消えちゃうと、そういうプロジェクトがいつの間にか消えちゃうんだよね。みんなランダムなgitホスティングの代替を選んでるけど、中には本当に使いやすいものもある。gitは分散型だけど、GitHubはコードをホストできる場所の一つに過ぎない。複数のリモートサーバーにコードをプッシュできるんだよ。

└

Forgejoは、ツールを分散型にするためにたくさんの作業をしてるよ。オープンプロトコルやスタンダードを使って、自己ホスティングのフォージをつなげてるんだ。

└

そうだけど、GitHubは単なるgit以上のものだよ。みんなが忘れがちなのは、プラットフォームの最も重要な側面であるソーシャルコンポーネントだよね。オフサイトのリポジトリを作って、リポジトリ間でコラボレーションするのが簡単だったんだから。

└

問題追跡やCIのことを忘れてるんじゃない？

└

gitの精神を忘れてるわけじゃないけど、GitHubが「オープンリポジトリ」を使って最初のCopilotを誰にも言わずにトレーニングしたことも覚えてるから、もういいや。個人のコードはもうそこにはコミットしないよ。それに、ソーシャルな側面にも興味ないし。発見性、スター、AIボットによる問題の爆撃なんていらない。今のままで満足してる。あと、「オープンソースはあなたのためじゃない」ってことも忘れないで。

└

誰もそれを忘れてるわけじゃないと思うけど、ほとんどの人は分散化の部分にそこまでこだわってないよ。彼らが気にしてるのは、使いやすさや無料であること、企業向けに必要なエンタープライズ機能やSSOが揃っているかどうかなんだ。

└

それに同意する。Gitリポジトリを移すのは簡単だけど、プロジェクト全体を移すのは難しい。問題、リリース、CI、ドキュメント、セキュリティアドバイザリー、検索や発見性が時間とともにGitHubに結びついてしまうから。オープンソースプロジェクトには、自己ホスティングを真実の源として、読み取り専用のGitHubミラーを持つのがいいと思う。そうすれば、みんなが実際に見つけられるし。

└

GitHubは2つのことを中央集権化してるんだ。認証とリポジトリホスティング。コードをこんな中央の場所にホストする必要が本当にあるのかな？（明らかにないから、みんなGitHubを離れてるんだよね）でも、GitHubが提供してる本当に価値のある部分はソーシャル面なんだ。torvaldsって名前のユーザーからPRが来たら、これは確かにLinusだって信頼できるよね。もっと分散型のシステムではそうはいかない。だから、認証やアイデンティティを提供する役割を持つエンティティがあればいいなと思ってる。ForgejoやGitea、Gitlabのインスタンスはそれを使うことができるし、例えば他の貢献者を迎え入れたい時、その人が自分のForgejoインスタンスを持ってたら、このプロバイダーを通じて招待できる。そうすると、その人がリポジトリをフォークすると、自分のForgejoに入って、簡単にあなたのリポジトリにPRを作成できるんだ。

└

「Gitは分散型だから」って、ファイルシステムの一種だよね。でも、チームの運営はそうじゃない。それがGitHubのポイントなんだ。調整問題からは逃げられないよ！（メールやパッチ、他の非同期の方法を言うなら、それも同じこと、もっと複雑になるだけ）

しばらくの間、Forgejoを自己ホスティングしてるけど、維持と運用が驚くほど簡単なんだ。ぜひ試してみることをおすすめするよ。

「私が諦めたこと」のセクションで、著者が自分のソーシャルグラフについて言及してるよ。GitSocialを使えば、自分のソーシャルグラフやコラボレーションの履歴を持っていけるし、どんなgitホスト間でもクロスフォージのプルリクエストができるんだ。すべてサードパーティの依存なしでね。

└

今日は学びました。ありがとう！

Hacker Newsで議論の続きを見る

ハクソク