10.12 オープンソース対クローズドソース

概要と動機

ほぼすべての現代のシステムは、自分で書いたソフトウェア、買ったソフトウェア、無料で手に入れたソフトウェアの混合です。そのうち二つには根本的な選択が付いてきます。そのソフトウェアはオープンソースかクローズドソースか。オープンソースソフトウェア(OSS)は、プログラムを定義する人間が読める命令であるソースコードを、誰もが使い、調べ、変更し、再配布する権利を与えるライセンスのもとで配布されます。クローズドソースソフトウェアは、プロプライエタリソフトウェアとも呼ばれ、ベンダーがソースコードを非公開に保つ完成品として配布されます。ライセンスのもとで動かす権利は得られますが、どう動くかを調べたり変えたりする権利は得られません。中間の区分であるソースアベイラブルソフトウェアは、読むためにソースを公開しますが、使用、変更、再配布を制限します。標準的な定義では見えるがオープンではありません。

比較する前に、二つの明確化が重要です。第一に、「フリー」は曖昧です。コミュニティは、自由という意味のフリー(変更し共有する自由。時に「libre」と書かれる)と、価格という意味のフリー(コストゼロ、「gratis」)を区別します。オープンソースは自由についてであって、必ずしも価格についてではありません。第二に、オープンソースのライセンスは二つの系統に分かれます。寛容なライセンス(MIT、BSD、Apache 2.0など)は、閉じた製品にコードを埋め込むことを含め、ほぼ何でもさせてくれます。コピーレフトライセンス(GNU一般公衆利用許諾書、GPLなど)は、配布する派生物も同じオープンな条件で公開することを要求し、批判者には「感染性」、支持者には「継承」と呼ばれることもある互恵のルールです。

この章は、この選択を二つの側から見ます。利用者として、オープンソースかプロプライエタリのコンポーネントを採用するかを決めます。生産者として、築いたソフトウェアをオープンソース化するかを決めます。大企業、特に政府にとって、どちらの決定もライセンスファイルをはるかに超える重みを持ちます。調達(10.3章)、デジタル主権(10.11章)、サプライチェーンのセキュリティ(4.2章)、相互運用性(3.8章)、築くか買うかの計算(6.1章)に触れます。

主要原則

「オープン」を定義するのはライセンスであって、価格ではない。 ライセンスを読みます。無料とオープンソースは別の主張です。
どちらのモデルも本質的により安全ではない。 どちらも優れていることも怠慢なこともあり、コードの周りの実践は、その開放性より重要です。
開放性は依存を減らすてこである。 ソースへのアクセスは、ベンダーロックインへの究極の保護です。
運用の負担は常に自分が負う。 取得が無料でも、動かすのは決して無料ではありません。総所有コストが本当の話を語ります。
差別化要因は閉じたままにし、コモディティは開ける。 あなたを区別しないものはオープンソース化し、区別するものは守ります。
コピーレフトには帰結がある。 配布する製品にコピーレフトのコードを埋め込む前に、互恵の義務を理解します。
生きたコミュニティは資産で、放棄されたリポジトリは負債である。 ライセンスだけでなく、プロジェクトを判断します。

推奨事項

ライセンスだけでなく、プロジェクトでコンポーネントを評価する

オープンソースかプロプライエタリかを問わず、依存関係を採用する前に、その健全性を評価します。リリースの周期、メンテナーの数と多様性、セキュリティ報告への応答性、採用の広がり。単一のメンテナーのオープンソースライブラリと小さなプロプライエタリのベンダーは、同じバスファクターのリスク(一人か少数の重要な人が去るとプロジェクトが崩壊する危険)を負います。広い貢献者の基盤を持つコンポーネントや、財務的に健全なベンダーを好み、評価をデューデリジェンスの一部として記録します(10.2章、4.2章)。

ライセンスを第一級の義務として読み、追跡する

すべてのコンポーネントとそのライセンスの目録を保ち、どの用途にどのライセンスの系統が許容されるかの方針を徹底します。決定的な区別はコピーレフトです。寛容なコード(MIT、Apache 2.0)は、一般に閉じた製品に自由に埋め込めます。強いコピーレフト(GPL)は、配布する自分の派生物を同じ条件で公開する義務を課しえます。依存関係をスキャンしてコンポーネント、ライセンス、既知の脆弱性を特定するツールである、自動のソフトウェア構成分析(SCA)を使い、製品のすべてのコンポーネントの正式な一覧であるソフトウェア部品表(SBOM)を生成します(10.3章、4.2章)。

