GitHub以前のオープンソースの世界
(lucumr.pocoo.org)- GitHubがオープンソースの社会的インフラとして定着する以前、開発者たちは独自のTrac、Subversionリポジトリ、メーリングリストなど自前で運営するインフラの上でプロジェクトを管理しており、依存関係を追加するにも相当な摩擦と慎重さが伴っていた
- GitHubはプロジェクトの作成・発見・貢献を飛躍的に容易にし、イシュートラッカー・プルリクエスト・CIなどを標準化しながら、オープンソースのアーカイブとしての役割まで担った
- npmなどのパッケージエコシステムと結びつくことでマイクロ依存性の爆発が起こり、GitHubは信頼体系の中核となったが、現在は不安定さ・製品方針の混乱・AIノイズなどによって信頼が侵食されつつある
- Ghosttyも離脱し、Strudel、TenacityなどがCodebergへ移行する動きも現れており、分散化は自律性を高める一方で、イシュー・レビュー・セキュリティ勧告など社会的文脈の喪失リスクもある
- 最近はGitHubの中心性が弱まりつつある兆しの中で、記憶は保存し依存は減らす公的アーカイブがいっそう重要になっている。次の時代のオープンソースは、記憶は維持しつつ依存性は減らす方向であるべきだ
GitHub以前のオープンソース環境
- GitHub以前は依存できるプロジェクト数が限られており、各プロジェクトの評判と継続性が依存先の選択に直接結びついていた
- 依存関係は単なるパッケージ名ではなく、プロジェクトの歴史、Webサイト、メンテナー、リリースプロセス、コミュニティ文脈まで一緒についてきた
- 大きなプロジェクトは独自インフラを運営することが多く、小さなプロジェクトは大学サーバーやSourceForgeに置かれることもあった
- Debianのパッケージング工程のように、ライセンスや著作権ヘッダーまで審査される摩擦があり、その摩擦も信頼判断の一部として機能していた
自前インフラ運営と分散バージョン管理の逆説
- 初期のオープンソースプロジェクトは、Trac、Subversion、tarball、ドキュメントを自前で運用するサーバーの上で回っていることが一般的だった
- Pocooのように、複数のプロジェクトがサーバー費用やSubversion、Trac、メーリングリスト運営の負担を分け合う構造もあった
- Subversionは中央集権型リポジトリだったためサーバー運営が自然に伴い、プロジェクトの家はホスト名やディレクトリ、Tracインスタンス、メーリングリストアーカイブのように物理的に明確だった
- MercurialとGitは、誰もが完全なリポジトリとブランチ、履歴を持てる分散型システムだったが、実際の中心は再びGitHubへ集約された
- 分散バージョン管理システムが勝利した後で、世界全体が1つの巨大な中央サービスへ標準化されたことは、現代オープンソースの大きな皮肉として残っている
GitHubがもたらした変化
- GitHubはプロジェクトの作成と発見を容易にし、開発メーリングリストの経験がない人でも貢献の流れを理解しやすくした
- イシュートラッカー、pull request、リリースページ、Wiki、organizationページ、API、webhook、さらに後のCIまで提供し、公開協業のデフォルトを塗り替えた
- オープンソースの協業は、見える履歴と見える議論の上で進める方式として一般化した
- 一時期のGitHubは、オープンソースプロジェクトを載せるための非常に合理的な標準選択肢として機能していた
- 米国の制裁対象国でもGitHubへのアクセス性を維持しようとした方針のように、中央集権化は単なるホスティングを超え、アクセス可能な共用基盤の役割も果たしていた
アーカイブとしてのGitHub
- GitHubのあまり注目されない機能はアーカイブとしての役割であり、放置されたプロジェクトも検索可能なまま残ることで、ソフトウェア共有資産のインデックスのように機能した
- fork、古いイシュー、議論の記録が残り続けることで、中央集権化は発見可能な記憶を生み出していた
- その一方で、大規模プラットフォーム以前には、個人ドメインの失効、VPSの終了、開発者不在とともに、プロジェクトのファイルやサービスが消えてしまうことがよくあった
- PyPIにメタデータだけが残り実際のパッケージは消えた初期プロジェクトのように、リポジトリURLが古い個人サーバーを指したまま切れてしまうこともあった
- 過去の多くのプロジェクトは、結局のところ Internet Archive のような外部保存手段に大きく依存することになった
npmと依存性の爆発
- micro dependency問題は、小さなパッケージが増えたことだけで終わらず、GitHubとnpmが作成、配布、検索、インストール、依存のコストをほとんどゼロに見せたことでさらに拡大した
- GitHub以前は、信頼と継続性が依存先選びの必須要素であり、他サービスの可用性を信じにくかったため、コードを直接リポジトリに含めるvendoringも一般的だった
- API以前の時代には、外部コードを持ってくるスクリプトの保守も面倒で、そうした摩擦が依存関係を追加する前にもう一度考えさせていた
- npm型エコシステムでは、パッケージグラフが人間の推論速度よりも速く成長しうる
- ライセンス状況が不明確になる問題に対応するため、GitHubは利用規約の改定も試みた
- 小さなパッケージに依存する場合でも、リポジトリ、メンテナーの実在、イシュー、最近の変更、他プロジェクトでの利用有無、コードとパッケージ説明の一致をGitHubで確認する文化が定着した
- GitHubはnpmのようなレジストリに対するtrusted publishingまで担う数少ないシステムの1つとなっており、GitHubへの信頼低下はソースホスティングを超えてサプライチェーン文化全体にも影響する
GitHubの弱体化と移行の兆し
- GitHubは最近、不安定さ、製品変更の繰り返し、Copilot AIの雑音、曖昧なリーダーシップのため、かつての必然性の一部を失いつつある
- agentic codingの流れの真ん中に置かれたことで内部の圧力も強まったが、現在はリーダーシップ不在が強く感じられる状態だと描写されている
- しばらくの間、GitHub離れは象徴的な動きに近かったが、今では影響力の大きいプロジェクトも公然と移行を検討または実行しつつある
- GhosttyのGitHub離脱発表は、移転先がまだ明確でなくても強いシグナルとして受け止められている
- Strudel moved to Codeberg
- Tenacity moved to Codeberg
- まだ大勢の転換を生むほどではないかもしれないが、GitHubの外にあるホスティング空間を再びより頻繁に見る流れが現れている
- Git自体がもともと複数の家を前提に設計されている以上、1社があらゆるものの標準的な家になる状態を終わらせることは、オープンソースにとって健全かもしれない
分散回帰のコスト
- 複数のforge、複数のサーバー、複数の小さなコミュニティへ戻れば、脱中央集権化と自律性は高まり、Microsoftのリーダーシップ変化への依存は減らせるかもしれない
- 各コミュニティがそれぞれ異なるワークフローを選べるという利点もある
- Piの現在のイシュートラッカー問題は、GitHubの製品選択が今日のオープンソース保守の現実と噛み合わない結果につながることを示している
- GitHubはメンテナーのメンタルヘルスよりもエンゲージメント中心に設計されている側面が見えている
- 一方で、self-hosted forge、自前のMercurialサーバー、cgitサーバーへ移ると、コード自体は分散しても社会的文脈は容易に散逸しうる
- イシュー、レビュー、設計議論、リリースノート、セキュリティ告知、古いtarballは思っている以上に簡単に失われる
- かつてこうした文脈を担っていたメーリングリストは、今日の要求には追いつけず、ユーザー体験も良くない
- ソフトウェアが忘れられる性質には浄化作用があるかもしれないが、損失リスクが大きくなるなら、分散バージョン管理システムを実際にどう活用するかも改めて考える必要がある
必要なのは公共アーカイブ
- GitHubが残ろうとプロジェクトが別の場所へ移ろうと、オープンソースには公共的で地味だが安定したアーカイブが必要だ
- 開発者生産性市場で勝つためのサービスではなく、重要なソフトウェアが消えないようにする仕組みが必要である
- endowmentや公的資金のように、長期的に維持可能な基盤の上で動くべきだ
- ソースアーカイブ、リリース成果物、メタデータ、プロジェクトの文脈は、1社の事業モデルやリーダーシップの気分に縛られない場所で保存されるべきである
- GitHubはオープンソース活動の中心になる中で偶然そのアーカイブ役まで担ってきたが、中心性が弱まればその機能が自動的に維持されると想定することはできない
- 個人サーバーと善意だけでは保存は十分でなく、Google CodeやBitbucketでもプラットフォーム終了後の空白がすでに露呈している
- 今後のシステムは記憶は保存し依存は減らす方向へ進むべきであり、プロジェクト移転、社会的文脈のミラーリング、リリース保存が容易になり、1社の漂流が皆の文化的危機へ波及しにくくならなければならない
- 壊れたtarballリンクや放棄されたTracインスタンスの時代に戻りたいわけでもなく、この20年のGitHub中心構造を恒久的な正常状態として受け入れることもできない、という緊張が残っている
3件のコメント
GitHubがこれまで大きな役割を果たしてきたのは事実ですが、私の記憶では、それ以前のオープンソースプロジェクトは関わる人だけがやるもので、個人が公開するケースはあまり多くありませんでした。社内でさえ、同じチーム内だけで共有することもありました。そしてオープンソースは、大きなプロジェクトに貢献する人として認められること自体が大きな名誉であって、個人のちょっとしたプロジェクトに関心を持つ人はほとんどいませんでした。
開発コミュニティの雰囲気が変わり、公開ソフトウェアを出して自分の実力を認めてもらうための手段として使われるようになり、最終的にはいくつかのDVCSの中でもgitがより広く使われるようになるなど、さまざまな幸運が重なったのが始まりだったと記憶しています。競合相手も似たようなサービスを提供していましたし、GitHubだけが特別にうまくやったからだとは思いません。
実際、問題なのは issue・PR・議論であって、git 自体はいつでも別のサービスに移せるんですよね。git にこの3つを組み込むプロジェクトもあったはずなので、そういうものを使えばいつでも移行できそうです
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があれほど大きく機会を逃したというのが、いまだに信じられない
あのサービスが閉じる前、自分はそのチームにいた