Forgejo: セルフホスト型の軽量ソフトウェアフォージ
(forgejo.org)- Forgejoは、開発プラットフォームを自分たちで運用したいチーム向けのセルフホスト型軽量ソフトウェアフォージで、インストールと保守の負担を下げることに重点を置いている
- Codeberg e.V.傘下のコミュニティが運営しており、プロジェクトと開発プロセスのいずれも自由ソフトウェアベースを維持している
- GitHubに慣れたユーザーが移行しやすい環境を提供しつつ、プラットフォームの所有権と協業の生産性をユーザー自身が直接コントロールできるよう設計されている
- 豊富な機能を提供しながらも低いサーバー要件を維持し、他のフォージより1桁少ない規模のリソースで済むとしている
- セキュリティ、拡張性、フェデレーション、プライバシー保護を中心に据え、分散型の協業開発を目指している
Forgejoの位置づけと運営方式
- Forgejoはセルフホスト型軽量ソフトウェアフォージで、自社サーバー上でソフトウェア開発プラットフォームを運用できるようにする
- インストールと保守が容易で、管理負担を低く抑えることを目標としている
- Codebergや他の公開インスタンスにアカウントを作ることも、直接ダウンロードしてセルフホストすることもできる
- 運営主体はCodeberg e.V.傘下のインクルーシブなコミュニティ
- Codeberg e.V.は民主的な非営利組織として紹介されている
- Forgejoは、専ら自由ソフトウェアとして信頼できるとしている
- プロダクトの焦点はセキュリティ、拡張性、フェデレーション、プライバシー保護にある
- 他のソフトウェアフォージとの違いは比較ページで確認できる
機能の方向性と参加できる領域
- Forgejoは、ソフトウェア開発プロセスのコントロールを取り戻し、プロジェクトをセルフホストし、参加者が質の高いソフトウェアの提供に共に集中できるよう支援することを目標としている
-
使いやすさと運用負担
- シンプルなプロジェクト管理を掲げ、協業と生産性のためのユーザー体験を重視している
- GitHubユーザーに馴染みのある環境を提供し、ユーザーが所有するプラットフォームへ移行できるようにする
- 専門的な技術がなくても自前のソフトウェアフォージを運用できるよう、インストールと保守の負担を減らしている
-
自由ソフトウェアと分散型協業
- 豊富な機能を提供しながらも、低いサーバープロファイルを維持している
- Forgejo自体とプロジェクトの開発プロセスのいずれも自由ソフトウェアを使用している
- 分散型プラットフォームを通じて、協業によるソフトウェア開発を可能にする方向性を示している
-
貢献できる領域
1件のコメント
Hacker News の意見
FAQ によると発音は forˈd͡ʒe.jo で、米国中西部式の耳には「4 Jay yo」のように聞こえる。Esperanto で Forge という意味らしい
Gitea のフォークだが、非営利で運営されており、プレミアム版へのアップセルなしで全て自由ライセンス（GPL）なのがよい。コミュニティでのやり取りが Matrix と Mastodon なのも気に入っている
Codeberg がこれを使っているようで、見た目は Gitea/GitHub のようだが問題ない。ソースコードは右上の小さなブランチアイコンから見られ、Codeberg にホストされている。今日知ったのは、Codeberg 自体が Forgejo インスタンスだということ
https://forgejo.org/2024-02-forking-forward/
https://v10.next.forgejo.org/explore/repos
https://codeberg.org/forgejo/forgejo
理解している限りでは、Gitea が企業からの依頼があればカスタム機能を作る会社を設立したためにフォークが生まれたのであって、ライセンスをひっくり返すような兆候が多かったわけではない
Fedora Projectがこちらへ移行中とのこと: https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/
Forgejo がなぜ Gitea から分岐したのか気になって調べてみたところ、またしても資金のない自由・オープンソースの作者／メンテナーが、上から、もしかすると下からもやられている事例のように見える。
Gitea の法人化発表を見ると、自由・オープンソースだけでは費用を賄えず、MIT ライセンスが許す裕福なフリーライダーたちがいたようだ。
「数年にわたり、メンテナーとプロジェクトを支援するために、バウンティ、直接スポンサー、助成金などさまざまな方法を試してきた。多くの素晴らしい個人と一部の企業は非常に寛大だったが、一部の企業は一部の国の GDP を上回る売上を上げながら、Gitea を中核製品に使い、改善を還元しなかった」というくだりが核心だ。
Bruce Perens が好きなわけではないが、「私たちには立派な企業福祉プログラムがあり、その利用者は世界で最も裕福な企業だ。逆に開発者は、そうした企業で働いていなければほとんど報酬を得られない」という言葉は、問題の本質を突いている。
一方で、創設者たちが会社を作るとコミュニティは反発したが、それは会社設立そのものよりも、その会社がドメインと商標を持っていたことが理由だったという。見た目には小さな理由のようだが、詳しい事情は分からない。
いずれにせよ、趣味開発者と FAANG の外では、FOSS が失敗する事例 #187のように見える。
自由ソフトウェアはもともと倫理運動であり、収益源を優先する必要はなかった。目的は持続可能な開発ではなく、ユーザーの自由だったからだ。「ユーザーはソフトウェアで望むことをする自由を持つべきだ」という言葉のどこにも、「そしてその倫理的目標のために働く数人の開発者に給料を払えるべきだ」とは書かれていない。
OSI 自身の歴史によれば、ある時点で人々はオープンな開発モデルがビジネスにも本質的に良いものだと考え始め、Netscape が加わり、一部の人々が集まって自由ソフトウェアをオープンソースとしてリブランディングした。
http://web.archive.org/web/20071115150105/https://opensource.org/history/
FOSS という言葉は、アメリカ式の企業仏教に似ているように感じる。マインドフルネスや瞑想が本来の深い宗教的文脈から切り離され、自己啓発プログラムになったように、もともとの実践者には認識しにくい形になっている。自由ソフトウェアとは、持続可能な開発ではなく、ユーザーの自由という正しいことを行うことに関するものだったし、残りはその目的のための手段だった。ところがある時点で手段が目的となり、FOSS がなぜ当然のように費用を負担してくれないのか不思議に思うようになった。
流れを正しく読んだのは GitLab だ。オープンソース方式で製品を提供しつつ運営費を賄う均衡点を見つけ、信頼と収益の両方を得たのだから、うまくやったと言える。
オープンソースの作業で生計を立てたいなら、ビジネスのように運営し、適切なビジネス上の仕組みを使うべきだ。そうでなければ、自分の努力がいつか自分自身への搾取のように跳ね返ってくる可能性がある。悪意を言っているのではないが、公正さはバランスの問題であり、一生懸命やった仕事が自分をきちんと扱えないなら、それも不公正だ。
ライセンスに追加のコピーレフト条件を入れることは拒みながら、結局は企業が善意でその条件があるかのように振る舞うことを期待するのは理解しがたい。
Google のような企業はパーミッシブライセンスを好み、toybox のように一般的な構成要素の MIT/BSD ライセンス代替品を支援することまでしている。
Forgejo v9 以降は実際に GPL ライセンスのようだ。
ビッグテック怪談は、オープンソースプロジェクトがライセンスをひっくり返すことを正当化するときには便利だが、ここには当てはまらない。たいていの場合もあまり筋が通らないが、この件ではメンテナー自身もそのような話をしたことはなさそうだ。
MongoDB、ElasticSearch、Redis のようなプロジェクトは、オープンソースだったから人気を得たのであり、無料と競争するのは難しいため、何年にもわたり競争も制限していた可能性が高い。そして後になってユーザーに背を向けたというわけだ。MongoDB 1.0 が商用製品だったら誰も使わなかっただろうから、彼らが稼いだ金もそもそもオープンソースだったから生まれたものだ。
Forgejoで興味深いのは、**Forge federation（フォージ連合）**の作業が進行中であること
https://codeberg.org/forgejo/forgejo/issues/59#issuecomment-1652830
理想的な世界ならGitHubやGitLabも連合をサポートするだろうが、おそらくそうはならなさそう
同じ問題領域の代替としては、P2P方式のhttps://radicle.xyz/のようなものがある
Forgejoインスタンス間の有用な連合は、OIDCといくつかのWebhookだけでも十分に解決できる。たとえば、インスタンス間のコラボレーション、フォーク、プルリクエストなど。ForgejoとMastodonの間の連合がなぜ必要なのか分からないし、それが何を意味するのかも曖昧
以前は2023年まで年次の進捗報告も出していたが、そのウェブサイトももうアクセスできないようだ: https://web.archive.org/web/20240830030315/https://forgefriends.org/blog/2023/06/21/2023-06-state-forge-federation/
それでも月次アップデートで連合が最後に言及されたのは10月で、そのとき連合はForgejoプロジェクトの「最優先事項」であり、今後もそうだと強調していた
https://forgejo.org/2024-10-monthly-update/#:~:text=Forgejo%20federation%20is%20and%20will%20always%20be%20the%20highest%20priority%20of%20the%20Forgejo%20project
Gitリポジトリをネットワークに公開するのはHTTPやSSHで非常に簡単で、メールベースのコードレビューの流れもサポートしている。ただ、git-appraiseのようにレビューをリポジトリ内に保存する方式はかなり気に入っている
https://github.com/google/git-appraise
CI/CDパイプラインもpushでトリガーできるなら、シンプルに統合できる。ところが私たちはGitの上に中央集権的なUIを作り、今度はそのUI同士を統合しようとしている。Gitがすでに分散化されていることを考えると、逆行しているように見える
関連内容: https://gitlab.com/groups/gitlab-org/-/epics/11247#why
今はセルフホストのForgejo、github.com、gitlab.comにまたがってミラーリングしていて、Forgejoインスタンスは必須インフラというよりセルフホスト趣味の一部になっている
GitLab Cellsも同じ方向に進む可能性がありそうで、設計文書に連合への言及がある
https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/cells/
数年かけて Gogs から Gitea へ、さらに Forgejo へ移ってきたが、本当に優れたソフトウェアだと思う。
90% の用途では、個人用 Git リポジトリを SSH サーバーに置くだけで十分。Chezmoi のリポジトリをすべてのコンピューターからアクセスできる場所に置きたい程度なら、Forgejo 系が大きく付け加えるものはない。
ただし残りの 10%、つまり何人かの友人とコードを非公開で共有したい場合には素晴らしい。GitHub の有料プランより無料のほうがいいし、どうせその 10% のプロジェクトのために動かすなら、残りも個人用の標準 Git リポジトリとして使ったほうがよい。
カンバンとコードエディタもある。
Gitea に変えたら息を吹き返し、Fedora がリポジトリサーバーとして Forgejo を選んだことで Forgejo が目に留まった。
自分の要件は単純で、ノートとソースコードの中央ファイルストア程度だ。Gitea 1.21 から Forgejo 9 への移行をテストしたが、摩擦はなかった。
真剣に移行を検討しているが、長期的にどちらがよりよくサポートされ、無料利用に適しているかはまだ悩んでいる。
正直、次の移行先は CI/CD 用の Forgejo Actions（https://forgejo.org/docs/next/user/actions/）を付けた Forgejo か、いっそ深い側に戻って Jenkins に戻る選択肢になりそうだ。
タグラインがあまり説明的ではない。メインページを 1、2 回スクロールして、ようやく目的、つまりセルフホスト型 GitHub 代替だと分かった。
ソフトウェアで「forge」という語は複数の意味に解釈できるので、もっと早い段階で明確に言ったほうがよさそうだ。
技術的には Redmine のような当時のシステムも forge と呼べたはずだが、その後この用語が定着したのだと思う。
参考: https://en.wikipedia.org/wiki/Forge_(software)
「forge」と聞くと、原材料を完成品に変える道具を思い浮かべる。たとえば鉄を馬蹄に変える鍛冶場の道具だ。
ソフトウェアの比喩なら、テキストのソースコードを実行可能なバイナリに変えるもの、つまりコンパイラやインタプリタのほうが合っている。
GitHub と SourceForge はソースコードをある場所から別の場所へ移す。比喩を無理に伸ばすなら、店と配送サービスの組み合わせに近い。ソースコードは移動するが、変形はしない。
だから古い C/C++ 開発者の立場からすると、forge がセルフホスト型 Git サーバーを指す用語なのはかなり奇妙に感じる。
GitLab CE を運用し続けようとして CPU とメモリを大量に食う問題に苦しんだあと、Forgejo に乗り換えたが、期待外れではなかった。
ルートレスコンテナで動いており、メモリと CPU をほとんど使わない。アップデートも
podman pull1 回でそのままうまくいく。今では Actions も動かして、Jekyll などを実行し、静的 Web サイトを継続的に更新している。
GitHub や GitLab のようなほかのフォージからリポジトリや Issue などを取り込める自分だけのフォージを持てるのは良いし、今後出てくる ActivityPub ベースのより広い Fediverse 統合にも期待している。
分散化されていながらつながったコードホスティングのアプローチは、ずっと望んでいたもので、今はほぼそこに到達した感じがする。
数年かけて GitHub → セルフホスト GitLab → Gitea → Forgejo と移ってきたが、後悔していない。
Forgejo は素晴らしく、フェデレーションが完成すればさらに良くなりそうだ。複数インスタンスにまたがる分散フォークとプルリクエストが可能になれば、セルフホストソリューションの断片化問題が解決する。
Gitea が VC 資金を背景に営利部門を作ったときに信頼を失い、まさにその理由で Forgejo にフォークされた。
GitLab から失った唯一のものは、組み込みの CI/CD プラットフォームだ。しかしパイプラインを Drone CI に移し、Webhook でトリガーできた。ただし GitLab パイプラインがどれほど複雑かによっては、常に可能な選択肢とは限らない。
いずれにせよ、小さなプロジェクトをいくつか動かすために RAM 5GB を食う GitLab サーバーをホストするのは嫌だった。Forgejo はピーク時でも RAM を 500MB 程度しか使わない。
コードレビュー体験がどんなものか気になる。Gitea と似ているのだろうと想像しているが、どちらも使ったことはない
最近 GitHub でかなり本格的なコードレビューをしてみたが、コードレビュー用ツールとしてはおもちゃ版に近かった。ソース管理モデル全体をそのツールに合わせて設計しない限り、本格的なエンジニアリング作業には使えなさそうで、そうすると履歴管理に影響するほかの要素が犠牲になる
主に Gerrit に慣れているが、基本モデルは合理的なものの粗い部分が多く、性能問題もある
ふと思うと、本当に気に入ったレビュー用ツールを使ったことがない気がする。業界はまともなツールなしで何とかしのいでいるだけなのでは、と思ってしまう
記憶では GitLab は GitHub より少し良かったが、詳しくは覚えていない
「Forgejo とは何か？」という質問に、「Forgejo はセルフホスト可能な軽量のソフトウェアフォージです。インストールが簡単で、メンテナンスの手間が少なく、やるべきことをこなします」と答えるようなものなのだろうか
もちろんすべてを英語に合わせる必要はないし、Esperanto だということだが、サイトのほかの部分はそうではないので、大半の人はそう解釈しないだろう