CodebergとSourceForgeの違いとは？脱GAFAMを目指す開発者におすすめのプラットフォーム

「GitHubで十分じゃないか？」――そう思っているなら、今この記事を読む価値は十分にある。
確かにGitHubは開発者のデファクトスタンダードだ。
だが、同時にMicrosoftという巨大企業の一部でもある。
オープンソースの精神を標榜しながら、そのプラットフォーム自体が閉鎖的なエコシステムへと変質しつつある現実を、あなたはどう捉えるか。

ここで浮上するのが、CodebergとSourceForgeという2つの代替プラットフォームだ。
どちらも「脱GAFAM」を掲げる開発者から注目を集めるが、その設計思想とターゲットは驚くほど異なる。
片やコミュニティ主導の軽量Gitホスティング、片や長い歴史を持つバイナリ配信の巨人。
この違いを理解せずに選べば、プロジェクトの成長を妨げかねない。

まず技術的な立ち位置から整理しよう。
Codebergは非営利団体が運営する、完全にオープンソースなForgejoをベースにしたプラットフォームだ。
APIはGitHub互換性が高く、CI/CDやIssueトラッキングも標準装備。
一方のSourceForgeは、SVNやMercurialもサポートするレガシーな柔軟性を持ち、特に大規模バイナリファイルのミラーリング体制が世界的に整備されている。

ここで両者の特徴を簡潔に比較する。

項目	Codeberg	SourceForge
主要リポジトリ	Git（Forgejo）	Git, SVN, Mercurial
ファイルサイズ制限	標準で~100MB	実質無制限（ミラー対応）
広告の有無	なし（寄付ベース）	あり（プロジェクトページに表示）
コミュニティ志向	ヨーロッパ中心の小規模コミュニティ	世界規模の旧来型ユーザーベース
CI/CD連携	Woodpecker等と親和性が高い	独自のビルドサービスは衰退傾向

重要なのは、「どちらが優れているか」ではなく「何を重視するか」 だ。
あなたが書くコードが軽量なWebアプリやライブラリで、コミュニティとの対話を大切にするなら、Codebergは理想的な環境を提供する。
UIも洗練され、プライベートリポジトリも無料だ。
しかし、ゲームのアセットや機械学習モデルなど、巨大なバイナリを配布する必要がある場合は、SourceForgeのグローバルミラー網が圧倒的に有利になる。
例えば、curl -L https://sourceforge.net/projects/yourproject/files/latest/download のようなワンライナーで世界中から高速ダウンロードを実現できる点は、無視できない強みだ。

ただし、SourceForgeには歴史的な経緯から「アドウェア問題」の汚名が残る。
現在は改善されたが、プロジェクトページに表示される広告や、インストーララッパーのオプトアウト仕様は、厳格なオープンソース推進派には受け入れられないだろう。
逆にCodebergは、哲学として「商業性の排除」を明確に打ち出しており、その純粋さゆえにスケーラビリティ面で未知数な部分もある。

結論を急ぐな。
まずは自分のプロジェクトのライフサイクルを書き出してみてほしい。
ソースコードのホスティングだけか、ユーザーへのリリース配信まで含むのか。
Issue管理の粒度はどの程度か。
外部コントリビューターのITリテラシーはどうか。
これらの問いに答えたとき、自ずと選ぶべきプラットフォームは見えてくるだろう。
脱GAFAMは単なるスローガンではなく、技術的選択の積み重ねだ。
その第一歩として、両者の違いを正しく理解すること。
それが、持続可能な開発環境への最短経路である。

なぜ今、GitHub代替なのか？――脱GAFAMの技術的・倫理的背景

2018年、MicrosoftによるGitHub買収は開発者コミュニティに衝撃を与えた。
当時は「オープンソースが守られるなら」という楽観論もあったが、時を経てその懸念は現実味を帯びている。
GitHub Copilotのトレーニングデータにパブリックリポジトリが無断利用された問題、サーバーダウン時のサポート遅延、そして何より単一企業への依存構造――これらは開発者のみならず、プロジェクトオーナーにとって無視できないリスク因子だ。

技術的依存がもたらすベンダーロックインの実態

GitHubは便利だ。
Pull Requestのワークフロー、ActionsによるCI/CD、Dependabotの自動更新。
しかし、これらの機能は全てGitHub独自のAPIとクローズドな実装に依存している。
つまり、一度GitHubを軸に開発フローを構築すると、移行コストが非常に高くなる。
特に、Issueのラベル体系やプロジェクトボードのカスタマイズ、シークレット管理の仕組みは、他プラットフォームへのエクスポートが容易ではない。

これを「便利な檻」と呼ぶのは過剰評価かもしれない。
だが、少なくとも技術的負債の一種として認識すべきだ。
オープンソースのプロジェクトであればなおさら、ホスティング基盤もオープンであることが理想ではないか。
Codebergが採用するForgejoは、GitHubのAPIとある程度互換性を持ちつつも、完全にフォーク可能なオープンソース実装である。
この違いは、長期的なプロジェクト継続性において決定的な差を生む。

倫理的観点――データ所有権と広告モデルの是非

もう一つ見過ごせないのが、データの帰属という問題だ。
GitHubはユーザーの行動ログ、コードメタデータ、コミットパターンを解析し、製品改善や営業資料に利用している。
利用規約上は「ユーザーに帰属する」と謳われていても、実際のデータ活用範囲は曖昧だ。
SourceForgeも広告表示をビジネスモデルとするが、それはプロジェクトページ上のバナーという明確な形で可視化されている。
対して、GitHubのデータ収集はブラックボックス化している点が、倫理的にはより深刻である。

また、特定の政治的・経済的圧力がGAFAMにかかった場合、サービス内容が一方的に変更されるリスクも考慮すべきだろう。
実際に、ロシアの開発者に対する一部サービス制限や、米国輸出規制への即時対応事例は、グローバルなオープンソースコミュニティが多国籍企業の判断に左右される脆弱性を露呈した。

コスト構造と長期的なプロジェクト持続性

無料プランが魅力的なのは承知している。
しかし、オープンソースプロジェクトが成長し、CIの実行時間やストレージ容量が増えると、GitHubの有料プランへの移行は避けられない。
その金額は月額数ドルから始まるが、大規模なプロジェクトでは年間数百ドルに達する。
一方、Codebergは非営利で運営され、寄付ベースながら無料プランの制限が非常に緩やかだ。
SourceForgeに至っては、プロジェクトページに広告を掲載することで、開発者自身が収益を得る仕組みも提供している。

