ギガバック（10億ドル）以上：GNU/Linuxのサイズ推定（2001年）

ギガバック以上：GNU/Linuxのサイズ推定
David A. Wheeler (dwheeler@dwheeler.com)
2001年6月20日
バージョン 1.0

この記事は、代表的なGNU/LinuxディストリビューションであるRed Hat Linux 7.1のソースコード量を分析し、興味深いと思われる結果を提示します。

特に、このLinuxディストリビューションを米国の従来のプロプライエタリな手段で開発した場合、10億ドル（1,000百万ドル、ギガバック）以上かかると推定されます（2000年米ドル換算）。これは、約1年前にリリースされたRed Hat Linuxバージョン6.2の6億ドルの推定値と比較してください。また、Red Hat Linux 7.1には3000万物理ソース行（SLOC）以上が含まれていますが、バージョン6.2の1700万SLOCをはるかに超えています。COCOMOコストモデルを使用すると、このシステムは開発に約8,000人年を要したと推定されます（バージョン6.2の開発に必要な4,500人年と比較して）。したがって、Red Hat Linux 7.1は、Red Hat Linux 6.2と比較して、サイズ、労力、および従来の開発コストで60%以上の増加を表しています。これは、世界中で利用可能な成熟した、または成熟しつつあるオープンソース/フリーソフトウェアプログラムの数が増加したためです。

他にも多くの興味深い統計情報が得られます。最大のコンポーネント（順不同）は、Linuxカーネル（デバイスドライバを含む）、Mozilla（Webブラウザ、メールクライアント、HTMLエディタを含むNetscapeのオープンソースWebシステム）、X-windows（グラフィカルユーザーインターフェースのインフラストラクチャ）、gcc（コンパイルシステム）、gdb（デバッグ用）、基本的なバイナリツール、emacs（テキストエディタであり、それ以上のもの）、LAPACK（数値線形代数のための大規模Fortranライブラリ）、Gimp（ビットマップグラフィックエディタ）、およびMySQL（リレーショナルデータベースシステム）でした。コード行数でソートされた使用言語は、C（71% - 以前は81%）、C++（15% - 以前は8%）、シェル（kshを含む）、Lisp、アセンブリ、Perl、Fortran、Python、tcl、Java、yacc/bison、expect、lex/flex、awk、Objective-C、Ada、Cシェル、Pascal、sedでした。

最も一般的なソフトウェアライセンスはGNU GPLです。ソフトウェアの半分強は単純にGPLでライセンスされており、コピーレフトライセンス（GPLおよびLGPL）を使用するソフトウェアパッケージは、少なくとも一部または代替として、コードの63%を占めていました。あらゆる点で、コピーレフトライセンス（GPLおよびLGPL）はこのLinuxディストリビューションで支配的なライセンスです。対照的に、ソフトウェアの0.2%のみがパブリックドメインです。

この記事は、GNU/Linuxのサイズを推定した以前の論文を更新したものです。Red Hat Linux 6.2を測定しました ["Wheeler 2001"]。Red Hat Linux 6.2は2000年3月にリリースされ、Red Hat Linux 7.1は2001年4月にリリースされたため、この記事は約1年間の変化を示しています。

詳細については、http://www.dwheeler.com/sloc で入手できます。

1. はじめに

GNU/Linuxオペレーティングシステム（単に「Linux」とも呼ばれる）は、未知のものから強力な市場力へと成長しました。ある調査では、インターネットサーバーのほとんどが他のどのオペレーティングシステムよりもLinuxを使用していることがわかりました ["Zoebelein 1999"]。IDCによると、1999年に購入されたサーバーオペレーティングシステムの25%がLinuxであり、Windows NTの38%に次ぐ第2位でした ["Shankland 2000a"]。

Linuxは無料または低コストで入手できるという理由だけでなく、これには多くの理由があるようです。例えば、実験ではLinuxは非常に信頼性が高いことが示唆されています。1995年の個々のコンポーネントセットの調査では、GNUおよびLinuxコンポーネントは、プロプライエタリなUnix競合製品よりも有意に高い信頼性を示しました（GNUとLinuxでは6%から9%の障害率、プロプライエタリソフトウェアでは平均23%の障害率でした） ["Miller 1995"]。1999年のZDnetによる10ヶ月間の実験では、MicrosoftのWindows NTが「典型的な」イントラネット負荷の下で6週間に1回クラッシュしたのに対し、同じ負荷とリクエストセットを使用したLinuxシステム（2つの異なるディストリビュータから）は一度もクラッシュしませんでした ["Vaughan-Nichols 1999"]。

しかし、おそらくLinuxが多くの開発者やユーザーに人気がある最も重要な理由は、そのソースコードが一般的に「オープンソースソフトウェア」および/または「フリーソフトウェア」（ここで「フリー」は「自由」を意味します）であることです。「オープンソースソフトウェア」または「フリーソフトウェア」のプログラムは、本質的に、ロイヤリティやその他の制限なしにソースコードを入手、表示、変更、再配布できるプログラムです。「オープンソースソフトウェア」のより正式な定義はOSI [1999]で、フリーソフトウェアのより正式な定義はFSF [2000]で入手でき、これらのトピックに関するその他の一般的な情報はWheeler [2000a]で入手できます。オープンソース/フリーソフトウェアを使用する定量的な根拠はWheeler [2000b]で示されています。Linuxオペレーティングシステムは、実際にはLinuxカーネルを含むコンポーネントのスイートであり、さまざまなディストリビュータによってパッケージ化、販売、サポートされています。Linuxカーネルは「オープンソースソフトウェア」/「フリーソフトウェア」であり、これは典型的なLinuxディストリビューションの他のすべての（またはほぼすべての）コンポーネントについても同様です。オープンソースソフトウェア/フリーソフトウェアは、ユーザーが特定のベンダーの虜になることから解放します。なぜなら、ユーザーは問題を即座に修正し、システムをカスタマイズし、ソフトウェアを任意の方法で分析できるからです。

驚くべきことに、Linuxは誰でも任意のプロパティについて分析できるにもかかわらず、Linuxに含まれるソースコード行数（SLOC）の公開分析はほとんど見つかりませんでした。私自身以外に見つかった唯一の公開データは、Microsoftが「ハロウィーンI」および「ハロウィーンII」と呼ばれるドキュメントで開発したものです ["Halloween I"] ["Halloween II"]。以前の論文では、Red Hat Linux 6.2とハロウィーン論文の数値を調査しました。

この記事は、私の以前の論文を更新し、今日のGNU/Linuxディストリビューションのサイズの見積もりを示し、従来のソフトウェア開発技術でこの典型的なLinuxディストリビューションを再構築するのにかかる費用を推定します。さまざまな定義と仮定が含まれているため、他の人がこれらの数値の意味を正確に理解できるようにします。以前のバージョンを最初に読む必要がないように、意図的にこの記事を作成しました。

私の目的のために、私は「代表的な」LinuxディストリビューションとしてRed Hat Linuxバージョン7.1を選択しました。このディストリビューションがいくつかの理由で合理的に代表的であると信じています：

1. IDCによると、Red Hat Linuxは1999年に販売された最も人気のあるLinuxディストリビューションでした ["Shankland 2000b"]。Red Hatは1999年の全販売数の48%を販売しました。市場シェアで2番目に大きいディストリビューションはSuSEで15%でした。すべてのLinuxコピーがこの研究でカウントされる方法で「販売」されているわけではありませんが、この研究は少なくともRed Hatのディストリビューションが人気のあるものであることを示しています。
2. 多くのディストリビューション（Mandrakeなど）は、古いバージョンのRed Hat Linuxに基づいています。
3. すべての主要な汎用ディストリビューションは、Red Hatと競争するためだけでも、Red Hat Linuxがサポートする種類の機能（少なくとも）をサポートしています。
4. すべてのディストリビュータは、統合するコンポーネントを選択するための同じオープンソースソフトウェアプロジェクトのセットから開始します。したがって、他のディストリビューションも、同じ種類の機能に対して、しばしば同様のサイズの同じコンポーネントまたは同様の種類のコンポーネントを選択する可能性が高いです。

異なるディストリビューションやバージョンでは異なるサイズ数値が得られますが、この記事は「すべて」のディストリビューションを評価しようとはしていませんが、有益であると願っています。一部のディストリビューション（SuSEなど）はさらに多くのアプリケーションを追加するかもしれませんが、これはより大きな（より小さいではない）サイズと推定労力を生み出すだけであることに注意してください。私がこのプロジェクトを開始した時点で、バージョン7.1がRed Hat Linuxの最新バージョンでしたので、分析のためにそのバージョンを選択しました。

