GitHub に至るまで

2026 年 4 月 28 日記載

GitHub は、私のオープンソースソフトウェアの最初の拠点ではなかった。それは SourceForge が務めていた。GitHub の以前には、私が管理するインフラストラクチャ上に独自の Trac インストール環境があり、Subversion リポジトリ、チケット情報、tarball パッケージ、そして文書などを保有していた。その後、プロジェクトを Bitbucket に移管したが、当時の Bitbucket はまだオープンソースプロジェクトにとっての真摯な代替先として、とりわけ Git への完全な移行を未遂成していた人々にとっては魅力的な場所と感じられていた。

やがて GitHub がその主要な拠点として定着し、全ての資産を那里に移しました。GitHub が私の人生においてどれほど重要な存在へと成長したかを過剰に強調するのは難しいのですが、私のオープンソースとしてのアイデンティティの多くはその場所で形成されました。そこで人々が私が開発に参加していたプロジェクトを見出し、そこを通じて彼らと出会いました。また、その一方で、私は多くのプロフェッショナルな関係や友情もそこから生まれ、あるリポジトリや issue、プルリクエスト、あるいはコメントスレッドが二人の間で認識の橋渡しとなり、互いの存在を知ったこともありました。

それがゆえに、現在の GitHub が経験している変化を見ていて悲しく、また失望感を抱いているのです。私はこれを取り扱う単なるマイクロソフト社内の製品決定による問題として捉えてはいません。GitHub は長らくオープンソースの社会的インフラの一部であったからです。多くの人にとって、それはコードが宿る場所という以上に、コミュニティそのものが住み続ける場所でした。

したがって、GitHub の衰退を考える際には、その前に存在したものや、後に何が来るのかについても同時に考えざるを得ません。数年前から私はいくつかの機会に「依存関係（dependencies）」について言及し、特にマイクロ依存関係の問題について書いてきました。私の視点において、この現象を誕生させたのは GitHub であったと言えます。それは私が完全に支持していたものではありませんでしたが、同時にオープンソースの包容力を高めた側面もありました。GitHub はオープンソースをどう感じるかを変え、その後 npm や他のシステムが依存関係への感受性を変えました。これらを合わせると、コードを公開する行為もまたそれを消費する行為もほぼ摩擦（コスト）のない世界となり、世界中のプロジェクト数が爆発的に増加しました。

これには多くのメリットがありますが、オープンソースは常にこのような仕組みで运作していたわけではないことを記憶しておく価値があります。

小さな世界

GitHub が登場する以前、オープンソースの世界ははるかに小さかったのです。関心を抱く人の数は変わらなかったかもしれませんが、私たちが現実的に対応可能なプロジェクトの数は少なかったという意味です。

有名なプロジェクトが存在し、比較的少数の人たちによって長期間にわたりメンテナンスされていました。彼らの名前を知っていました。メーリングリストについても知っており、何年もここに在り続けた人や信頼を勝ち得た人々も認識していました。その信頼は完全ではなかったものの、旧来の世界には多くの門戸管理（gatekeeping）もありました。しかし評判が非常に直接的な影響力を持っていました。Debian の関係者がやってきて、「あなたのライセンスに関する記述が曖昧だ」とか「著作権ヘッダーが適切でない」と指摘し、パッケージ化を拒否された際には、私たちは誇らしげでありながらもイライラすることもありました（笑）。

依存関係とは単なるパッケージ名ではなく、歴史があり、ウェブサイトを持ち、メンテナーが存在し、リリースプロセスがある、そして多くの摩擦を伴う、さらに大規模なコミュニティの一部分としてのプロジェクトそのものでした。依存関係を安易に追加することはありませんでした。なぜなら、何かを依存するということは通常、それがどこから来たのかを理解する必要があったからです。

すべてが意図的であったわけではありませんが、これらのプロジェクトは比較的大きなものであったため、独自のインフラストラクチャを持っていたことも必要でした。小さなプロジェクトは大学サーバーで動いていたこともあり、多くは SourceForge に置かれていましたが、大きなプロジェクトは独自の運営を行いました。それらはより大きな集団として連携して機能しました。

我们运行自己的基础设施

私の最初のオープンソースプロジェクトは、私が自分自身で運用するインフラストラクチャ上に存在していました。Trac インストール環境、Subversion リポジトリ、tarball パッケージ、ドキュメント、そしてリリースファイルを、自分のマシンや私が管理するサーバーから配信していました。それは普通のことでした。ソフトウェアを公開したい場合、あなたは小規模なシステム管理者となることも多くありました。Georg と私は、オープンソースプロジェクトのための集団「Pocoo」を独自に運営しました。サーバーコストと Subversion や Trac、メーリングリストなどの維持負担を共有しました。

特に Subversion は、「自分自身でホストを提供する（running your own forge）」というアプローチを自然なものとしていました。それは中央集権的であり、サーバーが必要になり、誰かがそれを運用する必要がありますでした。プロジェクトには居場所があり、それは往々にして文字通りの hostname やディレクトリ、Trac インスタンス、メーリングリストアーカイブといった具体的な存在でした。