重要なのは、コストを「今だけ」で見ないことだ。
10年単位で運用するライブラリやフレームワークの場合、ホスティング基板の変更コストは累積運用コストを上回る。
脱GAFAMは単なる思想ではなく、リスク分散戦略としても合理的なのである。

コミュニティの多様性と発展可能性

最後に、プラットフォームが育むコミュニティの質にも目を向けたい。
GitHubは巨大であるがゆえに、ノイズも多い。
スパム的なIssueや低品質なPull Requestが散見されるのも事実だ。
Codebergはまだ小規模だが、その分、真摯な議論や技術的な深掘りが行われやすい空気がある。
SourceForgeは古参のプロジェクトが多いため、安定性と実績を重視する開発者には心強い。

つまり、今まさに選択肢を再評価するタイミングだ。
「みんなが使っているから」という理由でGitHubを選び続けることは、もはや技術的に賢明とは言えない。
自分のプロジェクトの規模、目的、価値観に照らし合わせて、プラットフォームを選ぶ時代が来ている。
その第一歩として、CodebergとSourceForgeという2つの対照的な選択肢を、次章以降で徹底的に比較していこう。

Codebergとは？――Forgejoが支える非営利のGitホスティング

Codebergは、ドイツの非営利団体「Codeberg e.V.」が運営する、完全にオープンソースなGitホスティングサービスです。
その核心には、Giteaからフォークされた「Forgejo」というソフトウェアが存在します。
Forgejoは、軽量性とパフォーマンスを重視しながらも、GitHubと遜色ない機能セットを備えている点が最大の特徴です。
単なる「代替品」ではなく、むしろ「オープンなエコシステムの先駆け」と位置付けるべきでしょう。

アーキテクチャの概要――Forgejoが選ばれる理由

ForgejoはGo言語で記述されており、単一バイナリとして動作します。
この設計は、リソースが限られたVPSやオンプレミス環境でも快適に動作することを意味します。
実際、Codeberg本体もそれほど強力なサーバーで運用されているわけではなく、それでも数十万のリポジトリと多数のアクティブユーザーを捌けているのは、このアーキテクチャの効率性によるところが大きいです。

加えて、ForgejoはActivityPubプロトコルの実験的サポートを進めています。
これは連合型ソーシャルネットワーク（いわゆるFediverse）との連携を見据えたもので、将来的には異なるForgejoインスタンス間でIssueやPull Requestをやり取りできる可能性を秘めています。
この分散型のビジョンは、脱GAFAMの理念と完全に合致するものです。

機能セット――GitHub互換でありながら独自の強み

Codebergが提供する主要機能を列挙してみましょう。

• Gitリポジトリ（公開・非公開ともに無料、無制限）
• Issueトラッキング（ラベル、マイルストーン、アサイン機能付き）
• Pull Request（コードレビューと差分表示に対応）
• Wiki（プロジェクト文書のホスティング）
• プロジェクトボード（カンバン形式のタスク管理）
• Webエディタ（ブラウザ上での簡単なファイル編集）
• リリース機能（タグ付けとアーカイブ配布）

これらの機能だけ見れば、GitHubのサブセットに過ぎないと感じるかもしれません。
しかし、重要なのはその実装が全てオープンソースであり、自己ホストが可能だという点です。
つまり、Codebergが万一サービスを終了しても、あなたのプロジェクトデータと運用ノウハウはそのまま別のForgejoインスタンスに移せる。
ベンダーロックインが本質的に存在しない構造は、長期的な視点では非常に大きなアドバンテージです。

非営利モデルと資金調達の透明性

Codeberg e.V.は寄付とスポンサーシップで運営されています。
その財務報告は公開されており、サーバー費用や開発者への報酬が明確に開示されています。
この透明性は、商用サービスではまず得られない安心感です。
寄付はPayPalやクレジットカード、さらには暗号資産でも受け付けており、個人開発者から企業まで幅広い支援の受け皿を用意しています。

一方で、無料であるがゆえの制約も存在します。
CI/CDパイプラインの実行時間やストレージ容量に緩やかな上限が設けられており、大規模なビルドを頻繁に実行するプロジェクトでは、外部のCIサービス（例：WoodpeckerやJenkins）と併用する必要が出てくるでしょう。
ただし、これは設計上のトレードオフであり、非営利団体が持続可能性を保つための合理的な判断です。

利用シーンと導入のハードル

Codebergは特に以下のようなプロジェクトに適しています。

• 個人のオープンソースライブラリやユーティリティ
• 小〜中規模のWebアプリケーション
• 教育目的のサンプルコードや教材リポジトリ
• コミュニティ主導のドキュメントプロジェクト

また、GitHubからの移行も比較的容易です。
ForgejoはGitHub APIと一部互換性があるため、既存のIssueやPull Requestをエクスポートするツールもコミュニティで整備されつつあります。
例えば、ghコマンドラインクライアントを利用した移行スクリプトや、git push --mirrorによるリポジトリ転送は、ほぼそのまま活用できます。

気になるのはユーザーインターフェースの使い勝手でしょう。
実際にCodebergのダッシュボードは、GitHubよりはシンプルで、ややGiteaやGitLabに近い雰囲気です。
しかし、慣れの問題であり、特にGitに精通した開発者であれば、数時間の操作で十分に使いこなせるはずです。
何より、広告が一切表示されないクリーンな画面は、開発に集中する環境として優れています。

最後に、Codebergはまだ成長途上です。
ユーザー数は増加傾向にあり、コミュニティも活発ですが、GitHubほどの巨大なエコシステム（サードパーティツールやインテグレーション）は期待できません。
とはいえ、それは「足りない」のではなく、「これから作っていける」と捉えることもできます。
実際、Forgejoのプラグイン機構やWebhook機能を使えば、SlackやDiscord、Mastodonとの連携も自在です。

つまり、Codebergは理念と実装が一致したプラットフォームであり、オープンソースの精神を大切にする開発者にとって、非常に魅力的な選択肢の一つと言えます。
次の章では、対照的なSourceForgeの特徴を詳しく見ていきましょう。

SourceForgeの現在地――レガシーから進化する大規模配信の巨人

SourceForgeは、1999年の創設以来、オープンソースプロジェクトのホスティングにおいて最古参のプラットフォームです。
かつてはSourceForge.netという名称で知られ、Linuxディストリビューションのミラーサイトとしても機能してきました。
現在は「SourceForge」としてブランドを再編し、開発者向けの総合プラットフォームへと進化を遂げています。
その最大の特徴は、世界中に分散したリレーショナルミラーシステムにあります。
これは、大規模バイナリファイルやインストーラパッケージの配信において、他を圧倒する強みです。

