NewsInsight

[Analysis]

ソーシャル化するOSS開発者たち

2009/04/14

　ロング・テール理論の名付け親で、雑誌「Wired」の編集長としても知られるクリス・アンダーソン氏が3月12日付けのブログでオープンソースソフトウェア（OSS）プロジェクトの運営体制に関する誤解を指摘をしている。

　アンダーソン氏によれば、多くの人はオープンソースプロジェクトというのは草の根から立ち上がり、自律的に組織化し、民主的に運営されているという誤った認識を持っている。ところが現実はまったく逆で、1人か2人の「慈悲深い独裁者」によって運営されている、という。

　これはオープンソースプロジェクトに参加していたり、あるいは日常的に成果物を利用している人であれば、そういうものだと首肯するかもしない。メーリングリストで客観データに基づいて議論したり、リーダーを民主的に選ぶようなプロジェクトもあるかもしれないが、おおかたのオープンソースプロジェクトには、それを開始し、中心に位置し続ける“独裁者”がいるものだ。どの機能や修正の提案を受け入れ、どれ（あるいは誰）を排除するかは、ほんの1人か数人が決める。

「国家vs企業」とオープンソースの関係

　アンダーソン氏の指摘が面白いのは、OSSプロジェクトとソーシャルメディアの違いを、国家と企業の違いとして説明しているところだ。

　氏によれば、組織運営における20世紀初頭のパラドックスとして、こういうものがある。国家は民主的に運営するとき一番うまく行くのに、企業というのは独裁的運営がベストであるように見える。これはなぜか？

　この問いに対してアンダーソン氏は、マネジメント理論者のチャールズ・バーナード氏の組織論を引いて、こう答えている。企業（OSSプロジェクト）では、“共有された目的”が存在しているのに対して、国家（ソーシャルメディア）というのは、純粋に国民（参加者）に奉仕するためだけに存在している。目的の共有のためには、単一のビジョン、リーダーシップ、トップダウンの管理といったものが必要となる。一方、国民への奉仕は、ボトムアップによるニーズの認識と、集団による政策決定（投票）が有効だというものだ。

　OSSプロジェクトというのは企業のようなもので、優れたリーダーが存在するプロジェクトが成功する、というわけだ。

Linuxは開発スタイル自体でイノベーションを持続

　OSSプロジェクトはトップダウン――。アンダーソン氏の指摘は、「オープンソース」と聞いても具体的イメージがわかない人に対しての説明としては要を得ているかもしれない。ただ、もしかすると、これは少しずつ古い見方になっていくのではないかと最近感じている。特にLinuxの開発コミュニティは“慈悲深い独裁者”が存在するのとは異なる開発モデルとなっているようにも見える。

　Linuxカーネルの開発者として知られる米グーグルのアンドリュー・モートン（Andrew Morton）氏は、2008年7月に来日した際の講演で、こんなことを言った。

　Linux開発コミュニティは開発プロセス自体も常にイノベートし続けている。互いに顔を見たことがないこともあるような数千人の参加者が、ネットワーク上で分散して開発を行うというのは、これまで歴史上に1度もなかったことで、これは技術上の問題とは別のチャレンジとなっている。

　これは正確な引用ではないが、開発プロセスへの言及が多かったのは私の印象に強く残った。ただ、私には彼が具体的に何を言っているのかよく分からなかったので、そのとき書いた記事はLinuxカーネルにまつわる技術的なコメントを拾ったものとなっている（参考記事：Linuxの次世代ファイルシステムは「バターFS」!?）。

　Linuxコミュニティの人々には旧聞に属するかもしれないが、リーナス・トーバルズ氏が2007年5月に米グーグル社内で行った講演（YouTube動画）を見て、ようやくモートン氏が指摘していたことが、いくらか腑に落ちた。この講演はリーナス自身が開発して、Linux開発でも使っている「Git」（ギット）という分散ソースコード管理ツールに関するものだ。同ジャンルのツールと何が違うのか、そしてツールの特性の違いが開発プロセスにおいて重要な意味を持っていることなどを、きわめて明快に説明している。

GitHubとともにGitがブームに

