GitHubのスタッフソフトウェアエンジニア、Taylor Blau氏によるLinus Torvaldsのインタビュー。Gitの20周年を記念して実施され、2025年4月に公開されました。GitHubはMicrosoftの子会社ですが、このインタビューはMicrosoftではなくGitHub自身が企画・公開したものです。

テイラー・ブロウ：　Gitが最初のコミットを書き込めるほどセルフホスト化されてから、ほぼ20年が経ちました。20年後もまだGitを使い、それについて話しているなんて、想像していましたか？

リーナス・トラボルド:　ええ、まだ使っています。もしかしたら、話していないかもしれません。つまり、それがコード・マネージメントの世界全体を席巻したというのは、私にとって大きな驚きの一つでした。なぜなら、私はGitを自分個人の問題の解決策だと考えていたからです。そして、文字通り20年前、正直言ってかなり未熟だった最初のバージョンでさえ、CVSよりも優れていると思っていました。間違いなく。でも同時に、CVSが市場にとどまっているのを見てきました。Subversion（SVN）が登場したとはいえ、他の企業ではCVSが何十年も市場に浸透しているだけです。それで、私はこう思いました。「この市場は非常に流動的だ。CVSは大嫌いだから使えない。だから、自分のやり方でやろう」明らかにもう使えなくなってしまったので、自分に合った方法でやろう、他人のことは気にしない、ということにしました。確かに、最初の数ヶ月、数年は、使いにくくて直感的じゃないと文句を言われていました。そんな時、スイッチが入ったようなことが起こりました。ええと、先ほどBitKeeperについてお話しましたが、それについて少しお話ししましょうか。有名な話ですが、カーネルの代替としてgitの最初のバージョンを10日くらいで書いたんですよね。ええと、いいえ。実際は、カーネルで使えるようになるまで10日くらいでした。ええと、でも公平に言うと、全体のプロセスは、その前の年の12月か11月に始まりました。ええと、2004年です。何が起こったかというと、Bitkeeperは私にとって常にかなりうまく機能していました。完璧ではありませんでしたが、これまで試した他のものよりはるかに優れていました。でも、Bitkeeperはカーネルコミュニティでは常にあまり歓迎されていませんでした。商用だったからです。オープンソースは自由に使えるようにしたかったんです。というのも、私が知っていたラリー・マッコイ（バージョン管理システムBitKeeperの開発者）はオープンソースが大好きだったんです。彼は当時、オープンソースを使ってビジネスを展開していて、BitKeeperを大企業に売りたいと思っていました。しかし、オープンソースではないことと、世界最大級のオープンソースプロジェクトで使われていることが、多くの人にとってネックになっていました。もちろん、私も同じでした。ある程度はオープンソースを使いたかったのですが、同時に私は非常に実利的な人間で、オープンソースで十分と言えるものはありませんでした。だから、何かもっと良いものが出てくることを期待していました。でも、オーストラリアのTridgeがBitKeeperをリバースエンジニアリングしたんです。これはそれほど難しくありませんでした。BitKeeperは内部的にはSource Engineering Control System (SECS)の優れたラッパーだったからです。SECSは60年代に遡ります。SECSはCVSよりも劣っていると言ってもいいでしょう。しかし、これはBitKeeperのライセンス規則に明確に違反していました。BitKeeperは、これはオープンソースですが、リバースエンジニアリングもできないし、Bitkeeperのクローンを作ることもできません。それが大きな問題を引き起こしました。これはすべて非公開での話です。私はラリーと話し、アンドリュー・トリッジとメールでやり取りして解決策を探していましたが、トリッジとラリーは全く正反対の立場で、結局解決策は見つかりませんでした。そのため、Gitを書き始める頃には、実は4ヶ月間この問題について考え続け、何が自分に合っているか、Bitkeeperよりも優れた機能を持ちながらBitKeeperとは違う方法で機能させるにはどうしたらいいかを考えていました。ラリーに「おい、やっちゃいけないことを一つやったぞ」と言われるような状況にはなりたくなかったからです。そうですね、カーネルにGitを使い始めるまでの執筆期間は10日間くらいだったと思いますが、アイデアをどうするかを頭の中であれこれ検討する時間がたくさんありました。まあ、その両方についてお話ししたいと思います。まずはその10日間から始めましょう。