ミラーリングインフラの構造と地理的優位性

SourceForgeが運用するミラーネットワークは、北米、欧州、アジア、オセアニアにまたがる数十台のサーバーで構成されています。
アップロードされたファイルはこれらのミラーに自動同期され、ユーザーは自身の地理的位置から最も近いミラーからダウンロードできます。
この仕組みにより、例えば日本のユーザーが米国東海岸のサーバーからダウンロードするようなレイテンシ問題が解消されます。

具体的には、rsyncプロトコルを利用したバックエンド同期と、フロントエンドでの地理的負荷分散が組み合わされています。
開発者がプロジェクトページで「Download」ボタンを押すと、内部的には以下のようなリダイレクトチェーンが動作します。

https://sourceforge.net/projects/yourproject/files/latest/download
  → https://downloads.sourceforge.net/yourproject/yourfile.tar.gz
  → https://jaist.dl.sourceforge.net/yourproject/yourfile.tar.gz

この最後のミラーホスト名が、ユーザーのIPアドレスに基づいて動的に選択されるわけです。
このインフラは、1ファイルあたり数GBを超えるデータでも安定して配信できる実績を持っており、ゲームのアセットパックや機械学習のデータセット、大規模なフレームワークのバイナリディストリビューションに向いています。

サポートするバージョン管理システムの多様性

CodebergがGit専用であるのに対し、SourceForgeはGitに加えてSVN（Subversion）とMercurialを公式にサポートしています。
これは歴史的な経緯が大きく、2000年代から2010年代にかけてSVNが主流だった時代のプロジェクトが今も多数ホストされているからです。
例えば、古くからあるC言語のライブラリや、Perl製のシステム管理ツール群は、今でもSVNリポジトリで運用されています。

この多様性は、レガシープロジェクトの移行コストを大幅に削減します。
SVNからGitへの移行は理論上可能ですが、コミット履歴の変換やブランチモデルの再設計には手間がかかります。
SourceForgeはそうしたプロジェクトに対して「そのままの形でホスティングを継続できる」という選択肢を提供しているわけです。
また、Mercurialを採用しているプロジェクトも、特にPythonコミュニティの一部で根強く支持されており、それらも受け入れています。

広告モデルと開発者収益化の仕組み

SourceForgeのビジネスモデルは、プロジェクトページに掲載される広告収入が中心です。
この点はCodebergの非営利モデルと真っ向から対立しますが、SourceForgeはその代わりに開発者への収益還元プログラムを用意しています。
具体的には、プロジェクトのダウンロード数やページビューに応じて、運営側から開発者へ一定割合の広告収益が分配される仕組みです。

これは、オープンソース開発を持続可能にする一つの現実的な解として評価できます。
ただし、広告の表示形態はプロジェクトオーナーがある程度コントロール可能で、オプトアウトも選択できます。
ただしオプトアウトすると、そのプロジェクトは検索ランキングで下方に表示される傾向があるため、トレードオフが存在します。
「無料である代わりに広告が表示される」という旧来のWebサービスモデルを、開発者自身が受け入れるかどうかが判断の分かれ目です。

過去の汚名と現在の改善点

SourceForgeには、2010年代半ばに問題となった「アドウェアバンドル」の歴史があります。
当時、SourceForgeは一部のプロジェクトのインストーラに不要なツールバーやアドウェアを同梱するプログラムを実施しており、コミュニティから大きな批判を浴びました。
この出来事は現在では改善され、そのような行為は公式に廃止されていますが、未だに一部の開発者の間で「信頼できない」というレッテルが残っているのも事実です。

しかし、現在のSourceForgeはこの教訓を踏まえ、透明性を高める方向に舵を切っています。
ダウンロードページにはファイルのチェックサム（SHA-256）が明示され、ミラーサーバーのステータスもリアルタイムで公開されています。
また、スパムや悪意のあるプロジェクトの監視体制も強化されており、セキュリティ面での改善は顕著です。

現代的ユースケースと適したプロジェクト像

SourceForgeは、以下のようなシーンで真価を発揮します。

• 大容量バイナリ（数百MB〜数GB）を配布するゲームやシミュレータ
• オフラインインストーラやISOイメージを提供するOSディストリビューション
• 複数のバージョン管理システムを混在させたい研究開発プロジェクト
• 広告収益を開発資金に充てたい個人開発者や小規模チーム

また、SourceForgeはプロジェクトの分析ダッシュボードも充実しており、ダウンロード数の国別集計や、OS別・ブラウザ別のアクセス解析が視覚的に確認できます。
このデータは、リリース戦略やマーケティング施策に活用できるため、ビジネス寄りの開発者にとっては大きな付加価値です。

一方で、コードレビューの洗練度やIssue管理の柔軟性では、CodebergやGitHubに一歩譲る部分も否めません。
しかし、SourceForgeは「配信インフラ」としての特化が明確であり、その領域では現在でも業界トップクラスの実力を保持しています。
次章では、リポジトリ管理という観点から両者をさらに詳細に比較していきます。

リポジトリ管理の比較――Git/SVN/バイナリ、それぞれの得意分野

リポジトリ管理は、プラットフォーム選択において最も根幹を成す要素です。
CodebergとSourceForgeは、この点でまったく異なる設計哲学を持っています。
CodebergはGitに特化し、モダンな分散バージョン管理のメリットを最大限に引き出すことに注力しています。
一方、SourceForgeは複数VCS（バージョン管理システム）のサポートとバイナリ配信インフラという2つの柱で成り立っています。
ここでは、それぞれの得意分野を技術的な観点から掘り下げます。

Gitリポジトリのパフォーマンスと機能差

両プラットフォームともにGitリポジトリのホスティングは可能ですが、その内部実装に違いがあります。
CodebergのForgejoは、Git自体のネイティブ操作に加えて、Git LFS（Large File Storage）をサポートしています。
ただし、LFSのストレージ容量には制限があり、大規模なバイナリファイルを頻繁に更新するプロジェクトでは有料プラン相当の寄付が推奨されます。

対照的に、SourceForgeはGitリポジトリそのものよりも、リリース単位でのバイナリ添付に強みを持ちます。
つまり、ソースコードはGitで管理しつつ、ビルド成果物やデータセットはSourceForgeのファイルリリース機能で配布するというハイブリッド運用が効果的です。
この場合、リポジトリサイズは軽量に保ちながら、ユーザーには大容量ファイルを高速に届けられます。