Red Hat Linux 6.2は2000年3月にリリースされ、Red Hat Linux 7は2000年9月にリリースされました（そのコードはカウントしていません）、そしてRed Hat Linux 7.1は2001年4月にリリースされました。したがって、Red Hat Linux 7.1と6.2の違いは、約13ヶ月（約1年間）にわたって蓄積された違いを示しています。

明らかに、世界中にはこの論文でカウントされているよりもはるかに多くのオープンソース/フリーソフトウェアがあります。しかし、ディストリビュータの仕事は、これらのさまざまなオプションを調査し、ターゲット市場にとって十分に成熟しており有用であると信じるソフトウェアを選択することです。したがって、特定のディストリビューションを調査することは、そのようなソフトウェアの選択的な分析につながります。

セクション2では、このディストリビューションの「サイズ」を推定するために使用されたアプローチを簡単に説明します（詳細は付録Aにあります）。セクション3では、いくつかの結果について説明します。セクション4では結論を提示し、その後に付録を続けます。

2. アプローチ

私の基本的なアプローチは以下の通りです：

1. ソースコードファイルを非圧縮形式でインストールする。これには、分析するソースコードを慎重に選択する必要があります。
2. ソースコード行数（SLOC）をカウントする。これには、SLOCの慎重な定義が必要です。
3. 推定モデルを使用して、同じシステムをプロプライエタリな方法で開発した場合の労力とコストを推定する。これには、推定モデルが必要です。
4. 各コンポーネントのソフトウェアライセンスを決定し、これらのカテゴリに基づいた統計情報を開発する。

このアプローチの詳細については、付録Aで説明します。ただし、ここでいくつかの要約ポイントを述べる価値があります。

2.1 ソースコードの選択

Red Hatディストリビューションで提供されるすべてのソフトウェアを含めましたが、Red Hatはもはや他のCPUアーキテクチャにのみ適用されるソフトウェアパッケージを含めなくなったことに注意してください（したがって、x86ファミリに適用されないパッケージは除外されました）。「古い」バージョンのソフトウェアや、非ベータ版が入手可能な場合に「ベータ」ソフトウェアは含めませんでした。代替がない場合に「ベータ」ソフトウェアを含めました。なぜなら、一部の開発者は、広く使用され信頼性が高いと認識されていても、「ベータ」ラベルを削除しないからです。

MD5チェックサムを使用して重複ファイルを特定し無視しました。そのため、同じファイルの内容が複数のファイルに出現した場合、それは一度だけカウントされました（タイブレーカーとして、そのようなファイルはアルファベット順で最初に適用されるビルドパッケージに割り当てられます）。

MakefileおよびRPMパッケージ仕様のコードは含まれていませんでした。自動生成されたコードを検出するためにさまざまなヒューリスティックが使用され、そのようなコードもカウントから除外されました。言語がソースプログラムファイルであるかどうか、およびその言語が何であるかを判断するために、他の多くのヒューリスティックが使用されました。

2.2 SLOCの定義

この論文では、「物理ソースコード行数」（物理SLOC）をSLOCの主要な尺度として使用しました。より非公式には、この論文における物理SLOCは、コメントと空白（タブとスペース）以外のものを含む行です。より具体的には、物理SLOCは次のように定義されます：「物理ソースコード行とは、改行またはファイルの終端マーカーで終わる行であり、少なくとも1つの非空白、非コメント文字を含むもの」。コメント区切り文字（コメントを開始および終了する改行以外の文字）はコメント文字と見なされました。空白のみを含むデータ行（例：複数行文字列内のタブとスペースのみの行）は含まれませんでした。

「論理的」SLOCがここで使用される主要な尺度ではないことに注意してください。論理的SLOC尺度の1つの例は、「Cファイル内のすべての終端セミコロンのカウント」でしょう。物理SLOCは、測定する必要のある言語が非常に多かったため、論理的SLOCの代わりに選択されました。この規模で自由に利用できるツールを機能させるのに苦労し、非自由なツールは私の予算には高すぎました（それらがより良く機能したかどうかも確実ではありません）。自分でツールを開発する必要があったため、実装がはるかに簡単な尺度を選択しました。Park [1992]は、この理由やその他の理由で物理SLOC尺度の使用（最低限として）を推奨しています。物理SLOC尺度には欠点があります。特に、物理SLOC尺度はコードのフォーマット方法に敏感です。しかし、論理的SLOC尺度にも問題があります。第一に、述べたように、論理的SLOCを測定するツールの実装はより困難であり、より洗練されたコード分析が必要です。また、論理的SLOC尺度は多数存在し、さらに慎重な定義が必要です。最後に、論理的SLOC尺度は測定対象の各言語に対して再定義する必要があり、言語間の比較をより困難にします。ソフトウェアサイズの測定に関する詳細、および決定する必要のある問題については、Kalb [1990]、Kalb [1996]、およびPark [1992]を参照してください。

これには、すべてのファイルを言語タイプ別に分類する必要がありました（コメント、文字列などの正しい構文を適用できるようにするため）。また、自動生成されたファイルを検出し、無視する必要がありました。幸いなことに、私のツール「sloccount」はこれを自動的に行います。

2.3 推定モデル

物理SLOCを使用するという決定は、労力推定器については、新しい「COCOMO II」モデルではなく、元のCOCOMOコストおよび労力推定モデル（Boehm [1981]を参照）を使用する必要があることを意味しました。これは、COCOMO IIが物理SLOCの代わりに論理的SLOCを入力として必要とするためです。

基本的なCOCOMOは、製品設計（計画と要件が開発された後）から詳細設計、コード、単体テスト、および統合テストまでの時間を推定するように設計されています。計画と要件開発は含まれていないことに注意してください。COCOMOは、管理オーバーヘッドとドキュメント（例：ユーザーマニュアル）の作成、およびコード自体を推定するように設計されています。ここでも、モデルの仮定の詳細については、Boehm [1981]を参照してください。特に注意すべきは、基本的なCOCOMOには、他の人間言語への翻訳（ドキュメント、データ、プログラムメッセージ）やフォントの開発時間は含まれていないことです。

これらのモデルは不完全ではあるものの、オープンソース/フリーソフトウェアプロジェクトの労力推定には依然として有効であると信じる理由があります。多くのオープンソースプログラムは人的資源の管理を必要としませんが、技術的な管理、インフラストラクチャのメンテナンスなどは依然として必要です。オープンソースプロジェクトでは設計ドキュメントはより非公式にキャプチャされますが、地理的に離れた開発者が多いオープンソースプロジェクトでは必要に応じてキャプチャされることがよくあります。明らかに、システムは依然としてプログラムされる必要があります。テストも行われますが、今日の多くのプロプライエタリプログラムと同様に、アルファ版およびベータ版リリースを通じてかなりのテストが行われています。さらに、多くのオープンソースプロジェクトでは、提出されたコードのピアレビューを通じて品質が向上しています。人間言語の翻訳とフォントの推定が含まれていないため、推定値は実際の値よりも低くなる可能性があります。

プログラマの平均給与については、2000年9月4日号のComputerWorldの給与調査を使用しました。その調査によると、米国のプログラマの平均年間給与は56,286ドルでした。オーバーヘッド、または「ラップレート」の公的に裏付けられた平均値を見つけることができませんでした。これは、オフィススペース、機器、オーバーヘッドスタッフなどのコストを推定するために必要な値です。2人のコストアナリストに話を聞いたところ、2.4が合理的なオーバーヘッド（ラップ）率であると示唆されました。一部のDefense Systems Management College（DSMC）のトレーニング資料では、2.3（一般および管理（G&A）オーバーヘッドを含まない125.95%+100%）、およびG&Aを含めると2.8（125%のエンジニアリングオーバーヘッド、それにG&Aのためにさらに25%）の例が示されています ["DSMC"]。これは、少なくとも2.4が妥当な推定値であることを示唆しています。明らかに、これらの値は会社や地域によって大きく異なります。この記事で提供される情報は、必要に応じて異なる数値を使用するのに十分です。これらは、私の最後のレポートで使用されたのと同じ値です。

2.4 ソフトウェアライセンスの決定

ソフトウェアライセンスは、そのソフトウェアの使用方法と再利用方法を決定し、オープンソースソフトウェアのライセンスは大きな議論の的となっています。よく知られているオープンソースライセンスには、GNU General Public License（GPL）、GNU Library/Lesser General Public License（LGPL）、MIT（X）ライセンス、BSDライセンス、およびArtisticライセンスがあります。GPLとLGPLは「コピーレフト」ライセンスと呼ばれます。つまり、ライセンスはコードがプロプライエタリになるのを防ぐように設計されています。詳細については、Perens [1999]を参照してください。明白な質問は、「開発者はソフトウェアをリリースする際にどのライセンスを選択しているのか」と「さまざまなライセンスの下でどれだけのコードがリリースされているのか」ということです。