テイラー・ブロウ：　私の理解では、その期間はカーネルから離れる時間として、主にGitに集中して孤立していたということですね。Gitだけに集中してカーネルのことを考えない状態への移行は、どのようなものでしたか？

リーナス・トラボルド:　たった2週間だったので、結局そのようになってしまいましたが。実際には大したことではありませんでした。過去35年間で、そういうことは何度かやってきました。それほど多くはありませんが、以前にも数週間ほどカーネルから離れたことはありました。でも、その経験はちょっと興味深かったです。というのも、私が感じた反応の一つは、ユーザースペースでプログラミングをする方がカーネルでプログラミングするのに比較して、どれだけ簡単かということでした。つまり、気にする必要があることが、ずっと少なくなるということです。メモリの割り当てを気にする必要がありません。多くのことを心配する必要がありません。そして、あなたが書いているすべてのインフラストラクチャが揃っていれば、デバッグははるかに簡単になります。まさに正しいことをしているのです。だから、実際には、リラックスしたとは言えませんが、ユーザースペースで何かをするのは楽しかったです。

自分が何を望んでいるのか、かなり明確な目標がありました。明確な目標というのは、方向性は分かっていたけれど、詳細は知らなかったという意味です。実は、もう一つお話ししたかったのは、20年経った今でもGitについてとても興味深いと感じている点の一つです。Gitが推奨する開発モデルは、私にとって非常にシンプルで、今ではほぼ当たり前のように思えますが、私はこれを単純化した言葉として言っているわけではありません。Gitというソースコード管理のアイデアを、Gitとなるものに絞り込むには、かなりの思考が必要だったことは間違いありません。

テイラー・ブロウ：　当時、私たちが今持っているものを実現するために、どのような明白でない選択をしたのか教えてください。今では当たり前だと言うことは、当時は当たり前ではなかったと思います。

リーナス・トラボルド:　Gitが使いにくいと感じられた理由の一つは、Gitを使い始めた人のほとんどがCVSのようなバックグラウンドを持っていたことと、私がGitに取り組んだ時の考え方が、ファイルシステム担当者の立場から言うと、ほとんどのソース管理プロジェクトを軽蔑し、ほとんど憎悪していました。だから現状維持には全く興味がありませんでした。私にとって最大の問題は、2つの大きな問題がありました。1つはパフォーマンスです。当時は、もちろんたくさんのパッチを適用していました。Gitのおかげで、今は他の人のコードをマージするだけで済むようになったので、ほとんどなくなりました。しかし、私にとっての目標の一つは、50個、100個のパッチがあっても、基本的に30秒でパッチを適用できることでした。コーヒーを飲む必要はありません。まさにその通りです。そして、それは私にとって重要でした。なぜなら、それは実際には生活の質に関わることだからです。物事が瞬時に進むと、何か間違いが起きてもすぐに結果が見えて、そのまま作業を進めて修正できるのです。私が注目していた他のプロジェクトの中には、パッチ1つにつき30秒もかかるものもあり、それは私にとって受け入れられませんでした。ええ。カーネルはかなり大規模なプロジェクトで、多くのソースコード管理ツール（SCM）はスケーラブルに設計されていなかったからです。ええ、それが問題の一つでした。でも、本当の問題は分散化が必要だと分かっていたものの、本当に安定していなければならなかったことです。SHAハッシュを使うのは大きな間違いだったと思われがちですが、私にとってSHAハッシュはセキュリティではなく、もちろん破損を見つけることを目的としていました。BitKeeperの開発中にもそういう経験があったからです。BitKeeperはCRCとMD5を使っていましたが、すべてに使っていたわけではありません。ですから、初期の設計では、すべてが非常に優れたハッシュで保護されていました。それがプロジェクト全体の原動力となり、2つか3つの基本的な設計アイデアを生み出しました。そのため、低レベルのGitは実際にはかなりシンプルで、細部やユーザーインターフェース、そして誰もが望んでいる機能に複雑さが加わります。クレイジーな話ですが、いくつかのコアコンセプトを持つ低レベルの設計のおかげで、書きやすく、考えやすく、ある程度、人々にアイデアを説明するのも容易になりました。Unixと比較すると、Unixには「すべてがプロセスであり、すべてがファイルである」というコア哲学があります。パイプを使って物事を繋ぎますが、実際にはそれほど単純ではありません。つまり、その哲学の根底にあるシンプルなコンセプトがある一方で、細部は非常に複雑で、それがそもそも私がUnixを高く評価するようになった理由だと思います。

テイラー・ブロウ：　そうですね。Gitにも似たような考え方があります。設計には根本的なシンプルさがあり、実装にはわずかな複雑さがあります。UnixからGitの設計方法に通じるものがありますね。

リーナス・トラボルド:　はい、そうですね。Gitの最初のバージョンを開発していたこの1、2週間で私が考えていたことの一つは、たくさんの決断を下し、それが今でもずっと心に残っているということです。

テイラー・ブロウ：　ええ、ええと、もし後悔していることや、やり方が違っていたらよかったと思うことはありますか？ええと、SHAの選択も含めて、後悔している点、あるいは違うやり方をしていればよかったと思う点はありますか？

リーナス・トラボルド:　ええと、SHA256をサポートしようとして、しかもスナップショットもしたということで、無駄な混乱が生じたという意味で、後悔しています。なぜそうなったのかは理解できますが、ほとんど無意味だったと思います。本当に大きなニーズがあったとは思いませんが、人々が心配していたので公開されたのです。つまり、多くの労力が無駄になったと思います。他にもいくつか小さな問題があります。ええと、インデックスファイルのエントリの並べ替え方法を間違えたと思います。こうした些細な問題が、本来よりも物事を難しくしていたと思います。ええ、でも同時に、そういった問題の多くは修正できますが、それほど小さなものなので、あまり問題ではありませんよね。ええと、複雑な問題は他の部分にあります。

テイラー・ブロウ：　ええ、ええ、ええ。つまり、後悔はほとんどないようですね。それは良いことだと思います。ええと、興味があります。また、その時期に、何がわからないのか分からなくなった瞬間はありましたか？　実現しようとしていたことがうまくいくのか、うまくまとまるのか、使えるようになるのか、常にかなり明確な考えを持っていましたか？

リーナス・トラボルド:　最初の段階については明確な考えがありましたが、長期的にはどうなるか確信が持てませんでした。正直に言うと、最初の1週間後には、パッチを適用するのには使えるものがありましたが、他の部分についてはそれほどではありませんでした。マージを行うための基本的な部分はありました。データ構造も整っていましたが、最初のマージをうまく行うまでに実際にはさらに1週間かかったと思います。全体像を思い描いていなかった部分もいくつかありましたが、最終的にうまく行くかどうかは確信が持てませんでした。ええ、最初のステップ、つまり最初の1、2週間は、つまり、コードを見ればわかります。複雑なコードではありません。最初のバージョンは1万行くらいで、大体1回で読めるくらいでした。とてもシンプルで、エラーチェックなどもほとんど行いません。本当に、もっと重要だと考えている別のプロジェクトがあるので、これを動かそうという感じです。本当に、ええと、つまり、問題が発生して変更が必要になったんです。最初のバージョンでは、それが問題だったことは分かります。ある時点で、後方互換性のないオブジェクトストア転送を行ってしまいました。少なくともFile System Check（FSCK）は、古いオブジェクトについて警告を出していました。データ形式を変更したからです。それがどこから来たのかは分かりませんでした。最初のバージョンでは、必要なことをすべて実行していなかったものがありました。
ええと、実際に変換したかどうかは忘れましたが、変換する必要はなかったかもしれません。そして、カーネル内のオブジェクトについて、CKが「これは…」と警告するような警告がいくつかありました。古くてサポートされていないフォーマットのようなもの。」でも、全体的には本当にうまくいきました。驚くほどうまくいきました。大きな問題は、常に人々に受け入れられるかどうかでした。

テイラー・ブロウ：　そうですね。そして、それにはかなり時間がかかりました。

リーナス・トラボルド:　ええ、ええと、マージがどのように導入されたかについて少し話しましたが、2週間か3週間までは機能しませんでした。

テイラー・ブロウ：　初期バージョンでは省略されていた機能で、後になってプロジェクトにとって非常に重要だと気づいたものはありますか？

