GitHub以前の時代、エンジニアはどうやってコードを管理していたのか？

GitHubが当たり前の存在になった今、ふと振り返りたくなりますよね。バージョン管理システムが普及する前、あるいはGitHubのようなプラットフォームが存在しなかった時代、私たちはどのようにしてソースコードを管理し、チームで開発を進めていたのでしょうか。当時の現場のリアルや、苦労話について語り合いましょう。

Tracは大好きだった。新しいオープンソースプロジェクトを始めるたび、ステップ1としてTracをセットアップするのは信じられないほど手間がかかったけどね。

面白い豆知識だけど、Djangoは今でも20年以上Tracで動いてるんだ：https://code.djangoproject.com/timeline

（セットアップに関わったわけじゃないけど、その前身のプライベートなTracの立ち上げを手伝った可能性はあるかも。正直覚えてないや！）

これ読んでcode.google.comのことを思い出した。Googleがあそこまで盛大に失敗するなんて信じられないよ。

「GitHubが果たした最も過小評価されている功績はアーカイブ機能かもしれない。GitHubは図書館になったんだ。忘れ去られたプロジェクトでも見つけられる状態を維持することで、ソフトウェアコミュニティの大部分のインデックスとなった」

これ、実は悪いことだと思うんだ。99%の場面で役立つ一元化された場所があるせいで、僕たちのアーカイブ能力が退化してる。もし「すべて」を誰かがシード（種まき）して生き残らせないといけないなら、みんな自分が本当に大事にしているコピーを自分で手元に置くようになるはずだよ。必要な時にまたチェックアウトすればいい、なんて甘えられなくなるからね。

単一の削除ポイントなんてあってはいけないんだ。GitHubのプロジェクトがDMCAで消されたら、みんなのフォークも一緒に消える。2024年に任天堂が人気のSwitchエミュレータを削除した時を見てよ。アーカイブや存続の努力は、誰が最新のリビジョンをローカルに持っているかを探して共有し合うことでしか成り立たなかったんだから。それができたのは、そのプロジェクトがものすごく人気だったからにすぎない：https://news.ycombinator.com/item?id=40254602

余談だけど、このサイトのスプラトゥーンっぽいヘッダーとフッターのアニメーションすごくいいね！主張しすぎないし、雰囲気が良くなる上に、スクロールするとすぐに邪魔にならない場所へ行く。これ絶対パクるわ（笑）

必要なのは、GitLabがActivityPubを統合してくれることだね。そうすれば、どのインスタンスからでもフォークやコメント、マージリクエストができるようになる。Git自体はもう分散型なんだから、そんなに難しい話じゃないはず。

これを読んで、あとmitchellhの投稿を見てコードアーカイブサービスに興味がわいて、いくつか調べてみた。

GitHub自身もやってるね：https://archiveprogram.github.com/

Software HeritageはUNESCOから資金提供を受けている非営利団体だ：https://www.softwareheritage.org/2019/08/05/saving-and-referencing-research-software-in-software-heritage/

ただ、これらはほとんどコードやコミット履歴がメインで、Issue、PR、議論、Wikiみたいな周辺メタデータまではカバーしきれてないのが現状だね。

僕はおそらくFlaskを最初に試した人間の一人だと思う。AppEngineで無料かつ手軽にモダンなホスティングをしたくてPythonを学んでたから、Flaskが公開された時はちょうどいいタイミングだったんだ。ずっとArminのファンだったし、リンクをクリックする前にドメインで彼だとわかったよ。彼が指摘している通り、当時はGitHubをデフォルトで使うなんて時代じゃなかったしね。

彼の投稿は数時間前のMitchellの投稿に対するレスポンスだけど、あんなに質の高い長文の反論を即座に書き上げられるのは本当にすごい。

平均的なプロジェクトにおいて、GitがFossilに勝ったことが今でもすごく悔しいんだ。確かにLinuxカーネルみたいな巨大なコードベースならGitのパフォーマンス上の利点はわかるけど、ほとんどのプロジェクトはVCSの性能限界なんて一生迎えない。Fossilの内部ツール（Wiki、フォーラム、チケット機能など）はコードと一緒に一つのファイルでバージョン管理できるから、本当に便利なんだよ。

フリーランスの仕事は全部Fossilでやってるけど、プロジェクトの文脈やクライアントとの細かい取り決めなどをすぐに思い出せる。コードベースを汚したり、膨大なメールやメモアプリを漁ったりしなくても、すぐに開発を再開できるんだ。

まだ変わる余地はあると思ってる。「Gitが文化的に定着しすぎているから移行なんて不可能」っていう考え方は大嫌いだ。Fossilなら移行はめちゃくちゃ簡単だし、Gitから来ればワークフロー自体もずっと楽に感じるはずだよ。

「GitHubが私たちにもたらしたもの」

個人的に一番の恩恵は、プロジェクト単位ではなく「個人」に軸足を置いた構造だったことだと思う。SourceForgeで深刻な顔をしてプロジェクト名を考えて予約し、CVSやSVNリポジトリを作って、ウェブサイトやメーリングリストやバグトラッカーを……なんて準備するより、自分の名前の配下にサクッとリポジトリを作る方が解放感があった。GitHubなら「これちょっとしたコードだし」という軽い気持ちで始められたんだ。

「プロジェクトにIssueトラッカー、Pull Request、リリース用ページ、Wiki、組織ページ、APIアクセス、Webhook、そして後のCIをもたらした」

もっとも、これらが最初から全部あったわけじゃない。GitHubの組織機能ができる前に、組織を模倣するために新しいユーザーアカウントを作ったのを覚えてるよ。友達と「GitHubが数ヶ月以内にバグトラッカーを出してくれればいいんだけどね」なんて話してたっけ。結局、しばらくはリポジトリにテキストファイルをコミットするだけで凌いでた。Issue機能が発表されたのはその数ヶ月後だったね。

こういう話を読んで、自分が関わってきたプロジェクトの旅路を振り返るのって面白い。僕のオープンソース活動のほとんどは自己ホスト型のインフラでやってきた。メインの例はXfceで、2004年に参加した時はSVNサーバーを使ってたな。当時はCVSwebの新しいSVN対応機能を使っていたんだと思うけど、それくらいかな？

コアチームに入ってからBugzillaを立てた記憶があるけど、もしかしたら他の人だったかもしれない。Gitが主流になり始めた時、巨大なSVNリポジトリを複数のGitリポジトリに変換する作業を主導して、cgitのウェブインターフェースも用意したんだ。当時はまだBugzillaを使ってた。

2009年か2010年頃にプロジェクトを離れて（小さいスタートアップに入ってOSSに割く時間がなくなったからね）、2022年に復帰した。その間にGitLabインスタンスが立てられ、CIランナーも導入されて、Bugzillaのデータも全部GitLab Issueに移行されてたよ。

今でもチームはかなり小さい（アクティブなのは数人）し、インフラ管理もほぼ一人でやってる。小規模チームでも十分やりくりできるんだ。インフラを寛大にも寄付・スポンサーしてもらっているのは本当に幸運だけど、もし必要なら寄付だけで自分たちで賄えるレベルにはなってるとは思う。GitHubやMicrosoftに依存していないというのは本当にありがたいよ。真面目な話、20年前に「Microsoftがあの世界最大のOSSコードフォージを買収する」なんて言われてたら、吐いてただろうね。今でもその事実はどうも馴染まないよ。

自分にとって見落とされがちだけど重要だと思うのは「ログインの共通化」だね。Rustは「crater」というツールで既知のRustプロジェクトすべてのテストを実行している。Cargoの内部仕様に依存しているプロジェクトを特定するために200個のIssueを一つずつ手作業で作ってたんだけど、その時にプロセスの摩擦が少ないことが本当に助けになった。そのサイトの認証情報を持っていて、空のテンプレートも使えるからね。逆に自己ホスト型のインスタンスに当たった時は、だいたいいつも諦めてたよ。