項目	Codeberg（Git）	SourceForge（Git）	SourceForge（リリースファイル）
最大ファイルサイズ	~100MB（LFSで拡張可）	~100MB（標準）	実質無制限（ミラー対応）
バージョン履歴管理	完全なGit履歴	完全なGit履歴	タグベースのスナップショット
配信帯域	中程度（非営利）	中程度	高帯域（グローバルミラー）
アクセス制御	チーム・組織単位	チーム・組織単位	公開/非公開選択可

この表から分かるように、バイナリ配信に関してはSourceForgeに軍配が上がります。
ただし、Git自体の操作感やブランチ戦略の柔軟性ではCodebergも遜色なく、特にWebフックやAPIを介した自動化ではCodebergの方がシンプルに実装できるケースが多いです。

SVNとMercurial――レガシーシステムの現在価値

SourceForgeが今なおSVNとMercurialをサポートする理由は、既存プロジェクトの継続性にあります。
例えば、Apache FoundationやGNOMEプロジェクトの一部は長年にわたりSVNを使用してきました。
これらのプロジェクトをGitに移行することは技術的に可能ですが、コミットIDの変更やタグ構造の再構築など、運用コストが膨大になるケースがあります。

また、SVNには単一リポジトリ内での部分チェックアウト（sparse checkout）という特徴があり、巨大なモノレポの一部だけを扱いたい場合に便利です。
Gitでもsparse checkoutは実装されていますが、SVNの方が歴史的に安定しており、特にC++やJavaの大規模プロジェクトでは今でも採用例が見られます。

Mercurialについては、Pythonで記述された拡張機能の豊富さが魅力で、特にFacebook（現Meta）がかつて大規模に利用していたことでも知られています。
SourceForgeはこれらのVCSに対してWebベースのブラウジングインターフェースとコミット単位の差分表示を提供しており、レガシープロジェクトのメンテナンスを続ける開発者にとっては貴重な環境です。

バイナリ配信に特化した設計思想

SourceForgeの真骨頂は、リポジトリとは独立したファイルリリースシステムにあります。
このシステムでは、開発者がアップロードしたバイナリに対して自動的にチェックサム（MD5、SHA-1、SHA-256）が生成され、ダウンロードページに明示されます。
また、過去の全リリースバージョンがアーカイブとして保存されるため、ユーザーは任意のバージョンにロールバックできます。

さらに、SourceForgeはダウンロード統計をリアルタイムで集計し、プロジェクトオーナーに詳細なレポートを提供します。
このデータは、どのOS向けのビルドが多くダウンロードされているか、どの地域からのアクセスが集中しているかといったマーケティング指標として活用可能です。
Codebergにもリリース機能は存在しますが、統計情報は非常に基本的なものに留まります。

一方で、SourceForgeのバイナリ配信は公開リポジトリが前提であり、非公開のバイナリ配信には向いていません。
その点、Codebergは非公開リポジトリでもリリース機能を使えるため、クローズドな開発フェーズでの利用に柔軟性があります。

コード例で見る両プラットフォームの取得方法

Gitリポジトリのクローンは両者でほとんど変わりません。

# Codebergの場合
git clone https://codeberg.org/ユーザー名/プロジェクト名.git

# SourceForge（Git）の場合
git clone https://git.code.sf.net/p/プロジェクト名/code

しかし、SourceForgeのバイナリをコマンドラインで取得する場合は、次のようにミラーを意識したURL指定が有効です。

# SourceForgeの最新リリースバイナリを取得（ミラー自動選択）
curl -L -O https://sourceforge.net/projects/プロジェクト名/files/latest/download

この違いは、単なる表記の差ではなく、配信インフラの設計思想の差を如実に表しています。
Codebergは「コードの管理」に徹し、SourceForgeは「コード＋成果物の配信」をトータルで提供する。
この明確な棲み分けを理解した上で、次の章ではCI/CDやIssueトラッキングといった開発フロー全体に視野を広げて比較を続けます。

CI/CDとIssueトラッキング――開発フローに直結する機能差

バージョン管理だけがプラットフォームの価値ではありません。
現代のソフトウェア開発において、CI/CD（継続的インテグレーション／継続的デリバリー）とIssueトラッキングは、チームの生産性を左右する重要な要素です。
CodebergとSourceForgeは、これらの機能に対してまったく異なるアプローチを取っています。
ここでは、それぞれの実装方式と実用的なメリット・デメリットを徹底比較します。

CodebergのCI/CD――Woodpeckerとの親和性が生む柔軟性

Codebergは独自のCI/CDサービスを内蔵しておらず、代わりにサードパーティ製CIツールとの連携を前提としています。
特に推奨されているのがWoodpecker CIです。
Woodpeckerは、Drone CIからフォークされたオープンソースのCI/CDプラットフォームで、CodebergのForgejoと非常に相性が良いことで知られています。

Woodpeckerの特徴は、パイプライン定義をリポジトリ内の.woodpecker.ymlファイルで管理する点です。
このファイルには、ビルド手順、テスト実行、デプロイメントジョブをYAML形式で記述します。
以下に簡単な例を示します。

pipeline:
  build:
    image: golang:1.21
    commands:
      - go build -o myapp ./...
  test:
    image: golang:1.21
    commands:
      - go test -v ./...
  deploy:
    image: alpine
    commands:
      - scp myapp user@server:/app/
    when:
      branch: main

このワークフローは、コードのプッシュやPull Requestの作成をトリガーとして自動実行されます。
CodebergはWebhookを介してWoodpeckerインスタンスと通信するため、CIサーバーを自分でホストするか、公共のWoodpeckerインスタンスを利用する必要があります。
この点は、GitHub Actionsのように統合された環境に慣れた開発者には手間に感じるかもしれません。

しかし、この「分離アーキテクチャ」には大きな利点もあります。
それは、CI実行環境を完全に制御できることです。
特定のGPUドライバや専用ライブラリが必要なプロジェクトでも、自分でセットアップしたWoodpeckerランナーを使えば制約なくビルドできます。
また、実行時間や並列度の上限も実質的に自分で決められるため、大規模なテストスイートを持つプロジェクトにも対応可能です。

SourceForgeのCI/CD――ビルドサービスは縮小傾向、外部連携が現実解

SourceForgeは過去に「SourceForge Build Service」という独自のCI環境を提供していましたが、現在は公式には積極的に推進されていません。
代わりに、GitHub ActionsやGitLab CI、Jenkinsといった外部CIサービスと連携し、ビルド成果物をSourceForgeのリリース機能にアップロードする運用が一般的です。