リーナス・トラボルド:　まあ、それほど後になってからではなく、自分が気にしていなかった機能だと気づきましたが、これがどこかに展開するなら、他の誰かがやるだろうと思っていました。つまり、最初の週、カーネルに使用していたときは、文字通り、今で言う配管コマンド（plumbing）を手で使っていました。いわゆるporcelain（ユーザー向けに設計された高レベルのコマンドやインターフェース）のようなものはありませんでした。それ以上のものは何もありませんでした。それで、コミットするには、非常に難解なコミットツリー、コミットツリーの書き込みを行う必要がありました。これは、ヘッドファイルに手動で書き込むような、SHAのような値を返すだけです。それで終わりです。

テイラー・ブロウ：　最初のバージョンにハッシュオブジェクトは存在したのでしょうか？

リーナス・トラボルド:　ええと、あれは私が初めて手に入れたバイナリの一つだったと思います。それで、すべてを手動でハッシュ化して、ハッシュを標準出力に返して、好きなように操作できました。ええと、初期のporcelainは、使いにくいものをシェルスクリプトで処理していたようなもので、正直言って、シェルスクリプトを使っても使いにくいものでした。ええと。でも、公平を期すために言うと、この最初のターゲットユーザーは、BitKeeperを使っていたかなり熱心なカーネル開発者でした。だから、彼らは少なくとも私が目指していた概念の多くを理解していました。

テイラー・ブロウ：　ええと。そして、人々がそれを理解してくれたと思います。つまり、私が理解するまでにそれほど時間はかからなかったと思います。というのも、他のカーネル開発者が実際に使い始める前に、ソース管理担当者がすぐに参加し始め、最初のバージョンがリリースされてから数日以内に外部からパッチが届くようになったことに驚きました。ですから、最初の数バージョンについてはたくさん話しましたね。Git Yとの数週間の付き合いについて少し話を進めたいのですが、プロジェクトのかなり早い段階でJuneにメンテナーシップを引き継ぐという決断をされましたね。彼がプロジェクトを運営し、コミュニティがどのように関わっているかを見守るのはどんな感じだったか、少し教えていただけますか？

リーナス・トラボルド:　長年の経験から、少し距離を置いて、正直に言うと、私はGitを3、4ヶ月ほどメンテナンスしていました。8月かその頃だったと思います。引き継いだ時は、本当にただ引き継いだだけでした。「まだGitに関わっているんだ」という気持ちでした。今でもGitのメーリングリストを読んでいましたが、今はもう読んでいません。Juniorは、もし何か頼まれたら大丈夫かどうか確かめたかったんです。でも同時に、これは自分のやりたいことじゃない、と思いました。今でも馬鹿げた気持ちです。長女は大学に進学し、2ヶ月後に彼女が私にテキストメッセージを送ってきて、コンピューターサイエンスラボではGitの方が有名だと言ってきました。 Linuxではgitを使っているからです。gitは私にとって大したことじゃなかった。カーネルを作るためにこれをやらなきゃいけないって感じだった。確かにね。えっと、ちょっと馬鹿げてると思うけど、人生の4ヶ月をメンテナンスに費やしたんだ。でも20年経った今、Junoに話を聞くべきだよ。彼は素晴らしい仕事をしてくれているし。うまくいって本当に嬉しい。でも正直に言うと、インターネットで長い間一緒に仕事をしてきたから、メンテナンスをしていた4ヶ月間は、誰がセンスが良いのかを見抜くのが得意だった。そう、良いメンテナーになるには、センスが重要だ。私にとっては、説明するのは難しいけど、そう、そう、そう、そう、パッチを見ればわかる。他の人のコードにどう反応するか、どう考えるか、そういうこと。彼はプロジェクトの最初のメンバーではなかったけど、初期のメンテナーの一人でした。公開してからほぼ1週間後からずっと。彼は初期の頃の一人だった。でも、最初にタグを付けた人というわけではなく、まあ、この人が3ヶ月間働いているのを見て、このプロジェクトをメンテナンスしたくないから、メンテナーになりたいか聞いてみよう、という感じだった。最初は少し緊張していたと思うけど、本当にうまくいっている。彼は確かにプロジェクトを非常に積極的に運営している。つまり、私にとっては好みは非常に重要ですが、実際には20年間プロジェクトに関わっているという事実が、さらに重要な部分ですよね。彼は、つまり、ツリーのほぼすべての領域について、驚くほど詳しいんです。