さまざまなライセンスを使用するソフトウェアの量の近似値は、この特定のディストリビューションで見つけることができます。Red Hat LinuxはRed Hat Package Manager（RPM）を使用しており、RPMは各パッケージのライセンスデータをキャプチャすることをサポートしています（これらは仕様ファイル内の「Copyright」および「License」フィールドです）。この情報を使用して、各ライセンスでカバーされているコードの量を決定しました。このフィールドは単なるテキスト文字列であるため、データにはいくつかのばらつきがあり、修正する必要がありました。例えば、一部のエントリは「GNU」と記載されていましたが、ほとんどは「GPL」と記載されていました。一部のパッケージでは、Red Hatはライセンス情報を含んでいませんでした。その場合、特定の従来のファイル名と内容を探すプログラムを作成してライセンスを特定しようとしました。

これは不完全なアプローチです。一部のパッケージは異なるコード片を含み、異なるコード片に異なるライセンスが適用されます。一部のパッケージは「デュアルライセンス」されており、つまり複数のライセンスの下でリリースされています。これらの他のライセンスが記載されている場合もあれば、そうでない場合もあります。実際には2つのBSDライセンス（「古い」ライセンスと「新しい」ライセンス）がありますが、仕様ファイルはそれらを区別しません。また、ライセンスが一般的なライセンスの小さなセットのいずれかでない場合、Red Hatは「distributable」のような説明的でないフレーズを割り当てる傾向がありました。私の自動化された技術も限定的でした。特に、一部のライセンス（例：GPLおよびLGPL）は自動的に認識しやすいですが、BSDライクおよびMITライクのライセンスはライセンステキストが異なり、自動的に認識するのがより困難です（そして、ライセンスの変更によっては、それらを非オープンソース、非フリーソフトウェアにする可能性があります）。したがって、Red Hatがパッケージのライセンスを特定しなかった場合、BSDとGPLの両方のライセンスでデュアルライセンスされたプログラムは、これらの技術を使用してGPLのみでラベル付けされる可能性があります。それでも、このアプローチは、さまざまなライセンスを使用するソフトウェアの量に関する洞察を与えるのに十分です。将来の研究では、各ライセンスを個別に調べて分類する可能性があります。そのような研究では、2つのライセンスが特定の状況で「等しい」かどうかを判断するために、いくつかの弁護士が必要になるかもしれません。

この文脈で言及する価値のあるプログラムの1つはPythonです。Pythonはいくつかの異なるライセンスを持っていました。バージョン1.6以降（2.1まで）は、Free Software Foundation（FSF）がGPLと互換性がないと考えていた、より複雑なライセンスを持っていました。最近、Pythonライセンスの別の変更により、PythonがGPLと完全に互換性を持つようになりました。Red Hat Linux 7.1には古いバージョンのPython（1.5.2）が含まれています。これは、これらのライセンス問題のためであると思われます。Red HatがPythonの最新バージョンを将来含めることができるようになるでしょう。いずれにせよ、Python固有のライセンスはいくつかあり、それらはすべて正当に「Python」ライセンスと呼ぶことができます。Red HatはPython自体を「Distributable」ライセンスとしてラベル付けしており、パッケージDistutils-1.0.1は「Python」ライセンスとしてラベル付けされています。これらのラベルはこの論文で保持されています。

3. 結果

このアプローチに基づくと、いくつかの結果が得られます。セクション3.1では最大のコンポーネント（SLOCでソート）を提示し、セクション3.2ではLinuxカーネルのSLOCからの結果を具体的に示し、セクション3.3では言語別の合計カウントを提示し、セクション3.4では合計ファイル数を提示します（SLOCの代わりに）、セクション3.5ではソフトウェアライセンス別にグループ化された合計カウントを提示し、セクション3.6では合計SLOCカウントを提示し、セクション3.7では労力とコストの推定値を提示します。

3.1 SLOC別最大コンポーネント

ソースコード行数（SLOC）で測定された上位35個の最大のコンポーネントを、それらのライセンスとともに示します（これらのライセンス値の決定方法についてはセクション2.4を参照）。言語セクションでは、「ansic」はCコード、「asm」はアセンブリ、「sh」はBourneシェルおよび関連シェル、「cpp」はC++を意味します。

SLOC	Directory	SLOC-by-Language (Sorted)
2437470 kernel-2.4.2	ansic=2285657,asm=144411,sh=3035,perl=2022,yacc=1147,	tcl=576,lex=302,awk=248,sed=72
			[GPL]
2065224 mozilla		cpp=1279902,ansic=739470,perl=21220,sh=13717,asm=5212,	java=3107,yacc=1831,lex=470,csh=271,sed=24
			[MPL]
1837608 XFree86-4.0.3	ansic=1750460,asm=35397,cpp=20725,sh=14666,tcl=9182,	yacc=3360,perl=1675,lex=1608,awk=393,csh=85,sed=57
			[MIT]
984076	gcc-2.96-20000731	ansic=789901,cpp=126738,yacc=19272,sh=17993,asm=14559,	lisp=7161,fortran=3814,exp=3705,objc=479,sed=310,perl=144
			[GPL]
967263	gdb+dejagnu-20010316	ansic=871288,exp=58422,sh=12054,cpp=8252,yacc=5906,	asn=5031,tcl=4477,lisp=1403,sed=248,awk=170,java=7,fortran=5
			[GPL]
690983	binutils-2.10.91.0.2	ansic=489993,asm=161236,exp=13234,sh=12835,	yacc=5665,cpp=4777,lex=1488,perl=776,sed=561,lisp=394,awk=24
			[GPL]
646692	glibc-2.2.2		ansic=548722,asm=88413,sh=6036,perl=2120,awk=1037,	yacc=315,sed=49
			[LGPL]
627626	emacs-20.7		lisp=453898,ansic=169956,sh=2622,perl=884,asm=253,	csh=9,sed=4
			[GPL]
474829	LAPACK			fortran=473590,ansic=1239
					[Freely distributable]
455980	gimp-1.2.1		ansic=427967,perl=17482,lisp=9648,yacc=502,sh=381
					[GPL, LGPL]
402799	mysql-3.23.36		ansic=249350,cpp=84068,perl=25088,tcl=18980,sh=18323,	asn=3987,awk=1436,java=1149,sed=418
					[LGPL]
395194	tcltk-8.3.1		ansic=291457,tcl=84322,sh=12259,exp=5742,yacc=876,	awk=273,perl=265
					[BSD]
345949	kdebase-2.1.1		cpp=181210,ansic=158682,sh=4880,perl=1155,python=22
					[GPL]
323730	Mesa-3.4		ansic=286437,cpp=18189,asm=10002,sh=7611,objc=1184,	python=307
					[GPL/MIT]
321123	perl-5.6.0		perl=146755,ansic=118233,sh=49377,lisp=5739,yacc=996,	java=23
					[Artistic or GPL]
318430	libgcj			ansic=191432,cpp=56843,java=41716,sh=15581,asm=11262,	exp=841,perl=731,awk=24
					[GPL]
304819	teTeX-1.0		ansic=223491,perl=49789,sh=17634,cpp=9407,pascal=1546,	yacc=1507,awk=622,lex=323,sed=314,asm=139,csh=47
					[Distributable]
298742	qt-2.3.0		cpp=259310,ansic=34578,yacc=2444,sh=1493,lex=480,	perl=422,lisp=15
					[GPL]
286113	postgresql-7.0.3	ansic=237184,java=17540,yacc=9740,sh=8975,tcl=7751,	lex=1810,perl=1276,python=959,cpp=801,asm=70,csh=5,sed=2
					[BSD]
283785	kdelibs-2.1.1		cpp=261334,ansic=17578,sh=1887,java=1538,perl=731,	yacc=607,lex=110
					[LGPL]
277502	xemacs-21.1.14	ansic=199927,lisp=73366,sh=2948,perl=930,asm=247,	csh=62,sed=22
					[GPL]
264528	gs5.50			ansic=259471,cpp=2266,asm=968,sh=823,lisp=405,perl=336,	yacc=201,lex=58
					[GPL]
227354	krb5-1.2.2		ansic=197886,exp=19124,sh=5140,yacc=2474,perl=1529,	awk=393,python=348,lex=190,csh=147,sed=123
					[MIT]
215473	vnc_unixsrc		ansic=212766,cpp=848,asm=780,perl=648,sh=431
					[GPL]
213818	koffice-2.0.1		cpp=197637,sh=7296,yacc=3791,ansic=3213,perl=1801,	lex=80
					[GPL]
202842	openssl-0.9.6		ansic=131874,cpp=25744,perl=14737,asm=12428,python=10171,	yacc=3297,sh=2641,tcl=1583,lisp=224,objc=143
					[BSD-like]
