GitHub以前のオープンソースの世界
(lucumr.pocoo.org)- オープンソースの依存関係は単なるパッケージ選択ではなく、プロジェクトの評判と持続性、保守のされ方まで含めて検討するものだった
- 分散バージョン管理システムが普及したにもかかわらず、実際の協業の中心は再びGitHubへ集まり、これが現代オープンソースの大きなアイロニーとして残っている
- GitHubはissue tracker、pull request、リリースページのような機能によって、公開協業のデフォルトを変え、プロジェクトの発見や貢献の流れも大きく容易にした
- 同時にGitHubは、放置されたリポジトリや議論の記録まで残すアーカイブとしての役割も果たし、消えやすいソフトウェアの共有資産の記憶をつなぎとめてきた
- 最近GitHubの中心性が弱まる兆しの中で、オープンソースには一企業の事業モデルと無関係に、記憶は保存し依存は減らす公共的なアーカイブがいっそう重要になっている
GitHub以前のオープンソース環境
- GitHub以前は依存先として使えるプロジェクトの数が限られており、各プロジェクトの評判と持続性が依存関係の選択に直接結びついていた
- 依存関係は単なるパッケージ名ではなく、プロジェクトの歴史、Webサイト、メンテナ、リリース手順、コミュニティの文脈まで一緒に付いてきた
- 大きなプロジェクトは独自インフラを運用していることが多く、小さなプロジェクトは大学のサーバーやSourceForgeに置かれていることもあった
- Debianのパッケージング工程のように、ライセンスや著作権ヘッダーまで審査される摩擦があり、そうした摩擦も信頼判断の一部として機能していた
独自インフラ運用と分散バージョン管理の逆説
- 初期のオープンソースプロジェクトは、Trac、Subversion、tarball、ドキュメントを自前で運用するサーバー上で回っていることがよくあった
- Pocooのように、複数のプロジェクトがサーバー費用やSubversion、Trac、メーリングリスト運用の負担を共同で分け合う構造もあった
- Subversionは中央集権型リポジトリだったため、サーバー運用が自然に付随し、プロジェクトの家はホスト名やディレクトリ、Tracインスタンス、メーリングリストのアーカイブのように物理的にはっきりしていた
- MercurialやGitは、誰もが完全なリポジトリとブランチ、履歴を持てる分散型システムだったが、実際の中心は再びGitHubへ集まった
- 分散バージョン管理システムが勝利したあと、世界中がひとつの巨大な中央サービスに標準化されたことは、現代オープンソースの大きなアイロニーとして残っている
GitHubがもたらした変化
- GitHubはプロジェクトの作成と発見を容易にし、開発メーリングリストの経験がない人でも貢献の流れを理解しやすくした
- issue tracker、pull request、リリースページ、Wiki、organizationページ、API、webhook、のちのCIまで提供しながら、公開協業のデフォルトを作り変えた
- オープンソース協業は、見える履歴と見える議論の上で進めるやり方として一般化した
- しばらくの間GitHubは、オープンソースプロジェクトを置くための非常に合理的な標準選択肢として機能した
- 制裁対象国でもGitHubへのアクセス性を維持しようとした米国の政策のように、中央集権化は単なるホスティングを超えて、アクセス可能な共有基盤としても機能していた
アーカイブとしてのGitHub
- GitHubのあまり注目されてこなかった機能はアーカイブとしての役割であり、放置されたプロジェクトも検索可能なまま残り、ソフトウェア共有資産のインデックスのように機能した
- fork、古いissue、議論の記録が残り続けることで、中央集権化は発見可能な記憶を生み出していた
- 逆に大規模プラットフォーム以前には、個人ドメインの失効、VPSの終了、開発者の不在とともに、プロジェクトのファイルやサービスが消えることがよくあった
- PyPIにメタデータだけが残り実際のパッケージは消えた初期プロジェクトのように、リポジトリのURLが古い個人サーバーを指したまま切れてしまう状況もあった
- 過去の多くのプロジェクトは、結局のところ Internet Archive のような外部の保存手段に大きく依存することになった
npmと依存関係の爆発的増加
- micro dependency問題は、小さなパッケージが増えたことだけで終わらず、GitHubとnpmが作成、配布、検索、インストール、依存のコストをほとんどないかのように見せたことで、さらに大きくなった
- GitHub以前は信頼と持続性が依存関係選択の必須要素であり、ほかのサービスの可用性を信じにくかったため、コードを直接リポジトリに含めるvendoringも一般的だった
- API以前の時代には、外部コードを取り込むスクリプトの保守も煩雑で、そうした摩擦が依存関係を追加する前にもう一度考えさせる役割を果たしていた
- npm型エコシステムでは、パッケージグラフが人間の推論できる速度よりも速く成長しうる
- ライセンス状態が不明瞭になる問題に対応するため、GitHubは利用規約の改定も試みた
- 小さなパッケージに依存する場合でも、リポジトリ、メンテナの存在、issue、最近の変更、ほかのプロジェクトでの利用状況、コードとパッケージ説明の一致をGitHubで確認する文化が定着した
- GitHubはnpmのようなレジストリに対するtrusted publishingまで担う数少ないシステムのひとつとなり、GitHubへの信頼低下はソースホスティングを超えてサプライチェーン文化全体にも影響する
GitHubの弱体化と移行の兆し
- GitHubは最近、不安定さ、製品変更の反復、Copilot AIのノイズ、曖昧なリーダーシップによって、かつての必然性の一部を失いつつある
- agentic codingの潮流のど真ん中に置かれたことで内部の圧力も高まったが、現在はリーダーシップ不在が強く感じられる状態として描かれている
- しばらくの間GitHub離れは象徴的な動きに近かったが、今では影響力の大きいプロジェクトも移行を公に検討したり実行したりしている
- GhosttyのGitHub離脱発表は、移転先がまだはっきりしていなくても強いシグナルとして受け止められている
- Strudel moved to Codeberg
- Tenacity moved to Codeberg
- まだ大勢の転換を生むほどではないかもしれないが、GitHubの外にあるホスティング空間を再びより頻繁に目にする流れが現れている
- Git自体がもともと複数の家を前提に設計されていた以上、ひとつの企業があらゆるものの標準の家になる状態を終わらせることは、オープンソースにとって健全かもしれない
分散回帰のコスト
- 複数のforge、複数のサーバー、複数の小さなコミュニティへ戻れば、脱中央集権化と自律性は高まり、Microsoftのリーダーシップ変化への依存は減らせるかもしれない
- 各コミュニティがそれぞれ異なるワークフローを選べるという利点もある
- Piの現在のissue tracker問題は、GitHubの製品選択が今日のオープンソース保守の現実と噛み合わない結果につながっている
- GitHubには、メンテナのメンタルヘルスよりもengagement中心に設計されている面が露わになっている
- 一方でself-hosted forge、自前のMercurialサーバー、cgitサーバーへ移ると、コードそのものは分散しても社会的文脈は簡単に散逸しうる
- issue、レビュー、設計議論、リリースノート、セキュリティ通知、古いtarballは、思っている以上に簡単に失われる
- かつてこうした文脈を収めていたメーリングリストは、今日の要求には追いつけず、ユーザー体験もよくない
- ソフトウェアが忘れられていく性質には浄化作用があるかもしれないが、損失リスクが大きくなるなら、分散バージョン管理システムを実際にどう活用するかも改めて考える必要がある
必要なのは公共アーカイブ
- GitHubが残るにせよ、プロジェクトが別の場所へ移るにせよ、オープンソースには公共的で地味だが安定したアーカイブが必要だ
- 開発者生産性市場で勝つためのサービスではなく、重要なソフトウェアが消えないようにする仕組みが必要である
- endowmentや公的資金のような、長期的に維持可能な基盤の上で動くべきだ
- ソースアーカイブ、リリース成果物、メタデータ、プロジェクトの文脈は、一企業の事業モデルやリーダーシップの気分に縛られない場所に保存されるべきだ
- GitHubはオープンソース活動の中心になる中で偶然そのアーカイブ役まで担ってきたが、中心性が弱まればその機能が自動的に維持されると想定することはできない
- 個人サーバーと善意だけでは保存には不十分であり、Google CodeやBitbucketでもプラットフォーム終了後の空白はすでに明らかになっている
- これからのシステムは記憶は保存し依存は減らす方向へ向かうべきであり、プロジェクト移行、社会的文脈のミラーリング、リリース保存が容易になり、一企業の漂流がみんなの文化的危機へ広がりにくくならなければならない
- 壊れたtarballリンクや放棄されたTracインスタンスへ戻りたくはないし、この20年間のGitHub中心構造を恒久的な正常状態として受け入れることもできないという緊張が残っている
1件のコメント
Hacker Newsのコメント
自分の名前にそのままリポジトリをぶら下げてすぐ作れるという点が、SourceForgeでプロジェクト名を決めて予約し、CVSやSVNリポジトリ、Webサイト、メーリングリスト、イシュートラッカーまで揃えていた重たい手順よりも、ずっと解放感があった
「これはただのちょっとした試作」という心理的ハードルを大きく下げてくれた
GitHubが最初からイシュートラッカー、PR、リリースページ、Wiki、組織ページ、API、Webhook、CIをまとめて提供していたわけでもなかった
昔は組織機能がなかったので新しいユーザーアカウントを作って組織のふりをしたり、「GitHubが数か月以内に出すだろう」と思って別のバグトラッカー導入を先送りし、結局リポジトリ内のテキストファイルで管理したこともあった
Linuxカーネルのような超大規模コードベースではGitに性能上の利点があるのだろうが、大半のプロジェクトはVCSの性能限界に達すること自体ほとんどない
FossilはWikiやフォーラム、チケットといった内蔵ツールがコードと一緒に1つのファイルでバージョン管理される点が本当に便利だ
フリーランスの仕事では、Fossilのおかげでプロジェクトの文脈や細部、クライアントとの合意内容を把握し直すのがとても簡単になる
コードベースを散らかしたり、メールやメモツールをあちこち掘り返して文脈を復元したりする必要がない
Gitが文化的に深く根付いてしまったから変えられない、と考えるのも嫌だ
Fossilは移行も簡単で、Gitから移ってもワークフローはむしろもっと単純になる
ただ、大多数はそういうものを求めておらず、だから広がらなかった
イシューをプロジェクトと一緒に保存すると困る場合もかなりある
クライアントがバグ再現用のスクリーンショットや動画ファイルを大量に送ってくると、リポジトリはすぐ膨らむし、コードと一体化しているとローカルでチケットを見るために全員が肥大化したリポジトリを受け取る必要があって非常に煩雑になる
結局「これは使うのをやめよう、複雑すぎるしリポジトリを膨らませるだけだ」という流れになりがちだ
Fossilの機能の大半はGitバックエンドの上にも実装できそうで、Wikiやイシューは別の並列ブランチ階層として置けばよさそうだ
記憶では、Gitがすでに安定して日常的に使える段階だった頃でも、Fossilはバージョン更新時にリポジトリを丸ごと作り直さなければならないことがあった
GitのUXはもっと悪かったし今でもそうかもしれないが、とにかく動いたし、実戦投入できる感じが強かった
しかも世界最大級のオープンソースプロジェクトのひとつが使っていたのだから、認知面でその差は決定的だった
ただ、しばらくの間は大きなblobの処理ではその利点があまり見えなかった記憶がある
99%の時間で便利な中央集権的サービスがあると、共同体全体の保存能力は退化する
何かを生かしておくために誰かが自分でシードしなければならない仕組みだったなら、人々は本当に重要だと思うもののコピーをもっとしっかり保持していただろう
「あとでまたcheckoutすればいい」と簡単に思えるようになったこと自体がむしろ問題だ
何かを取得できる単一の場所があってはいけない
GitHubのプロジェクトがDMCAを受けると、forkまで一緒に消える
Nintendoが2024年に人気のSwitchエミュレータを削除したときも、誰が最新リビジョンをcheckoutしていたかを探し出して動かす、という形でしか保存や継続作業はできなかった
それすら、非常に人気のあるプロジェクトだったからこそ可能だったことだ: https://news.ycombinator.com/item?id=40254602
付け加えると、このサイトのSplatoonっぽいヘッダー/フッターアニメーションは本当に良い
うるさくなく雰囲気を出しつつ、スクロールするとすぐどいてくれるので、そのまま盗んで使いたくなる
コードがほかの場所にも保存できるという事実自体を知らない開発者が多すぎる気がする
情報をアクセス可能にする障壁が減れば、権力の集中も弱まるだろう
GitHubが長年にわたって信頼を得てきた理由のひとつは、少なくとも今まではそのアーカイブとしての役割を直接収益化してこなかったからだ
もちろんCopilot関連の新機能を見ると、今後はわからないが
代替案が複数のサイトへの分散だとすれば、それぞれ異なるDMCAルールを持つだけだ
それより良い代替案が具体的に何なのか、改めて問い直したくなる
自分のオープンソース作業の大半はself-hostedインフラの上で行われていて、代表例はXfceだ
2004年に最初に参加した頃は、SVNサーバーと、たぶんCVSwebの新しいSVN対応Webインターフェースのようなものがあったと記憶している
自分がコアチームに入ったあとでBugzillaを設定した気もするが、それは別の人だったかもしれない
Gitが主流になり始めたときは、大きなSVNリポジトリを複数のGitリポジトリに移す作業を主導し、cgitのWebインターフェースも付けた
その時点でもまだBugzillaを使っていた
2009〜2010年ごろに小さなスタートアップへ入ってOSSに割ける時間が減り、プロジェクトを離れたが、2022年に戻ってみると、その間にGitLabインスタンスとCIランナーが立ち上がり、BugzillaもGitLabイシューへ移されていた
いまでも活動人数はほんのひと握りで、インフラ管理もほぼ1人が担っているが、小さなチームでも十分回せる
インフラがスポンサー提供なのは大きな幸運で、定期支援だけでも必要なら自前で費用を出せそうだ
何よりGitHub/Microsoftに依存していないのが本当に良い
20年前にMicrosoftが世界最大のOSSコードフォージを所有するようになると言われていたら吐き気がしただろうし、今でもそれはかなり居心地が悪い
Rustは
craterというツールでRustプロジェクト全体のテストを回すのだが、Cargoの内部実装に依存しているプロジェクトを見つけて何百件ものイシューを手作業で立てるとき、摩擦の少ない流れが大いに役立ったサイトの認証情報をすでに持っていて、空のテンプレートも許可されていれば、200件のイシューを立てる作業はずっと楽になる
逆にself-hostedインスタンスに出会うと、たいていはそこで諦めてしまう
新しいオープンソースプロジェクトを始めるとき、最初の段階でTracをセットアップするのは信じがたいほど摩擦が大きかったが、それでも好きだった
Djangoはいまでも20年以上にわたってTrac上で動いている: https://code.djangoproject.com/timeline
それを自分が設定したわけではないが、それ以前の非公開Tracを立ち上げるのは手伝ったかもしれない
ただ、自分の最初のイシュートラッカーはBugzillaで、セットアップはかなり苦痛だったし、ほかのツールとの統合もうまくなかった
それでも
Zarro Boogsを見る楽しみはなかなか特別だったプラグインシステムが本当に素晴らしかった
役割をきちんと果たしていたし、自分にとって特に壊れることもなく、Mercurialのほうが好みに合っていた
会社がGitHubを使うので自分も移ったが、いまでもGitHubはただの鈍いGitエンドポイントとして使い、ビルド/デプロイはDockerとシェルスクリプトで処理しているので、乗り換えコストは非常に低い
仕事では、自分に決定権がないならSVN時代と同じで、お金を払って使うツールをそのまま使えばいいと思っている
あれこれやりすぎて、どれひとつとして卓越していないと感じていた
今その地位はたぶんGitLabが取っていて、後になればそれも良い記憶になるのだろう
GitHub自身のプログラムもある: https://archiveprogram.github.com/
UNESCO支援の非営利団体であるSoftware Heritageもある: https://www.softwareheritage.org/2019/08/05/saving-and-referencing-research-software-in-software-heritage/
ただしこちらは主にコードとコミット履歴の保存に近く、イシューやPR、議論、Wikiといった周辺メタデータまではあまり扱っていない
無料で簡単なモダンホスティングだったAppEngineを活用したくてPythonを学び、そのおかげでFlaskが出てきたときにちょうど良い位置にいた
Arminのことは長く尊敬していて、リンクを開く前からドメインを見ただけですぐわかった
当時はGitHubがデフォルトの選択肢ではなかったという彼の話にも共感する
この文章が数時間前のMitchellの記事への応答だという点も印象的で、こんなに早く長くてよく構成された高品質な文章を書いたことに驚く
Googleがあれほど大きく機会を逃したというのが、いまだに信じられない
あのサービスが閉じる前、自分はそのチームにいた