テイラー・ブロウ：　ええ、ええ、さて、初期のGitについてはたくさん話しましたが、Gitの中期について少しお話ししたいと思います。このツールがこれほど普及していることを考えると、私がとても興味深いと思うことの一つは、明らかにカーネルの開発に効果的でしたね。ええ。でも、大学の学生がノートパソコンでちょっとした授業課題を書くのにも本当に効果的でした。ソフトウェアエンジニアリングの両極端でGitが効果的だったのは、何がユニークだったと思いますか？

リーナス・トラボルド:　分散型という性質によって、多くのことが簡単になり、それがそれ以前のほぼすべてのSCMと大きく異なる点でした。ええ、分散型SCM（ソースコードマネージメント）は存在しましたが、私の知る限り、Gitを第一の設計目標とするようなものはありませんでした。つまり、他の第一の設計目標に加えて、Gitを純粋にローカルで操作できるということです。そして、後で他の場所で利用できるようにしたい場合もとても簡単です。これは、例えばCVSとは大きく異なります。CVSでは、Gitを使うには集中管理されたリポジトリを設定する必要があり、他の場所に移動したい場合は非常に面倒です。それに、誰かと共有すると、追跡が失われてしまいます。従来のSCM（Software Configuration Management）を使うと、常に特別なリポジトリが1つ存在します。Gitはそれをせず、意図的にそうしなかったという事実が、GitHubのようなサービスを簡単にした理由です。つまり、私はGitHubを簡単化しようとしています。なぜなら、Gitを中心としたインフラを構築するには多くの作業が必要だと認識しているからです。しかし同時に、Gitの基本的なホスティング側は基本的に何もありません。なぜなら、Gitの設計全体が簡単にコピーできるように設計されており、すべてのリポジトリが同じで同等だからです。そして、それが最終的に、個々の開発者にとって非常に使いやすくした理由だと思います。新しいリポジトリを作成するとき、Gitリポジトリは大したことではありません。まるで、そこにアクセスして作業を完了し、インフラをセットアップする必要がなく、従来のSCMで行う必要のある作業は一切必要ありません。そして、もしそれがプロジェクトは、いつか他の人にも使ってもらいたいと思うようなものに成長していくものです。ええ、それもうまくいきます。そして、これもまた、何もする必要はありません。GitHubにプッシュするだけで完了です。ええ、それは私が本当に望んでいたことでした。そして、他の人がそれを望んでいるとは思っていませんでした。CVSとSVNで満足している人はたくさんいると思っていました。実際にはそうは思っていませんでしたが、私はそう思っていました。ほとんどの人にとっては十分だと思っていました。先ほど少しお話ししましたが、Gitはソフトウェアエンジニアリングの両極端に適用できます。私はこれまでずっと、ソフトウェア開発の一部としてバージョン管理と共に生きてきました。そして、私が興味を持っていることの一つは、今日のソフトウェア開発のやり方を形作る上で、Gitの役割をどのように見ているかということです。それは私にとっては大きすぎる質問で、よくわかりません。私がGitを書いた理由はそれではなく、自分自身のために書いたのです。問題 は、ええと、GitHubや他のホスティングサービスのおかげで、以前はできなかったような方法で、こういったランダムな小さなプロジェクトを簡単に作れるようになったと思います。
はい、そして多くのプロジェクトが頓挫しました。例えば、誰かが何かをして放置したまま、それがまだ残っているような、一回限りのプロジェクトです。でも、ソフトウェア開発のやり方を全体的に本当に変えたのでしょうか？よく分かりません。細かい部分は変わります。コラボレーションはある程度容易になりましたか？使い捨てプロジェクトがやりやすくなり、うまくいかなければそのままで済みます。もしうまくいけば、他の人と共同作業できます。でも、ソフトウェア開発において根本的な変化があったかどうかは分かりません。少し先を見据えると、現代のソフトウェア開発は今ほど急速に変化したことはありません。

テイラー・ブロウ：　AIという言葉を使うつもりですか？AIという言葉は使いたくなければ言いません。いいえ、いいえ。このツールのどの部分が進化したと思いますか？あるいは、人々が使っているような新しく要求の厳しいワークフローをサポートし続けるために、まだ進化が必要だと思いますか？

