なぜオープンソースソフトウェアにコントリビュートすべきなのか

Akihiro Suda

Follow

31 min read

·

Mar 31, 2025

8

Share

NTTの須田です。2024年9月に開催された 第57回 情報科学若手の会 にて、「なぜオープンソースソフトウェアにコントリビュートすべきなのか」と題して招待講演させていただきました。講演内容をブログとして再編成しました。

なぜOSSにコントリビュートすべきなのか

結論から言うと、主にOSSの持続可能性のためです。

OSSは「タダ飯」(free lunch) であるかの如く、対価を支払うことなく消費されがちです。ミートアップなどで提供される実際の「タダ飯」🍕🍣とは異なり、遠慮なく好きなだけ食べても他の人の迷惑にはなりませんが、この「タダ飯」を提供する側のことを誰かが気にかけていないと次の問題が生じます:

• 「タダ飯」が出てこなくなる (OSSの開発が停滞する)
• 毒入りの「タダ飯」が出てくる (OSSにマルウェアが混入する)

前者はましな方で、後者が特に事業や社会にとっての脅威となります。後述しますが、xz・liblzmaのように広く普及しているOSSにさえ、バックドアが混入する事件が実際に起こっています。

結局、OSSは「タダ飯」ではありません (No such thing as a free lunch)。持続的に安全に利用するには、対価、すなわちコントリビューションが不可欠です。

OSSとは

まず、そもそもOSSとは何かについて見ていきます。誤解されがちですが、OSSとは「無料で使えるソフトウェア」(freeware) のことではありません。

非営利公益法人 Open Source Initiative はOSSの定義 (Open Source Definition, v1.9) として10個の条件を挙げています。主に次の内容が含まれます:

• 再配布の自由
• ソースコード形式での配布
• 派生ソフトウェアの作成・配布の自由
• 利用目的制限の禁止

無料で使えるソフトウェアであっても、ソースコードが公開されていなかったり、利用目的に制限があったりするソフトウェアはOSSではありません。

OSS と Free Software

OSSと非常によく似た概念として、Richard M. Stallman 氏らが唱える Free Software があります。Free Software もまた、「無料で使えるソフトウェア」(freeware) のことではありません。Free Software は日本語では「自由(な)ソフトウェア」と訳されます。なお、日本語の「フリーソフト」はFree Softwareのことではなく、単なる無料ソフトを指すことが多いようです。

OSS と Free Software は実践上はほとんど区別がつかないこともありますが、異なる動機に基づいています。Free Software が「自由と正義のための運動」(movement for freedom and justice) であると位置付けられているのに対し、OSS では理念よりも実利が重視されています。

両者に思想的な違いはありますが、まとめて FOSS (Free and Open Source Software) と呼ばれたり、「自由」(libre) の側面を強調して FLOSS (Free/Libre and Open Source Software) と呼ばれたりもします。

主要なOSSライセンス

一口にOSSといっても、そのライセンスには様々なものがあります。ライセンスが異なるソフトウェアは、混ぜて良いこともありますし、混ぜてはいけないこともあります。例えば、Apache License v2.0 を採用するソフトウェアに MIT License のコードを混ぜても問題ありませんが、GPL のコードを混ぜてしまうとApache License v2.0 での配布を継続できなくなります。近年では、GitHub Copilot などのコーディング支援AI の普及により、意図せず他ライセンスのコードが混ぜられることも懸念されつつあります。

また、利用目的に制限を加えるなど、OSSに似て非なるライセンスも多数存在し、OSSとの混同が問題視されています。

本記事ではOSSへのコントリビュートを推奨していますが、ライセンスについて最低限の知識を得るまでは、OSSにコントリビュートしてはいけません。ライセンスを無視してコードを切り貼りされると、ソフトウェアの配布を継続できなくなることもあるため、むしろ迷惑になります。