このアプローチのメリットは、既存のCIノウハウをそのまま流用できることです。
例えば、GitHub Actionsでテストとビルドを実行し、最後のステップでcurlを使ってSourceForgeにバイナリをアップロードするスクリプトを組めば、ハイブリッドな配信パイプラインが成立します。
SourceForgeはアップロード用のAPIキーを発行できるため、自動化スクリプトからのファイル投稿がセキュアに行えます。

一方で、この方式はCIとリリースが分断されるため、パイプライン全体の可観測性が低下する欠点もあります。
ビルドログと配信ログが別々のダッシュボードで管理されるため、障害発生時の原因特定に余計な手間がかかるでしょう。

Issueトラッキング――Codebergの柔軟性とSourceForgeの伝統的アプローチ

CodebergのIssueトラッキングは、GitHubユーザーにはほとんど違和感なく受け入れられるでしょう。
ラベル、マイルストーン、アサイン機能はもちろん、Issueテンプレートのサポートや、クローズドIssueの再オープンといった基本的なワークフローも備わっています。
さらに、Pull RequestとIssueを連携させて、特定のPRでIssueを自動クローズするキーワード（Closes #123など）も有効です。

特に評価すべきは、カスタムラベルの作成と色分けが非常に直感的である点です。
プロジェクトの進行状況に合わせて「バグ」「機能要望」「ドキュメント」「質問」などのラベルを自由に定義でき、フィルタリングも高速です。
また、マイルストーン単位での進捗バー表示は、リリース計画の可視化に役立ちます。

SourceForgeのIssueトラッカーは、よりクラシックな設計です。
チケット番号、タイトル、説明、カテゴリ、優先度、担当者という基本項目に加えて、カスタムフィールドを追加できる点が特徴です。
例えば、「再現手順」「対象ブラウザ」「影響バージョン」といった独自の項目をチケットに持たせることが可能です。
これは、QAプロセスが厳格に定義されたプロジェクトでは非常に重宝します。

ただし、UIのモダンさや検索機能のレスポンスではCodebergに分があります。
SourceForgeのチケット検索は多少クセがあり、高度なクエリを組むには専用の構文を覚える必要があります。
また、Pull RequestとIssueの連携は、SourceForgeではGitリポジトリとトラッカーが別システムとして動作するため、自動クローズ機能は標準では提供されていません。

機能	Codeberg	SourceForge
Issueテンプレート	あり（YAML/Markdown）	なし（自由記述形式）
ラベル管理	色分け＋フィルタリング充実	カテゴリベースの簡易管理
マイルストーン	進捗バー表示、期日設定可	期日設定のみ
PR×Issue連携	キーワードで自動クローズ可	手動リンクが必要
カスタムフィールド	なし	あり（拡張性が高い）

開発フロー全体のまとめ――使い分けのポイント

CI/CDとIssueトラッキングを総合すると、Codebergはアジャイル開発志向のチームに向いていると言えます。
軽快なIssue管理と外部CIとの連携により、スピード感のあるイテレーションが可能です。
一方、SourceForgeはウォーターフォールに近い計画駆動型や、厳格な品質管理プロセスを持つプロジェクトに適しています。
カスタムフィールドによる詳細なチケット追跡は、エンタープライズ的な運用にマッチするでしょう。

また、CI実行環境を自前でホストできるかどうかも重要な判断基準です。
Codebergの方式は自由度が高い反面、運用負荷が増えます。
SourceForgeの方式は既存CIとの連携が楽ですが、配信まで含めた統合感は薄れます。
このトレードオフを理解した上で、次の章ではコミュニティやガバナンスといった、より社会的な側面を検討していきます。

コミュニティとガバナンス――運営体制がプロジェクトに与える影響

プラットフォームの技術仕様も重要ですが、それを支える運営組織とコミュニティの在り方は、長期的なプロジェクトの健全性に直結します。
CodebergとSourceForgeは、この点で対照的なガバナンスモデルを採用しています。
ここでは、運営主体の構造、意思決定プロセス、そしてそれが開発者コミュニティに及ぼす影響を、多角的に検証します。

Codeberg e.V.――非営利協会がもたらす透明性と持続可能性

Codebergは、ドイツの法律に基づく登録非営利協会（e.V.） によって運営されています。
この法人形態は、利益を構成員に分配せず、全ての収益をサービスの維持・改善に再投資することを義務付けられています。
理事会は公開選挙で選出され、その議事録や財務諸表はWebサイトで誰でも閲覧可能です。

この透明性は、開発者にとって「突然のサービス終了や有料化」というリスクを劇的に低減します。
非営利団体が解散する場合でも、資産は他の非営利団体に譲渡されることが定款で定められており、ユーザーデータが買収先に悪用される可能性はほぼありません。
また、意思決定がボランティアベースで行われるため、商用サービスに見られる「株主価値優先」のバイアスが働きにくい構造です。

コミュニティ面では、Codebergは穏やかではあるが活発な議論文化を持っています。
MatrixやMastodon上の公式チャンネルでは、機能リクエストやバグ報告に対して開発者が直接レスポンスするケースが多く、特にヨーロッパ時間帯ではほぼリアルタイムのやり取りが期待できます。
とはいえ、ユーザー数がGitHubの1%にも満たないため、質問への回答が数時間かかることも珍しくありません。
この「規模の小ささ」は、親密さと引き換えにしたトレードオフと捉えるべきでしょう。

SourceForgeの企業運営――商業ベースがもたらす安定性と緊張関係

SourceForgeは、現在は米国の企業「SourceForge Media, LLC」が所有・運営しています。
かつてはDice HoldingsやSlashdot Mediaなど複数の企業を経由して現在の体制に至っており、商業ベースの安定した資金調達が可能です。
これは、サーバーインフラの拡充やセキュリティ監査の頻度を高める上で有利に働きます。

しかし、商業運営には常に収益性へのプレッシャーが伴います。
SourceForgeの場合は広告収入が主軸ですが、これがプロジェクトページのデザインやユーザー体験に影響を与えることは避けられません。
実際に、ダウンロードボタンの周囲に表示されるプロモーションリンクや、検索結果のスポンサー表示は、純粋に技術的な観点からはノイズと言えるでしょう。

また、企業の経営判断がサービス方針を一方的に変更するリスクも存在します。
過去にSourceForgeが実施したアドウェアバンドル問題は、まさに短期的な収益拡大が長期的な信頼を損なった典型例です。
現在は是正されていますが、この歴史的経緯は、一部の開発者に「SourceForgeはビジネス優先」という印象を根付かせています。