リーナス・トラボルド:　バグ追跡機能をもっと見たいです。誰もがやっていることです。あなたがトラッキングとか、問題とか、何と呼ぼうと、何でもいいですが、もっと統一された形になってほしいです。今はとても断片化されていて、ホスティングサイトごとに独自のバージョンを作っているからです。なぜそうするのかは理解できます。A. 標準的な良い基盤がない。B. 価値を高め、たとえそれ自体が優れていても、そのエコシステムの中で人々に安心感を与える方法でもある。つまり、コードの移動が非常に簡単だということです。でも、もっと統一されたものがあればいいのにと思います。バグトラッキングや一般的な問題が、ホストや興味深いサイト間でもっと共有されるようなものになればいいのに。

テイラー・ブロウ：　そうですね。先ほどおっしゃっていましたが、あなたはあまり素早くなかったかもしれませんが、少なくともメーリングリストを定期的にフォローしていたのは久しぶりですね。

リーナス・トラボルド:　ええ、実はプロジェクトにコミットしてから少し時間が経っています。私の数え方では、最後にコミットしたのは2022年の8月だったと思います。ええ、私のツリーには実験的なパッチがいくつかあります。最近はgitのソースをプルして、自分で使っているパッチを4、5個持っていて、そのうちいくつかはgitのメインリストに投稿したと思いますが、それほど重要ではありません。それらは私のワークフローに特有の細かい部分です。でも正直に言うと、これはLinuxカーネルにも当てはまります。私は35年間Linuxを使ってきましたが、最初の1年間で必要なことはすべてできました。そして、私がカーネルを使い続けているのは、ハードウェアが進化し続け、カーネルもそれに合わせて進化する必要があるからです。もちろん、他の人のニーズも重要です。人生でカーネルのすべての機能が必要になることは決してありません。ええ、ええと、私はカーネルに興味があり、35年経った今でも続けています。gitに関しては、gitは最初の1年間で必要なことをすべてやってくれました。実際、ほとんど最初の数ヶ月で。ええ、必要なことができるようになると、興味を失ってしまいました。カーネルに関しては興味がなかったから。カーネルの仕組みにすごく興味があって、それが私の仕事なんだ。でもSCMに関しては、うーん、全く興味がない。

テイラー・ブロウ：　過去、つまり数年前のプロジェクトで注目した機能で、興味深いと思ったものはありますか？

リーナス・トラボルド:　マージ戦略が少し賢くなったのが良かった。ええ、スクリプトの一部が最終的にC言語で書き直されて高速化されたのが良かった。ええ、もう100個ものパッチシリーズを適用しなくなったにもかかわらず、それを見てきたから。ええと、テストツリーのリベースとか、そういうことをやって、パフォーマンスを改善した部分もあるんだけど、でも、それはかなり小さな実装の詳細だからね。結局のところ、それほど大きな変更ではない。数年前まで私がまだ追っていた最大の変更は、マルチハッシュの件で、私にとっては本当に面倒に思えた。

テイラー・ブロウ：エコシステムの中で、一緒に使っていたツールは何かあった？私自身、TIG（ティグ） の熱心なユーザーです。皆さんは使ったことがないかもしれませんが、Gitがまだ使いにくくてアドオンUIみたいなものだった初期の頃でさえ、使ったことのあるGitのラッパーはgit K（Gitの履歴（ログ）を視覚的に表示するビューア）だけでした。ええ、そしてそれは明らかにGitに統合されました。ええ、かなり早く統合されました。でも、今でも私は完全にコマンド言語を使っています。エディター統合機能は一切使っていません。私のエディターはあまりにも貧弱で、何も統合できないので、そういうことはしていません。あまり良くないですから。だから時々git historyの使用状況の統計を取ることがあります。どんなコマンドを使っているか調べるからです。すると、5つのgitコマンドを使っていることになりました。git merge、git Blame、git logの3つです。

リーナス・トラボルド:　はい、その通りです。つまり、私はgitをあまり使わないユーザーです。他の2つは何なのか聞かなければなりません。つまり、コミットとポークです。このトップ5のことは、いつかやったことがあります。変わっているかもしれないけど、でも、そんなに多くはないですね。いくつかスクリプトがあって、get revlist を使ってプロジェクトの統計情報を取得するなどしています。でも、プロジェクトとの関わり方という点では、ええ、ええ。

テイラー・ブロウ：プロジェクトの機能のいくつかは、初期から、あるいはそれ以降も、十分な評価を受けていないと感じていますか？つまり、本来の評価をはるかに超える評価を受けているということです。

