この話題は前回で終えるつもりだったものの、前回紹介した「バージョン間のファイルサイズの変化量」を「かかった日数」で割った値、すなわち「ソースコードの1日あたりの増加量」は、カーネルのサイズと公開日から簡単に計算できるので、もう1回使って分析範囲を現行の4.xシリーズにまで広げてみることにしました。

シリーズごとの開発速度

前回はLinuxの特徴とされる「早めの公開、しばしば公開（release early, release often⁠）⁠」が具体的にどのようなものだったかを調べるために、1.1.xや2.1.xといった各シリーズごとのバージョンアップ回数や間隔から調べてみました。しかし、シリーズごとの「ソースコードの1日あたりの増加量」を比較するなら、あるシリーズの最初のバージョンと最後のバージョンを比較すれば事足ります。

たとえば、linux-2.5シリーズの場合、最初のバージョンであるlinux-2.5.0.tar.xzは18.8MBで2001年11月23日にリリースされ、最終バージョンであるlinux-2.5.75.tar.xzは25.9MBで594日後の2003年7月10日にリリースされているので、シリーズを通して見た1日あたりの増加量は12KB（11987.22バイト）となります。この方法で各シリーズごとに1日あたりのソースコードの増加量を整理すると以下のような結果になりました。なお、以下では「1日あたりのソースコードの増加量」を「開発速度」と称することにします。

この結果をグラフにまとめると、図1のようになります。

図1を見ると、linux-2.1までの開発速度と2.3以降の開発速度は文字通りケタが違っていて、2.1と2.3の間で何か大きな変更が行われたことが伺えます。その変更が「BitKeeperの採用」なのでしょう。

なお、今回用いた「開発速度」はシリーズを通して計算しているため、バージョンごとのサイズの増減が均(なら)された結果、前回計算した「バージョンごとの1日あたりの増分の平均値」よりは少なめになるようです。

BitKeeper問題とGitの開発

前回も触れたように「Linuxの開発にBitKeeperを採用する」とLinusさんが宣言したのが2002年、linux-2.5を開発している時期でした。当時のBitKeeperはBitMover社が管理している商用ソフトウェアだったものの、Linusさんを始めとするカーネル開発者たちには無償で提供されていました。

その後数年間、LinuxとBitKeeperの蜜月は続くものの、2005年になって両者の関係は破綻することになります。

具体的には、BitKeeperを無償提供されていたカーネル開発者の一人が、BitKeeper互換のフリーソフトウェアを作ろうとBitMover社の定める使用条件に違反してプロトコルを解析（リバースエンジニアリング）し、それに気づいたBitMover社がLinuxプロジェクトへのBitKeeperの無償提供を中止することになりました。

この発表は2005年の4月に行われ、無償提供の終了日は3ヵ月後の2005年7月1日とされました。BitKeeperに代わりうるソースコード管理ツール（SCM）は存在しない、かと言ってパッチとtar ballのやりとりでは開発が進まない、そう考えたLinusさんは当時進めていたlinux-2.6.12の開発を一時中断し、以前から暖めていたアイデアを元に独自のSCMを開発することにしました。

こうして約1ヵ月ほどの間に開発されたSCMがGit（ギット）で、2005年6月17日に公開された2.6.12以降のLinuxはGitを使って管理されています。

このように書くと、また前節で紹介したグラフだけを見ていると、BitKeeperからGitへの移行はスムーズに進んだように聞こえます。しかし、最初期のGitは急ごしらえのコマンドとスクリプトの集合体だった上、既存のSCMとは異なる方針で設計されていたため、優れたカーネルハッカーたちにも容易には使いこなせませんでした。

そのあたりの事情がソースコードの開発速度から見てとれないかと、もう少し詳しく見てみることにしました。

シリーズ内の開発速度分析

前節で用いたシリーズ単位の開発速度を使えば、シリーズごとの違いは見やすくなるものの、シリーズ内の違いは見えなくなります。たとえばlinux-2.6シリーズは開発に7年強の期間が費やされており、最初のころと終盤では傾向が変っていそうです。

一方、前回用いたバージョンごとの開発速度だと、ソースコードの出入りによるバラツキが大きすぎて、「⁠傾向」を見るには不向きです。

そのため両者の折衷案として、1つのシリーズをバージョン番号を手掛りに「前期」「⁠中期」「⁠後期」の3つの段階に分けてみることにしました。

たとえばlinux-3.xの場合、3.0から3.19まで20のバージョンがリリースされているので、3.0から3.6を「前期⁠」⁠、3.7から3.13を「中期⁠」⁠、3.14から3.19を「後期」と考え、各期ごとに開発速度を計算してみました。同様に、132回バージョンアップしている2.1シリーズの場合、2.1.0から2.1.43を「前期⁠」⁠、2.1.44から2.1.87を「中期⁠」⁠、2.1.88から2.1.132を「後期」としました。なお、4.xシリーズは現在も開発中なことを鑑み、4.0から4.5を「前期⁠」⁠、4.5から最新の4.10を「中期」としてみました。

