玩式草子─ソフトウェアとたわむれる日々

第90回 Linuxの成長過程をふりかえる(おまけ2)

この記事を読むのに必要な時間:およそ 3 分

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

前節で用いたシリーズ単位の開発速度を使えば,シリーズごとの違いは見やすくなるものの,シリーズ内の違いは見えなくなります。たとえば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期ごとに分け,各期の最初と最後のバージョンから,各期ごとの開発速度を計算すると下表のような結果になりました。

前期中期後期
Linux-1.1206617763182
Linux-1.33659414213013
Linux-2.1513058764452
Linux-2.311351961315646
Linux-2.513643178546529
Linux-2.66884927621679
Linux-3.x111421789911693
Linux-4.x1798817124

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

図2 各シリーズを3分割した開発速度

図2 各シリーズを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バイトというのがメーリングリストとパッチファイルでやりとりできる最大速度のようです。

本稿で扱っている開発速度はtar.xzファイルを元にしているので,展開した実際のソースコードではこの5~10倍くらいになるでしょう。

一方,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開発者たちの能力や努力に改めて感嘆しているところです。

著者プロフィール

こじまみつひろ

Plamo Linuxとりまとめ役。もともとは人類学的にハッカー文化を研究しようとしていたものの,いつの間にかミイラ取りがミイラになってOSSの世界にどっぷりと漬かってしまいました。最近は田舎に隠棲して半農半自営な生活をしながらソフトウェアと戯れています。

URLhttp://www.linet.gr.jp/~kojima/Plamo/index.html