以下では主要なOSSライセンスをいくつか紹介しますが、ここでは特徴的な点についてのみ触れます。利用にあたっては、必ずライセンス原文をご参照ください。

• MIT License: 制約が緩いことで知られます。プロプライエタリな派生物の作成も許可しています。Ruby on Rails や Node.js など多数のプロジェクトで採用されており、GitHub上で最もよく使われているライセンス (44.69%、2021年) とも言われています。類似ライセンスにX11 License、BSD License (2-Clause)、ISC License などがあります。
• Apache License v2.0: MIT License に似ていますが、特許ライセンスを明示的に付与している点で異なっています。ユーザが特許訴訟を起こすと、ユーザ自身に付与された特許ライセンスは終了します。Apache HTTP Server、Docker Engine (Moby)、Kubernetes など多数のプロジェクトで採用されています。
• GPL (GNU General Public License) v2: バイナリを受け取ったユーザへのソースコード再配布を義務付けている点が特徴です。Linux や git などで採用されています。
• GPL v3: GPL v2の後継ライセンスです。改変したソフトウェアをインストーすることの妨害 (“Tivoization”) の禁止などの条項を追加しています。GCC や Emacs など多くのGNUプロジェクトはGPL v2 から v3 に移行しましたが、Linux は v3 への移行を予定していません。”Tivoization” を禁止する意図がないためです。
• AGPL (Affero GPL) v3: バイナリを受け取っていないSaaSユーザに対してもソースコードを再配布することを義務付けています。Mastodon や OnlyOffice などで採用されています。
• LGPL (Lesser GPL) v2.1、v3: GPLと異なり、LGPLを採用しているライブラリは動的ライブラリとして呼び出す場合にはライセンスが「感染」しません。glibc や glib などで採用されています。

OSSライセンスに似た非OSSライセンス

OSSライセンス と混同されがちな、非OSSライセンスも紹介します。

• BUSL (Business Source License) v1.1 : OSSライセンスと異なり、商用利用を禁じています。ただし、一定期間後に別のライセンス(大抵はOSSライセンス)が適用されます。元々は MariaDB MaxScale のために作られたライセンスで、Terraform (2023年8月以降) や Vagrant (同) でも採用されています。
• SSPL (Server Side Public License) v1.0: AGPL v3 に類似しますが、当該のソフトウェアのみならず、提供するサービス全体のソースコード開示を要求しています。元々はMongoDB (2018年10月以降) のために作られたライセンスで、Elasticsearch (2021年2月以降) や Redis (2024年3月以降)でも採用されています。Elasticsearch や Redis では他のライセンスも併用しています。
• Llama 3 Community License: ユーザ数や使用目的に制限を課しています。Llama 3 で採用されています。

これらの非OSSライセンスを採用するプロプライエタリソフトウェアも、OSS を自称していたり、あるいはマスコミなどによってOSSと混同されていたりすることがあるため注意が必要です。

OSS略史

OSSとは何かを理解するためには、OSSが定義されるまでの歴史を把握する必要があります。

OSSの歴史がいつ始まったかの問いに答えるのは容易ではありませんが、OSSの文脈での “open source” との表記は1998年まで確認できません。さらに古い用例 “Caldera Announces Open-Source Code Model for DOS” (1996)も見受けられますが、1998年以降の用法とは意味が異なっています。

ただし、OSSに似通ったソフトウェア配布形態は、20世紀半ばの電子計算機黎明期から既に見られます。そもそも、1960年代半ば(米国の場合)までソフトウェアの著作権自体が確立していませんでした。それ以降のソフトウェアはプロプライエタリな著作物としての配布が進みました。