　一部のOSS開発者の間で、この1年ほどGitがブームとなっている。Gitはもともと、Linuxカーネル開発のために、それまで使っていたソースコード管理システムのBitKeeperを置き換える目的でリーナス・トーバルス氏が2005年に作ったものだが、すでにPerl、GNOME、Ruby on Rails、Android、Wine、Fedora、Samba、X.org、VLC、Prototype.jsなど多くの名だたるOSSプロジェクトがソースコードをGit管理へと移行している。明示的にGitを使っていないプロジェクトでも、利用者の便宜を図るためにGitリポジトリを用意していたり、個々の開発者がローカルPCでGitを使っていたりといったことも増えているようだ。

　gitはイギリス英語の俗語で、愚か者とか役立たず、嫌なヤツといったほどの意味のようだ（例えば、YouTubeのモンティ・パイソン公式チャンネルで「Argument Clinic」というコメディを見ると「stupid git！」という用例が聞ける）。リーナスは自嘲気味に「ぼくは自己中心的なクソ野郎で、自分のプロジェクトにはすべて自分の名前にちなんだものを付けるんだ。最初はLinux、次はGit」としている。

　そのリーナスが口を極めて罵倒するのが、Git以前からソースコード管理ツールのデファクトスタンダードとなっている「Subversion」（以下、svn）だ。

集中型ソースコード管理システムが抱える問題

　リーナスは、svnやその前身といえるCVSのような集中型ソースコード管理システムには、根本的な問題があったという。

　「Subversionほど的外れなプロジェクトはない。スローガンは、正しく作られたCVSというものだけど、CVSを正しくやるなんてできないんだから」。

　リーナスはSubversionチームは5年間もの間、ずっとどうでもいい問題領域ばかりを見ていて、本当に大事なものは手つかずだったと批判する。彼によれば、技術上の一番大きな問題はブランチ作成とマージに関するもの、特にマージのほうだ（ソースコードを分岐させて開発の目的や機能ごとに仮の別バージョンを作ることを「ブランチング」とか「ブランチ作成」、「ブランチを切る」と呼び、逆にブランチへ分岐したソースコードを元に開発した改変や修正、追加などを差分としてオリジナルに反映することを「マージ」と呼ぶ）。

　「ブランチを作ることなんて問題じゃない。マージこそが重要なんだ。マージしようとしたある日、巨大で解決の難しいコンフリクトが発生する。Subversion設計者たちは、真性のバカだよ。ああ、この部屋にもいるかもしれませんね……、あんたはバカだ！ （笑）」

　にこやかに「はっきりと強い意見を言う。それがぼくなんだよ」と話すリーナスに嫌みなところはあまりないが、それにしても集まったグーグル社員に向かって、ものすごい物言いである。

　リーナスの指摘は、あちこちのサーバや開発者のPC上にソースコードを管理するレポジトリ（置き場所）がある分散型ソースコード管理こそが唯一の正しいやり方で、特定のサーバ上など単一の中央レポジトリが存在する集中管理方式は、どのようにやったところで多くの問題を抱えることになる、というものだ。

　リーナスは、svnプロジェクトがブランチ作成の容易さを喧伝してきたことを批判していう。

　「svnではブランチ作成はO（1）オペレーションだって言うけど、（中略）、たとえブランチ作成に100万分の1秒しかかからないとして、そんなの誰が気にする？ 計測するものが間違ってますよ。ブランチ作成なんて、マージができなきゃ意味がないんだから」

　svnでは1度はマージができるものの、マージの履歴をすべて保存しないため、次回のマージでは何らかのコンフリクトが発生するのだという。svnではブランチ上で開発した差分のマージは、「とてつもなく悲惨だ」（リーナス）という。特に多くの人が関わるsvnプロジェクトには「絶対に失敗するので、ぼくは近づかない」と話している。

そもそもコミットが困難になりがち

　リーナスはsvnのような中央レポジトリを使った開発では、典型的には次のようなことが起こるという。あるアプリケーションの新機能を5人で開発する場合、ブランチを切って、5人がそのレポジトリに対して“コミット”（ソースコードを改変）する。それを最終的に元のマスターソースコードにマージすることになる。ところがこのとき、一般的には非常に厳格なコミット権限の運用ルールがあるものだという。下手をすればマスターのソースコードが壊れて、修復に多くの時間がかかってしまうからだ。

　ソースコードに変更を加えたときに、意図せぬバグが入り込んだり、修正した場所以外で不具合が顕在化することがある。こうしたことを防ぐため、中央リポジトリの運用では、コミット権限を限定する。そしてコミット時には必ずテストスイートを走らせて、すべてにパスしなければ絶対にコミットさせないようにするという。

　「テストに完全にパスするまで絶対にコミットは許されないんだよね。ところで、テストを実行するには2時間かかるんだよ……、キツイよ」。

　「簡単にコミットさせるわけにはいかない。これはどんな会社でもあることで、ここグーグルでも絶対あることでしょう。現実はどうかというと、開発者は1行だけ変更したとき、テストスイートを無視するんです。だって、たった1行の変更で壊れるわけないじゃない！ ……、これは本当にひどいモデルですよ」。

　厳格すぎるルールや、守るコストが高すぎるルールは、むしろルール破りの「例外」を多く生むという矛盾をはらむのが世の常だろう。

コンフリクトを誰が解消するのか

　2週間にわたって同じサンドボックスで開発していたとしたら、ほかの人が加えた変更が見えない。このため、マージのときにコンフリクトが発生して、その解決に時間がかかる。

　「svnでブランチをマージするときには、1週間前から計画するもんです。これはひどすぎる」

　分散ソースコード管理システムでは、各人が自分のレポジトリを管理しているため、互いに他人が作成したパッチを常に取り込んでいくことができる。何かコンフリクトがあっても、問題が小さい間に、そのコードに詳しい開発者が問題を解決できる。リーナスは、Linuxカーネルの開発モデルとして、これが非常にうまく機能すると指摘している。

　本質的にコンフリクトは避けようがない。リーナスがパッチを適用するのはたまたまメールが先に届いた順だったりして、そうすると後から届いたパッチが素直に適用できないということが起こるのだという。すでにオリジナルが変わってしまっているからだ。ちなみに、リーナスは過去2年でGitを使って2万2000のファイルを含むLinuxカーネルを管理していて、これまで1日平均4.5回のマージを行っているという。

　こうしたとき、Gitを使った分散開発モデルでは、もう1度そのパッチをリーナスが管理するツリーごと開発者に戻してコンフリクトを解決してもらうことができるのだという。「ネットワーク関連のモジュールとか専門外のものだと、ぼくには判断はできないし、テストもできない。だからぼくにコンフリクトを解決しろなんて土台無理な話」。こういうときリーナスは、パッチを送ってきた人たちにコンフリクトの解決を依頼するのだという。それは単純作業などではないが、何しろパッチを作った本人なので、どうすればいいのかは一番よく分かっている。こうして問題を解決してもらったパッチを再び自分のツリーに取り込めばいい、というわけだ。

分散管理によって消失する「政治」というムダ

　Gitのような分散管理は、単にミラーがたくさんあるというのとはかなり違う。リーナスはこう言う。「開発者たちのデータを追跡する中央の場所というのはどこにもなく、どこか特定の場所が、ほかのどこかと比べて重要ということはないんです」。

　これは、リーナスが管理するLinuxカーネルのソースコードのレポジトリも、それをクローンして私が手元に置いたソースコードのレポジトリも、まったく等価であるという意味だ。ネットワーク上に“オレオレレポジトリ”が増殖することになるが、むしろこれが好都合なのだという。

　中央レポジトリのモデルでは、レポジトリにアクセスできる“コミッター”を厳密に管理することになる。これが諸悪の根源となる、というのがリーナスの論理だ。

　「誰もかれもがレポジトリに書いてしまっては困りますよね、ほとんどの人はバカだから。それで表面上バカっぽくなさそうな人たちのグループを作って、そのグループを小さく保つことになるわけです。誰が優秀かなんて簡単に分かりませんからね」

　こうして誰にコミット権限を与えるか、誰が何をコミットできるのかということを巡って、心理的なバリアが生まれたり、不毛で終わることのない政治的駆け引きが延々と行われることになるのが、中央レポジトリを使った多くのOSSプロジェクトの姿なのだという。

　「分散ソースコード管理では、この問題はなくなるんです。みんな自分のブランチを持つ。なんでも好きなプロジェクトをやればいい。いい仕事だろうと、くだらない仕事だろうと、誰も気にしません。もし優れた仕事だということであれば、後から、“ねえ、これぼくのブランチ、ほかの人のブランチより10倍速いよ。ここからpullするってどう？”と言えばいい。それで実際、他の人はpullするんです」

　「こうして、われわれは政治問題を完全に回避……、いや完全にとはいかなくてまた別の政治が出てくるわけですが……、少なくともコミットアクセスに関する諸問題はなくなります。これは非常に大きな問題なので、たとえこの1点だけであっても、あらゆるOSSプロジェクトは下手な分散モデルを利用するべきじゃないんですよ」

独裁者の特権が消える

　各自が自分のレポジトリに対して何らかの作業を行い、それがいいものであると認められれば、それをほかの人が取り込む。これは、冒頭の“独裁者”モデルとは明らかに異なる。よい機能や改変であれば、多くの開発者が取り込み、一般化するという意味で、きわめて民主的なモデルだ。

　例えば、リーナスが時間とともに過度に独善的になっていったり、技術的判断が鈍っていくようなことがあれば、いつでもプロジェクトの中心人物は変わりうる。これまで属人的な信望やコミュニティ内の力関係だけでなく、アクセス権というシステム上の仕組み（パスワードやパーミッション）で保証されていた「特権」というものが、分散管理システムでは、まったく消えてなくなってしまう。

　これは、自分が始めたプロジェクトですら、そのお株を誰かに奪われてしまう可能性があるということで、一見怖いモデルだ。しかし一方、やっぱり自分のレポジトリをほかの誰かが乗っ取ることも決してできないわけで、これはプロジェクト創始者にも、結果としてプロジェクトの中心の座を奪うことになる開発者にとっても、どちらにとっても悪いことは何もない。「プロジェクトの中心にいる」ということは、あくまでもどれだけほかの開発者から参照され、中心であると思われるかということだけにかかってくる。すでに現在でも、設計・実装能力の高い人や調整能力が高い人が認められる傾向にあるとはいえ、それがよりドラスティックに、システム的な意味で保証されるという意味で、これは非常に健全なモデルかもしれない。

　問題は、あちこちに同一プロジェクトのレポジトリが多数あって、そのどれもが本質的に平等である場合、どのように重要なプロジェクトと、そうでない学生の実験プロジェクトのようなノイズを見分けるかということだ。この辺りの妙を、リーナスは「信頼の輪」という言葉を使って説明する。

信頼の輪による分散開発モデル

　「非常に多くのブランチがありますが、99.9％は無視していいんです。マージというのは、セキュリティのようにやるものです。信頼の輪。それこそがセキュリティへの唯一のアプローチであり、ソフトウェア開発への唯一のアプローチです」

　「ぼくは誰でも信用するわけじゃない。ほんとのところ、シニカルで疑り深い人間で、ほとんどの人はまったく無能だと思ってるわけです（笑）。分散ソースコード管理のポイントというのは、（自分が管理するレポジトリに対する）コミット権を与えないことにあります」

　「ただ、大勢の平均的な群衆の中にも、際だっている人、信頼できる人がいる。5人、10人、15人ほどもいればいい。彼らは傑出しています。ぼくは彼らからpullできるのです」

　こうして、各開発者は、それぞれが信頼できる思う優秀な人を見つけることで、全体として信頼のネットワークが構成される。われわれは結局のところ、自分がよく知る人が言うこと、やることを信用して行動したり、情報の取捨選択をする傾向がある。リーナスは、このモデルは社会的動物としての人間の本性に根ざしていると論じる。

　「これは単に技術的に簡単だというばかりでなく、この部屋にいるすべての人が非常に深いところでプログラムされている行動の仕方です。われわれの思考方法そのものです。誰も、100人の人間を知ることはできません。5人……、7人、10人とかの親しい友人がいるでしょう、あっ、われわれはギークだから2人ですが（笑）、まあ、ともかくそれが基本的な人間の動き方です。（分散ソースコード管理ツールを使うために）何らかの心理モデルを持ち合わせている必要なんてないんです、われわれはそのようにプログラムされているのですから。これは非常に大きなアドバンテージです」

　こうしたことから、リーナスは、Git、Mercurial、BitKeeperなど一連の分散コード管理ツールには大きなメリットがあるという。

　Linuxカーネルは最初の10年間はあらゆるファイルを1つの圧縮ファイルにするtarボールで配布していた。その後、商用の分散ソースコード管理ツール「BitKeeper」を使っていたが、ライセンスの問題などから自作のGitへ移行した。Linuxコミュニティは、カーネルそのものの開発だけでなく、開発モデルやリリースプロセス自体も改革を重ねてきた。それが、冒頭に挙げたアンドリュー・モートン氏の発言の意味だと思う。例えば、リリース用のレポジトリを管理する人がいれば、開発者は常にリリースのタイミングに関係なくプロジェクトを進めることができる。

オフラインでも開発継続が可能

　これほど分散管理のメリットを喧伝するリーナスも、svnのような集中管理型がうまくいくケースがあることは認めている。そもそもリーナスは前提として「オープンソースこそ正しくソフトウェア開発を行う唯一の方法だ」と言い切っているので、世の中には彼の論理が当てはまらないケースが多いのは当然だ。

　「厳密に管理された企業環境であれば、中央レポジトリのほうがうまく行くというのは明らかに真実でしょう。過去35年もうまく行っていました。分散管理ほどでないにしろ、ちゃんと使える」

　こう指摘した上で、ローカルPCに各人がレポジトリを持てることのメリットも改めて強調する。

　「異なるロケーションに複数の開発グループがあると、中央レポジトリが問題を抱えるようになるのは不可避です。光ファイバもあるかもしれませんが、いやホントに、ネットワークを見に行かなくていいというのは、めちゃくちゃ大きなパフォーマンス上のメリットです」

　自分のレポジトリに対して仕事をするということは、飛行機に乗っていても、まったく通常通りに開発を継続できるということだという。

　これはLinuxカーネルのように数千人が関わるプロジェクトではさらに重要な意味を持っているという。インターネットで“つながっている”といっても、現実問題として実はそこまで“つながって”もいないからだ。ノートPC利用者が増えたことで、むしろオフラインの時間をどうするかは大きな問題だろう。

　中央レポジトリではなく、分散型ではローカルPCに好きなだけブランチを作れることから、名前の衝突がなく「test」など、すぐに誰でも付けなくなるような名前をブランチに付けることができるのもメリットだという。また、中央レポジトリ上にブランチを作ると、それはプロジェクトメンバ全員から見えるという、場合によってあまり都合のよくない問題も起こりうる。

Git人気の理由：速さ

　Gitを公式に採用するプロジェクトがある一方、こっそり現場がGitを使っているケースも多いのではないかとリーナスは言う。サーバが不要で、いくつかコマンドを叩くだけで、手軽にブランチが作れて、しかも非常に速い。単に新しくブランチを作るだけなら、1つあたり41バイトのファイルが生成されるだけなので、ブランチングは処理的にも心理的にもコストが低い。Git利用者はブランチが大好きで、10個や15個のブランチを平気で作るという。

　Gitは複数のコマンドラインツール群からなっており、古き良きUnix文化のにおいがする。Git人気が高まっている理由の1つに、ゴリゴリにCで書かれていてパフォーマンスと小回り重視で書かれたツールであること、というのはあるかもしれない。リーナスも、パフォーマンスへの徹底したこだわりを、分散モデルの重要さと同じぐらい強調している。

　0.5秒で差分が取れるのか、同じ作業に30秒かかるのかでは、まったく仕事のやり方が変わってくるという。例えばPythonで書かれたMercurialというものがある。これはGitと同様の分散ソースコード管理ツールでリーナスも評価はしているのだが、パフォーマンスの点でGitがベターだと訴える。「コミットや差分作成に30秒かかるかもしれない。30秒というと、そんなに悪くないと思うかもしれないけど、まじめな話、10分の1秒というのに慣れてしまったら30秒なんて最低なんです」。

　大きなプロジェクトで分散開発を行うには、こうしたツールのパフォーマンスが非常に重要になるという。Gitはマージしたときに、デフォルトで、どこに何行の変更が加えられたかなどの統計情報を表示する。そのために、ソースコード全体を走査する。これは比較的重たい処理で、規模が大きいと1、2秒かかるという。しかし、このデフォルトの機能をオフにすることをリーナスは勧めない。「彼らのことは信じていますよ、でも、クスリ飲むのをやめたかもしれないじゃないですか。正直に言いましょう、昨日彼はオッケーなヤツだったかもしれないけど、今日はそうじゃないかもしれないよね」。だから、信頼している開発者から取り寄せたパッチの適用であっても、それによってどういう変更があったかを毎回確実に確認できることは重要だという。だから、差分が1秒で取れるか30秒かかるかというパフォーマンスの違いはクリティカルで、それは開発スタイルを変える重要な要素であるのだ、という。

　コミット管理を厳格に行っている開発プロジェクトで、テストケースの実行に時間がかかるために「この程度のコード変更がほかに影響を及ぼすわけがない」と“例外”に目をつぶってしまうのと同様に、「あいつが寄こしたパッチなんだから、まあ……、大丈夫だろう、差分を取るのに30秒かかるとタルいし、今回だけは……エイヤ」という例外に陥る、ということだろうと思う。

　リーナスや多くの開発者にとっては、これ以上のパフォーマンスは望めないというぐらい、ローレベルでアルゴリズムやコードを最適化することには大きな意味があるのだろう。Gitのソースコードは読みづらい、そもそもC++じゃないし、文字列処理を自前でやるのはムダなばかりかエラーが入りやすいのではないか、という苦情をメーリングリストで述べた人に対して、リーナスがこてんぱんにやりこめている議論を見れば、どれほどパフォーマンスにこだわっているかということが、よく分かる（ついでに百戦錬磨のハッカーと、コンピュータサイエンスの理論家の違いに関するリーナスの冷めた見方も分かる）。

　リーナスによれば、多くのソースコード管理ツールにはチェックサム程度しかないのだという。一方、Gitはソースコードやコミットのログを対象としたハッシュ（SHA1）を取ることによって、ディスクエラーなどでコードのどこかが壊れてしまっていないかや、余計なコードや変更が混入していないこと、これまでの変更履歴が自分が思っているものと確実に同一であることを保証してくれるという。リーナスはバックアップは取らない（なぜなら他人がどんどんミラーしてくれるから）と公言しているが、この160ビットのSHA1の値だけを管理していれば、1000万行を超えるソースコード全体に目を光らせていなくても、夜よく眠ることができるのだという。

　多くの開発者はLinuxカーネルほど大きなプロジェクトに携わっていないかもしれない。しかし、「Gitは軽い」というのは体感できる違いで、それがGit人気の理由の1つになっているのかもしれない。

開発者向けSNS、「GitHub.com」

　Git人気が高まった理由は、処理の軽快さ、モデルの分かりやすさ、ブランチ作成の容易さ、基本的な使い方の簡単さなど、いくつかあるだろう（私はg-i-tがキーボードでタイプのしやすいこととか、ソフトウェア名とコマンド名が一致していて音の響きにインパクトがあるという覚えやすさも重要なのではないかと思う）。

　そうしたGit自体の特質もあるが、2008年2月にスタートしたGitレポジトリのホスティングサービス「GitHub.com」の存在抜きにGitの流行は語れないだろう。GitHubは「ソーシャルコーディング」という言葉を自ら冠しているが、これは開発者向けSNSと呼ぶべき興味深いサービスだ。Gitが開発モデルを改革したように、GitHubもまたオープンソースのあり方を変えるポテンシャルを持っているように思う。

　GitHubは、単にGitのレポジトリをホスティングすることで、開発者がバックアップや公開目的で使えるようにしてくれているだけではなく、開発者同士の交流を促すソーシャルな場として成り立っている。アカウントを取得してログインすると（ちなみに作成できるレポジトリの数や容量によって無料、有料さまざまある）、表示されるのは、まるでSNSのマイページだ。

　GitHubには、SNSやTwitterなどで一般化したソーシャルな機能が数多く実装されている。気になる開発プロジェクトをウォッチできるだけでなく、特定の開発者を“フォロー”することで、その人がコミットしたり、ほかの人のコミットに対してコメントした内容がライフストリームとしてタイムラインに表示されるようになる。注目されている開発者、例えばRuby on Railsで知られるデビッド・ハイネマイヤー・ハンソン氏などは500人以上のフォロワーを集めている。

　その開発者のページに飛べば、どのプロジェクトに対してどのぐらいの頻度でパッチをコミットしているかとうことがグラフで一覧表示される。つまり、誰がどのプロジェクトに、どれぐらいコミットしているか（文字通り注力という意味でもコミットだし、パッチを書いて投稿するという意味でもコミット）がひと目で分かるようになっている。これは裏返して言えば、プロジェクトありきの従来のOSSプロジェクトのあり方が変わっているのだとも言える。これまでは、プロジェクトの周囲に開発者が集まるものと見るのが一般的だったと思うが、GitHubでは開発者という「人間」に対してプロジェクトが紐付いているという印象が強い。開発者たちは、修正や機能追加のためのコードの塊や、たまたま思いついたコードの断片を陰に陽に互いに投げ合うことでコミュニケーションを取ることができる。何かいい機能を開発したと思えば、オリジナルの開発者に対して“取り込み要求”を送ることもできる。

　もう1つ、GitHubで興味深いのは、プロジェクトのページのかなり目立つ部分に「fork」（分岐）のボタンが付いていることだ。プロジェクト名の横に「fork、watch、download」と並んでいる。ウォッチリストへの追加やダウンロードより、むしろフォークのほうが先にあるのは示唆的だ。ふつうに考えれば、ダウンロードやクローンによってオリジナルを手元に持ってくるだけで十分なケースでも、あまりにも手軽なので、ちょっといじってみたいという程度でもフォークさせることができてしまう。人気の高いプロジェクトでは、フォークだらけになってしまうが、むしろそれがGitの正しい運用スタイルなのだろう。例えばRuby on Railsは、GitHub上でもっとも知られたプロジェクトの1つだが、586個のフォークが存在し、3449人がウォッチリストに入れている。

プロジェクトではなく、人間が主役に

　先日、こんな経験をした。リリースされて間もないRuby 1.9.1で、HTMLパーサライブラリとして知られる「Hpricot」を使おうとしたときのことだ。Ruby 1.9.1から標準添付となったライブラリ管理ツールのRubyGemsを使って入れたのだが、どうもうまく動かない。その時点ではHpricotは1.9系に対応していなかったようだった。ところが少し調べると、1.9系に対応済みのHpricotのレポジトリがGitHub上にあることが分かった。

　GitHub上にはHpricotのレポジトリを持つ開発者が3人いる。私はwhy氏が管理するものを入れたのだが、このとき、コマンドラインから明示的に開発者名を入れるようになる。「sudo gem install why-hpricot --source http://gems.github.com」というように。

　単に「hpricot」ではなく「why-hpricot」だ。これはwhyさんが開発・管理しているhpricotをインストールする、ということであって、よく顔が見えない「開発者」が作ったhpricotを入れるのとは、かなりニュアンスが異なる。

　この辺りの事情を、日本Rubyの会の高橋征義氏とRubyのユーザー会「Asakusa.rb」の松田明氏は、共同執筆した雑誌の特集記事の中でこう記している。

　「（ライブラリ名に開発者名を付けるというGitHubの利用方法を指して）この命名には『パッケージ名のユニーク性を保つための名前空間』という以上の意味があります。今まで単に便利だからで使っていたプロダクトも、『誰が』作っているかをインストール時に強制的に意識させられるのです。さらに、同じプロジェクトにさまざまな変種が存在する場合もあるので、間違った変種をつかまないためにも、プロダクトの進化の歴史を人物ベースで理解する必要が出てきます。このことは、『オープンソースソフトウェアは人が作っているものだ』という原点を強く意識させます」（「WEB＋DB Press」、技術評論社、vol.48、p22〜p23）。

　開発者を名前で認識することが、相応のリスペクトと感謝の気持ちを持つきっかけになる、という。

　Git/GitHubというツール・サービスによって、開発者たちがネットワーク上で、今まで以上に柔軟につながり、そのつながりの情報を軸としてプロジェクトを進めたり、分岐させたり、進化させたりしていく。確かに冷静に考えれば、これまでのオープンソースプロジェクトのあり方と、それほど本質的な違いがあるわけではないかもしれない。結局のところ、リーナスが管理するレポジトリに入らない機能はLinuxといえない。

　しかし、ツールの速度の違いが、仕事のやり方を変えてしまうという話と同様に、人と人とのつながりが容易になり、レポジトリを作成、維持するコストも劇的に下げてしまうツールの登場は、これまでの開発プロセスに大きな影響を与えていく可能性があるのではないだろうか。私には、Git/GitHubの流行が、非常に大きなトレンドの変化を示しているように思える。あらゆる情報系サイトがソーシャル化し、そのことによって参加者がメリットを得ているのと同様に、開発者コミュニティも、よりソーシャルなツールや概念を取り入れていくことが増えるのかもしれない。