Linux ディストリビューションの総開発コスト推定試算
Amanda McPherson / Brian Proffitt / Ron Hale-Evans 著
Linux ディストリビューションの総開発コスト推定試算
Amanda McPherson / Brian Proffitt / Ron Hale-Evans 著
Linux オペレーティングシステムは歴史上、最も成功したオープンソースのプロジェクトですが、
Linux ディストリビューションのソフトウェアにはどの程度の「価値」があるのでしょうか。David A.
Wheeler 氏は 2002 年、一般的な Linux ディストリビューションで使用されるソフトウェアのコー
ド行数を調査した論文を発表して注目を集めました。どのような結果になったのでしょうか。
一般的な Linux ディストリビューションに必要な総開発費は 12 億ドルでした。本稿では、同
氏のツールと手法を使用してその結果を更新しています。同じツールを使用した場合、現在
では、Fedora 9 ディストリビューションを開発するのに約 108 億ドルかかると推定されます。ま
た、Linux のカーネルだけでも開発に 14 億ドルかかります。本稿では、この予測の手法と
Linux の最新の開発費について説明します。
Linux オペレーティングシステムは現在、最も人気のあるオープンソースのオペレーティングシステムであり、2008 年には 250 億 ドルのエコシステムを形成しています1。1991 年に発表されて以来、コンピューティングの世界の一大勢力に成長し、ニューヨ ーク証券取引所から携帯電話、スーパーコンピュータ、家電まで、あらゆるデバイスで利用されています。 Linux はオープンなオペレーティングシステムとしてコラボレーションによって開発されます。すなわち、特定の一社が開発やサポ ートに責任を持つものではありません。Linux のエコシステムに参加する企業は、調査開発費をそのパートナー、あるいは、競 合企業とさえも共有しています。このように、開発の負担を個人や企業の間で分散させることによって大規模で効率的なエ コシステムを構築し、画期的なソフトウェア技術を実現しています。 100 社以上の 1,000 名を超える開発者の協力によって１つのカーネルがリリースされます。過去 2 年間だけでも、200 社以 上の 3,200 名を超える開発者がカーネルの開発に参加しています2。カーネルは Linux ディストリビューションのほんの小さな一部に過ぎません。Linux ディストリビューションはカーネルをはじめ、GNOME と KDE のデスクトップ環境、GNU コンポーネント、 X Window システムなどの複数のコンポーネントで構成されています。これらのプロジェクトに参加している開発者を合計する と数千人に上ります。
Linux は集合的に開発されるため、技術開発費も単一の情報源だけでは推定できません。2002 年、David A. Wheeler 氏 は一般的な Linux ディストリビューション（Red Hat Linux 7.1）における SLOC（Software Lines of Code）を分析した論文を
発表して注目を集めました3。この論文では本稿と同様、SLOC は企業別や開発者別の推定ではなく開発の最終結果に
着目しているため、オープンソースソフトウェアの価値を分析するには最も実用的な手法であると結論付けています4。同氏
は SLOC の計算と分析用に自ら開発した業界標準のツールを使用して、Linux ディストリビューションを、米国において、従 来の方法で開発した場合、12 億ドルを超えるコストがかかると推定しました。
これが 6 年前のことです。Linux は毎年革新と成長を続けているため、この 12 億ドルという数値を更新して、現在の Linux の状況を反映して、適切な開発費（およびソフトウェア開発費自体の上昇分）を推定する必要があります。本稿は、一般 的な Linux ディストリビューションの総開発費を推定し、2002 年の発表以来広く使用されてきた 12 億ドルの数値を更新す ることを目的としています。
本稿では、2008 年 5 月 13 日にリリースされた Fedora 9 ディストリビューションを分析しています。このディストリビューションは 一般に広く利用され、Linux の市場で大きな割合を占める Red Hat Enterprise Linux のベースにもなっています。Wheeler 氏が 2002 年の論文で分析した Red Hat Linux 7.1 ソフトウェアの直系でもあります。
また、この分析では David A. Wheeler 氏の有名な SLOC ツールである SLOCCount を使用しました。SLOCCount は業界 標準の COnstructive COst MOdel（COCOMO）を使用しています。このソフトウェアコスト推定モデル5は Barry Boehm 氏 6により開発されました。このモデルでは基本的回帰式7に、過去のプロジェクトデータと現在のプロジェクトの特徴から抽出し たパラメータを用いています8。本稿では Wheeler 氏の 2002 年の分析を更新し、増大する Linux カーネル、および、その他 のパッケージのコードベースに加え、ソフトウェア開発者の年俸の上昇分を含めました（詳細については、次の「アプローチ」の セクションを参照してください）。 この方法で計算すると、Linux ディストリビューション Fedora 9 を 2008 年時点において、従来の方法で開発した場合、108 億ドルかかります。
アプローチ
基本的なアプローチ
1. ソースコードファイルを非圧縮形式でインストールします。そのためには、事前にソースコードをダウンロードして、テストマ シンに正しくインストールすることが必要です。2.
ソース コードの行数（SLOC）を計算します。SLOC を注意深く定義することが必要です。 3. 推定モデル（COCOMO）を使用します。従来方法で同じシステムを開発した場合の労力とコストを計算します。 ソースコードのインストールおよび分析の方法については、「付録」を参照してください。2002 年の分析を更新するため、2002 年の分析で使用されたのと同じコードベースとして、Fedora（Red Hat Enterprise Linux の基盤となるコミュニティのディストリビューション）を評価することにしました。また、Fedora 9 を評価するにあたり、 mirrors.kernel.org のミラーアーカイブで公開されていたすべての Fedora 9 パッケージを調査しました。評価対象の Fedora 9 のパッケージを恣意的に決めることのないよう、すべてのパッケージを調査することにしました。Fedora には Red Hat のエンター プライズバージョンを大幅に上回るソフトウェアが含まれています。その理由のひとつは、多様性に富んだコミュニティが Fedora の開発に関わっているからです。SLOCCount アプリケーションの使用は驚くほど簡単です。ソースコードが格納された正しい ディレクトリを指定して実行するだけです。プログラムの機能およびその使用方法の詳細は、Wheeler 氏の Web サイト9で確 認できます。 これらのディストリビューションのコストを計算するために、コンピュータプログラマの基本給与を米国労働統計局で調べました。 労働統計局によると、2008 年 7 月、米国のプログラマの平均給与は 75,662.08 ドル10でした。この金額を SLOCCount で 使用しました（最近のソフトウェア開発はグローバル化しているため、米国の給与だけでは十分とはいえません。さらに細かく 分析するのであれば、世界の平均給与を開発コストの基準として使用するのもひとつの方法です）。 ただし、給与だけがソフトウェア開発費の決定要因というわけではありません。Wheeler 氏はその論文の中で、SLOCCount には諸経費のパラメータが存在することを指摘しています。これにはテスト、機材、会社運営費、開発者の報酬の総額が含 まれます。このパラメータは配賦率とも呼ばれます。 これらの配賦額がどれほど急速に増加するか一例を挙げると、米国では専門職の社員の補償率（病欠、休暇、保険）は 平均で 29％です11。そのため、プログラマの米国での平均給与は 75,662.08 ドルですが、実際には補償だけでも 97,604.08 ドルを雇用主が負担していることになります。これは配賦率全体のほんの一部に過ぎません。 Wheeler 氏の推定では、配賦率の合計値は 2.4 です。この数値は会社や地域によって異なりますが、その後の調査でも今 回のテストのためにこの数値の調整が必要であるという十分な証拠は得られませんでした。
ソースコードと推定コストの試算結果
最終的に、上記で説明したすべての前提を考慮すると、Fedora 9 の SLOC と推定開発費は以下のとおりになります。物理的なソースコードの行数（SLOC）の合計
204,500,946
推定開発作業量、人年（人月）
（基本 COCOMO モデル、人月＝2.4*（KSLOC**1.05））
59389.53 (712674.36)
推定開発期間、年（月）
（基本 COCOMO モデル、月＝2.5*（人月**0.38））
24.64 (295.68)
推定開発費の合計
（平均給与＝$75,662.08/年、諸経費率＝2.40）
$10,784,484,309
備考： SLOCCount の年間給与は 2000 年では 56,286 ドルでした。現在のコストを 2000 年のコストに換算すると興味深 い結果になります。そのためには、2008 年の Fedora 9 の総開発費計（10,784,484,309 ドル）を 0.744 で乗算します。0.744 は、SLOCCount で使用されるプログラマの 2000 年の給与（56,286 ドル）に対する 2008 年 7 月の給与（75,662.08 ドル） の比率です。この計算では、2000 年時点での Fedora 9 の開発費は 80 億ドルを少し上回ります。このことから、この 6 年間 でどれほど多くのコードと機能が Linux ディストリビューションに追加されたかわかります。Linux カーネルと中間モデルについて
本稿の分析の過程で、単一の Linux ディストリビューションであってもすべてのコンポーネントを
平等に扱わないほうがいいことがわかりました。プロジェクトによっては、その性質と複雑さから
COCOMO モデルで異なる考察が必要です。
このことを最も明確に指摘したのは Wheeler 氏でした。同氏は 2002 年の論文を補足する論文で、Linux カーネルに対して 異なる予測モデルが必要であると強調したのです12。この新しい論文で同氏は、一般的に Linux カーネルコードは「平均的 な」アプリケーションより複雑なため、基本 COCOMO モデル以上の分析が必要であると主張しました。たとえば、Mozilla のよ うなユーザー空間アプリケーションは、はるかに高いレベルで抽象化され、はるかに少ないタスクを処理するため、コード作成も はるかに簡単です。最新のエンタープライズクラスのオペレーティングシステムのカーネルは、複雑な作業を大量に、しかも同 時に処理することが求められます。 Wheeler 氏の説明によると、カーネルの評価にはディストリビューションのすべての要素の分析に使用される標準の手法では なく、中間 COCOMO モデルを使用すべきとのことです。中間モデルは変数の選択肢が豊富なため、複雑なソフトウェアでも より正確な分析が期待できます。2004 年の論文で同氏はこれらのパラメータの推定値を説明しましたが、それによって全体 が調整され、SLOCCount の作業効率値がデフォルトの 3 から 4.64607 へとなりました。また、作業指数値も 1.12 に変更さ れました。この値はソフトウェア開発推計用の中間 COCOMO モデルで半分離ソフトウェアプロジェクトに適用されます。これらの新しいパラメータを念頭に、Fedora 9 に含まれる Linux ストックカーネル linux-2.6.25.i686 で別の評価を行いました。
物理的なソース コードの行数（SLOC）の合計
6,772,902
推定開発作業量、人年（人月）
（作業人月＝4.64607*（KSLOC**1.12））
7557.4 (90688.77)
推定開発期間、年（月）
（基本 COCOMO モデル、月＝2.5*（人月**0.38））
15.95 (191.34)
推定平均開発者数（作業量/期間）
473.96
推定開発費の合計
（平均給与＝$75,662.08/年、諸経費率＝2.40）
$1,372,340,206
この研究のアプローチの制約と利点
Linux のように複雑で進化を続けるシステムの場合、その価値を完璧に予測する方法はあり
ません。本稿の手法は最良のアプローチであると考えられますが、場合によっては Linux の価
値を過大または過小に評価している可能性があります。このアプローチには次のような制約が
あります。
COCOMO モデルは従来型のソフトウェアの開発を調査して設計されました。そのため、Linux のようにコラボレーションに よって開発されたオープンソースのソフトウェアプロジェクトに内在するテストの複雑さを過小評価しているように思われま す。大小を含め、膨大な量の変更が行われ、かつ、開発者もそれぞれのプロジェクトも広く分散しているため、Linux エ コシステムの参加者に対するテストの負担は単独の企業が行うよりも 1 桁大きくなります。 Linux ディストリビューションの価値の評価におけるもうひとつの問題点は、基本となる Linux ディストリビューションの構成 要素の判断がむずかしいことです。本稿では、Fedora の公開されたソース コードのレポジトリにあるすべてのパッケージ を対象にしています。ただし、Fedora より小さいディストリビューションもあれば（LiveCD バージョンなど）大きいディストリビ ューションもあります。たとえば、Debian GNU/Linux13のレポジトリは Fedora のレポジトリより大規模です。また、ディストリビューションには入っていないオープンソースのソフトウェアも数多くあります。オープンソースの世界は広大なため、本稿 では、1 つのディストリビューションの利用できるパッケージを使用することにしました。 SLOC による分析の最大の弱点は、ソフトウェアプロジェクトへの追加だけが焦点になっていることです。たとえば、カーネ ルの開発では、コードが削除または変更されたときの人件費が最も高くなります。コードの追加ではなく、削除と変更に 必要な労力はこの推計には反映されていません。コラボレーションの開発モデルでは、コードを開発してから変更と削除 が行われるため、実際の値は既存のコードベースよりはるかに大きくなります。これは、そのプロセスを考えてみればわか ります。たとえば、数行のコードがカーネルに追加されると、その変更に対応するためにさらに多くの変更が必要になりま す。依存関係と結果を把握してからコードを変更する作業は、この分析では十分に考慮されていません。 コラボレーションによる開発では多くの場合、複数の個人やグループが異なるアプローチを使用して同じ技術的問題を 解決しますが、これらのアプローチの中で「勝ち組」として最終バージョンに含まれるのは１つだけです。「負け組」のアプ ローチは最終製品には含まれないため、この SLOC のアプローチではこのようなアプローチの開発作業は考慮されていま せん。 ソフトウェアコードの行数はディストリビューションやディストリビューションのバージョンによって大きく異なるため、1 つの分 析で「Linux」の価値を正しく評価できるわけではありません。分析には多くのオプションがあり、本稿で選択したのはその うちのたった１つです。そのため、すべてのディストリビューションが共有する個々のパッケージ（カーネル）の予測の方が興 味深いものになります。 残念ながら、この手法では価値は量に一致します。Linux のコミュニティでは「膨張」を懸念しますが、Linux にはほとん ど使用されないコードも古いドライバと同様に数多く含まれています。ただし、Linux にはアーキテクチャに固有のコードと ドライバの両方が含まれているため、このようなコードを含めることは重要です（他のオペレーティングシステムとはこの点 で異なります）。その結果、これらの要素が OS に含まれない他のオペレーティングシステムよりもこの数値は大きくなりま す。
本稿ではすべての開発が米国で行われ、米国での労働に関連するコストを前提としています。多くのソフトウェア開発 は本質的にグローバルに行われるため、労務費も大きく異なります。
本稿で使用する数値は、Linux ディストリビューションをスクラッチ開発した場合のコストを示しています。これほど広く利 用されている技術のコード変更には、計り知れないほど膨大な経済的影響があるため、これはコストの予測であって、 大きなエコシステムに対する価値ではない点に注意してください。
Linux の成長
本稿では、Linux のコードベースを段階的に更新および拡大するための積年の開発費も考
慮していません。これらの数値を見ると（または Linux ディストリビューションを直接体験すると）、
Linux ディストリビューションに含まれる機能が過去 6 年間でどれほど爆発的に増えたかすぐに
わかります。
たとえば、Fedora Linux 9 の物理的なソースコードの行数（SLOC）は 2 億 400 万を超えているのに対し、Red Hat Linux 7.1 （2002 年リリース）では 3,000 万、バージョン 6.2 では 1,700 万です。わずか 6 年でコードベースは 1 億 7,400 万も増えました。 COCOMO コストモデルを使用した予測では、Fedora 9 に必要な開発時間は 60,000 人年です（Red Hat 7.1 では 8,000 人年、バージョン 6.2 では 4,500 人年）。Fedora 9 は Red Hat Linux 7.1 に比べて規模が約 680％、作業が 750％、開発 費が 900％増加しています。これは、世界で利用できる成熟度の高いオープンソース/フリーソフトウェアプログラムが増えてい るためです。このような増加は、Linux が大きく成長していることを示しています。オープンソースのパッケージを継続的に追加 することで Linux ユーザーに提供されるアプリケーションが強化され、それによって Linux はより魅力あるコンピューティングプラッ トフォームになります。 また、Linux は本質的にモジュラー（ディストリビューションの構成において）であることも、ディストリビューションに含まれるリスト の上位 10 個のパッケージを見れば明らかです。時間と関心があれば、たとえば、組み込み型 Linux ディストリビューションの 上位コンポーネントとそのの開発費を分析してみると興味深い結果になるでしょう。
Linux の成長は行数の追加だけでは評価できません。最近の「Who Writes the Linux Kernel」の記事では次のように語られ ています。「これまでのリリースでは、カーネル チームは年間約 10％の成長率を維持していますが、コードツリーのサイズを考 えるとこれは非常に優秀です。カーネルが増加しているだけではありません。カーネルのソースツリーが変更されるたびに、その 変更のために行が追加、修正削除されているのです14。」
Linux カーネルは Linux の他の構成要素よりも多く変更されているかもしれませんが、本稿では Linux 全体が毎年一定のペ ースで増加し、変更されているものとして数値に反映しています。Linux カーネルは Linux ディストリビューションの（非常に重 要ではあるものの）小さな一部に過ぎないため、毎年膨大な開発費が Linux につぎ込まれますが、この文書では十分に検 証していません。
結論
これで Linux の「価値」を理解できたでのしょうか。この質問には完全に答えることはできなくて
も、いくつか明らかになったことがあります。Linux の真価は再使用できること、そしてその優れ
た柔軟性にあります。
Linus Torvalds が（実際とは逆に）Linux ユーザーのコントリビューションを他のユーザーが再使用することを禁止していたら、コ ンピューティングの世界はどうなっていたでしょう。Linux を無料で、かつ、ニーズに合わせて修正できなかったら、Google は存 在したでしょうか。この 108 億ドルのソフトウェアを無料で使用できなかったら、350 ドル以下のウルトラモバイル PC という新し い成長分野は存在したでしょうか。開発費に 14 億ドルを投じたソフトウェアを無料で使用できなかったら、Amazon は Kindle 電子ブック リーダーの新製品を開発できたでしょうか。Linux ディストリビューションのソフトウェアの効果はコストだけではなく時 間にも現れます。これらの企業がデバイスごとやサーバーごとにライセンス料を支払わされたり、このようなソフトウェアを開発す るのに数千人月の開発時間をかけていたら、上記に例として挙げたようなことは経済的に不可能だったでしょう。 本稿から何を学べばいいのでしょうか。コミュニティベースの Linux ディストリビューションに相当な開発費が投じられているという ことは、コンピューティングの世界におけるその価値と重要性が増したことを反映しています。Linux 関連のプロジェクトに参加 する企業や個人は、開発の苦労を仲間（時には競合会社）と共有することでその価値をビジネスに活用しています。このよう な研究開発の苦労をマイクロソフトが行っているように、単独で背負ったなら、ソフトウェア開発は高価なアプローチになるとい うことがだんだん明らかになってきました。ソフトウェア企業の過去のの独占的なポジションがあれば開発に膨大な資金を供給 できますが、コラボレーションによる開発を共有する競合からは、そのような独占的な立場はありえないでしょう。 本稿でも説明しましたが、あらゆるコンピューティングの分野への Linux の浸透を見てもわかるように、コラボレーションによる開 発によって大きな経済価値が創出されます。IBM、Intel、HP、富士通、NEC、日立、Google、Novell、Oracle、Red Hat を はじめ、多くの企業がこのソフトウェア開発のオープンモデルによって作り出された巨大なエコシステムに参加し、活用していま す。ただし、間違ってはいけません。企業も参加していますが、このソフトウェアとその価値の拡大には個人も重要な役割を 担っています。結局、すべてはそこから始まったのですから。
本稿のデータは SLOCCount（Copyright (C) 2001-2004 David A. Wheeler）によって作成されました。SLOCCount は GNU GPL に基づいてライセンス供与されるオープン ソース ソフトウェア/フリーソフトウェアです。
SLOCCount は一切の保証を伴いませんが、GNU GPL ライセンスで規定された条件に基づいて再配布できます。詳細につ いては説明書をお読みください。
謝辞
この文書のレビューとフィードバックに協力してくれた James Bottomley 氏、Jon Corbet 氏、David A. Wheeler 氏に感謝の 意を表します。
付録
Fedora 9 については、インストール CD にはソースコードが収録されていないため、
mirrors.kernel.org の Web サイトからダウンロードしました。分析対象ファイルの決定には主観
が影響してしまうため、利用可能な 5,547 のオープンソースパッケージ（src.rpm）をすべてダウ
ンロードしてからテストマシンにインストールしました。
FTP サーバーから src.rpm をダウンロードしてインストールしました。ｒｐｍがバイナリ PRM としてインストールされなくても（実際 にはアプリケーションとしてテストマシンにインストールされる可能性があります）、root アクセス権なしでソース RPM をビルドす るし手順を採用しました（Red Hat ハウツー ページのアーカイブの手順を修正しました）15。 ソースコードは test ユーザーのホームディレクトリにダウンロードしました。 gedit を使用してスクリプトを作成し、.rpmmacro として同じホームディレクトリに保存しました。インストール先ディレクトリを作 成し、次のコマンドを使用して src.rpm ファイルをインストールしました。 rpm -ivh *.src.rpm 時間がかかりますが、5,547 のパッケージすべてをインストールし、仕様書ファイル（.spec）は rpm/SPECS ディレクトリに、ソー スファイルとグラフィックは rpm/SOURCES ディレクトリに保存しました。 この段階で src.rpm ファイルの構築と準備が完了し、すべてのアプリケーションのソースコードとともに、rpm/BUILD ディレクトリ のそれぞれのディレクトリに保存しました。この作業には、次のコマンドを使用しました。rpmbuild -bp --nodeps *.spec
このコマンドの実行後、すべてのパッケージが BUILD ディレクトリに正しくインストールされました。
実際の計算はこの後で行います。ディストリビューションは単一のソフトウェアプロジェクトではないため、単一のものとしては計 算しません。SLOCCount ではそのための補正用のパラメータとして、--multiproject が提供されています。
Fedora 9 のレポートには、次のコマンドを使用しました。
sloccount --multiproject --personcost 75662.08 /usr/src/rpm/BUILD/ &> sloc.txt
さらに詳しく分析するには、Fedora 9 のソース コードの上位 10 個のパッケージを使用します。