開放性ではなく実践でセキュリティを判断する

「多くの目」の議論(リーナスの法則、「十分な数の目があれば、すべてのバグは浅い」)のゆえにオープンソースが安全だと想定してはいけません。また、隠蔽によるセキュリティ(ソースを隠せば欠陥も隠れるという誤った信念)でプロプライエタリのコードが安全だと想定してもいけません。多くの目は、有資格の人が実際に見る場合にだけ役立ち、広く使われる多くのプロジェクトは薄くしか保守されていません。どちらのモデルもサプライチェーンのリスクを負います。オープンソースは侵害された、あるいは放棄された依存関係を通じて、プロプライエタリは検査できない不透明なコードと更新経路を通じて。モデルにかかわらず、バージョンを固定し、出所を検証し、継続的にスキャンし、勧告を監視します(4.2章)。

出口と相互運用性のために設計する

後で置き換えられるよう、オープン標準と可搬なデータ形式を話すコンポーネントを好みます(3.8章、10.11章)。オープンソースなら究極の出口が得られます。プロジェクトが停滞しても、フォーク(自分のコピーを作って保守すること)できます。プロプライエタリソフトウェアでは、前もって保護を交渉します。オープンな形式でのデータのエクスポート、文書化されたAPI、ソースコードエスクロー(ベンダーがソースを第三者に預け、ベンダーが失敗したらあなたに解放される法的な取り決め)。どちらの種類でも、単一のコンポーネントがシステムを人質に取れないように設計します。

見出しの価格ではなく総所有コストを量る

ライセンス料だけでなく、取得、統合、運用、サポート、訓練、アップグレード、最終的な置き換えを含む全寿命のコストである総所有コスト(TCO)で選択肢を比較します。オープンソースはしばしば、ライセンスのコストを、より高い運用と人員のコストと交換します。プロプライエタリソフトウェアはしばしば、予測可能なサブスクリプション料金を、ロックインとより少ない制御と交換します。モデル自体のコストを含めてください。自己サポートのオープンソースは社内の技能を要し、プロプライエタリソフトウェアはベンダー管理の能力を要します。

生産者として、差別化しないものをオープンソース化する

自社のソフトウェアを、競争上あるいは使命上の優位性を与えるものと、差別化されない配管に分類します。差別化要因はプロプライエタリに保ちます。コミュニティが保守と改善を分かち合える、コモディティのインフラストラクチャのオープンソース化を検討します。政府では、透明性、再利用、主権の推進力として、「公金には公開コード」(納税者が資金を出したソフトウェアは既定で公に利用可能であるべきという原則)を量ります(10.5章、10.11章)。ライセンスを意図して選びます。採用を最大化するなら寛容、エコシステムをオープンに保つならコピーレフト。

トレードオフ: 長所と短所

次元	オープンソース	クローズド/プロプライエタリ
取得コスト	通常、取得はゼロ	ライセンスあるいはサブスクリプション料金
総所有コスト	コストが運用と人員にシフトする	より予測可能だが、ロックインのプレミアム
制御とカスタマイズ	完全。ソースを読んで変更できる	ベンダーが公開するものに限られる
サポートと説明責任	コミュニティ、または有料の第三者。責任を問える一つの窓口がない	契約上のサポートと、明確な説明責任のある当事者
セキュリティの姿勢	監査可能。本当に保守されていれば「多くの目」	ベンダー管理。不透明。隠蔽は保護ではない
寿命/放棄	保守されればフォークできる。それでも衰えうる	ベンダーの存続とロードマップに依存
ベンダーロックイン	低い。ソースとオープンな形式が出口を可能にする	標準とエスクローで緩和しない限り高い
エコシステム	オープンなコミュニティと相互運用性	選り抜かれ、統合され、時に壁に囲まれる

繰り返される緊張は、制御対利便性と説明責任です。オープンソースは、制御、監査可能性、ロックインからの自由を最大化しますが、能力、統合、サポートを自分で供給するよう求めます。プロプライエタリソフトウェアは、サポートされ、統合され、説明責任のある製品と、執行できる契約を届けますが、制御を譲り、ロックインを招きます。解決が全部かゼロであることはまれです。ほとんどの成熟した資産群は、サポート、説明責任、専門的な能力がトレードオフを正当化する所で、オープンソースの基盤とプロプライエタリのシステムを混ぜています。

チームで議論すべき問い

パイプラインの自動SCAとSBOMで、特に出荷前に強いコピーレフトを捉えるために、ライセンス方針を徹底していますか。 配布するプロプライエタリ製品にGPLライブラリを埋め込むと、自分のソースを公開する義務が生じえ、その驚きは通常遅く、元に戻すのが高価な時に表面化します。すべてのコンポーネントとそのライセンスの目録を保ち、どの用途にどのライセンスの系統が許容されるかを徹底し、出荷時に弁護士が捉えるのではなく、パイプラインが違反をブロックするようソフトウェア構成分析を自動的に走らせます。SBOMを当然のこととして生成します。大きな、あるいは政府の資産群では、これはサプライチェーンの衛生であり、しばしば調達の要件です。現在のライセンスの目録、あるいは持っていないという事実を持ち込み、誰が方針を所有するかを決めてください。
依存関係を採用するとき、デューデリジェンスとして、プロジェクトの健全性とバスファクターを評価していますか。 単一のメンテナーのオープンソースライブラリと小さなプロプライエタリのベンダーは、同じリスクを負います。一人か少数の重要な人が去ると、プロジェクトが崩壊する。何かを採用する前に、リリースの周期、メンテナーの数と多様性、セキュリティ報告への応答性、採用の広がりを評価し、評価を記録します。どちらのモデルも既定で安全ではありません。「多くの目」は有資格の人が実際に見る場合にだけ役立ち、広く使われる多くのプロジェクトは薄くしか保守されていません。製品が最も依存する三つか四つの依存関係を持ち込み、それぞれについて、何人が去ったらあなたの問題になるかを尋ねてください。答えられなければ、それが自分に負っている評価です。
プロプライエタリを買うとき、出口の保護を前もって確保していますか。 プロプライエタリソフトウェアは、制御と引き換えに説明責任と利便性を提供し、隠れたコストはロックインです。ベンダーがほとんど救済なしに価格を上げたりサービスを劣化させたりできる、切り替えのコスト。署名する前に、まだてこがある間に保護を交渉してください。オープンな形式でのデータのエクスポート、文書化されたAPI、ベンダーが失敗したらソースを解放するソースコードエスクロー。オープンソースでは、出口はフォークする能力ですが、プロプライエタリでは出口を契約に書き込まなければなりません。最も重要なプロプライエタリのシステムを持ち込み、ベンダーが価格を倍にする、あるいは倒産したら実際に何が起こるかを尋ねてください。答えが「身動きが取れない」なら、更新時に契約を直します。
自分で築くソフトウェアについて、何をオープンソース化し何を閉じておくかをどう決め、その判断をする権限を誰が持っていますか。 一方向に誤れば、あなたを差別化するまさにそのコードを手放し、他方向に誤れば、コミュニティが喜んで保守を分かち合うコモディティの配管を抱え込みます。相反する圧力は本物です。エンジニアは公開リポジトリの採用と評判の上振れを望み、プロダクトと法務は、競合に優位性を渡す、あるいはセキュリティ上機微なヒューリスティクスをさらすことを心配します。システムを、使命を差別化するものと差別化されないインフラストラクチャに誠実に分類したものを持ち込み、リリースを承認する人あるいは委員会を名指ししてください。リポジトリをプッシュした人が下すその場しのぎの決定は、重要資産が漏れる方法だからです。大企業にとってこれはポートフォリオの戦略であり、政府にとっては、納税者が資金を出したソフトウェアは既定で公開であるべきという原則「公金には公開コード」と衝突するので、どの免除(国家安全保障、不正検知、個人データ)がコードを閉じておくことを正当化するかを、事前に決めてください。
築くか買うかの比較は、総所有コストの全体を捉えていますか。それとも、まだゼロのライセンス料をゼロのコストとして扱っていますか。 オープンソースについての最も一般的な財務上の間違いは、「取得が無料」を「動かすのも無料」と読み、それから、統合、運用、セキュリティ対応、有料のサポートが、避けたどんなライセンスも小さく見せると発見することです。緊張は、プロプライエタリのサブスクリプションが、請求書では高く見えてロックインのプレミアムを隠し、オープンなコンポーネントが、請求書では無料に見えてコストを自分の職員に移すことです。二、三の本物の決定について、同じ条件のTCOモデルを持ち込んでください。取得、統合、運用、サポート、訓練、アップグレード、セキュリティ対応、最終的な置き換えを、最初の年ではなく全寿命で値付けしたもの。企業や政府の資産群では、運用モデル自体のコストを加えてください。自己サポートのオープンソースは、採用して保持しなければならない社内の技能を要求するので、それらの項目を省いた比較は、分析ではなく証拠として扱ってください。
コンポーネントのセキュリティを、実践で判断していますか。それとも、「多くの目」であれ閉じたコードの秘密であれ、開放性のラベルに寄りかかっていますか。どちらの既定も罠です。「多くの目」は、有資格の人が実際にコードをレビューする場合にだけ守り、広く使われる多くのオープンなプロジェクトは一人の疲れたメンテナーで動いています。攻撃者に見られないことに頼る閉じたソースは、統制ではなく隠蔽によるセキュリティです。この議論が重要なのは、乏しいセキュリティの労力をどこに使うかを変えるからで、誠実な答えは、どちらのモデルもサプライチェーンのリスクを負うということです。オープンソースは侵害された、あるいは放棄された依存関係を通じて、プロプライエタリは検査できない不透明な更新経路を通じて。最も重要なコンポーネントの証拠を持ち込んでください。誰が実際にレビューするか、勧告がどれだけ速くパッチされるか、バージョンが固定され出所が検証されているか、SBOMを生成しているか。大きな、あるいは政府の資産群では、これを調達と継続的スキャンの義務に結びつけてください。規制当局は、ソースが公開だったかではなく、何を検査したかを尋ねるからです。

セクター別の視点

スタートアップ。 滑走路が乏しいので、ライセンス料を払えず、プロジェクトが停滞したらフォークする自由が欲しいため、オープンソースの基盤の上に築きます。出荷する前に構成分析のスキャンを走らせ、強いコピーレフトのライブラリが静かに自分のソースの公開を義務づけないようにし、唯一の本物の差別化要因を厳密に閉じておきます。採用の助けになるなら小さく重要でないツールをオープンソース化しますが、担えない保守の負担に人員を置かないでください。

小規模事業者。 社内に法務やプラットフォームの専門家はいないので、ライセンスを、習得できる話題ではなく、読み違えてはならないリスクとして扱ってください。ベンダーがパッチと説明責任を負う、サポートされたプロプライエタリのツールや商用オープンソースのディストリビューションを好みます。運用できないスタックを自己サポートするのは偽の節約だからです。無料のコンポーネントを採用するときは、そのライセンスがあなたの使用を許し、プロジェクトが放棄されず実際に保守されていることを確認します。

大企業。 規模での問題は、多くのチームにわたる一貫性です。書かれたライセンス方針、すべてのパイプラインでの自動のソフトウェア構成分析とSBOMの生成、チームごとの習慣ではなくTCOに基づく築くか買うかの決定。オープンとプロプライエタリのソフトウェアを一つのポートフォリオとして管理し、調達でオープンな形式やソースコードエスクローのような出口の保護を標準化し、単一の放棄されたプロジェクトがインシデントにならないよう、重要な依存関係の健全性を追跡します。生産者の側も統治し、組織が何をオープンソース化し何を閉じておくかの明確なルールを持ちます。

政府。 調達規則、透明性の義務、公的な説明責任があらゆる選択を形づくります。機関間の再利用とデジタル主権を進めるために、「公金には公開コード」、つまり納税者が資金を出したソフトウェアは既定で公開であるべきという原則を量りつつ、セキュリティに敏感なコードや個人データのコードには狭い免除を設けます。プロプライエタリのサプライヤーに、ベンダーの失敗が公共サービスを取り残さないよう、オープンな形式でのデータのエクスポートとソースコードエスクローを提供させ、市民が自分たちを統べる規則を監査できるよう、機微でないソースを公表します。

事例

スタートアップ。 3人の創業者のスタートアップは、ライセンス料を払えず、プロジェクトが停滞したらフォークする自由が欲しいため、プロダクト全体をオープンソースの基盤(Linux、オープンソースのデータベース、ウェブフレームワーク)の上に築きます。出荷前に、創業者の一人が構成分析のスキャンを走らせ、独自のマッチングアルゴリズムの公開を強いたであろう強いコピーレフトのライブラリを捉えるので、寛容なライセンスの同等品に差し替えます。その唯一の差別化要因であるアルゴリズムは厳密に閉じておき、善意を築きエンジニアを引きつけるために、小さな社内のログツールだけをオープンソース化します。