• 1974年: UNIX のAT&T (米国電信電話会社)社外への提供が始まりました。UNIXは後に広く普及したOSですが、この時点での提供先はごく少数に限られたようです。当時のUNIXは無料ではありましたが、その利用は自由ではなく、学術・教育目的に限られていました。翌年には有償化されました。UNIXはやがて、AT&T系の System V と、カリフォルニア大学バークリー校系の Berkeley Software Distribution (BSD) とに分かれましたが、BSDもAT&T や関連会社の著作物を含んでいました。
• 1983年: Richard M. Stallman 氏が “Free Unix!” を標語とし、GNU (Gnu’s Not Unix) プロジェクトを創設しました。カーネルを含む完全なUNIX互換OSの開発を目指しましたが、実際には bash などのユーザ空間のみが普及し、今日でも広く使われています。カーネルの開発にも1985年頃には着手していたものの、一度失敗しています。1990年頃にMach 3 マイクロカーネルをベースとして開発が始まったGNU Hurd は、普及には至っていないものの、現在でも開発が続いています。

“I consider that the golden rule requires that if I like a program I must share it with other people who like it.”
— Richard M. Stallman (September 27, 1983)

• 1988年: 初のfreeなBSD (FreeBSDではない) を目指した4.3BSD Net/1 がリリースされました。AT&T 関連の著作物を除去したことにより、自由な再配布が可能になったとされていましたが、除去が不十分であったため1992年には訴訟に至りました。4.4BSD Lite (1994) にて、改めて自由な再配布が可能になりました。Net/1 の系譜は、Net/2 (1991) から 386BSD (1992) を経て、NetBSD (1993) や FreeBSD (1993) に連なります。NetBSDやFreeBSDは、後に4.4BSD Lite のコードを元にして書き直されました。
• 1991年: Linux v0.01 がリリースされました。当初は有償再配布を厳格に禁じており、「無料」ではあっても「自由」なソフトウェアではありませんでした。Linux v0.12 (1992) にてGPL v2 を採用し、晴れて「自由」ソフトウェアとなりました。Linuxは初のfreeなUNIX互換OSというわけではありませんが、GNUは技術的に、BSDは法的に難航している間に、漁夫の利を得て勢力を築きました。なお、この時点での Linux は Linus Torvalds 氏の趣味として開発されており、大規模なOSとなることは想定されていませんでした。

“just a hobby, won’t be big and professional like gnu”
— Linus Torvalds (August 25, 1991)

• 1997年: Eric S. Raymond 氏が講演「伽藍とバザール」(The Cathedral and Bazaar) にて、閉鎖的な「伽藍」型 (GNU Emacs等) と、開放的な「バザール」型 (Linux 等) の開発モデルとを比較し、後者の優位性を指摘しました。なお、混同されがちですが、「伽藍」がプロプライエタリなソフトウェアを、「バザール」がOSSを意味するわけではありません。
• 1998年: 当時広く使われていたWebブラウザ Netscape Communicator の開発元である Netscape 社が、次期製品のソースコードを公開すると発表しました。この時に公開されたソースコードの大半は一旦破棄されましたが、紆余曲折を経て今日の Mozilla Firefox に繋がっています。Netscapeのソースコード公開は、前述の「伽藍とバザール」の影響を受けたものとされています。この時点では ”free source distribution with a license which allows source code modification and redistribution” との文言が使われており、未だ “open source” とは呼ばれていませんでしたが、まもなく Christine Peterson 氏らにより “open source” の表現が提案されました。”free software “の表現は既に長らく存在していましたが、「自由」ではなく「無料」ソフトウェアのように解釈されがちなことが問題視されたようです。
• 1999年: OSS向けホスティングサービスとして SourceForge が始まりました。以後、OSSコミュニティが活発化しました。この頃には、Linux 等の主要OSSの商用導入も進みました。2000年には、後の Red Hat Enterprise Linux や SUSE Linux Enterprise Server に繋がる製品が発売されました。
• 2007年: Linus Torvalds 氏を雇用する非営利団体 Open Source Development Labs (OSDL) が Free Standards Group (FSG) と合併し、Linux Foundation となりました。Linux Foundation は Linux に限らず、極めて多数の OSS プロジェクトの開発を推進しています。
• 2008年: GitHub のサービスが開始し、OSSコミュニティの一層の活発化が進みました。
• 2000年代末: OSSをかつては癌 (cancer) とも呼んでいた Microsoft 社が、OSS への敵対を中止し、むしろ積極的に OSS に貢献するようになりました。他の大企業からも OSS への貢献が進むようになりました。
• 2023年: OSSの定義を管理する非営利公益法人 Open Source Initiative が、Open Source AI の定義の策定を開始しました。策定された定義は Open Source AI Definition (OSAID) v1.0 (2024) として公開されました。機械学習モデルの「ソースコード」とも言える(が、似て非なる)訓練データについては、法的観点から非公開を許容しています。