Mercurial や Git が登場したとき、それらの哲学的な方向性は全く逆でした。どちらも分散型（distributed）であり、全員の全員が完全なリポジトリを持ち得るものでした。全員の全員が自分のコピー、独自のブランチ、そして独自の歴史を持つことができました。原則的には、これらの分散型バージョン管理システムは単一のセンターを必要としないように設計されていました。しかし、これにもかかわらず GitHub は中心となり、今や世界的に標準化されています。

これは現代のオープンソースにおける大きなアイロニーの一つです。分散型のバージョン管理システムが勝利し、その後に世界がそれをホストするための巨大な中央集権型サービスに標準化したのです。

GitHub が与我了我们什么

現在では GitHub の失敗談ばかりを話題にするのが容易ですが、それは不公正です。GitHub は、過去においても今もなお、オープンソースにとって多大なる贈り物であったからです。

プロジェクトの作成を容易にし、新しいプロジェクトの発見を容易にしました。人生において開発メーリングリストへの購読経験が一度もない人々にも、コントリビューション活動の理解を促しました。プロジェクトに issue トラッカー、プルリクエスト、リリースページ、Wiki、組織ページ、API アクセス、webhooks、そしてその後 CI を提供しました。

「オープンソースは公開された状態で進化する」という考え方を標準化し、可視的な歴史とコラボレーションを実現させました。またそれは一貫して優れた合理的なデフォルトの選択肢でした。

しかし、最も過小評価された GitHub の貢献の一つはアーカイブ機能です。GitHub は図書館になりました。それはソフトウェアの公衆財の巨大な部分を指数化するものとなり、放棄されたプロジェクトであっても検索可能であることで保証されました。フォークを見つけることができ、古い issue や議論も全てオンライン上に残り続けています。中央集権化への批判はいくらでもあるものの、その中央集権化は「発見可能な記憶」を創出しました。

当時の経営陣は、アメリカから制裁を受けた国においても GitHub の利用を保証することに多大な関心を示していました。代替案がどのようなものかについては、私自身がそれを体験したためよく知っています。私の最も古いオープンソースプロジェクトの一つは技術的には今でも PyPI 上にありますが、実際のパッケージファイルは失われています。メタデータは古いサーバーを指しており、そのサーバーは長年以來これらのファイルを配信しなくなっています。これは大規模プラットフォーム以前の時代における正常な現象でした。個人のドメインの有効期限が切れる、VPS が停止する、開発者が他界するなどといったことで、それらが提供していたサービスも消えてしまいました。かつてウェブには小さなソフトウェアの居場所がたくさんありましたが、多くは失われました。

npm と依存関係の爆発

マイクロ依存関係の問題は、単に非常に小さなパッケージが公開されたことだけではありません。GitHub と npm のホストインフラストラクチャが存在することにより、作成・公開・発見・インストール・依存する行為にコストがないかのような錯覚を与えました。

GitHub 以前の時代には、評判と長寿性こそが依存関係の選択プロセスにおいてほぼ当然として考慮される必要があり、それがしばしばベンダー化（vendoring）を必要としました。私たちの初期の多くの依存関係は、他社のサービスが本当に利用可能であることを信頼できないことや、API が存在しなかった時代においてそれらを取得するスクリプトを維持するのが困難なことから、デフォルトとして自分の Subversion ツリーに直接ベンダー化されていました。この暗黙的な摩擦（friction）は一定の省察を促し、開発者の行動に影響を与えました。npm 型のエコシステムでは、パッケージグラフは人間がそれを理解できる限界を超えて急速に拡大するようになります。

このような思考パターンが生んだ問題に対処するためには、途中から解決策を見つける必要がありました。GitHub は責任追及（accountability）の問題を緩和し、ライセンス問題の解決にも寄与しました。ある時点で、新規に流入した開発者とマージされたプルリクエストが、ライセンスの実態について多くの未解決の質問を残しました。GitHub はその問題を Terms of Service で是正しようとさえ試みました。

長年における思考は、「もし小さなパッケージに依存するならば、少なくともリポジトリを見るべきだ」というものでした。メンテナーが存在するか、issue があるか、最近の変更はあるか、他のプロジェクトで利用されているか、コードがパッケージの説明通りなのかを確認したいという欲求がありました。GitHub は信頼を供給するシステムの一部となり、最近では npm および他のレジストリへパッケージを配布するための信頼性のある配信機能を提供できる少数のシステムの一つへと成長しました。

つまり、GitHub への信頼が低下すると、その問題がソースコードホスティングに限定されるわけではありません。それを中心に形成された全体のサプライチェーン・カルチャーにも影響を与えます。

GitHub は徐々に死滅している

現在 GitHub は、それを「必然的な存在」と感じさせる要素を失い始めているようです。それは大規模な中央集権型プラットフォームの生命と死亡のプロセスの一部なのかもしれません。結局のところ、それらは最終的に失望させます。現時点では、人々が不安定さ、製品の回転（product churn）、Copilot AI のノイズ、不明瞭なリーダーシップ、そしてプラットフォームがもはやその価値を生み出したコミュニティを主要な設計対象としていないという感覚に疲れています。