大企業。 大手の保険会社は、中核のプラットフォームを、Linux、広く使われるオープンソースのデータベース、コンテナオーケストレーターというオープンソースの基盤の上で動かします。しかし、ベンダーの領域の専門性、規制上の認証、サポート契約が料金に見合い、比較できるオープンな代替がないため、プロプライエタリの保険数理モデリングのスイートを買います。配管に説明責任とパッチを得るために、商用オープンソース(オープンなコンポーネントのベンダーがサポートするディストリビューション)のサブスクリプションを払い、自社を差別化する価格設定のアルゴリズムは厳密にプロプライエタリで社内に保ちます。イデオロギーではなく、TCOの分析(10.10章)が各選択を駆動します。

政府。 国の税務当局は、「公金には公開コード」の方針のもとで、他の機関が再利用でき、市民が規則を監査できるよう、新しい給付資格のサービスを、オープンソースのコンポーネントとオープン標準(3.8章)の上に築きます。機微でないコードを公開リポジトリに公表し、セキュリティ上の理由から不正検知のヒューリスティクスだけを閉じたまま保ちます。これはベンダーロックインを減らし、デジタル主権(10.11章)を進めます。調達規則(10.3章)は、供給者が失敗した場合の継続性を保証するため、どのプロプライエタリのコンポーネントにも、オープンな形式でのデータのエクスポートとソースコードエスクローを要求します。

ビジネスケース: 動機、ROI、TCO

オープンソースの財務的な魅力、つまりライセンス料がないことは、取得がTCOのごく一部なので、ケースの中で最も頼りにならない部分です。持続的な見返りは戦略的です。ロックインからの自由(再アーキテクチャなしにサプライヤーを変えたり捨てたりする能力)、セキュリティとコンプライアンスのための監査可能性、エンジニアがコミットする前に試せるためのより速い採用、産業全体にわたるコモディティコードの共有の保守。相殺するコストは本物です。統合、運用、セキュリティ対応、しばしば有料のサポートを自分で供給しなければならず、まずく選ばれた保守されないプロジェクトは、どんなライセンスよりもインシデントで高くつきえます。

プロプライエタリソフトウェアのビジネスケースは、説明責任と利便性です。製品に責任を負う単一のベンダー、執行できるサポート契約、統合された機能、予測可能な予算。その隠れたコストはロックインで、ベンダーがほとんど救済なしに価格を上げたりサービスを劣化させたりできる切り替えのコストに、ベンダーの支払い能力とロードマップへの依存が加わります。一般的なビジネスモデルは線を曖昧にします。オープンコア(プロプライエタリの有料アドオンを伴うオープンな基盤)、デュアルライセンス(同じコードをコピーレフトと有料の商用ライセンスの両方で提供)、サービスとしてのソフトウェア(SaaS)(ソフトウェアが借りるホスト型のサービスとして動き、バイナリを所有しないのでソースは無関係かもしれない)、そうでなければ無料のコードの周りのサービスを売るサポート/サブスクリプションモデル。

生産者にとって、差別化しない自社のソフトウェアをオープンソース化するROIは相当なものになりえます。外部の貢献者があなたの保守の負荷を減らします。プロジェクトは採用と評判の資産になります。外部の採用が、あなたの標準を事実上の標準にします。政府にとっては、公共部門全体の透明性と再利用を届けます。戦略的なルールは単純です。コストを分かち合いエコシステムを育てるためにコモディティをオープンソース化し、他のすべてに資金を出す優位性を守るために差別化要因を閉じておく。

アンチパターンと落とし穴

「無料は無料を意味する」: ゼロの取得コストをゼロのTCOとして扱い、運用とサポートに資金を出さないこと。
ライセンスへの盲目: 配布するプロプライエタリ製品に強いコピーレフトのコードを埋め込み、計画していなかった義務を引き起こすこと。
「多くの目」への信仰: 一人の疲れたメンテナーしかおらずセキュリティレビューもないのに、オープンなプロジェクトが監査されていると想定すること。
隠蔽によるセキュリティ: 攻撃者が読めないというだけで、クローズドソースは安全だと信じること。
イデオロギー的な絶対主義: コンポーネントごとに価値とTCOで選ぶ代わりに、「すべてオープン」や「すべてプロプライエタリ」を義務づけること。
出所の無視: SBOM、バージョン固定、サプライチェーンの検証なしに依存関係を引き込むこと(4.2章)。
重要資産のオープンソース化: あなたを差別化するまさにそのコードを公開し、優位性を手放すこと。
フォークして放置: 実際にフォークを保守する能力なしに、放棄されたプロジェクトをフォークすること。