200908	Python-1.5.2		python=101017,ansic=96521,lisp=2353,sh=673,perl=342,	sed=2
					[Distributable]
194799	bind-9.1.0		ansic=173830,sh=12101,yacc=6025,perl=2830,tcl=13
					[BSD-like]
192394	xpdf-0.92			cpp=167135,ansic=21621,sh=3638
					[GPL]
191379	php-4.0.4pl1		ansic=173334,cpp=7033,sh=6591,lex=1867,yacc=1569,	java=437,awk=367,perl=181
					[PHP]
190950	pine4.33			ansic=190020,sh=838,csh=62,perl=30
					[Freely distributable]
173492	abi				cpp=159595,ansic=12605,perl=725,sh=550,python=17
					[GPL]
167663	kdemultimedia-2.1.1	cpp=140731,ansic=23844,tcl=1004,sh=800,asm=598,	lex=578,perl=106,awk=2
					[GPL]
163449	4Suite-0.10.1		python=91445,ansic=72004
					[Apache-like]
159301	linuxconf-1.24r2	cpp=142970,perl=6738,sh=3821,java=3074,ansic=2613,	python=85
					[GPL]

オペレーティングシステムカーネル（Linux）は最大の単一コンポーネントであり、240万行以上のコード（主にC言語）です。これはRed Hat 6.2の150万行のコードと比較されます。Linuxカーネルに関する詳細な議論については、セクション3.2を参照してください。

次に大きいコンポーネントはMozillaです。これはWebブラウザ、メールリーダー、ニュースリーダー、HTMLエディタなどを含むアプリケーションのスイートであるため、大きくなっています。MozillaはNetscape Navigator 6.0の基盤です。MozillaはRed Hat Linux 6.2には全く含まれていませんでした。

次に大きいコンポーネントはXウィンドウシステムで、グラフィカルユーザーインターフェース（GUI）の重要な部分です。GUIの重要性、このプログラムの長い歴史（機能とサイズが増加する時間を与えた）、およびサポートする必要のある多くの互換性のないビデオディスプレイを考えると、これはおそらく驚くべきことではありません。

次に大きいのはgccコンパイルシステムで、CおよびC++コンパイラ、シンボリックデバッガ、バイナリファイル用のユーティリティセット、およびCライブラリ（実際には他のほとんどの言語ライブラリでも使用されています）が含まれます。Emacsが次に大きいですが、これは驚くべきことではありません。一部のユーザーはemacsしか使用しません（例：emacs経由でメールを読む）、emacsを仮想オペレーティングシステムのようなものとして使用します。

言語実装は、特にライブラリにおいて、それ自体で書かれる傾向があることに注意してください。Perlの実装は主にPerlで書かれており、Pythonは主にPythonで書かれています。興味深いことに、Tclについてはそうではありません。

すべてのコンポーネントとそのSLOCカウントの完全なリストについては、http://www.dwheeler.com/sloc/redhat71-v1/summaryを参照してください。

3.2 LinuxカーネルのSLOCの検討

最大の単一コンポーネントがLinuxカーネル（240万SLOC以上）であったため、その理由と影響を学ぶためにさらに調査しました。

カーネルの1,400,000行以上（Linuxカーネルの57%）が「drivers」サブディレクトリにあったことがわかりました。したがって、カーネルがそれほど大きい主な理由は、非常に多くの異なる種類の周辺機器をサポートしているためです。他のどのサブディレクトリもこれに匹敵しません。2番目に大きいのは「arch」ディレクトリ（446,000 SLOC以上、カーネルの18%）で、各CPUアーキテクチャのアーキテクチャ固有のコードが含まれています。多くの異なるファイルシステムをサポートすることもサイズを増加させますが、予想ほどではありません。ファイルシステムコード全体で168,000 SLOCを超えています。

Richard Stallmanらは、結果として得られるシステムを「Linux」と呼ぶ代わりに「GNU/Linux」と呼ぶべきだと主張しています ["Stallman 2000"]。特に、GNUの貢献を（GNUの名前を含めないことによって）隠すことで、多くの人々がGNUプロジェクトとその目的、つまり「フリーソフトウェア」（自由としてのフリー）への移行を奨励することを知らなくなります。確かに、結果として得られたシステムは、GNUプロジェクトの努力の意図された目標であり結果でした。用語「GNU/Linux」を正当化するために使用されるもう1つの議論は、オペレーティングシステム全体とオペレーティングシステムカーネルの両方が「Linux」と呼ばれるのは混乱を招くということです。「Linux」という用語の使用は、Debian GNU/Linuxディストリビューションを取得し、1つのコンポーネント（Linuxカーネル）を交換するGNU/Hurdにとっては特に奇妙です。

ここでのデータは、システムを「Linux」または「GNU/Linux」と呼ぶことを正当化するために使用できます。オペレーティングシステムの最大の単一コンポーネントはLinuxカーネルであることは明らかであるため、多くの人々がシステム全体をその最大の単一コンポーネント（「Linux」）にちなんで名付けることを選択した理由を理解することは少なくとも可能です。また、GNUプロジェクト自体だけでなく、多くの貢献者がおり、その貢献者の一部はGNUプロジェクトの哲学に同意しないことも明らかです。一方で、システムの多くの最大のコンポーネントは本質的にGNUプロジェクトです：gcc、gdb、emacs、binutils（バイナリファイル用のコマンドセット）、およびglibc（Cライブラリ）。システムに含まれる他のGNUプロジェクトには、binutils、bash、gawk、make、textutils、sh-utils、gettext、readline、automake、tar、less、findutils、diffutils、およびgrepが含まれます。これはGNOME（GNUプロジェクト）を数えていません。要するに、GNUプロジェクトのコードの合計はLinuxカーネルのサイズよりもはるかに大きいです。したがって、貢献された総労力を比較すると、システム全体を単に「Linux」ではなく「GNU/Linux」と呼ぶことは確かに正当化できます。Linuxカーネルコンポーネントのサイズに関する詳細については、http://www.dwheeler.com/sloc/redhat71-v1/kernel_slocを参照してください。

3.3 言語別の合計カウント

ここでは、ソースコード行数（SLOC）でソートされたさまざまなプログラミング言語を示します（SLOCをカウントするために使用されたプログラムsloccountの命名規則を使用）：

ここで、Cが圧倒的（71%以上）であり、次にC++、シェル、LISP、アセンブリ、Perl、Fortran、Pythonが続いていることがわかります。コード量が少ない言語の一部（Objective-CやAdaなど）は、主にテストケースまたはそれらの言語のユーザーをサポートするためのバインディングとして表示されます。それでも、さまざまな言語のサポートが少なくともいくつかあるのは良いことです。なぜなら、各言語は特定の種類のアプリケーションに対して何らかの強みを持っているからです。

C++は約450万行のコードがあり、非常に立派な結果ですが、C（2100万SLOC以上）には遠く及びません。それでも、C++コードの使用は増加しています。前回の調査では、Cは80.55%、C++は7.51%でした。C++のコード量はCよりもはるかに少ないですが、C++コードの増加は顕著です。Cコードがこれほど多い理由、特にC++と比較して、なぜこれほど多いのかと問うことができます。1つの可能な議論は、適切に書かれたC++はCよりも少ないコード行数で済むということです。これはしばしば真実ですが、これだけでは完全に説明できない可能性が高いです。もう1つの重要な要因は、多くの大規模プログラムがC++が広く使用される前に書かれており、誰も自分のCプログラムをC++に書き直したいと思っていないことです。また、言語全体の単純さのためにCをC++よりも好む（例：言語全体の単純さのため）かなりの数のソフトウェア開発者がおり、これは間違いなくこれらの数値に影響します。LinuxカーネルでCからC++に切り替えるためのいくつかの過去の試みがありましたが、それらはすべて（さまざまな理由で）失敗しました。

LISPは依然として非常に高い位置にあり、Perl、Python、Fortran、またはJavaよりもはるかに多いです。LISPは多くのコンポーネントで使用されていますが、その高い位置はemacsの広範な使用によるものです。Emacs自体は主に独自のLISPバリアントで書かれており、emacsパッケージ自体がLISPコードの87%（627626/722430）を占めています。さらに、多くの言語には、これらの言語で構築されたコンポーネントを制御するための洗練された（そして大規模な）emacsモードが含まれています。Perlには5739行のLISPが含まれており、Pythonにはプログラム編集のための複雑なEmacsモードをサポートするために直接使用されるさらに2353行のLISPが含まれています。他のプログラム（GIMPやSawmillなど）も、LISPまたはそのバリアントのいずれかを、他の言語（この場合はC）で構築されたコンポーネントを制御するための「制御」言語として使用しています。LISPは、MITの古いITSコミュニティからの強力な影響により、ハッカー（コンピュータ愛好家）コミュニティで長年の使用実績があります。ハッカー文化の歴史、特にITSとLISPの影響については、["Raymond 1999"]を参照してください。

多くの人がさまざまな言語の数に驚くかもしれませんが、これは弱点ではなく強みと見なされるべきだと私は信じています。このLinuxディストリビューションは幅広い言語をサポートしており、開発者は「その仕事に最適なツール」を選択できます。

3.4 ファイル数の合計

もちろん、SLOCを数える代わりに、さまざまなカテゴリのファイル数だけを数えて、他の洞察を探すこともできます。

Lex/flexとyacc/bisonは広く使用されているプログラムジェネレータです。SLOCを数える際にはかなりの数を示しますが、ファイル数を調べるとその広範な使用がより明らかになります。lex/flexファイルは94個、yacc/bisonファイルは138個あります。一部のビルドディレクトリでは、lex/flexまたはyacc/bisonが複数回使用されています。

ファイル数からも他の洞察が得られます。ファイルは352,549個あり、そのうち130,488個がソースコードファイルとしてカウントされました（重複ファイルと自動生成ファイルを除く）。このカウントに含まれていないのは、重複した内容を含むファイルが10,807個、自動生成されたと検出されたファイルが1,587個です。

これらの値を使用して、システム全体のファイルあたりの平均SLOCを計算できます。例えば、C言語の場合、78,676ファイルに含まれるSLOCは21,461,450で、「平均」Cファイルは273（14218806/52088）物理ソースコード行を含んでいます。興味深いことに、Red Hat Linux 6.2は、物理Cコードの平均行数がほぼ同じでした。

3.5 ライセンス別の合計カウント

ここでは、SLOCでソートされたさまざまなライセンスタイプを示します（これらのライセンス値の決定方法についてはセクション2.4を参照）：

 15185987 (50.36%) GPL
  2498084 (8.28%)  MIT
  2305001 (7.64%)  LGPL
  2065224 (6.85%)  MPL
  1826601 (6.06%)  Distributable
  1315348 (4.36%)  BSD
   907867 (3.01%)  BSD-like
   766859 (2.54%)  Freely distributable
   692561 (2.30%)  Free
   455980 (1.51%)  GPL, LGPL
   323730 (1.07%)  GPL/MIT
   321123 (1.07%)  Artistic or GPL
   191379 (0.63%)  PHP
   173161 (0.57%)  Apache-like
   161451 (0.54%)  OpenLDAP
   146647 (0.49%)  LGPL/GPL
   103439 (0.34%)  GPL (programs), relaxed LGPL (libraries),
                   and public domain (docs) 
   103291 (0.34%)  Apache
    73650 (0.24%)  W3C
    73356 (0.24%)  IBM Public License
    66554 (0.22%)  University of Washington's Free-Fork License
    59354 (0.20%)  Public domain
    39828 (0.13%)  GPL and Artistic
    31019 (0.10%)  GPL or BSD
    25944 (0.09%)  GPL/BSD
    20740 (0.07%)  Not listed
    20722 (0.07%)  MIT-like
    18353 (0.06%)  GPL/LGPL
    12987 (0.04%)  Distributable - most of it GPL
     8031 (0.03%)  Python
     6234 (0.02%)  GPL/distributable
     4894 (0.02%)  Freely redistributable
     1977 (0.01%)  Artistic
     1941 (0.01%)  GPL (not Firmware)
      606 (0.00%)  Proprietary

これらのライセンスタイプを、特定のキーワードを含むライセンスのSLOCを合計することでグループ化できます：

 16673212 (55.30%) GPL
  3029420 (10.05%) LGPL
  2842536 (9.43%)  MIT
  2612681 (8.67%)  distributable
  2280178 (7.56%)  BSD
  2065224 (6.85%)  MPL
   162793 (0.54%)  public domain

これらの数値から、次のことがわかります：

1. GPLは、単一ライセンスでは圧倒的に最も一般的なライセンスです（コード行数で）。実際、「GPL」カテゴリ（このライセンスのみを持つパッケージ）だけでも、パッケージの50.36%を占めています。ライセンステキストに「GPL」が含まれるすべてのパッケージのSLOCを合計すると、合計は55%に増加します。どのように見ても、GPLはこのディストリビューションで支配的な単一ライセンスです。
2. 次に一般的なライセンスは、MIT、LGPL、MPL、BSDライセンスでした（順不同）。これは予想と一致しています。最も有名でよく使用されているオープンソースライセンスは、GPL、MIT、LGPL、およびBSDライセンスです。MPLはSLOCの点で良好ですが、このディストリビューションでは1つのプロジェクト（Mozilla）でのみ使用されています。「Artistic」ライセンスの使用もありますが、その使用ははるかに少ないです。Perens [1999]のような論文では、法的曖昧さのためにArtisticライセンスの開発を特に推奨しないと述べていることに注意してください。
3. パブリックドメインソフトウェア（「著作権なし」）としてリリースされているソフトウェアは非常に少ないです。このディストリビューションでは、コードの0.2%のみが「パブリックドメイン」とラベル付けされたパッケージに含まれています（上記の0.54%の数値には、ドキュメントがパブリックドメインにある「sane」パッケージが含まれていることに注意してください）。これにはいくつかの要因が考えられます。第一に、開発者が自分の仕事のクレジットを得たい場合、これは悪い「ライセンス」です。法律により、誰でも「パブリックドメイン」ソフトウェアの所有権を主張できます。第二に、訴訟の恐れがあるかもしれません。MITおよびBSDライセンスは、実質的に任意の用途を許可しますが、訴訟は禁止します。MITやBSDのようなライセンスは訴訟に対する証明ではありませんが、少なくとも法的な保護を提供します。一方、パブリックドメインにソフトウェアをリリースしても、保護は全く提供されません。最後に、パブリックドメインにリリースされたソフトウェアは、他のどのライセンスの下でも再ライセンスできます。したがって、パブリックドメインソフトウェアがパブリックドメインに留まることを妨げるものはありません。ここにある他のどのライセンスも、パブリックドメインライセンスを「支配」できます。
4. ごくわずかなプロプライエタリコードしかありません。これは完全に1つのコンポーネント、Netscape Communicator / Navigatorに含まれています。このコンポーネントはMotifツールキット（オープンソースではない）を使用しており、プロプライエタリコードが混在しています。その結果、このパッケージのコードはCD-ROMにはほとんど含まれていません。プレースホルダーコードが少量だけあります。将来的には、このコンポーネントはMozillaに置き換えられると予想されます。
5. 明らかにMITライク/BSDライクのライセンスを持つパッケージ（MIT、BSD、MITライク、BSDライク、およびなし/パブリックドメインのエントリを合計）は、合計で4,742,021 SLOC（15.92%）です。これらのうち1,837,608行（39%）は、Linuxのグラフィカルユーザーインターフェース（GUI）に使用されるインフラストラクチャコンポーネントであるXFree86 Xサーバーによって占められていることに注意する価値があります。
6. 「distributable」、「freely distributable」、「MPL」、「Free」、「Artistic」、「Apache」、「Apache-like」、および「IBM Public license」のソフトウェアもMITライク/BSDライクと見なされた場合、合計SLOCは7,954,474（26%、36%から減少）になります。残念ながら、これらの他のパッケージのどれが単にBSDライク/MITライクのライセンスであるかを判断するための情報は、仕様ファイルに含まれていません。
7. コピーレフトライセンス（GPLまたはLGPL）を含むパッケージは合計で63%です。GPL、LGPL、またはその両方のみに限定すると60%になり、Red Hat Linux 6.2と同じ割合で、明確な過半数です。

このディストリビューションでは、GPLが支配的なライセンスであり、コピーレフトライセンス（GPLおよびLGPL）がBSD/MITスタイルのライセンスを大幅に上回っていることは明らかです。これは、いくつかの目立つプロジェクト（Mozilla、Troll TechのQt、Python）がライセンスを変更してGPLと互換性を持たせた理由の単純な定量的説明です。GPLソフトウェアがこれほど多い場合、GPL互換性は多くのオープンソースプロジェクトの存続にとって極めて重要です。GPL互換性に関する情報については、Free Software FoundationのVarious Licenses and Comments about Them [FSF 2001a]を参照し、GPL全般についてはGPL FAQ [FSF 2001b]を参照してください。

このディストリビューションで最も一般的なオープンソースライセンス（SLOC別）は、GPL、MIT、LGPL、およびBSDライセンスです（MPLも含まれますが、1つのプロジェクトでのみ使用されていることに注意してください）。これは、Perens [1999]とも一致しており、開発者に可能な限り新しいライセンスを開発するのではなく、既存のライセンスを使用するように求めています。