明らかに GitHub は、今や「エージェント型コーディング革命」（agentic coding revolution）の真っ只中にあり、これはそこに在る人々にとって多大なる圧力となっています。しかし、サイトにはリーダーシップが存在しません！現状のように進行していることは奇跡的なことです。

しばらくの間、GitHub を離れるのは主に小規模なプロジェクトやソフトウェア自由に関する明確な見解を持つ人々によって行われる記号的な動きのように感じられました。Zig が Codeberg に移った時には確かにぎこちない思いをしました。しかし今では、重量のある人物や明確なシグナルを持つ人々が GitHub を離れることを議論しています。最も顕著なのは Mitchell Hashimoto であり、Ghostty の移行を宣言しました。どこへ移動するかはまだ不明ですが、強いシグナルです。他にもいます。Strudel や Tenacity も Codeberg に移りました。これらが十分な転換をもたらすでしょうか？おそらくそうではないでしょうが、私は一年前と比較して GitHub を利用していない資産に頻繁にいるようになりました。

これは良いことだとは主張できます：オープンソースにとって、一つの企業がすべてのデフォルトの居場所であるようなpretense（ pretension ）を止めることは健全です。Git 自体が多様な居場所の世界のために設計されました。

分散にはコストがある

多くの forge、多くのサーバー、多くの小さな居場所、そして多くの独立したコミュニティへと戻ることによって、非中央集権化が進み、多くの場合システムが適応を強いられます。これは自律性の回復と、Microsoft の経営陣の whims に依存しないプロジェクトを可能にします。また、異なるコミュニティが異なるワークフローを選択することを可能にします。現在 Pi の issue トラッカーで行われていることの多くは、GitHub の製品選択が現代のオープンソース世界で機能しなくなった結果です。それはエンゲージメントのために設計されたものであり、メンテナーの健全性のためには設計されていませんでした。

また、ウェブを再び忘却させることもできます。私は忘れ去られるようなソフトウェアを愛好します。なぜならそこには清浄（cleansing）の要素があるからです。

損失のリスクが真に大きい場合、私たちは分散型バージョン管理システムの実際の利点をより深く考うる必要があります。しかし、プロジェクトが自己ホスト型の forge へと移行したり、独自の自己ホスティング Mercurial や cgit サーバーを採用したりする場合、私たちが失いたくないものを失う危険性に直面します。コードは理論上では分散しているかもしれませんが、社会的文脈はそうではないことが多いです。Issue、レビュー、デザインに関する議論、リリースノート、セキュリティアドバイザリ、そして古い tarball は脆いものです。それらは我々が認めたくないほど簡単に消えてしまいます。かつて多くのこうした要素を運んでいたメーリングリストは、今日のニーズについていくことができず、大まかなユーザ体験の災害となっています。

我们需要档案库

私が「存在から薄れていく」というアイデアが好きだとしても、図書館やアーカイブは不可欠です。

GitHub が存続するか、プロジェクトが新しい居場所を見つけるかにかかわらず、私はオープンソースソフトウェアのための公的・退屈かつ資金を十分な-archive を見たいと願っています。寄付金または公的資金によって支えられ、存続を確保できるようなものです。その役割は開発者の生産性市場で勝利することではなく、私たちが作成した最も重要なものが消えないようにすることです。

bells and whistles（派手さ）は他の人の問題になりますが、ソースコードのアーカイブ、リリースアチファクト、メタデータ、そして何が起こったかを理解するのに十分なプロジェクト文脈は、単一の企業のビジネスモデルやリーダーシップの気分とは無関係な場所に保存されるべきです。GitHub は偶然としてオープンソース活動の中心となり、アーカイブ機能を持つようになりました。それがもう続かない場合、魔法のようなアーカイブ機能が出現するか、GitHub がそのような機能として継続的に機能するとは考えません。

すでにプロジェクトの居場所が個人のサーバーと善意だけである場合に何が起こるか、そして Google Code や Bitbucket のことがどうなったかも見てきました。

GitHub が回復することを願っています、本当にそう願っています。なぜならそこには多くの歴史があり、現在それを維持している人々は真に重要なものを継承したからです。しかし、私はもうオープンソースの継続的な記憶が GitHub の健全な製品であることに依存させるのは責任ある対応ではないと考えています。

GitHub 以前の時代には、より自律性があり、より多くの損失がありましたが、いくつかの点では、私たちは再びそこに移動する必要があるかもしれません、少なくともしばらくの間。人々が次にとりかかることを検討するならば、記憶を保ちながら依存関係を断ち切るように努力すべきです。プロジェクトを移動することを容易にし、社会的文脈のミラーリングを容易にし、リリースを保存を容易にし、一つの企業の漂いがすべての人々にとって文化的危機になるのを困難にすべきです。

私は破損した tarball リンクや放棄された Trac インスタンスがある古いウェブに戻るわけではありません。また、過去二十年が正常または恒久的なものだったとオープンソースが pretend するのにも同意しません。GitHub はオープンソースにおいて驚異的な章を書きました。その章が終わるとすれば、次の章はその学びと前を振り返るべきです。

この記事は以下でタグ付けされています：github, open-source, thoughts

日本語訳: