GitHubを離れてForgejoへ移行する
(jorijn.com)- GitHubを離れる直接のきっかけは2026年4月の障害ではなく、GitHub上で実行されるコードとワークフローの所有権の問題である
- GitHubは2025年8月以降、独自のCEOを持たずMicrosoftのCoreAI divisionに編入され、コードはMicrosoftのAI組織配下に置かれることになった
- Copilot Free、Pro、Pro+は2026年4月から、インタラクションデータがデフォルトで学習データに使われるオプトアウト方式へ変更された
- GitHubとMicrosoftは米国企業であるため、FISA 702とCLOUD Actの管轄下にあり、EUのdata residencyだけでは解決しない
- Forgejo v15 LTSはcode.jorijn.comの単一のNUCで運用されており、runnerはKVM、gVisor、週次リビルド、egress filterで隔離されている
GitHubを離れる理由は障害ではなく所有権の問題
- 2026年4月の障害は開発者にとって十分深刻だったが、GitHubを離れる中核的な理由は障害そのものではなく、GitHub上で実行されるコードとワークフローの所有権にある
- 2026年4月27日、オランダ内務省は政府ソースコード向けのセルフホストForgejoインスタンスであるcode.overheid.nlをソフトローンチした
- プロジェクトマネージャーのBoris Van Hoytemaは、省庁が法的にソースコードを「所有する場所」で公開しなければならないという要件から、このプラットフォームが始まったと述べた
- Forgejoは完全なオープンソースであり、デジタル主権に必要な自由を提供することから、GitLabより優先して選ばれた
- 個人コードのデフォルトGitホストもcode.jorijn.comへ移行しており、Forgejo v15 LTSが単一のNUCの強化構成上で動作している
- 一部のリポジトリはすでに移行済みで、残りは待機中である
- 移行が完了したら公開GitHubリポジトリをアーカイブし、各アーカイブから新しい場所を指す計画である
障害とAI負荷
- 2026年4月23日、merge queueのsquash-mergeコードパスが、機能フラグの不完全なロールアウト後に658件のリポジトリと2,092件のpull requestで、すでにマージされたコミットを静かに巻き戻した
- ModalやZiplineを含む企業が手動でデータを復旧した
- 4日後には過負荷状態のElasticsearchクラスターにより、Pull Requests、Issues、Packagesが6時間以上停止した
- 2026年2月の1か月だけで37件のインシデントが記録されており、Actions、Copilot Coding Agent、Code Review、CodeQL、Dependabot、Pagesが同時に停止した3時間40分の障害も含まれている
- 2025年10月1日には10時間のmacOS runner障害が発生した
- IncidentHubの集計では、2025年5月から2026年4月までの間にGitHubは257件のインシデントと48件の重大障害を記録し、総ダウンタイムは約112時間だった
- GitHub CTOのVlad Fedorovは4月28日に謝罪し、2025年12月以降の「agentic AI workflow growth」による負荷に追従するには、容量を30倍に増やす必要があると明らかにした
- 信頼性の問題はAI機能拡大の副次的な結果として解釈される
- GitHubはAI機能を遅らせるのではなく、さらに強く推し進めている
- The Pragmatic Engineerは、GitLab、Bitbucket、Vercel、Linear、Sentryは同じ年を経験していないと指摘している
- これらも開発者需要の圧力を受けているため、GitHubの障害パターンはGitHub固有の問題に見える
GitHubの組織変化
- 2025年8月11日、Thomas DohmkeがGitHub CEOを退任し、Microsoftは後任CEOを置かなかった
- GitHubはMicrosoftのCoreAI divisionに吸収された
- CoreAIは、Satya Nadellaが2025年1月に紹介した組織で、1st-partyおよび3rd-party顧客向けのend-to-end CopilotとAI stackの構築を目標としている
- GitHubの売上、エンジニアリング、サポートはJulia Liusonの下でMicrosoft developer divisionにレポートされる
- GitHub CPOはMicrosoft AI platform VPにレポートする
- ブランドは残るが、独立したリーダーシップは消えた
- 2018年から2024年までは、MicrosoftがGitHubをある程度距離を置いて運営していたという評価は実質的に正しかったが、2025年8月以降はその前提を維持しにくくなった
- 現在github.comにコードをpushすることは、MicrosoftのAI組織配下のユニットにコードをpushすることを意味する
Copilot学習データのデフォルト変更
- GitHubは2026年3月25日、4月24日から適用されるプライバシーステートメント変更を発表した
- Copilot Free、Pro、Pro+ユーザーのインタラクションデータ、とくに入力、出力、コード断片、関連コンテキストが、ユーザーが拒否しない限りAIモデルの学習と改善に使用される
- 中核的な変化は、opt-inではなくopt-outである点にある
- Copilot Free、Pro、Pro+ユーザーは、Copilot設定ページで無効にしない限りモデル学習に貢献することになる
- リポジトリ単位のブロックが存在しない
- 管理者は特定リポジトリ内のインタラクションを学習しないようGitHubに指定できない
- オプトアウトはユーザーアカウントごとの設定であるため、各コントリビューターが自分で選択しなければならない
- 結果として、Copilot Free/Pro/Pro+ユーザーがリポジトリを扱えば、ライセンスに関係なくコードベースが学習材料になり得る
- 非公開リポジトリの例外も限定的にしか適用されない
- GitHubは非公開リポジトリの「at rest」コンテンツは学習に使用しないと述べている
- しかし、非公開リポジトリ内でCopilotを使っている間に生成された「code snippets and interaction context」は収集する
- 「静止状態のコード」と「編集中に生成された断片」の境界は曖昧である
- Copilot BusinessとCopilot Enterpriseの顧客は、別個のData Protection Agreementsが適用されるため除外される
- 十分な費用を支払えばインタラクションは学習データにならず、そうでなければ学習データになる構造である
- GitHubのユーザーインタラクションデータに対する戦略的関心は、もはや選択的要素ではなく構造的要素になった
管轄権リスクはデータ所在地では解決しない
- GitHub Inc. と Microsoft Corp. は米国企業であり、これらが保有するデータは FISA Section 702 や 2018年のCLOUD Act を含む米国法の適用範囲に入る
- これら2つの法律は、データが物理的にどこにあるかに関係なく適用されうる
- Section 702 は 2024年4月に2年間再承認され、2026年4月末に署名された 45日間の延長 によって維持されている
- 米国内に所在する電子通信サービス提供者を通じて、非米国人を対象とした米国情報機関による収集を認める
- CLOUD Act は、米国に本社を置く企業に対し、世界のどこに保存されているデータであっても提出を強制できる
- GitHub は 2024年10月に Enterprise CloudのEU data residencyの一般提供 を発表した
- これはデータ所在地の問題には対処するが、管轄権の問題は解決しない
- CLOUD Act への露出は地理的位置ではなく、企業の支配構造に従う
- Microsoft 側の弁護士は 2025年6月のフランス上院公聴会で宣誓のうえ、欧州のMicrosoftデータセンターに保存されたフランスのデータが、秘匿された米国政府アクセスから安全だと保証できないと回答した
- コードが github.com にある限り、そのコードは米国の法的領域にある
- EU data residency は安心材料にはなりうるが、解決策ではない
オランダ政府の code.overheid.nl 選定
- オランダ政府の選択の法的背景には、2020年から施行されている「Open, tenzij」政策がある
- 公的資金で開発されたソフトウェアは、セキュリティや機密性が求められない限り、原則としてオープンソースになる
- これを順守するには、省庁が実際に管理できる場所にコード公開先が必要だった
- 欧州委員会は 2022年9月から、自前でホスティングするGitLabベースの code.europa.eu を運営している
- ドイツの openCode もGitLabベースである
- フランスの code.gouv.fr は独自forgeではなく、他所でホスティングされているリポジトリを索引するアグリゲーターである
- オランダ政府はGitLabではなく Forgejo を意図的に選んだ
- OSOR によれば、Forgejo が完全なオープンソースであり、open-core の分離がなく、デジタル主権に必要なあらゆる自由を提供する点が理由だった
- Van Hoytema は、Forgejo のロードマップが代替案よりも「way more aligned」していたと付け加えている
- オランダ政府は、単なる主権的な forge ではなく、商用ベンダーのプレミアムティアの背後に閉じ込められない主権的な forge を求めていた
- 政府も同じ問題構図を見て同じ決定を下しており、Forgejo の選択をもはや周辺的な選択と見るのは難しい
Forgejo を選んだ理由
- GitLab も真剣に検討された
- 自己ホスト型の GitLab CE はよく知られた選択肢であり、より大きな商用エコシステムと、より洗練された UI を備えている
-
ライセンス
- GitLab は open core モデルである
- Community Edition は MIT ライセンスだが、運用環境で望まれる多くの機能は非自由ライセンスの Enterprise tier にある
- Forgejo は逆方向に進んでいる
- 2024年8月の v9.0 から、MIT から GPLv3+ へと再ライセンスされた
- 明示的な目標は copyleft を維持し、コードベースの将来的な商業的囲い込みを防ぐことにある
- Forgejo が 2022年12月に Gitea からフォーク された理由も、Gitea Ltd がコミュニティの同意なしに商標とドメインを管理していたためだった
- その教訓がライセンス選択にも反映されている
- GitLab は open core モデルである
-
ガバナンス
- Forgejo は Codeberg e.V. の下にある
- Codeberg e.V. は 2018年9月からベルリンに登録されている非営利団体である
- 会員が選出した理事会、公開予算、ホスティングインスタンス上の 300,000 以上のリポジトリを持つ
- 会員は毎年予算に投票する
- 2025年計画は賛成 88 票、反対 0 票、棄権 1 票で承認された
- Forgejo は Codeberg e.V. の下にある
-
リリースと成熟度
- Forgejo v15.0 LTS は 2026年4月16日にリリース された
- プロジェクトの100回目のリリースである
- 長期サポートは 2027年7月15日まで続く
- Forgejo Actions は v15 で必要な水準に到達した
- ephemeral runner、OpenID Connect、reusable workflow expansion が含まれる
- フォーク以降のリリースは着実で、月次レポートも活発である
- Forgejo v15.0 LTS は 2026年4月16日にリリース された
-
商用エコシステムの限界
- Forgejo の商用エコシステムは存在するが、薄い
- 現時点で最も整った商用製品は Codey by VSHN である
- 2025年3月に Servala で公開された、スイスでホスティングされるマネージド Forgejo である
- 月額 19 CHF から始まる
- Red Hat 的なエンタープライズサポートのサブスクリプションはない
- 24時間365日の電話サポートと責任を負うベンダーが必要なら、自前で構築するか待つしかない
code.jorijn.com の構成
- code.jorijn.com はホームオフィスの単一の Intel NUC 上で動作している
- RAM は 64GB である
- Forgejo v15 LTS、Postgres 17、Traefik は Docker 内で動作する
- Incus 管理の KVM 仮想マシンが横で Forgejo Actions runner を実行する
- Forgejo、Postgres、reverse proxy の配置そのものより重要な判断は、runner の構成である
runner が最も危険な部分
- 自己ホスト型 forge において、forge 自体は簡単な部分であり、難しいのは CI ジョブを実行する環境である
- runner は毎日、Renovate のスケジュールに従って
npm install、composer install、pip installを実行しなければならない- 対象は自身のリポジトリで生成された lockfile である
- これは lifecycle script の実行を意味する
- あらゆるジョブが潜在的に信頼できないコードを実行しうる
- 最近の npm worm や axios サプライチェーン攻撃が、1時間以内に自動マージされる dependency bot を経由して移動したのと同じリスクがある
- runner の役割はコードを実行することではなく、実行中のコードを 隔離 することである
- 単一の防御層は失敗しうると想定し、次の層がその失敗を吸収するように設計されている
runner 防御レイヤー
-
永続的な KVM 仮想マシン
- runner はホストのコンテナではなく、別個の KVM VM 内にある
- ジョブ環境はホストカーネルを共有しない
- runner 内部の Linux カーネル CVE が NUC に到達するには、まず KVM 境界を破る必要がある
-
VM 内部のデフォルト Docker runtime として gVisor を使用
- ジョブコンテナは
runsc配下で実行される runscはシステムコールをホストカーネルへ直接渡さず、ユーザー空間で横取りする- コンテナ脱出には gVisor とその外側の KVM の両方を破る必要がある
- ジョブコンテナは
-
週次の破壊的リビルド
- 毎週月曜日 02:00 UTC に VM 全体を削除し、新しい Ubuntu base image から再作成する
- Forgejo 向けの新しい persistent runner registration も再発行される
- base image は日曜日にリビルドされるため、新しい VM にはその週の apt とカーネルパッチが反映される
- 永続状態が 7 日を超えて残ることはない
-
runner bridge の nftables egress filter
- runner は公開宛先の
:443、:80、:22、:53にアクセスできる- npm、pypi、ghcr、そして hairpin NAT 経由で公開ホスト名として到達する自身の Forgejo が対象
192.168.0.0/16、10.0.0.0/8、172.16.0.0/12にはアクセスできない- 侵害されたジョブは LAN をスキャンしたり、ルーターの管理インターフェースやホスト上の他のサービスにアクセスしたりできない
- runner は公開宛先の
-
スコープ制限付き runner token
- 2 つの persistent runner registration はそれぞれ単一ユーザースコープと単一組織スコープに結び付けられている
- 管理には
write:user,write:organizationPAT scope を使う - 流出したトークンではスコープ外に runner を登録できず、admin scope の操作もできない
- レイヤーは意図的に重なるよう構成されている
- 各レイヤーは柵であり、組み合わせることで多層防御の境界を作る
- KVM isolation、gVisor、週次リビルド、scope-bound runner registration はいずれも Forgejo と Incus が標準で支援する要素である
諦めたもの
-
発見性とソーシャルグラフ
- GitHub はコントリビューターがリポジトリを見つける場所である
- 公開リポジトリに小さな修正を送りたい人は、見知らぬドメインではなく github.com で作業できることを期待する
- 移行が完了したら、各公開 GitHub リポジトリをアーカイブし、README が code.jorijn.com を指すようにする予定である
- 発見経路は維持される
- 人々は引き続き GitHub でリポジトリを見つけ、アーカイブの案内を見た後で canonical home に移動する
- まだ完了しておらず、一部のリポジトリだけが code.jorijn.com にあり、残りは保留中である
-
GitHub Actions エコシステムとの脆い互換性
- Forgejo Actions は互換性ではなく、なじみやすさを目標にしている
- 大半は動作するが、一部は動作しない
- workflow レベルの
permissions:ブロックは黙って無視される actions/checkout@v6は 2026 年初頭に non-GitHub runner で authenticated checkout を壊したため、v5 に固定しているactions/upload-artifact@v4には Forgejo-hosted fork が必要である- OIDC は動作するが、GitHub の
permissions: id-token: writeではなく、enable-openid-connect: trueという別の workflow key を使う - workflow が GitHub 固有機能に強く依存しているなら、移行は一晩で終わる作業ではなくプロジェクトになる
-
Dependabot の不在
- Forgejo には Dependabot がない
- Renovate を同じセルフホスト runner で 3 時間おきに実行している
- 同じ役割は果たすが、設定項目が多く、構成には 1 日かかった
-
24/7 のベンダーサポート
- GitHub Enterprise は電話番号と SLA を提供する
- Forgejo は issue tracker と chat room を提供する
- 1 人運用には十分だが、200 人規模のエンジニア組織には十分でないかもしれない
移行する価値がない場合
- チームにインフラを運用する意思も能力もまったくないなら、セルフホストの Forgejo へ移行しないほうがよい
- マネージド Forgejo である Codey や、FOSS 向けの Codeberg はその差を大きく埋めてくれるが、移行コスト自体は依然として残る
- GitHub Apps marketplace、Codespaces、Copilot Workspace、Advanced Security のような GitHub 固有機能 に深く投資しているなら不向きである
- Forgejo は forge であって developer-platform-as-a-service ではない
- コントリビューターベースが GitHub のソーシャルグラフに依存しているなら、発見性のほうが所有権より重要かもしれない
- コントリビューターがいる場所にとどまるか、摩擦を受け入れて移行完了後に公開 GitHub リポジトリをアーカイブし、新しい場所を指すようにしてから後で再評価するという選択がある
- runner に対する信頼できる運用上の答えがないなら、移行は難しい
- ここが最も真剣に扱うべき領域である
- KVM isolation、gVisor、nftables、週次リビルドを検討する用意がないなら、CI ジョブはマネージド runner host で実行するか、GitHub に残るほうがよい
- オランダ政府でさえ、すべてを一度に移したわけではない
- code.overheid.nl は各省庁がオープンソースコードを共有するためのソフトローンチ版プラットフォームであり、使っているすべてを全面的に置き換えたわけではない
- code.jorijn.com の構成も同じ形である
- Forgejo が canonical host、GitHub が mirror であり、mirror は後で再評価できる
1件のコメント
Hacker Newsの意見
みんながGitHubを離れる中で、git本来の精神を忘れているように見える
gitはもともと分散化を意図していたのであって、問題はGitHubがより洗練され、スケールしやすく、管理もうまかったために、git周辺のツール群がすべてGitHubへ集中してしまったことにある
それでもGitHubに自動同期されるミラーは残っていてほしい。何年も、プロジェクトがセルフホストやニッチなホスティングへ移ったあと、GitHubミラーが死んだり削除されたりして、最終的にプロジェクトが時の中に消えていくのを見てきたからだ
gitは分散型であり、GitHubはコードを置ける場所のひとつにすぎず、複数のリモートサーバーへpushできる
だからもう個人のコードをそこへコミットするつもりはない
発見性やスター、AIボットが大量に投げてくるIssueのようなソーシャル機能にも興味はない。今の状態で十分だ
そして「Open Source is not about You」も覚えておくべきだ
みんなが忘れているこのプラットフォームの最も重要な側面はソーシャル要素であり、永続的な外部リポジトリを作れて、リポジトリ間の協業を非常に簡単にした点にある
セルフホストされたforge同士をつなぐために公開プロトコルと標準を使っている
本来想定されたメールパッチモデルで使ったことがある人はごく少数で、残りの大半は学ぼうとすらしない可能性が高い
人は基本的にGitHubを使うからgitを使うのであって、少し好意的に言っても、GitHubのような中央ホストと組み合わせたときにうまく機能するから使っている
ローカルでコードを書き、WebポータルでIssueやパッチを議論するモデルに惹かれているのであり、その中でgit自体が提供している部分は小さい
Issue、リリース、CI、ドキュメント、セキュリティ勧告、検索性と発見性は、時間が経つにつれてすべてGitHubに結び付けられていく傾向がある
オープンソースのプロジェクトなら、セルフホストを信頼できる唯一の情報源にしつつ、人々が実際に見つけられるよう読み取り専用のGitHubミラーを維持するのがよいと思う
本当にゲームチェンジャーになるのは、完成した連合サポートだ
だからForgejoとCodebergに寄付しているし、Forgejoチームがきちんと実装できるよう、みんなももっと時間とリソースを投じてほしい
もうひとつの有力候補は、Gitの上に完全分散型を構築するRadicleだ
https://codeberg.org/forgejo-contrib/federation/src/branch/m...
https://liberapay.com/forgejo
https://donate.codeberg.org/
https://radicle.dev/
https://radicle.network/nodes/seed.radicle.dev
自分のgitリポジトリもセルフホストのNUCへ移した
まだ外部公開用のHTTPフロントエンドは付けていない。AIスクレイパーにコンテンツを提供したくないし、それらをブロックする作業もしたくないからだ
オープンソースの恩恵を受けた企業が業界をこんなふうに汚染したのは恥ずべきことだ
3年間動き続けている。LAN内からしかアクセスできないように閉じてインターネットへ公開しなければ、堅牢で長持ちする使い心地だ
リポジトリは数週間は問題なくミラーされるが、その後止まる。期限のないPATトークンを入れているのに、期限切れだと主張してくるし、別の場所で試すとトークンは正常に動く
ログに何も出ないこともあれば、データベースがロックされているときもある。データベースを使っているのはForgejoだけだ
今のところ、これがForgejoの問題なのか、PiのひどいSDカードI/Oのせいでデータベースロックが起きているのか、Forgejoがミラー用途に向いていないのかを切り分けられていない
独占的な巨大クラウド企業はただ働きを手に入れ、それを使って追跡監視網、勝手にインストールできないスマートフォン、デバイス証明、広告ブロックのないブラウザ単一文化のような、私たちが嫌う世界を作っている
Googleは人々にBSD/MITを愛させ、その結果がどうなったかを見ればいい
典型的な手口のひとつは「それはもう我々のものだ」だ。ElasticsearchやRedisのようなものをベンダーが作ると、巨大クラウドが自社の独占商品として取り込み、利益をさらっていき、元の作者や会社は飢えることになる
もうひとつは「受け入れ、拡張し、抹殺する」だ。KHTMLやLinuxのようなオープンソースプロジェクトを取り込み、自分たちの版を作って市場にばらまき、競合を押しのけたうえで、反競争的な手段によって人々の目の前に自社製品を置き、シェアを取ったら追跡を仕込み、自由を奪う
オープンソースは「人には自由、企業は金を払う」に置き換えるべきだ。巨大クラウドに対抗できる牙を持ったソース公開シェアウェアが必要だ
Richard Stallmanのライセンスですら十分に強くなく、CC BY-NC-SAのほうがましだと思う
「純粋な」オープンソースは企業福祉であり、間違いだった。巨人たちに、私たちのロープで私たちを吊るせるようにしてしまった
自分のコードはAIにどんどん読んでほしい
記事の「What I gave up」の節で、著者は自分のソーシャルグラフに言及していたが、GitSocialを使えばソーシャルグラフと協業履歴を持ち運べる
どのgitホスト間でもforge間pull requestを可能にし、しかも完全にサードパーティ依存なしで動作する
だからこうした代替案はなかなか伸びない
「CTOが公開で謝罪し、AIベースの負荷に耐えるには容量を30倍にしなければならないと言った」というくだりを見ると、GitHubが通常利用に課金し始めないことを願う
だが、一部のバイブコーダーが1日に何千ものコミットを作っているのを見ると、だんだん懐疑的になってくる
コードを無料で共有して協業できなくなるなら、本当に残念だ
熟練者なら、リポジトリにこういう問題があると数秒で見抜けるので、調整済みのシステムも可能だろう
厄介なのは、バイブ割当量を適用できるような法的利用規約を書くことだ
AnthropicはすでにCCでそうしているし、GitHubやGitLabもたぶん似たようなことをするはずだ。その代償はTwitter開発者たちや小さなsubredditの一部から嫌われることだろうが、十分に受け入れられる範囲だと思う
一方で、/r/vibecodingのような場所で、人々が月200ドルのサブスク料金を払って、趣味プロジェクトやおもちゃサイトに近いものを作っているのをよく見ると、かなり驚かされる
余裕があるときにばかな出費をしたことはあるが、これは少し違って感じる
もしかすると、意味と目的を与えてくれるサービスに年2400ドル払っているのかもしれない。40代くらいになって、自分は金持ちにも有名人にもなれないと悟るなら、ほかの選択肢に比べて払える価格なのかもしれない
BlueskyのようにAT Protocol上に作られた分散型サービス、Tangledのことも聞いた
GitHubが実装を引き延ばしたせいで、その機能をGitHubに追加する会社まで現れた、pull requestの積み上げのような実際に便利な機能もある
使ったことのある人がいるのか気になる
https://tangled.org/
https://tangled.org/h14h.com/knot
全体として、このプラットフォームはかなり有望に見える。AtProtoが個人データサーバー、リレー、AppViewを分離するやり方は、適切な折衷案に思える
gitリポジトリをヘッドレスなデータ専用サーバーとしてホストできるので、セルフホストとしてはほとんど苦痛がない
ForgejoのようなActivityPubの解法と比べると、自分が気にしているのはデータの統制だけなので、Webアプリ全体をホストしてスケールさせる退屈さを避けられるのがいい
初期設定後の運用保守は、knot-serverのバージョンを上げて再デプロイしただけだ。tangled.orgが古いバージョンなら警告バナーを表示してくれる
他のプロジェクトでもTangledをもっと使って機能を試してみたい。特にjjとstacked PRのネイティブサポートに興味がある
カスタムCIをつなぐtackのような面白い実験もある
ATProtoが非公開データをサポートするようになれば、将来的には非公開リポジトリもサポートできるかもしれないが、少し時間はかかりそうだ
https://tangled.org/mitchellh.com/tack
まだビジネスモデルへの言及がないので、どうなるのか本当に気になる
その代わりradicle.xyzを使うほうがよい
Fossilも検討に値する
コード履歴、Wiki、チケット、フォーラムを含むリポジトリ全体の状態を単一ファイルにまとめ、その状態が複製される
ホスティング提供者を変えなければならないときでも、Fossilならそのせいで失われるデータはない
https://fossil-scm.org/
だが問題はネットワーク効果だ。チームをFossilへ連れていけない
チームは他の人や他部署とコードを共有しなければならず、みんな、実際99%以上がgitを使っている
Fossilを使えと強制するのは、むしろ害になる感じがして、板挟みだ
技術分野の他の多くのことと似ている。同僚の開発者に関数型スタイルのイディオムを使わせたり、不変性を強制しようとするときもそうだ
FacebookやGoogleのプロジェクトのような大きな何かが、コミュニティを強制的に動かさないといけないように感じる
しかし哲学的にはFossilは好きになれない。履歴を整理する方法がなく、すべてをそのまま保存する
それが望むものならよいが、自分のgitワークフローでは、あれこれ試したあと、pushする前にコミットを整理して構成し直すのが好きだ
人々は絶えず分散化を叫ぶ
だが現実には、ほとんどのシステムは結局中央集権化する
もしかすると人々が分散化を求めるとき、実際に探しているのは、自分たちが新たな開拓者になれる新しい中心なのかもしれない
既存のルールでは勝てる見込みがないと感じると、分散化を大義名分に盤面をひっくり返そうとしているように見える
人々がそれを望むのは、その単一の中央管理が何らかの理由で十分ではないからだ
人々が叫んでいることと、実際に望んでいることの間に違いはない
さらに悪いのは、中央集権型システムはたいていの時間は素晴らしく、痛みは合併や突然の値上げのように短期間で非常に強くやってくる点だ
分散化は常に少しずつ痛い代わりに、中央集権の代替が崩れるまれな瞬間に大きな幸福をもたらす
普通の言い方をすればボイコットだ。「お菓子がNestléにあまりにも集中しているから、お菓子を分散化しなければならない」とは言わない
Tangledへ移行中で、AT Protocol上に構築されているため、Blueskyなどと同じアカウントを使う
使ってみるとかなり気に入っている
https://vale.rocks/micros/20260511-0440
1年前からホームラボでセルフホストのGiteaへ移行し、公開アクセスは閉じている
HTTPSもなく、登録は無効化しており、リポジトリも公開していない
公開インスタンスを作ってHTTPSを使いつつ、攻撃面を最小化するべきか考えているが、特にGitea/Forgejo関連のおすすめが知りたい
ローカル登録を無効化するのが重要だ。自分の場合、authentikをIdPとして使っていて、tailnetからしかアクセスできない。あるいは自分のアカウントを作ってから登録を閉じればいい
robots.txtで、個別にレンダリングされたgitコミット表示のような一部をブロックしている。そうしないとスクレイパーが無限ループに陥る
Forgejoのパッケージリポジトリアクセスも厳格に禁止している。非公開パッケージがあり、その権限の粒度がまだ自分の望む水準ではないので調整中だ
引き続き監視しているが、今のところ大きな問題はない。詳しくはdocs.eblu.meにあり、望むならインフラコードにもそのまま案内できる
以前は内部インスタンスをミラーする公開の読み取り専用インスタンスを立て、内部から公開インスタンスへ向かうreverse proxy接続を1本だけ用意して、公開側がgitデータを取りに行けるようにしていた
その後はおおむね勝手にうまく回り、内部Forgejoで何か変えると公開側も更新された
IssueやCIなどは完全に非公開のままLAN内に置いておけた
それでもGiteaを使い続けている理由が気になる。今ではForgejoではなくGiteaをもう一度試すべきか迷っている