この記事の執筆時点では、これらのライセンスの中でGPLが最も注目を集めています。なぜなら、Microsoftは特にGPLライセンスを攻撃してきたからです。GPLライセンスはプログラムの商用利用を許可しますが、プログラムの変更バージョンのディストリビュータは、その変更のソースコードも同じ条件でリリースすることを要求します。したがって、GPLの下でリリースされたソフトウェアは、Microsoftの通常の「抱き込みと拡張」アプローチによる競合他社の破壊に抵抗します。MicrosoftはGPL化されたコードを使用および変更できますが、そのコードへの変更をプロプライエタリにすることはできません。対照的に、Kerberos（MITライセンスではなくMITライセンスでリリースされたセキュリティコンポーネント）は、最近Microsoftによって製品に組み込まれ、その後、製品間の完全な相互運用性を防ぐように非互換な方法で拡張されました ["Schneier 2000"]。KerberosがGPLまたはLGPLライセンスでリリースされていた場合、これははるかに困難だったでしょう。多くのGPLおよびLGPLコンポーネントの存在は、Linuxディストリビューションが「抱き込まれ、拡張され、消滅させられる」ことに対する抵抗力を高めるはずです。

3.6 合計SLOCカウント

これらすべての仮定を考慮すると、カウントプログラムは合計30,152,114物理ソースコード行（SLOC）を計算しました。これを「3000万SLOC以上」と簡略化します。これは驚くべき量のコードです。他のシステムの報告されているサイズと比較してください：

これらの数値はBruce SchneierのCrypto-Gram [["Schneier 2000"]]から来ており、スペースシャトルの数値はNational Academy of Sciencesの調査 [["NAS 1996"]]から、Red Hat Linux 6.2の数値は[["Wheeler 2001"]]から来ています。Microsoft製品の後期バージョンの数値は、公開されている文献で値に大きな不確実性があるため、ここでは示されていません。これらの数値のほとんどの仮定は不明確です（例：これらは物理行数か論理行数か？）。しかし、それらは比較可能な物理SLOCカウントである可能性が高いです。

展開された「最小システム」はコード量が少なくなることに注意してください。これについては、Red Hat Linux 6.2を分析した論文でさらに議論しています ["Wheeler 2001"]。

Red Hat Linux 7.1システムには多数のアプリケーションが含まれていることに注意してください。多くの場合、各カテゴリに選択肢があります。2つの主要なデスクトップ環境（GNOMEとKDE）があり、さらにさまざまな軽量オプションがあります。2つのワードプロセッサ（AbiwordとKWord）、2つのスプレッドシート（GnumericとKSpread）、2つのリレーショナルデータベースシステム（MySQLとPostgres）、および2つのWebサーバー（ApacheとTUX）があります。要するに、Red Hat Linux 7.1には多数のアプリケーションが含まれており、その多くはMicrosoftやSunの同等製品には含まれていません。

一見すると、このオペレーティングシステムへのアプリケーションのバンドルは、Microsoftのオペレーティングシステムへのアプリケーションのバンドルポリシー（Microsoftが法的な問題に巻き込まれた原因）に似ているように見えるかもしれません。しかし、いくつかの違いに注意する価値があります。第一に、そして法的に最も重要なのは、裁判官がMicrosoftは独占企業であると判決を下し、米国法の下では独占企業は他の組織が実行できる特定の行為を実行できないということです。第二に、誰でもLinuxを入手し、アプリケーションとバンドルして、結果の製品を再配布できます。アプリケーションがLinuxで動作したり、Linuxと統合したりするのを妨げる「秘密のインターフェース」や再ライセンス料のような障壁はありません。第三に、このディストリビューション（および他の多くのディストリビューション）には代替が含まれています。ユーザーはCD-ROM上で複数のオプションから選択できます。したがって、Linuxディストリビューションもシステムにアプリケーションを追加する方向に進んでいるように見えますが、ユーザーが代替を選択する能力を著しく妨げる方法ではそうしていません。

SLOCカウントが必ずしもユーザーの機能性を非常によく測定するわけではないことに注意する価値があります。例えば、賢い開発者は問題の単純化のために創造的な方法を見つけることがよくあります。そのため、SLOCカウントが少ないプログラムでも、SLOCカウントが多いプログラムよりも優れた機能を提供できる場合があります。しかし、SLOCカウントが労力（したがって開発時間）と相関するという証拠があるため、SLOCを使用して労力を推定することは依然として有効です。

信頼性の高いコードを作成するには、信頼性の低いコードを作成するよりもはるかに多くの労力が必要になる場合があります。例えば、スペースシャトルのコードは、典型的な商用ソフトウェアよりもはるかに厳格なテストと分析を受けたことが知られており、開発コストが上昇しています。しかし、LinuxとSolarisまたはWindows NTの間の信頼性の違いが、Linuxの開発にそれほど労力がかからないことを必然的に引き起こすとは合理的に主張できません。これを見るために、Linuxがこれらの他の製品と同じようなプロセスで、従来のプロプライエタリな手段を使用して開発されたと仮定しましょう。前述のように、実験ではLinux、または少なくともその一部は、それらのどちらよりも信頼性が高いことが示唆されています。これは、より多くのお金がかかる（テストの増加による）か、開発プロセスに実質的な変更が必要になる（例：ピアレビューの増加による）でしょう。したがって、Linuxの信頼性は、同様の開発プロセスが使用された場合、同様のサイズのプロプライエタリシステムと比較して、同等の信頼性レベルでLinuxを伝統的に開発するには少なくとも同じ労力が必要であったことを示唆しています。

3.7 労力とコストの推定値

最後に、前述のすべての仮定を考慮すると、労力の値は次のとおりです。

Total Physical Source Lines of Code (SLOC)                   = 30152114
Estimated Development Effort in Person-Years (Person-Months) = 7955.75 (95469)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Estimated Schedule in Years (Months)                         = 6.53 (78.31)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Total Estimated Cost to Develop                              = $ 1074713481
 (average salary = $56286/year, overhead = 2.4).

これらの労力値の計算方法の詳細については、付録Aを参照してください。詳細情報はhttp://www.dwheeler.com/slocから取得できます。

4. 結論

Red Hat Linux 7.1には3000万物理ソースコード行（SLOC）以上が含まれており、バージョン6.2（約1年前にリリースされた）の1700万SLOCをはるかに超えています。COCOMOコストモデルを使用すると、このシステムは開発に約8,000人年の開発時間を要したと推定されます（バージョン6.2の開発に必要な4,500人年と比較して）。

このLinuxディストリビューションが従来のプロプライエタリな手段で開発されていた場合、米国内で開発するには10億8000万ドル（1,000百万ドル）以上かかったと推定されます（2000年ドル換算）。これはバージョン6.2の6億ドルの推定値と比較してください。したがって、Red Hat Linux 7.1は、Red Hat Linux 6.2と比較して、サイズ、労力、および従来の開発コストで60%以上の増加を表しています。これは約1年間の期間であることを考えると、非常に驚異的です。

他にも多くの興味深い統計情報が得られます。最大のコンポーネント（順不同）は、Linuxカーネル（デバイスドライバを含む）、Mozilla（Webブラウザ、メールクライアント、HTMLエディタを含むNetscapeのオープンソースWebシステム）、X-windows（グラフィカルユーザーインターフェースのインフラストラクチャ）、gcc（コンパイルシステム）、gdb（デバッグ用）、基本的なバイナリツール、emacs（テキストエディタであり、それ以上のもの）、LAPACK（数値線形代数のための大規模Fortranライブラリ）、Gimp（ビットマップグラフィックエディタ）、およびMySQL（リレーショナルデータベースシステム）でした。MozillaとLAPACKはRed Hat 6.2には全く含まれていなかったことに注意してください。

使用言語は、コード行数でソートすると、C（71% - 以前は81%）、C++（15% - 以前は8%）、シェル（kshを含む）、Lisp、アセンブリ、Perl、Fortran、Python、tcl、Java、yacc/bison、expect、lex/flex、awk、Objective-C、Ada、Cシェル、Pascal、sedでした。Cは依然として主要な言語ですが、その割合は減少し、C++が主にその差を埋めています。これは、GUI開発において多くのプログラマがCよりもC++を選択していることを部分的に反映しているようです。Fortranの量の増加は、主にLAPACKの組み込みによるものです。

最も一般的なソフトウェアライセンスはGNU GPLです。ソフトウェアの半分強は単純にGPLでライセンスされており、コピーレフトライセンス（GPLおよびLGPL）を使用するソフトウェアパッケージは、少なくとも一部または代替として、コードの63%を占めていました。あらゆる点で、コピーレフトライセンス（GPLおよびLGPL）はこのLinuxディストリビューションで支配的なライセンスです。対照的に、ソフトウェアの0.2%のみがパブリックドメインです。