なぜOSSにコントリビュートすべきなのか

OSSの概要や歴史を踏まえた上で、表題の問いについて考えてみます。

OSSへの依存は不可避

Synopsys社は、2023年の時点で 96% の商用コードはOSSを含んでいると報告しています (2024 Open Source Security and Risk Analysis Report)。また、OSSを直接使っている認識がない場合でも、開発ツールやOSなどのことを考えると、誰しもが少なくとも間接的にはOSSに依存しているといえます。身近な例では、iOS や Android を搭載したスマートフォンには多数のOSSが含まれているので、ソフトウェアエンジニア以外の方でも知らないうちにOSSに依存しています。

OSSへの依存が不可避である今日では、OSSの停滞や脆弱性がビジネスや社会の脅威に直結します。特に、OSSプロジェクトが乗っ取られて悪意のあるコードを仕込まれたりすると多大な損害が発生する可能性があります。

こうした脅威は、企業、学校、団体、個人がOSSに自ら積極的に関与することで抑えることができます。ここでの関与とはソフトウェアのコーディングに限った話ではなく、むしろプロジェクトのマネジメントにも関わる話です。とはいえ、コーディングで貢献しなければマネジメントに携われないことが多いので、まずはコーディングでの貢献が重要となります。

OSSは誰が開発・維持しているのか

OSS の開発・維持は個人の趣味とみなされがちですが、それは必ずしも正しい認識ではありません。1991年時点でのLinuxなど、趣味 (“Just for Fun”) で開発されたOSSも多数存在するのは事実ですが、今日の主要なOSSには企業や団体の業務で開発されているものも多数存在します。Linux を開発した Linus Torvalds 氏の場合は、2003年より 前述のOSDL (現 Linux Foundation) に雇用されています。

Tidelift社の調査 (The 2023 Tidelift state of the open source maintainer report) によると、OSSメンテナの13%は収入の大半を、23%は収入の一部をOSS活動により得ているとされています。併せて36%のメンテナはOSS活動で収入を得ていることになります。「メンテナ」とはプロジェクトの管理権限を持つ開発者のことで、プロジェクトによっては「コミッタ」とも呼ばれます。メンテナ以外の開発者については、OSS活動で収入を得ている割合が下がるものと思われます。大規模で活発なOSSに限れば、収入を得ている割合は上がるようにも思われます (個人的な感覚)。

OSSに強く依存している企業であっても、従業員がOSSに業務で取り組むことを認めていないこともありますが、OSSを個人の趣味とみなして「やりがい搾取」するのは持続可能ではありません。

合成の誤謬

市場経済の下では、営利企業は経済的に合理的な行動を選択するはずです。しかしながら、何が合理的な行動であるのかは自明ではありません。ミクロな視点で合理性を追求すると、マクロでは却って非合理的になることもあります。これを合成の誤謬 (fallacy of composition) と呼びます。経済学者 Paul Samuelson 氏の言葉とされます。

OSSに当てはめてみると、OSSは無料で使えますし、他の誰かが勝手に開発・維持してくれるので、自らはコントリビュートしないことがミクロな視点では合理的に思えます。しかしながら、誰しもがこの「合理的」な行動を選択すると、誰もOSSにコントリビュートしなくなってしまうため、結局は合理的ではありません。自らOSSにコントリビュートし、その価値を他者と分かち合うのが実は合理的であると言えます。

OSSは贈与経済か

Eric S. Raymond 氏は OSS文化の理解を促進するため、エッセイ ”Homesteading the Noosphere” (1998) にて、社会地位を築く方法 (ways of gaining social status) を3つに分類しました:

1. 上意下達 (command hierarchy): 軍事力・強制力に依る方法です。
2. 交換経済 (exchange economy): 使用・交換するモノ (things) に対する支配力に依る方法です。典型例として自由市場経済が挙げられます。
3. 贈与文化 (gift culture): 何を贈与するかに依る方法です。典型例として北米先住民のポトラッチ (potlatch) が挙げられます。ポトラッチは競覇的贈与とも呼ばれます。相手が返礼をできなくなるまで食糧や毛皮の贈与を繰り返すことで権力を得る風習です。なお、Raymond氏のエッセイでは触れられていませんが、関連する著作として 社会学者 Marcel Mauss 氏の 贈与論 (Essai sur le don, 1925) が挙げられます。日本語訳「太平洋民族の原始經濟 : 古制社會に於ける交換の形式と理由」(1943) は国立国会図書館デジタルコレクションで無料で閲読できます (要登録)。Mauss 氏は、贈与は無償ではなく、時として過大なまでの返礼の義務が伴うことを指摘しています。この義務を果たせないものは地位を失うとしています。

Raymond氏はOSSを3番目の「贈与文化」 (gift culture) に分類し、身内での評判 (reputation among one’s peers) が競争の成功を測る唯一の指標となる状況が生まれると指摘しました。しかしながら、今日のOSSは評判のみがモチベーションであるとは言い難いように思われます。個人レベルでみると、業務で取り組んでいる場合は給与が第一のモチベーションとなり得ます。趣味の場合でも、自己研鑽がモチベーションとなり得ます。企業レベルでみると、例えば次のようなモチベーションが考えられます:

• プロジェクト維持によるセキュリティの担保
• 社外開発者との協力による新技術創出
• 社内forkを維持する負担の軽減

もちろん、評判も主要なモチベーションにはなり得ますが、これは承認欲求や感情論ではなく経済的実益としても解釈できます。個人レベルでは昇進や転職、企業レベルでは売上や人材獲得が経済的実益となり得ます。

結局、古典的な贈与モデルではOSSコミュニティのダイナミクスを説明しきれないように思われます。特に、元々開発に参加していないユーザは「贈与」に対する「返礼」を怠っても開発者コミュニティ内での地位を失いません 。というより、元々築いていない地位は失いようがありません。OSS活動には贈与モデルを当てはめなくても、自由市場経済の下での合理的行動として解釈できます。これは純粋公共財 (pure public goods) が非公共部門 (non-public sectors) により効率的・持続的に供給されうる稀有な例であると言えます。

OSSにただ乗りし続けると何が起こるか

古典的な贈与モデルがOSSに当てはまりきらないとしても、ただ乗りが望ましくない点での結論は変わりません。ただ乗りが続くとOSSコミュニティは停滞し、新機能が追加されなくなったり、バグが修正されなくなったりします。ですが、これ自体はユーザにとっては大した問題ではありません。他のソフトウェアに乗り換えるとか、自分でforkしてメンテナンスするとかの選択肢があるからです。問題なのは、悪意を持った開発者からの “Gift” です。”Gift” は英語では「贈与物」を意味しますが、ドイツ語では「毒」を意味します。贈与物→投与物→毒 と意味が変化したようです。

xz 乗っ取り事件

そのような “Gift” の一例としては、2024年3月に発覚した、xz・liblzma 乗っ取り事件を挙げることができます。圧縮・展開ツールであるxz および、そのライブラリであるliblzmaはほとんどのLinuxディストリビューションに標準で含まれているコンポーネントであり、当然に信頼できるものと思われがちでした。実際、元々のメンテナは悪意を持っていませんでしたが、途中から開発に参加した “Jia Tan” (おそらく偽名)と名乗るメンテナによって、不正なSSH接続を可能にするバックドアが仕掛けられていました。

“Jia Tan” が xz・liblzma の乗っ取りに成功した背景には、xz・liblzma が広く使われているにも関わらず、開発コミュニティが停滞していたことが挙げられます。停滞するコミュニティにおいて、”Jia Tan” は有益・無害(と思われる)コントリビューションに2年を費やして信頼を築き、身元が明らかでないにも関わらずメンテナ権限を付与されていました。個人のいたずらにしてはあまりに長い時間をかけていることから、組織的な犯行とも推測されています。

xz・liblzmaの場合は、幸いなことに主要なディストリビューションにパッケージングされる前にバックドアが発見されました。しかしながら、xz・lzmaの事例は氷山の一角かもしれません。他のOSSも、悪意ある個人ないしは組織によって乗っ取られている可能性があります。

他の事案

やや似た事案をいくつか紹介します。

• 2022年1月: JavaScriptライブラリ colors.js および faker.js が開発者自身によって意図的に破壊され、意味不明な文字列やアスキーアートを無限回表示するコードが加えられました。AWS Cloud Development Kit などに影響しました。先立つこと2020年には、開発者は次のコメントを投稿していました:

”Respectfully, I am no longer going to support Fortune 500s
( and other smaller sized companies ) with my free work.”
— faker.js 開発者 (November 9, 2020)

• 2022年3月: Node.js 用 IPCライブラリ node-ipc が開発者自身によって意図的に破壊されました。ロシアやベラルーシで実行されている場合にファイルを破壊するコードが加えられました。
• 2024年2月: ブラウザの差異を吸収するJavaScript ライブラリである polyfill.io のドメイン及びGitHubアカウントが売却され、悪性サイトへリダイレクトするコードが加えられました。

コミュニティによる貢献や相互監視が活発になされていれば、これらの事案は防げた可能性があります。

何をコントリビュートすべきか

何をコントリビュートすべきかについて、まずはコミュニティの持続可能性の観点から考えてみます。

コミュニティの持続可能性

コミュニティの持続可能性の観点では、他の開発者がやりたがらない作業に取り組むことが重要です。例えば、バグ修正、テスト、リファクタリング、ドキュメント更新、質問対応などが挙げられます。これらの地道な作業を自らやってくれる人の善意を疑わないといけなくなったのがxz事件の最も悲しいところでもあります。

また、他の開発者の支援や監視も重要です。支援としては、pull requestをレビューしたり、途中で放棄されたpull requestを引き継いだりすることが挙げられます。監視項目としては、不審なコミットがないか、アカウントが乗っ取られていないか、名前や所属に偽りがないかなどが挙げられます。監視は相互かつ友好的に実施する必要があります。

自分・自社の活動の持続可能性

「コミュニティの持続可能性」に挙げた項目は味気ないものです。自分・自社がモチベーションを保って活動を持続できなければ、コミュニティの持続にも貢献できなくなりますので、モチベーションを保てることをコントリビューションするのも重要です。

例えば、大きい新機能を提案すると、その機能のメンテナンスで数年以上活動を続けられる(悪く言えば縛られる)ことがあります。

なお、モチベーションを保つために自己研鑽や趣味として凝った機能を作ってみても良いのですが、他の開発者がメンテナンスできるかへの配慮も必要になります。配慮したくない場合は、既存プロジェクトにマージさせるのではなく、forkしたり新規プロジェクトを立ち上げたりすることも検討すると良いでしょう。