コミュニティガバナンスの比較――オープン性とコントロールのバランス

CodebergとSourceForgeのガバナンスを、次の表で整理してみましょう。

項目	Codeberg	SourceForge
運営主体	非営利協会（ドイツ）	営利企業（米国）
収益源	寄付・スポンサーシップ	広告収入・プレミアムサービス
財務公開	完全公開（年次報告）	非公開（一般的な企業会計）
意思決定プロセス	理事会の合議制＋コミュニティ投票	経営陣によるトップダウン
サービス終了時のリスク	資産は他非営利団体へ移譲	資産は売却または清算される可能性
コミュニティ参加の自由度	誰でも議論に参加可能	フォーラムモデレーションあり

この表から見えてくるのは、「透明性」と「効率性」のトレードオフです。
Codebergの非営利モデルは、誰もが運営に参画できるオープン性を持つ反面、意思決定に時間がかかる場合があります。
SourceForgeの企業モデルは、迅速な機能改善や大規模投資が可能ですが、その判断基準が外部からは見えにくいという欠点を持ちます。

プロジェクトへの実影響――あなたのOSS活動にどう響くか

ここからが本題です。
このガバナンスの違いは、あなたのプロジェクトに具体的にどのような影響を与えるのでしょうか。

Codebergを選ぶ場合、あなたのプロジェクトは「コミュニティ主導のエコシステム」の一部となります。
つまり、プラットフォーム自体がオープンソースであるため、不具合があれば自分でパッチを当ててPull Requestを送ることが可能です。
また、運営への寄付やボランティア活動を通じて、間接的にインフラを支える文化的な満足感も得られます。
ただし、サポートがボランティア依存であるため、緊急性の高い問題への対応が遅れるリスクは許容する必要があります。

SourceForgeを選ぶ場合、あなたのプロジェクトは「商業プラットフォーム上のテナント」として位置付けられます。
これは、サポート窓口が明確で、障害時のエスカレーションパスが整っていることを意味します。
また、広告収益の分配プログラムを活用すれば、開発資金を得られる可能性もあります。
その一方で、プラットフォームのポリシー変更にプロジェクトが翻弄されるリスクや、広告表示によるプロジェクトのブランドイメージ低下は、戦略的に考慮すべき要素です。

ガバナンスを軽視してはいけない理由

コンピューターサイエンスの観点から言えば、ソフトウェアの持続可能性はコードの品質だけでなく、それを支える社会システムにも依存します。
10年単位で運用されるOSSプロジェクトでは、リポジトリホストの運営体制が突然変わることで、プロジェクトの存続そのものが危ぶまれるケースも珍しくありません。
実際に、SourceForgeのアドウェア問題で多くのプロジェクトがGitHubへ移行した歴史は、ガバナンスが技術選択に与える影響の好例です。

だからこそ、今の時点で両者の運営哲学を理解し、自分のプロジェクトの価値観と合致する方を選ぶことが賢明です。
次の章では、実際の移行作業に焦点を当て、既存のGitHubプロジェクトをどれだけ現実的に移動できるのかを検証します。

移行コストと互換性――GitHubからの乗り換えを現実的に考える

「脱GAFAM」という言葉に惹かれても、実際に既存のプロジェクトを移行するとなると、そのコストとリスクが大きな障壁となります。
GitHubで構築された開発フローを、CodebergやSourceForgeに移すにはどれほどの手間がかかるのか。
ここでは、リポジトリ、Issue、Pull Request、CI/CD、そしてチームの習熟度という5つの軸で、現実的な移行シナリオを検討します。

リポジトリ移行――git push –mirror で済む話か？

Gitリポジトリそのものの移行は、最も簡単なステップです。
両プラットフォームとも標準的なGitプロトコルをサポートしているため、以下のコマンドで全てのブランチとタグを転送できます。

git clone --mirror https://github.com/ユーザー名/旧プロジェクト.git
cd 旧プロジェクト.git
git remote set-url origin https://codeberg.org/ユーザー名/新プロジェクト.git
git push --mirror

この操作により、コミット履歴、ブランチ構造、タグ、そしてGit注記（notes）までもが完全にコピーされます。
ただし、GitHub固有の機能（例：Releasesに添付されたバイナリアセットや、Pagesでホストされた静的サイト）はこの方法では移行できません。
Releasesのバイナリは手動で再アップロードする必要があり、Pages相当の機能はCodebergではPageサーバーを別途用意するか、SourceForgeのWebホスティング機能を利用する形になります。

IssueとPull Requestの移行――APIを活用した現実的アプローチ

これが最大の難関です。
GitHubのIssueやPull Requestには、コメント、ラベル、マイルストーン、アサイン、クローズ状態、さらにはクロスリンク（他のIssueやPRへの参照）といった豊富なメタデータが付随しています。
これらを完全に再現するのは、プラットフォーム間のデータモデルの違いから事実上不可能です。

しかし、完全一致を諦めれば、実用的な移行は可能です。
コミュニティで開発されたツールとして、github-to-forgejo-migratorやgh-issue-exportといったスクリプト群が存在します。
これらはGitHub APIを叩いてIssue一覧をJSONでエクスポートし、ForgejoやSourceForgeのAPI経由で再インポートする仕組みです。
一例として、Pythonで簡易的な移行スクリプトを書く場合の骨格は次のようになります。

import requests
from github import Github

g = Github("GITHUB_TOKEN")
repo = g.get_repo("ユーザー名/旧リポジトリ")
for issue in repo.get_issues(state="all"):
    payload = {
        "title": issue.title,
        "body": issue.body + f"\n\n(元Issue: {issue.html_url})",
        "labels": [label.name for label in issue.labels],
    }
    # CodebergのAPIエンドポイントにPOST（要認証）
    requests.post("https://codeberg.org/api/v1/repos/ユーザー名/新リポジトリ/issues", json=payload)

ただし、この方法ではコメントのスレッド構造や、Issue間の参照関係は再現されません。
移行後のデータは「静的スナップショット」 と割り切り、重要な議論は新プラットフォーム上で再開するという運用が現実的です。
SourceForgeの場合は、インポートAPIがやや限定的なため、専用のフォーラムやチケットシステムへの移行は手動作業が主体となります。

CI/CDパイプラインの再構築――ワークフロー書き換えの実作業