リーナス・トラボルド:　ええ、それは私が尋ねたいことの逆ですね。私にとって大きな出来事は、人々がGitの違う点について文句を言うのではなく、実際にGitの可能性を評価し始めた時でした。ええ、それは最初のGit導入から数年後のことでした。Gitを本格的に使い始めたのは、奇妙なWeb開発者たちだったと思います。Ruby on Railsのようなものだと思います。当時はRubyが何なのか全く分かりませんでしたが、RubyとRailsの開発者は、 2008年頃だったかな。そう、それで不思議な感じがしたんです。少なくとも今まで見たことのないような、全く新しいタイプのGitユーザーが出現したんです。そういうユーザーが背景には存在していたに違いない。突然、人生で​​SCMを使ったことのない若い人たちがGitを初めて使い、彼らが使っていたプロジェクトでもGitが使われていたので、それがデフォルトになっていたのがはっきりと分かったんです。ええ、それで状況が変わったと思います。今まで全く違うSCMを使ってきたベテランしかいなかったのに、突然他のものを見たことがない若い人たちがGitを使い始めたんです。そして、Gitを高く評価するようになったんです。「難しい」と言う代わりに、「この古いプロジェクトはCVSにあるのに、どうやってこれをやればいいの？」と文句を言う人たちを見かけるようになったんです。それはおかしかったですね。

テイラー・ブロウ：ええ、今では、これまで以上に人々がGitを高く評価しているという事実は、考えました

リーナス・トラボルド:　ええ、特に最初の数年間はgitインターフェースのせいでかなり嫌われていたことを考えると、ああ、苦情が絶えませんでした。「それについて教えてください。ああ、というか、dt test （Linuxカーネル開発におけるDevice Tree Test）について指摘できないんです。Googleで調べないとわかりませんが、なぜこうなるの？」という苦情を送ってくる人の数、そして、私が選んだ名前をめぐる炎上騒動もありました。例えば、getstatus のようなコマンドがありませんでした。これは私がかなり頻繁に使うコマンドの一つです。トップ5には入っています。トップ5には入らないかもしれませんが、それでもかなり一般的なコマンドです。CVSでは使ったことがなかったと思います。とても遅くて、みんなが期待していたからです。最初の数年間は、サブコマンドの名前が何の理由もなく違うという苦情ばかりでした。主な理由は、私がCBSをあまり好きではなかったからです。だから、時々わざと違うことをしたり、シフトしたりしました。文字通り、 2007年と2010年ですね。ええ、ええ。人々がGitの使いにくさに不満を言っていた頃から、Gitのパワーを本当に理解するようになったのは、私にとって興味深いことでした。

テイラー・ブロウ：ええ、プロジェクトのごく初期の頃や立ち上げの頃について話しました。そして、今日のGitの実際の使い方についても少し話しました。えっと、プロジェクトの将来について少し考えさせてください。まず、Gitが現在直面している、あるいは今後直面するであろう最大の課題は何だと思いますか？

リーナス・トラボルド:　ええと、私にはわかりません。つまり、Gitは私が想像していたよりもはるかに成功しています。統計を見ると信じられないほどです。カーネルや他のいくつかのプロジェクトで使われていた頃から、かなり人気になり、今ではSCMUの98%を占めています。去年のレポートで見た数字です。つまり、それがどれだけ本当かはわかりませんが、大きな課題です。ええ、ええ、そして、その意味では課題については心配していません。なぜなら、SCMには非常に強力なネットワーク効果があると思うからです。おそらくそれが、一度SCMが普及し、大きく成長した理由でしょう。

