この話題は前回で終えるつもりだったものの，前回紹介した「バージョン間のファイルサイズの変化量」を「かかった日数」で割った値，すなわち「ソースコードの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とは異なる方針で設計されていたため，優れたカーネルハッカーたちにも容易には使いこなせませんでした。

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