GitHub Actionsを利用していた場合、そのワークフローはCodebergやSourceForgeではそのまま動作しません。
CodebergではWoodpecker CIへの移行が推奨されるため、.github/workflows/*.ymlを.woodpecker.ymlに書き換える必要があります。
両者の構文は似ているものの、トリガー条件やコンテキスト変数の名前が異なるため、完全な自動変換は難しく、手作業での調整が不可欠です。

具体的な違いとしては、以下のような点が挙げられます。

• GitHubの${{ secrets.XXX }} → Woodpeckerの${CI_SECRET_XXX} または secrets.XXX
• on: push → when: event: push
• jobs から pipeline へのトップレベルキー変更
• マトリックスビルドの構文が異なる

SourceForgeの場合はそもそも内蔵CIがないため、既存のGitHub Actionsをそのまま使い続け、ビルド成果物だけをSourceForgeにアップロードするというハイブリッド戦略が現実的です。
この場合、移行コストは非常に低く、actions/upload-artifact の代わりに curl でSourceForge APIを呼ぶステップを追加するだけですみます。

チームの習熟度とドキュメント更新の負担

技術的な移行以上に見落とされがちなのが、チームメンバーの心理的・習慣的な負担です。
新しいUI、新しい用語（「Pull Request」がCodebergでは同じく「Pull Request」、SourceForgeでは「Merge Request」相当の機能はやや異なる）、新しい運用ルールに適応するには、少なくとも数週間の移行期間が必要です。

また、プロジェクトのREADMEやコントリビューションガイドに記載されたURLやコマンド例も全て書き換える必要があります。
このドキュメント更新作業は、規模によっては数人日を要するため、移行プロジェクトとして計画を立てることを強く推奨します。

現実的な移行判断マトリックス

最終的に、移行を決断するための判断基準を整理します。

• 移行すべきケース
• プロジェクトが非営利・オープンソースの理念を強く重視している
• GitHubのクローズド機能に依存していない（ActionsやPagesを使っていない）

• チームが分散型ガバナンスに積極的で、運用コストを許容できる

• 移行を見送るべきケース

• GitHub CopilotやCodespacesなど、Microsoft独自機能を日常的に活用している
• IssueやPRの履歴を完全な形で残すことがビジネス要件となっている
• コントリビューターが多く、移行時の混乱がプロジェクトの停滞を招く恐れがある

移行は技術課題であると同時に、プロジェクトマネジメント課題でもあります。
完全な移行ではなく、ミラーリング戦略（GitHubをメインにしつつ、CodebergやSourceForgeに読み取り専用ミラーを置く）も有効な選択肢の一つです。
次章では、具体的なユースケースごとに最適なプラットフォームを提案します。

ユースケース別の選び方――Webアプリ・ライブラリ・ゲームアセットで変わる最適解

ここまで機能やガバナンス、移行コストを比較してきましたが、最終的な選択はあなたのプロジェクトの特性に大きく依存します。
同じ「オープンソース」といっても、その規模、配布形態、ターゲットユーザーによって、CodebergとSourceForgeのどちらが適しているかは明確に分かれます。
ここでは、代表的な3つのユースケース――Webアプリケーション、汎用ライブラリ、ゲームアセット――を想定し、それぞれの最適解を導き出します。

Webアプリケーション開発――Codebergが持つ軽量性とCI連携の強み

Webアプリケーション、特にフロントエンドフレームワーク（React, Vue, Svelteなど）やバックエンドAPI（FastAPI, Ruby on Rails, Djangoなど）を開発する場合、Codebergが非常に強力な選択肢となります。
その理由は3つあります。

• 軽量なリポジトリ運用：Webアプリのソースコードは通常、バイナリが少なくテキストファイルが中心です。Codebergの100MB制限はほとんどのケースで十分であり、Git LFSも補助的に利用できます
• CI/CDとの親和性：WoodpeckerやDrone CIと連携することで、プッシュごとに自動テストやビルド、さらにはステージング環境へのデプロイまでをシームレスに実行できます。特に、docker buildと連携してコンテナイメージを生成し、レジストリにプッシュするワークフローは、Codeberg＋Woodpeckerの組み合わせで非常にスムーズです
• Issue駆動開発との相性：Webアプリは機能追加やバグ修正のサイクルが速いため、軽快なIssueトラッキングとPull Requestレビューが欠かせません。Codebergのシンプルかつ高速なUIは、このイテレーションを妨げません

具体的なユースケースとして、個人開発のブログエンジンや、チーム内で使うタスク管理ツールのバックエンドAPIなどが該当します。
これらのプロジェクトは、大規模なバイナリ配信を必要としないため、Codebergの非営利モデルの恩恵を最大限に受けられます。

汎用ライブラリ（OSSパッケージ）――両方のハイブリッド運用が現実解

PythonのPyPIやJavaScriptのnpm、Rustのcrates.ioなどに公開するライブラリの場合、ソースコードはGitで管理し、ビルド済みの配布物（wheelファイルやtarball）を別途ホスティングする必要があります。
このケースでは、Codebergをソースコード管理に使い、ビルド成果物の配信にSourceForgeを併用するハイブリッド戦略が非常に有効です。

• ソースコードとIssue、PRレビューはCodebergで完結させる
• リリースタグが打たれたタイミングでCIがビルドを実行し、その成果物をSourceForgeのリリース機能にアップロードする
• パッケージマネージャのダウンロードURLにはSourceForgeのミラーリンクを指定する

この構成のメリットは、ソースコード管理の柔軟性と配信の安定性を両立できる点です。
ユーザーはSourceForgeの高速ミラーからバイナリを取得できるため、ダウンロード体験が向上します。
一方、開発者はCodebergの使い慣れたGitフローとIssue管理を維持できます。
移行コストも、CIスクリプトにアップロードステップを追加するだけで済むため、比較的低く抑えられます。

ゲームアセットや大規模データセット――SourceForgeの独壇場

3Dモデル、高解像度テクスチャ、音声ファイル、機械学習用のトレーニングデータセットなど、ファイルサイズが数百MBから数GBに達するプロジェクトでは、SourceForgeが圧倒的に優位です。
その理由は以下の通りです。

• ファイルサイズ制限の実質的撤廃：SourceForgeはリリースファイルに対して個別のサイズ上限を設けておらず、プロジェクト全体のストレージ容量も非常に大きいです。ゲームのアセットパックや、大規模なニューラルネットワークの重みファイルをそのままホストできます
• 地理的負荷分散：世界中のユーザーが同時にダウンロードしても、ミラーネットワークが帯域を分散するため、サーバーダウンや速度低下が起こりにくいです。これは、人気のあるゲームMODやオープンソースゲームのフルビルド配布において非常に重要な要素です
• ダウンロード統計の可視化：どのアセットがどの地域で多くダウンロードされているかを把握できるため、次回リリースの配信戦略をデータ駆動で立案できます

また、SourceForgeはバイナリのバージョン管理も得意としており、過去の全リリースを保持しつつ「最新版」へのショートカットURLを提供します。
例えば、https://sourceforge.net/projects/yourgame/files/latest/download という固定URLは、常に最新のビルドをユーザーに届けるため、アップデートの通知が不要になります。

ユースケース別の判断フローチャート

以上の考察を基に、簡易的な判断フローチャートを作成しました。

• プロジェクトの主な成果物がテキスト（ソースコード）のみ → Codeberg
• バイナリ配布が必要だが、ファイルサイズが合計で100MB未満 → Codeberg（LFSで対応可）
• バイナリ配布が必要で、ファイルサイズが大きく（>100MB）、かつ世界中のユーザーが対象 → SourceForge（単独利用）またはハイブリッド
• ソースコード管理とバイナリ配信を分離したい → ハイブリッド（Codeberg＋SourceForge）
• プロジェクトが非営利・コミュニティ志向を強く打ち出したい → Codeberg
• 広告収益を開発資金に充当したい → SourceForge

実際の導入事例と学び

例えば、某オープンソースの3Dゲームエンジンは、ソースコードをCodebergで管理し、毎週のナイトリーリースバイナリをSourceForgeで配信しています。
開発チームは「CodebergのIssueトラッカーが軽快で、コントリビューターからのバグ報告が捗る」と評価する一方、「バイナリ配信はSourceForgeのミラーがなければ成り立たなかった」とも語っています。

また、小規模なユーティリティライブラリの作者は、Codeberg単独で完全に運用しており、「広告がなく、プロジェクトページがクリーンなのが気に入っている。
ユーザーからのフィードバックも質が高い」と述べています。

このように、適切なプラットフォームはプロジェクトの性質によって明確に異なります。
全てのプロジェクトに万能な選択肢は存在しないため、自分のユースケースを冷静に分析し、場合によっては両方を使い分ける柔軟な姿勢が求められます。
最終章では、本記事全体を振り返り、持続可能な開発環境を構築するための総合的な視点を提供します。

まとめ――脱GAFAMは手段であり、目的は開発の持続可能性にある

ここまで、CodebergとSourceForgeの機能差、ガバナンス、移行コスト、そしてユースケース別の適性を詳細に比較してきました。
最終的に何をお伝えしたいかと言えば、「脱GAFAM」はそれ自体がゴールではなく、あなたのプロジェクトをより持続可能にするための一つの手段に過ぎないということです。
プラットフォームを乗り換えること自体に満足するのではなく、その先にある開発環境の健全性と長期的な成長可能性にこそ、注力すべきポイントがあります。

選択の本質は「エコシステムの多様性」にある

GitHubが悪いプラットフォームだと言いたいわけでは決してありません。
実際、GitHubは優れたUXと豊富なエコシステムを提供しており、多くのプロジェクトにとって今でも最適な選択肢です。
問題は、選択肢が事実上一つに収斂してしまうことです。
競争がなければ、サービスの質は徐々に低下し、ユーザーの声は軽視され、価格や制約は一方的に変更されるリスクが高まります。

CodebergやSourceForgeのような代替プラットフォームが存在し、実際に利用可能であるという事実は、開発者コミュニティ全体にとっての交渉力を維持する上で極めて重要です。
たとえ最終的にGitHubを使い続けるとしても、「いつでも移行できる」というオプションを持っていることは、心理的な安心感だけでなく、実際のプロジェクトリスク管理にも寄与します。

持続可能性を構成する3つの要素

開発の持続可能性を考えるとき、私は以下の3つの要素がバランスよく満たされる必要があると考えています。

• 技術的持続可能性：プラットフォームが将来的にも機能を維持し、スケールアップや技術的負債に対応できること
• 経済的持続可能性：運営モデルが破綻せず、無料または手頃な価格でサービスが継続されること
• 社会的持続可能性：運営組織がコミュニティの価値観と衝突せず、透明性のある意思決定を行うこと

Codebergは技術的・社会的持続可能性に優れ、SourceForgeは経済的持続可能性（商業ベースの安定性）に強みを持ちます。
そしてGitHubは、経済的・技術的には非常に強固ですが、社会的な透明性やデータ所有権の面で課題を抱えています。
どの軸を優先するかは、あなた自身のプロジェクト哲学とリスク許容度が決めるべきものです。

移行は「イベント」ではなく「プロセス」として捉える

多くの開発者が「明日から全部移行しよう」と考えがちですが、これは現実的ではありません。
前述の通り、Issue履歴やCI/CD設定の再構築には時間がかかります。
むしろ、段階的な移行戦略をお勧めします。

• 最初は読み取り専用のミラーをCodebergまたはSourceForgeに設置する
• 新しいコントリビューターにはミラー先を勧めつつ、既存のメインはGitHubに置く
• 徐々にIssueやPRの受け皿を移行し、チームの習熟度が上がったタイミングで完全移行を実施する

このプロセスを数週間から数ヶ月かけて行えば、移行に伴う生産性の低下を最小限に抑えられます。
また、移行後に「やっぱり戻したい」となっても、データが両方にあるため柔軟に対応できます。

あなたのプロジェクトに合った「最適解」を見つけるために

最後に、本記事で提示した比較情報を、あなた自身のプロジェクトに当てはめて再評価してみてください。
プロジェクトの規模は？ コントリビューターの数は？ 配布するファイルの総容量は？ 将来の展望は？ これらの問いに対する答えが、Codebergなのか、SourceForgeなのか、それともハイブリッドなのかを教えてくれます。

重要なのは、意思決定を後回しにしないことです。
今すぐ移行する必要はなくても、少なくとも両方のプラットフォームでアカウントを作成し、ダッシュボードを触ってみるだけでも大きな意味があります。
実際の操作感を知ることで、将来的な選択肢が具体的なものとして見えてくるはずです。

脱GAFAMは、決して過激な思想ではありません。
それは、開発者としての自律性を取り戻し、自分のコードとコミュニティを大切にするための、ごく自然な流れの一つです。
CodebergとSourceForge、そしてその他の代替プラットフォームが、あなたのプロジェクトの持続可能性を高める一助となることを願っています。
技術選定に正解はありませんが、考え抜いた上での選択は、必ず未来の自分を支える資産になるでしょう。