このように各シリーズを3期ごとに分け、各期の最初と最後のバージョンから、各期ごとの開発速度を計算すると下表のような結果になりました。

この結果をグラフにまとめてみると図2のようになります。図2は、図1の各シリーズの棒グラフをバージョンによって3つに分けたことになります。

図2からは図1だけではわからなかった傾向が見えてきます。たとえば、図1では1.3シリーズの開発速度が2.1シリーズを上回っていたものの、それは1.3シリーズの後期にずいぶん頑張った結果だったことがわかります。

1.3の後期は次の安定版である2.0に向けて、m68k用のコードなど別プロジェクトとして開発されていたコードが一気にマージされた時期で、その結果が開発速度の爆発的な増加として現われたようです。

1.3後期の突出を除いて考えると、linux-1.1からlinux-2.1まで開発速度は漸進的に増えていて、「⁠1日あたり5000バイト」というのがメーリングリストとパッチファイルでやりとりできる最大速度のようです。

一方、linux-2.3では前期のころから開発速度が10000バイトを越えており、2.1までとはずいぶん異なった傾向を示します。どうやらBitKeeperは2.3シリーズの最初から採用されていたようです。

BitKeeperの利用はLinusさんら中心的な開発者から始まり、次第に開発者の間に広がって行って、linux-2.5の時代に正式採用が表明されました。その結果が2.3の後期から2.5の中期ごろに見られる開発速度の向上で、この時期の開発速度は1日あたり15000バイトに逹しています。

その後、BitKeeper問題が発生し、独自SCMであるGitを開発、BitKeeperからGitへの移行作業と開発者たちが新しいSCMであるGitに習熟する必要があったため、2.5の後期から2.6の中期にかけては開発速度が低下することになる、そのようなストーリーが描ければ面白いと思ったものの、実際のところBitKeeperからGitへの移行が問題になるのは2.6の前期から中期のころで、2.5の後期で開発速度の低下が見られる理由にはなり得ませんし、3.xの前期、後期も中期に比べると開発速度が低下しています。

なぜこの時期に開発速度が低下したのだろう……、そういう疑問からChangeLogや実際のソースコードに遡ってみたところ、開発速度が低下している時期でも機能の追加や更新の勢いはそれほど減っていない一方、これらの時期にはメンテナが不在でobsoleteとされたコードが多数削除されていることに気づきました。

たとえば、増加量が少なめになっている3.xの後期でバージョンごとのtar.xzのサイズを調べてみると、3.16が80501KBだったのに対し3.17は80333KBで、バージョンが上がったのに168KBほど減少しています。

このサイズ減少が起った原因を調べるため、両者のソースコードを展開し、それぞれのディレクトリを比較してみたところ、3.17ではdrivers/stagingディレクトリから10ほどのドライバが削除されていました。

drivers/stagingディレクトリは、開発途中だったりメンテナが不在でメンテナンスされていなかったりして、必要な水準に達していないと判断されたドライバを集めたディレクトリで、3.17ではそれらのうち放置されたままだったコードがまとめて削除されたようです。

その結果、drivers/stagingディレクトリは10MBほど小さくなったものの、その他のコードに行われた追加や修正の結果、3.16では326MBだったdriversディレクトリが3.17では321MBと、5MB程度の減少に留まっています。すなわちこの間にdriversディレクトリには5MB程度のコードが追加されていたことになります。一方、一つ前の3.15のdriversディレクトリは322MBだったので、3.15から3.16の間では4MBのコードが追加されています。

このあたりから類推すると、図2に見られるシリーズ内の開発速度の低下は、「⁠追加、更新されるコードが減った」わけではなく、「⁠obsoleteとされていたコードがそれらの時期にまとめて削除された」ことによる相殺の結果、と考えた方がよさそうです。2.5の後期や3.xの前期にもそれぞれこのような古いコードを整理した時期がある、ということでしょう。

前回の分析でBitKeeperによる開発速度の向上が確認できたことに味をしめて、今回はBitKeeperからGitへの移行時の状況を開発速度から調べてみました。

Gitを開発するためにlinux-2.6シリーズの開発が一時中断されたこともあり、BitKeeperからGitに移行したlinux-2.6シリーズの前期には開発速度が低下するものの、その程度は不要になったコードをまとめて削除した時期とそれほど変わらない、という結論となりました。

あれこれ頭を捻って分析した結果としてはちょっと残念に思う反面、「⁠SCMの変更を余儀なくされた」という大きなトラブルにもかかわらず、その影響を最小限に留め得たLinux開発者たちの能力や努力に改めて感嘆しているところです。