GitHub以前のオープンソース
要約
- GitHub以前のオープンソースは、自己ホスト型のTrac・Subversion・SourceForgeで動いており、評判とセットアップの煩雑さが依存関係の自然なフィルターとして機能していた。
主なポイント
- GitHub以前、依存パッケージを選ぶには出所を理解する必要があった。パッケージとは、ウェブサイト・メンテナー・メーリングリスト・リリースプロセスを持つプロジェクトを意味していた。
- GitHubの最も過小評価されている貢献はアーカイブだ。放棄されたプロジェクトも検索可能なまま残った。個人サーバーは期限切れになり、ソフトウェアごと消えていた。
- 分散型VCS（Git）が勝利したにもかかわらず、世界は結局ひとつのホスティングサービスに集中した――著者が直接指摘する構造的な皮肉である。
- npmとGitHubはコードの公開・利用からほぼすべての摩擦を取り除き、マイクロ依存関係の爆発を加速させ、パッケージグラフを監査不可能な規模へと拡大させた。
- GitHubがtrusted publishing（npmリリースの署名など）で果たす役割を考えると、GitHubへの信頼が失われればサプライチェーン全体が損なわれる。ソースホスティングだけの問題ではない。
Hacker Newsコメントレビュー
- GitHubによるアーカイブの集中化が全体として良かったかどうかで意見が割れた。「コモンズを守った公共図書館」と見る立場と、「分散アーカイブの習慣を退化させ、単一障害点リスクを生んだ」と見る立場が対立した。
- SourceForgeへのノスタルジーとともに、CodePlexやcode.google.comが話題に上った。支配的なforgeは消えるという教訓であり、Googleによるcode.google.comの廃止がGitHub依存への警鐘として引用された。
- Tracは好意的に記憶されているが、セットアップの負担も語られた。Djangoが20年以上Tracを使い続けていることは、著者の「摩擦が強制力になる」という議論をそのまま体現している。
注目コメント
- @simonw: Tracのセットアップの煩雑さを自ら経験したと証言。DjangoがTrac上で20年以上動き続けていることをGitHub以前のインフラの耐久性の生きた証拠として挙げた。
- @Lammy: 集中型アーカイブは有害だと主張。「すべて誰かがシードする必要があった」という仕組みが集合的なアーカイブ能力を維持したはずだと指摘。
- @pistoriusp: code.google.comをforge史上最大の失敗例として取り上げ、プラットフォーム依存への懸念をより鮮明にした。
英語版: Before GitHub · Original source