他のすべてのプロジェクトがデフォルトでGitを使うようになると、新しいプロジェクトもすべてGitを使うようになるからです。なぜなら、2つの異なるプロジェクトで2つの異なるSCMを使うのは面倒だからです。それだけの価値はありません。ですから、私はこれをGitの課題とは考えていません。むしろ、もっと良いものを持っていると思っている人にとっての課題だと考えています。正直なところ、Gitは私が必要とするすべてのことを実現してくれるので、課題はおそらく新しい用途から生じるでしょう。つまり、私たちもその一部を見てきました。明らかに間違ったアプローチだと私が考えていた方法でGitを使っていた人たちも見てきました。そうですね。Microsoftがあらゆるものにモノリポジトリを使用していたように、スケーラビリティの問題が明らかになりました。Microsoftがそれを間違っていたと言っているのではなく、Gitは本来そのような用途を想定していなかったと言っているのです。ええ、そうだと思います。これらの問題のほとんどは解決しました。苦情は見当たらないからです。しかし同時に、以前ほどGitのメーリングリストをフォローしていないので、大きなファイルの問題が、例えばDVDイメージをGitにコピーしたい場合、なぜそんなことをしたいのかという疑問がありましたが、それが問題なのです。Gitが普及すると、想像もつかないような奇妙なことをする人がたくさん出てきます。私が想像もしなかったような、そして明らかに間違っていると思うようなことをする人がいます。でも、まあ、これは個人的な意見です。明らかに他の人は全く違う個人的な意見を持っています。だから、それは常に課題です。カーネルにも同じようなことが見られます。なぜそんなことをするんだ？と。そう、それはうまくいかないはずなのに、あなたは明らかにそこまでやっている。つまり、98%とか統計的にどうであれ、Gitはソフトウェア開発において非常に支配的なコンポーネントであることは明らかだと話しました。それと同時に、新しいバージョン管理の新興企業も現れているようです。Jujutsu (JJ) – A Modern VCSが思い浮かびます。柔術パイパーとか、そういうのが。興味があります。もし試したことがあれば教えてください。いいえ、本当に試していません。

テイラー・ブロウ：そもそもソース管理に全く興味がなかったのに、なぜ代替手段を探す必要があるのでしょうか？

リーナス・トラボルド:　今は自分に合ったものが手に入ったので。ええ、試しました。本当に。最初はソース管理が好きではなかったのですが、今はもう嫌いではありません。データベースは私にとって人生で最も退屈なことのように思えますが、SCMはまだ本当に興味のあるものではありません。

テイラー・ブロウ：前回の質問に少し終止符を打ってくれましたね。Linuxは予定通り34年前に登場しましたね。

リーナス・トラボルド:　ええ、20年ですね。ああ、悪い質問ですね。次の大きなものは5年ほど遅れていると思います。いいえ、私はその逆だと思います。これまで作らなければならなかったすべてのプロジェクトは、他の誰かが作ったものより良いものが見つからなかったから作らざるを得なかったのです。でも、私は他の人に私の問題を解決してもらう方がずっと好きです。そう、つまり自分で考え出さなければならないプロジェクトは実は世界の失敗です。そう、そして世界は過去20年間、私にとって失敗していません。ええ、ええ、Linuxを使い始めたのは、OSが必要だったのですが、自分のニーズに合うものがなかったからです。そして、Gitを使い始めたのも同じ理由で、Subsurfaceを使い始めました。Subsurfaceは私のダイアローグ、いや、もうダイビングソフトウェアではありませんが、あまりにも特化していたので、大々的に普及することはありませんでした。そして、ある特定の問題を解決しました。でも、私のコンピューターの使用は実際には非常に限られているので、すべての問題を解決したと思っています。ある程度は、おそらく、長年使い続けているため、特定の方法でしか物事ができないからでしょう。大学時代と同じエディターを今でも使っています。
私の指は一つのことを覚えてしまっていて、もう元に戻ることはできません。そのエディターがダメだと分かっていて、誰も使っていない死んだプロジェクトなので、それを維持しています。だからソースツリーを持っていて、新しいマシンをインストールするたびに自分のバージョンをコンパイルしています。ええと、誰にも勧めませんがそのエディタは使えないんです。もっと新しい、ソースコードをカラー化したり、そういう機能があるエディタを何度も探してみたんですが、毎回「うわー、この手はもう年寄りすぎる」って思うんです。だから、これをやらなきゃいけないって思わせるようなプロジェクトが来ないことを心から願っています。ええ、そうそう、そうそう、20年間の贈り物をありがとう。ええ、これは私自身のとても利己的な理由でやったことで、本当に、ここでもう一度言わせていただくと、20年間のうち、たった4ヶ月しか費やしていないんです。だから、本当にすべての功績はジュニアに帰属します。それに、それに関わった他の人たちも、今までに私がやったことよりもはるかに多くのことをやってくれました。ありがとう。[音楽]

蛇足：Githubより前に存在していた、いわゆるバージョンコントロールシステム