まともなソフトウェア製品はどれも、誰か他人が書いて無償で公開したコードの上で動いています。Webサービスは暗号ライブラリに依存し、データパイプラインはパーサーを取り込み、モバイルアプリはある一人が余暇に保守している小さなユーティリティ群を組み込んでいます。これらはすべて同じラベルでくくられていますが、新しい論文は、この一つのラベルが、本番環境に投入された際の挙動を左右するほど大きな違いを覆い隠していると指摘しています。
研究者たちはオープンソースソフトウェアを14のサブジャンルに分類しました。分類の基準は、誰がプロジェクトを立ち上げ、誰がそれを維持し、何のために行っているかという点です。今回のレビューでは、2つの学術データベースから抽出された約4,000本のユニークな論文を精査しています。その結果導き出されたのが一つの分類体系であり、研究がどの種類のプロジェクトを対象にサンプリングしたかによって、その結論がどこまで一般化できるかが決まるという主張です。
一枚のラベルに隠れる多様なプロジェクト
コミュニティ主導のLinuxディストリビューション、単一ベンダーが手がけるデータベース、大学の研究用ライブラリ、人道支援団体の医療記録システム、そして一人で開発されるユーティリティ――これらは存在意義も、方向性を決める主体も、開発資金の出所もそれぞれ異なります。
論文の著者らは、こうした違いに名前を与えています。DebianやArch Linuxのようなコミュニティ主導型プロジェクトは、ボランティアと実力主義による権限体系によって運営されています。Elastic、MongoDB、GitLabのような企業支援型プロジェクトは、そのソフトウェアで収益を上げ、ロードマップを管理する単一企業の傘下にあります。Apache HTTP、Kubernetes、Eclipseのような財団統治型プロジェクトは、商標を保有し競合企業同士を対等な立場に置く、ベンダー中立の非営利団体の下で運営されています。
他のカテゴリーは、一般的なイメージからさらにかけ離れています。「複数企業によるコーペティション(協調的競争)」は、OpenStackやLinuxカーネルを巡って各企業が行っているように、ライバル企業同士が共有インフラを共同で構築するケースを指します。「研究・科学ソフトウェア」は、助成金のサイクルや学術的キャリアを追い求める分野の研究者が研究室内で書くソフトウェアです。「プロテストウェア」は、メンテナーが政治的・経済的メッセージを発信するためにパッケージを改変したり妨害したりするケースを指し、node-ipcやcolors.jsがその例として挙げられます。
カテゴリーが挙動を予測できる理由
実務上重要なのは資金調達とガバナンスです。この2つが、多くの人がそのプロジェクトに依存するようになった後、そのプロジェクトがどれだけ持ちこたえられるかを左右するからです。特に顕著な例が、重要なデジタルインフラです。OpenSSL、curl、log4jといったコンポーネントは、ソフトウェアエコシステムの大部分を下支えしていますが、それを維持しているのはわずか数名のボランティアであることが少なくありません。Nadia Eghbal氏はフォード財団の報告書の中でこの持続可能性の問題を指摘し、その後の研究はこれを「アンダープロダクション(過小生産)」として定式化しました。これは、あるコンポーネントが受ける労力が、それがどれだけ広く依存されているかに見合わないという状態です。npmエコシステムを対象にした研究でも、これに関連したリスクが示されています。ごく少数のメンテナーアカウントが、ネットワークの大部分に影響を及ぼしているのです。
趣味的なプロジェクトや個人プロジェクトも、同じ脆弱性を抱えています。研究者たちはこれを「低トラックファクター」と呼びます。これは、プロジェクト全体が止まってしまうまでに何人が離脱すればよいかを問う指標です。一人だけで開発されているプロジェクトなら、その答えは「1人」です。そのメンテナーが多忙になったり、燃え尽きたり、離れていったりすれば、コードもそこで止まってしまいます。一方、会費制で有給スタッフを抱える財団に支えられたプロジェクトであれば、同じことが起きても頼れる人材が他に大勢います。
コミュニティの性質もまた異なる
違いは資金面にとどまりません。例えば「社会貢献のためのオープンソース(OSS4SG)」を見てみましょう。これは利益を上げることよりも人々を助けることを目的に構築されたプロジェクトで、医療記録システムのOpenMRSや危機マッピングツールのUshahidiなどが該当します。こうしたプロジェクトに参加した人は、そのまま定着する傾向があります。論文の著者らはこれを「粘着性(sticky)」があると表現しています。
一方、従来型のプロジェクトは「磁力的(magnetic)」であり、多くの人を引き寄せるものの、その多くは通り過ぎていくだけで定着しません。初めての貢献者から信頼されるコアメンバーへと至る道筋も異なっており、OSS4SGでは人々がより早く、しかも複数の経路を通ってコアに到達します。つまり、あるタイプのプロジェクトを前提に作られた「貢献者を定着させるための戦略」は、別のタイプのプロジェクトには通用しない可能性があるのです。
分類だけでは見えてこないもの
IT業界で働く人にとって、これは決して他人事ではありません。この分類体系はまだ発展途上であり、著者ら自身も出発点となる仮説として扱う簡易的なレビューだと位置づけているため、今後の研究の積み重ねによってカテゴリーは変化していくでしょう。とはいえ、実務上の教訓は変わりません。組織がオープンソースツールの採用を決めたり、新しい依存関係を取り込んだりする前に、そのプロジェクトのカテゴリーを知ることは、スター数を見ているだけでは決してわからない情報を教えてくれます。
単一ベンダーによるオープンコア製品には、そのベンダーの事業計画に紐づく再ライセンス化のリスクが伴います。個人メンテナーによるパッケージには、たった一人が離脱するだけで壊れてしまう「バスファクター」のリスクがあります。財団に支えられたプロジェクトには、そもそも競合企業同士が共有できるようにするためのガバナンスが備わっています。自分が扱おうとしているプロジェクトがどの種類に属するかを知っておけば、コードを実際に導入する前にリスクを明確に把握できます。
翻訳元: https://www.helpnetsecurity.com/2026/07/10/open-source-software-library-types/