明らかに、これはオープンソースのアプローチを使用して大規模システムを構築することが可能であることを示しています。1976年、Bill Gatesは「ホビイストへの公開書簡」を発表し、ソフトウェアが自由に共有されると、優れたソフトウェアの作成が妨げられると主張しました。彼は修辞的に尋ねました、「誰が無料でプロフェッショナルな仕事をする余裕があるだろうか？どのホビイストが3人年のプログラミングを行い、すべてのバグを見つけ、製品を文書化し、無料で配布できるだろうか？」彼はこれらを答えられない質問だと仮定し、彼自身と他の人々はこの仮定に基づいて産業を築きました [Moody 2001]。しかし今では、何千人もの開発者が独自の優れたコードを書いており、それを無料で提供しています。Gatesは根本的に間違っていました。ソースコードを共有し、他者がそれを拡張することを許可することは、実際には大規模システムの開発のための実用的なアプローチであり、その製品はより信頼性が高くなる可能性があります。

他のLinuxディストリビューション（SuSEやDebianなど）や他のオープンソースシステム（FreeBSDなど）でこれらの値を再実行することは興味深いでしょう。例えば、SuSEやDebianはポリシーとしてさらに多くのパッケージを含んでおり、おそらく労力と開発コストのより大きな推定値を生み出すでしょう。

以前の論文で述べたように、開発者によるいくつかの行動は、同様の分析をさらに簡素化する可能性があります。最も重要なのは、プログラマが常に、生成されたファイル（例：「Automatically generated」というフレーズで）を一番上にマークすることです。これはカウントツールを助けるだけでなく、プログラマはファイルが編集されるべきではないファイルとして明確にマークされていない限り、そのようなファイルを誤って手動で編集する可能性が高いです。開発者がファイル拡張子を一貫して使用し、他の意味で拡張子名を「再利用」しないことは有用でしょう。suffixes(7)のマニュアルページには、すでに主張されている拡張子のリストがあります。これは、あまり使用されない言語にとってはより困難です。多くの開発者は、「.m」がObjective-Cの標準拡張子であることを知りません。また、ここに示されているすべての言語で、論理的SLOCカウントを実行するための高品質なオープンソースツールがあると良いでしょう。

これらは推定値であることを強調する必要があります。すべてのファイルを正確に分類することは非常に困難であり、一部のファイルはサイズ推定器を混乱させる可能性があります。いくつかの仮定（Makefileを含めないなど）をする必要がありましたが、それらが異なれば異なる結果が得られたでしょう。自動生成されたファイルを特定することは非常に困難であり、誤って分類されたものがある可能性も十分にあります。

それにもかかわらず、オープンソースシステム全体の分析から得られる洞察は数多くあり、この記事がそれらの洞察の一部を提供したことを願っています。オープンソースシステムは誰でも分析できるため、他の人々がこれらのシステムへのさらなる洞察を得るために、他の多くの分析ラインを追求することを願っています。

詳細については、http://www.dwheeler.com/slocで入手できます。

---

付録A. アプローチの詳細

この付録では、分析を実行する際に私が対処しなければならなかった問題の一部を、誰かがその作業を繰り返せるように十分な詳細で説明します。

特に、ソースコードのインストールには2つのステップが必要でした：

1. ソースコードファイルをインストールする（ソースRPMパッケージを「spec」ファイルと圧縮ソースファイルに変換する）。
2. ソースコードファイルを解凍する（非圧縮ソースコードとライセンス情報が生成される）。

その後、sloccountバージョン1.9を実行してソースコードファイルを分析し、警告メッセージを調べて、発生した深刻な問題を修正しました。これは簡単なことではありませんでした。以前の論文（Red Hat Linux 6.2を分析したもの）では、これについてさらに詳しく説明しています ["Wheeler 2001"]。その後、私がコードカウントに使用したツールをsloccountプログラムとしてリリースしました。これはhttp://www.dwheeler.com/sloccountで入手できます。

ここで1つの複雑さを言及する価値があります。Red Hat Linux 7.1パッケージには「Source Code」とラベル付けされたCD-ROMが付属していますが、「Source Code」CD-ROMにはすべてのソースコードが含まれているわけではありません。バイナリCD-ROMのソースコードをスキップすると、無効なカウントになります。なぜなら、224のソースコードパッケージがそこ（ssl、perl、python、sambaなどの重要なパッケージを含む）に配置されているからです。これはおそらくCD-ROMのスペースの必要性のためでしょう。ソースコードは非常に多いため、圧縮しても1枚のCD-ROMには収まりません。

次に、CDに含まれているプログラムの「古い」バージョン（同じプログラムが2回カウントされないようにするため）や、Intel x86以外の操作に必要なバージョン（これらは完全にカウントされないため）を探しました。これは、タイトルに「compat」または「10」または「11」が含まれる仕様（/usr/src/redhat/SPECS）を調べることによって行いました（それらのすべてが古いものであり、削除する必要があることが判明しました）。また、末尾が数字または「x」で「.spec」で終わるものを調べ、qt1x.specを見つけました。このプロセスを通じて、以下を削除しました：

 compat-egcs.spec  compat-glibc.spec  compat-libs.spec  kde1-compat.spec
 gtk+10.spec libxml10.spec x86-compat-libs.spec qt1x.spec

また、「beta」ソフトウェアで非ベータバージョンが入手可能なものも削除しました（ベータソフトウェアは、パッケージまたは仕様ファイル名に「beta」を検索することで特定されました）。これにより、以下が削除されました：

  glib-gtkbeta.spec  gtk+-gtkbeta.spec pango-gtkbeta.spec

「mysqlclient9.spec」も削除しました。この仕様には、Red Hat Linux 7に同梱されていた古いMySQLクライアントライブラリバージョン3.23.22が含まれており、それにリンクされたアプリケーションで使用されていました。「mysql.spec」（新しいバージョン3.23.36のMySQL（リレーショナルデータベースパッケージ）のコードが含まれていました）は含めました。

Red Hat Linux 6.2とは異なり、Red Hat Linux 7.1にはbashまたはncursesの2つのバージョンがなかったため、それらの古いバージョンを削除する必要はありませんでした。db1、db2、およびdb3はそのまま残しました。なぜなら、これら3つのうちどれも他の2つを必ずしも置き換えるとは言えないという議論があるからです。

1つの複雑さは、グラフィカルサブシステム「XFree86」の処理でした。XFree86のバージョン4はすべてのクライアント側アプリケーションに使用されましたが、バージョン3はXサーバーを実装するために使用されました。XFree86開発者はXFree86を完全に再構築し、Red Hatは古いサーバーと新しいクライアントを使用することを選択しました。XFree86ソースパッケージのバージョン4を調べたところ、サーバーコードがパッケージに含まれていることがわかりました（標準のRed Hatディストリビューションでは使用されていませんでしたが）。XFree86を実質的に2回（一度はバージョン3として、もう一度はバージョン4として）カウントするのを避けるために、バージョン4のXFree86のコードのみをカウントしました。

次に、実質的に次のようなコードを実行してソースコードを解凍しました：

  cd /usr/src/redhat/SPECS
  rpm -bp *.spec

これによりソースコードが解凍され、実際のシステムで使用されているすべてのパッチが適用されます。システムに含まれるコードの量をカウントしたかったため、パッチを含めることが重要でした。ソースコードを解凍する実際のコードは、各解凍されたディレクトリ（BUILDディレクトリ内）にそれがどのspecファイルから来たのか、およびプログラムのライセンスを識別するようにマークしたため、より複雑でした。ライセンスは、（1）specファイルの「Copyright」および「License」フィールドを確認し、それが機能しない場合は、（2）「LICENSE」、「COPYING*」、および「Artistic」などのビルドディレクトリ内のさまざまなファイルを確認することによって決定されました。残念ながら、MITライクおよびBSDライクのライセンスは検出が難しい場合があります（テキストが変更される可能性があるため）。しかし、多くのライセンス（GPLおよびLGPLなど）は非常に高い確信度で検出できます。specファイルは、人間（法的技術的な詳細を機械よりもよく理解できる）によって配置されたため、プライマリソースとして使用しました。

実際、解凍を複数回繰り返す必要がありました。RPMシステムは、ソフトウェアのビルドに必要な依存関係が不足していることに気づき、抗議しました。これには、不足しているコンポーネントのインストールが必要でした（場合によっては、プログラムをインストールする必要はなく、インストールを強制することもできましたが、パッケージをインストールしないことで結果を破損させるリスクを冒したくありませんでした）。

驚くべき展開は、「imap」および「samba」パッケージが解凍エラーを報告したことでした。imapの場合、パッチ#5（imap-4.7c2-flock.patch）、sambaの場合、パッチ#21（samba-ia64.patch of source/passdb/pass_check.c）が解凍を停止させました。ソフトウェアを解凍し、そこにあるものを単純にカウントしました。これは、元の開発者が行ったことのようです。