何をやりたいか自分でもわからない場合はtypo修正など簡単なことから始めても構いませんが、typo修正ばかりやっていると荒らし(troll)と見做される恐れもあります。

コードを書くだけがコントリビューションではない

コードを書くだけがコントリビューションではなく、マネジメント面でのコントリビューションが実は一番重要です。特に、どうすれば他社・他者の行動を促せるかが鍵となります。例えば、コーディングやテストを必要とする部分を整理し、開発者を募ることが挙げられます。業務指示を出せるわけではない他社の方に行動を促すのは容易ではありませんが、会社をまたがってプロジェクトをまとめ上げられると、効率的に開発を進めることができます。

また、レビューされず放置されている pull request や脆弱性報告を洗い出し、適切なレビューワーを割り当てたり、自ら判断を下したりすることも重要です。マージするつもりがないpull requestについては、放置するよりもリジェクトする方が親切です。明示的にリジェクトしてもらえると、開発者はレビューを待たずに次の行動に進むことができます。脆弱性報告については、そもそも脆弱性が実在するのか怪しかったり、zero-day attack 防止の観点から公表時期の決定が難しかったりして対応が長引くことがあります。公表に当たっては、主要なユーザとの折衝が必要となることもあります。

こうしたマネジメントについては、ソフトウェア技術よりも、人脈や交渉力の方が重要になることもよくあります。とは言っても、コードを書かない「口だけ番長」は発言力を得られないので、結局はコードを書くのが基本となります。

その他、各 foundation 等への資金拠出ももちろん重要なコントリビューションとなります。

コントリビュータの評価

コントリビュータをどう評価すべきかについて、コミュニティ目線および企業目線でそれぞれ考えてみます。

コミュニティ内での評価は、主にメンテナの選定に関係します。大きい新機能を追加したコントリビュータは、当該モジュールのメンテナンスを長期的に任されることがあります。また、バグ管理、リリース管理、他のプロジェクトとの折衝などができると、プロジェクト全体の管理を任されやすいと言えます。

次に、OSS活動に取り組む従業員を、企業としてどう評価すべきかについて考えてみます。OSS活動が自社製品の売上に直結していると理想的ではありますが、それだけを評価指標にするとコミュニティの持続可能性を損なう恐れがあります。コミュニティの持続可能性の観点からは、コミュニティ内での評価も社内評価に取り入れることが望ましいと考えられます。なお、業務成果を定量評価するためにコミット件数やコード行数を測定している企業も多く存在しますが、定量性にこだわりすぎると迷惑行為の助長に繋がるのでよくありません。数値目標を満たすために、typo修正などの些細なpull requestを大量に投稿する組織も散見されます。

NTTでの自身のOSSコントリビューション事例

NTTグループは今までに Linux、 PostgreSQL、 OpenStack、 Hadoop など多くのOSSに積極的にコントリビュートしてきました。

日本電信電話株式会社 ソフトウェアイノベーションセンタ に所属する私自身は、Docker/Moby (2016-)、BuildKit (2017-)、containerd (2017-)、runc (2020-)、OCI Runtime Spec (2022-) など主要なコンテナ関連OSSのメンテナを務めています。2015年末、Docker のファイルシステム関連の問題に遭遇したことがきっかけで、pull request を投稿したり、課題整理などのコントリビューションを行なったりするようになった結果、メンテナとしての役割を任せてもらえるようになりました。

機能的に大きなコントリビューションとしては、コンテナランタイムを非root権限で実行することでセキュリティを強化するRootlessコンテナと呼ばれる技術をcontainerd、BuildKit、Docker、Kubernetes に実装しました (2018-)。コンテナのネットワークを非root権限で実行可能にするモジュールとして開発した slirp4netns は、Red Hat社が主導するDocker互換OSSである Podman でも採用されました。振り返ってみると、提案がDockerに採用された時はモチベーションが大きく向上しましたが、マージとリリースに時間がかかった点で向上分がやや相殺されたと感じています。