成熟度モデル

レベル1(開始)。 オープンソースとプロプライエタリのコンポーネントが、その場しのぎで資産群に入ります。ライセンスは読まれず、目録もSBOMもなく、モデルの選択は習慣や価格だけで行われます。放棄とライセンスのリスクは、何かが壊れたときにだけ表面化し、各チームが独自に反応します。

レベル2(発展)。 一部のチームが基本的な実践を始めます。コンポーネントとライセンスの目録、許容されるライセンスの大まかな見方、時折のソフトウェア構成分析。築くか買うか、オープンかクローズドかの決定が書き留められますが、規律は部分的でチーム間で一貫しないため、習慣が根づいていない所では、コピーレフトやバスファクターの驚きがなお紛れ込みえます。

レベル3(標準化)。 消費と生産の両方を統べる文書化された枠組みが、組織全体にあります。コンポーネントはTCOとプロジェクトの健全性で選ばれ、ライセンスはパイプラインで自動的に徹底されて違反がビルドをブロックし、SBOMは当然のこととして生成され、明示的な方針が組織が何をオープンソース化し何を閉じておくかを述べます。オープンな形式やソースコードエスクローのような出口の保護は調達の標準で、すべてのチームが独自ではなく同じルールに従います。

レベル4(管理)。 プログラムが、ベースラインに対して測定され制御されます。組織は、製品にわたるSBOMのカバレッジ、方針に違反する依存関係の割合、公表された依存関係の脆弱性にパッチを当てる平均時間、重要なプロジェクトのバスファクターと健全性のスコア、各選択を正当化した見積もりに対する実現されたTCOのような指標を追跡します。閾値が行動を引き起こします。保守が停滞する、あるいはパッチの遅延が目標を超えてずれるコンポーネントは、証拠に基づいて置き換えの旗が立てられ、オープンかクローズドか、築くか買うかの決定は、習慣で擁護されるのではなく、数字に照らして見直されます。

レベル5(オーケストレーション)。 オープンソースの戦略は、意図した事業能力として、組織全体に統合され、継続的に改善されます。組織は依存するプロジェクトに貢献し、時にはそのスチュワードを務め、差別化しないソフトウェアを当然のこととしてオープンソース化し、依存関係の健全性とTCOのデータを調達、セキュリティ、プロダクトの計画にフィードバックします。コスト、リスク、主権、戦略的優位性の変化が危機を強いる前に適応しながら、オープンとプロプライエタリのソフトウェアのポートフォリオを日常的に再均衡させます。

議論のためのアイデア

資産群のどこで、単一のベンダーやメンテナーを失うことが存在に関わり、出口の計画は何ですか。
自社のシステムのうち、オープンソース化できるコモディティはどれで、守るべき本物の差別化要因はどれですか。
あなたの組織は「多くの目」を本物のセキュリティ統制として扱っていますか。それとも検討されない想定ですか。
公共部門の読者へ。「公金には公開コード」を既定にすると、次の調達の何が変わりますか。
TCOの比較は、オープンソースがあなたに移す運用とサポートのコストをどれだけ捉えていますか。

要点

オープンかクローズドかはライセンスで定義され、価格ではありません。自由という意味のフリーと価格という意味のフリー、寛容とコピーレフトの違いを知ります。
どちらのモデルも本質的により安全でも安くもない。 オープンの表示ではなく、プロジェクトの実践と全体のTCOを判断します。
開放性はロックインへの最強の解毒剤で、監査可能性、可搬性、フォークする能力を届けます。プロプライエタリソフトウェアは、制御と引き換えに説明責任と利便性を提供します。
コンポーネントごとに価値で決め、イデオロギーではなく、意図してモデルを混ぜます。
生産者として、コモディティをオープンソース化し、差別化要因を閉じておく。 政府では、透明性、再利用、主権のために「公金には公開コード」を量ります。

参考文献とさらなる読み物

Eric S. Raymond, The Cathedral and the Bazaar
Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Adrian Cockcroft and others, various O’Reilly titles on open-source strategy and operations
Free Software Foundation, The Free Software Definition (and the GNU General Public Licence texts)
Open Source Initiative, The Open Source Definition and approved-licence list
Free Software Foundation Europe, Public Money, Public Code campaign materials
Yochai Benkler, The Wealth of Networks