■ 1. GitHub以前のオープンソースの姿
- SourceForge・Trac・Subversionが主要な開発基盤であり 開発者自身がサーバを運用するのが通常であった
- プロジェクトには固有のウェブサイト・メーリングリスト・リリースプロセスがあり 依存関係の追加には相当な調査と理解が伴った
- 評判と実績が信頼の基準として機能し 長期にわたるメンテナンスの継続が重視された
- 小規模プロジェクトは大学サーバや共有インフラ上に置かれ 大規模プロジェクトは自前のインフラを維持するか複数プロジェクトが連合して運用コストを分担した
- MercurialやGitの登場により分散型バージョン管理が普及したが 皮肉にも一極集中型のGitHubが標準プラットフォームとなった
■ 2. GitHubがオープンソースにもたらしたもの
- プロジェクトの作成・発見・コントリビューションの障壁を大幅に引き下げた
- イシュートラッカー・プルリクエスト・CI・Webhook・APIなどの開発インフラを一元提供した
- オープンな開発履歴と可視化されたコラボレーションを業界標準として定着させた
- 放棄されたプロジェクトを含む膨大なコードを検索可能な状態で保存する事実上のアーカイブとして機能した
- 制裁対象国へのアクセス維持に尽力するなど 歴史的には開放的な姿勢を示した
■ 3. 依存関係の爆発的増加とその問題
- GitHubとnpmの組み合わせにより コードの公開・消費・依存が事実上コストゼロになった
- GitHub以前は依存関係の選択において評判・寿命・ベンダリングが自然なフィルタとして機能していた
- マイクロ依存関係の急増により パッケージグラフが人間の把握能力を超えて拡大した
- GitHubはnpmなどのレジストリへの信頼できる公開経路としても機能するようになり サプライチェーン文化の中核を担った
- GitHubへの信頼が低下することはソースホスティングだけでなくサプライチェーン全体に影響を及ぼす
■ 4. GitHubの衰退と分散化の動き
- 現在のGitHubはCopilot AIによるノイズ・製品の迷走・不明確なリーダーシップ・コミュニティ軽視への批判に直面している
- エージェント型コーディングの台頭が組織に大きな圧力をかける一方でリーダーシップが不在の状態にある
- GhosttyのMitchell Hashimotoら影響力のある開発者がGitHubからの移行を表明し始めている
- StrudelやTenacityはCodebergへ移行しており 非GitHubプロパティへの訪問頻度が著者自身にも増加している
- Gitはもともと多数の拠点を想定して設計されており 単一企業への依存はGitの設計思想に反する
■ 5. 分散化のコストとアーカイブの必要性
- 分散化の進展はプロジェクトの自律性を回復し 特定企業の意思決定への依存を減らす
- 一方でコード以外の社会的文脈(イシュー・レビュー・設計議論・リリースノート・セキュリティ情報)は分散環境で失われやすい
- メーリングリストは現代のOSSニーズに対応できておらず代替としての機能を果たしていない
- 公的資金または寄付基金によって維持される中立的なOSSアーカイブ機関の設立が必要である
- アーカイブの目的は開発者生産性市場の獲得ではなく ソース・リリース成果物・メタデータ・プロジェクト文脈の永続的保存に限定すべきである
- Google CodeやBitbucketの前例が示すように 一企業への依存が終わった後にアーカイブ機能が自然発生することは期待できない
- 次世代のプラットフォームはプロジェクトの移行容易性・社会的文脈のミラーリング・リリース保存の堅牢性を設計原則とすべきである