こうした経験も踏まえ、2020年からはcontainerd をベースにしたDocker互換プロジェクトとして nerdctl (contaiNERD CTL) を開発しました。OSSとしてのDocker (Moby) のリリースが当時は停滞しており、containerd側で進んでいたセキュリティや性能面での改善を取り込みにくい状態が続いていたことが、新しい互換プロジェクトを立ち上げた理由です。OSSとしてのDocker (Moby) は現在では活気を取り戻しています。

また、 nerdctl 入りの Linux 仮想マシンを簡単に立ち上げるツールとして Lima も開発しました。nerdctl 及び Lima は SUSE社のRancher Desktop や AWS社のFinchなどの製品にも取り込まれており、広く使われています。

2023年頃からは、OSSのサプライチェーンセキュリティを向上する取り組みをいくつか並行して進めています。その取り組みの一つとして、ソースコード汚染の検出を容易化する技術である Reproducible Builds のコンテナへの採用を推進してきましたが、ツール群の実装は進んでいても Docker Hub への採用交渉は難航しているところです。OSS活動においては実装力よりも交渉力が重要となることを改めて実感しています。

OSSの今後

最後に、OSSの今後についての展望を述べます。

LLM界隈からの影響

良くも悪くも、OSSはLLM界隈からの影響に晒されつつあります。GitHub Copilot などのLLM系アシスタントが生成するコードには他社の著作物が混入する懸念がありますが、生産性の観点からはLLMの使用を禁止するのは現実的ではありません。仮に禁止したとしても、コントリビュータは勝手にLLMを使うので実効性がないと考えられます。生産性を維持・向上しつつ、ライセンス上の懸念を払拭するにはどうすれば良いかが課題となっています。

また、利用目的に制限を課すLLMをも “open source” と呼ぶ文化が、LLM 以外のソフトウェアにも波及する恐れがあります。”open source” を名乗っていたり、あるいは “open source” であると報道されていても信用せず、ライセンスの原文を確認することが従来にも増して重要になります。

匿名性の低下

氏名や所属の公開を望まないOSS開発者も多く存在しますが、そのような匿名開発者は一部の活動が困難になる可能性があります。特に、2024年3月のxz・liblzma 乗っ取り事件以後は、優秀でも身元が不明な人物をメンテナに登用することは難しくなりつつあります。

新規のコントリビュータが信頼を得る方法の1つとしては、Open Source Summit や FOSDEM (Free and Open source Software Developers’ European Meeting) などの会議にオフラインで参加し、他の開発者と交流することが挙げられます。ただし、旅費を勤務先に請求できない個人コントリビュータをどう包摂するかが課題です。業務としてOSSに取り組んでいるコントリビュータでも、登壇しない場合は出張を申請しにくいことも考えられます。

プロジェクトの定量化

本記事ではOSSプロジェクトの持続可能性について何度も言及してきましたが、これを定量化することは容易ではありません。開発者が何人バスに撥ねられてもプロジェクトを持続できるかを示す、”Bus factor” (“Truckfactor”) なる物騒な指標も提唱されてはいますが、厳密性には乏しく、普及していないようです。別の指標が必要そうです。

また、プロジェクトの発展・衰退(・復活)を数理モデル化することも有益になると思われます。再現性のあるやり方で、プロジェクトを発展させたり復活させたりできるようになると良さそうです。

まとめ

長文となりましたが、お伝えしたかったことは次の3点です:

• なぜOSSにコントリビュートすべきなのか
  → 持続可能性のため (だけとは言っていない)
• OSSが放置されると悪意をもった開発者に乗っ取られることがある
• ただ乗りは合理的のようで合理的ではない

本記事がOSSコミュニティの更なる活性化に少しでも役立てば幸いです。

私たちNTTは、様々なオープンソースコミュニティで共に活動する仲間を募集しています。ぜひ弊社採用情報ページをご覧ください。