報告されたライセンス値を調査しました。特に、100,000ソースコード行を超えるすべてのコードについて（最大のコンポーネントとして、これらのコンポーネントの誤った値はより大きなエラーを引き起こす可能性が高いです）。Perlはspecファイルで「GPL」に割り当てられていましたが、これは全体ではありません。READMEファイルに記載されているように、PerlはGPLまたはArtisticライセンスのいずれかで使用できるため、ライセンスエントリは「GPL or Artistic」に変更されました。Mozillaのライセンス状況はより複雑です。その一部は実際には個別のデュアルライセンススキーム（GPLとNetscape Public License、つまりNPLの両方でライセンスされている）の下にあります。しかし、それを「MPL、NPL、およびGPL」とラベル付けすると、GPLでライセンスされたコードの量が過大評価される可能性が高いため、MPLライセンスとしてエントリを残しました。

解凍されたソースファイル（ソースコード、フォント、ドキュメントなどを含む）の合計は4.4ギガバイトを超えました。

分析コードを通常のユーザーとして実行したため、最初にユーザーにコードを読み取る権限を設定する必要がありました。その後、通常のユーザーアカウントに戻り、sloccountバージョン1.9を使用してソースコードを測定しました。次のbashコマンドを使用しました：

sloccount --multiproject /usr/src/redhat/BUILD > sloc-actions 2>&1 &

sloccountの「--follow」オプションは使用しなかったことに注意してください。一部のプログラム、特にpineは、/usr/libなどの他のディレクトリへのシンボリックリンクを含んでいます。したがって、--followを使用すると、意図したディレクトリ外のファイルが分析に含まれることになります。

さまざまなエラーレポートを確認し、どれも結果を根本的に無効にするものではないと判断しました。例えば、XFree86ソースコードには、フォーマットが不適切な文字列に関連するいくつかのエラーがありました。これらはコンパイラによって（したがってコンパイラによって）認識されないプリプロセスされるコード内の構文エラーのようです。これらの問題はXFree86プロジェクトに報告する予定です。1つのプログラムは、「#! /usr/bin/env bash」で始まるbashシェルスクリプトでしたが、sloccountのヒューリスティックでは当時処理できませんでした。その後、sloccountを修正してそのタイプを正しく特定しました（bashシェルスクリプトです）。

sloccountは多数の小さなファイルを生成することに注意してください。これは根本的な問題ではありませんが、システムの規模が大きいため、複数の結果のコピーを保存しようとするとinodeが不足しました。これを再現しようとする人は、ファイルシステムをより多くのinodeを含むように特別にフォーマットすることを検討するかもしれません。

すべてのコンポーネントとそのSLOCカウントの完全なリストについては、http://www.dwheeler.com/sloc/redhat71-v1/summaryを参照してください。

参考文献

[Boehm 1981] Boehm, Barry. 1981. Software Engineering Economics. Englewood Cliffs, N.J.: Prentice-Hall, Inc. ISBN 0-13-822122-7.

[Dempsey 1999] Dempsey, Bert J., Debra Weiss, Paul Jones, and Jane Greenberg. October 6, 1999. UNC Open Source Research Team. Chapel Hill, NC: University of North Carolina at Chapel Hill. http://www.ibiblio.org/osrt/develpro.html.

[DSMC] Defense Systems Management College (DSMC). Indirect Cost Management Guide: Navigating the Sea of Overhead. Defense Systems Management College Press, Fort Belvoir, VA 22060-5426. Available as part of the "Defense Acquisition Deskbook." http://portal.deskbook.osd.mil/reflib/DTNG/009CM/004/009CM004DOC.HTM.

[FSF 2000] Free Software Foundation (FSF). What is Free Software?. http://www.gnu.org/philosophy/free-sw.html.

[FSF 2001a] Free Software Foundation (FSF). 2001. Various Licenses and Comments about Them. http://www.gnu.org/philosophy/license-list.html.

[FSF 2001b] Free Software Foundation (FSF). 2001. General Public License (GPL) Frequently Asked Questions (FAQ) http://www.gnu.org/copyleft/gpl-faq.html.

[Halloween I] Valloppillil, Vinod, with interleaved commentary by Eric S. Raymond. Aug 11, 1998. "Open Source Software: A (New?) Development Methodology" v1.00. http://www.opensource.org/halloween/halloween1.html.

[Halloween II] Valloppillil, Vinod and Josh Cohen, with interleaved commentary by Eric S. Raymond. Aug 11, 1998. "Linux OS Competitive Analysis: The Next Java VM?". v1.00. http://www.opensource.org/halloween/halloween2.html

[Kalb 1990] Kalb, George E. "Counting Lines of Code, Confusions, Conclusions, and Recommendations". Briefing to the 3rd Annual REVIC User's Group Conference, January 10-12, 1990. http://sunset.usc.edu/research/CODECOUNT/documents/3rd_REVIC.pdf

[Kalb 1996] Kalb, George E. October 16, 1996 "Automated Collection of Software Sizing Data" Briefing to the International Society of Parametric Analysts, Southern California Chapter. http://sunset.usc.edu/research/CODECOUNT/documents/ispa.pdf

[Masse 1997] Masse, Roger E. July 8, 1997. Software Metrics: An Analysis of the Evolution of COCOMO and Function Points. University of Maryland. http://www.python.org/~rmasse/papers/software-metrics.

[Miller 1995] Miller, Barton P., David Koski, Cjin Pheow Lee, Vivekananda Maganty, Ravi Murthy, Ajitkumar Natarajan, and Jeff Steidl. 1995. Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services. http://www.cs.wisc.edu/~bart/fuzz/fuzz.html.

[Moody 2001] Moody, Glyn. 2001. Rebel Code. ISBN 0713995203.

[NAS 1996] National Academy of Sciences (NAS). 1996. Statistical Software Engineering. http://www.nap.edu/html/statsoft/chap2.html

[OSI 1999]. Open Source Initiative. 1999. The Open Source Definition. http://www.opensource.org/osd.html.

[Park 1992] Park, R. 1992. Software Size Measurement: A Framework for Counting Source Statements. Technical Report CMU/SEI-92-TR-020. http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.020.html

[Perens 1999] Perens, Bruce. January 1999. Open Sources: Voices from the Open Source Revolution. "The Open Source Definition". ISBN 1-56592-582-3. http://www.oreilly.com/catalog/opensources/book/perens.html

[Raymond 1999] Raymond, Eric S. January 1999. A Brief History of Hackerdom. Open Sources: Voices from the Open Source Revolution. http://www.oreilly.com/catalog/opensources/book/raymond.html.

[Schneier 2000] Schneier, Bruce. March 15, 2000. "Software Complexity and Security". Crypto-Gram. http://www.counterpane.com/crypto-gram-0003.html

[Shankland 2000a] Shankland, Stephen. February 14, 2000. "Linux poses increasing threat to Windows 2000". CNET News.com. http://news.cnet.com/news/0-1003-200-1549312.html.

[Shankland 2000b] Shankland, Stephen. August 31, 2000. "Red Hat holds huge Linux lead, rivals growing". CNET News.com. http://news.cnet.com/news/0-1003-200-2662090.html

[Stallman 2000] Stallman, Richard. October 13, 2000 "By any other name...". http://www.anchordesk.co.uk/anchordesk/commentary/columns/0,2415,7106622,00.html.

[Vaughan-Nichols 1999] Vaughan-Nichols, Steven J. Nov. 1, 1999. Can you Trust this Penguin? ZDnet. http://www.zdnet.com/sp/stories/issue/0,4537,2387282,00.html

[Wheeler 2000a] Wheeler, David A. 2000. Open Source Software / Free Software References. http://www.dwheeler.com/oss_fs_refs.html.

[Wheeler 2000b] Wheeler, David A. 2000. Quantitative Measures for Why You Should Consider Open Source / Free Software. http://www.dwheeler.com/oss_fs_why.html.

["Wheeler 2001"]. Wheeler, David A. May 9, 2001 (minor update from November 6, 2000). Estimating Linux's Size. Version 1.04. http://www.dwheeler.com/sloc.

[Zoebelein 1999] Zoebelein. April 1999. http://leb.net/hzo/ioscount.

• Trademark owners own any trademarks mentioned.*

This paper is (C) Copyright 2001 David A. Wheeler. All rights reserved. You may download and print it for your own personal use, and of course you may link to it. Talk to me to request republication rights. When referring to the paper, please refer to it as More than a Gigabuck: Estimating GNU/Linux's Size by David A. Wheeler, located at http://www.dwheeler.com/sloc. Please give credit if you refer to any of its techniques or results.