オープンソース戦略の策定

オープンソースを利用している企業のほとんどは、そのビジネス価値を理解し、効率性、柔軟性、相互運用性、イノベーションのスピードなど、オープンソースの優位性を評価しています。しかし、「オープンソースの将来」に関する最新調査によると、コミュニティ開発やコード保守など、基本的なオープンソースの管理を実践している企業は、オープンソースを利用している企業のわずか半分に過ぎないと報告されています。

オープンソースによるROIを実現するためには、まず始めに戦略を策定しそれを文書化することが必要です。オープンソース戦略は、ビジネス目的に合致したオープンソースの管理、参加、創出といった行動計画につながっているのです。オープンソース戦略を策定することにより、多くのチャンスが開かれ、イノベーションが促進されるのです。

内容

1. 戦略の必要性とは？
2. オープンソース戦略文書
3. 戦略へのアプローチ
4. 考慮すべき重要な事項
5. その他の事項
6. ROIの確定
7. 何に投資をするか

ガイド一覧 »
GitHub上で貢献する »

オープンソースの管理と戦略に対する皆さんの組織のアプローチを正式化することによって、ビジネスの効率を高め、リスクを最小限に抑えるためのガイドラインを作ることができます。実際にはまだオープンソース 活動に関するビジネス戦略を立てていないとしても、これが重要性であることは既に理解されているものと思います。

オープンソースへの投資を増やす最も重要な最初のステップは戦略文書を作成することです。これにより、組織がオープンソースから得られる利益を最大限に引き出すことが可能になり、間違ったライセンスを選んだり、コードを適切に保守できないなどの問題を予防することができます。戦略文書により、以下の効果が得られます。

• リーダー達を刺激し、関心を高める
• 会社内のさまざまなレベルからの同意を得る
• 組織内の多部門間の意思決定を容易にする
• 個人や発明者がより適切な決断を下すのに役立つ
• 発明に対する健全なコミュニティを構築するのに役立つ
• 会社のオープンソースへのアプローチと、オープンソース利用に対する会社のサポートを明確にする
• 会社が外部のどのコミュニティ主導型のR＆Dに投資するか、また、どの付加価値の差別化に重点を置くのかを明確にする

まず、最終的なゴールから始め、そうしてどうやってゴールに達するかを説明しましょう。我々のゴールは、オープンソース戦略を詳細に文書化することにより、エンジニアリングや法律部門から、マーケティングや経営幹部レベルに至るまで、すべての人がオープンソース戦略を参照できるようにすることです。戦略文書は、社員全体がオープンソース プログラムの背景にあるビジネス目標の理解を助け、より適切な意思決定を行い、リスクを最小限に抑えられるようになります。

「Salesforceでは、エンジニアリング チームに社内文書を配布し、オープンソースの戦略的ガイダンスを示すことにより、オープンソース戦略を促進しています。会社の戦略リーダー達が全面的に支援する戦略であるということを明確な言葉で知らせることにより、オープンソースの創成と利用を促進できるのです。また、当社のエンジニアに使用して欲しくないライセンスやオープンソース ガイドラインがある場合、その旨を社内文書に明示する必要があります。」－ Salesforce ソフトウェア アーキテクト、Ian Varley

• 文書に含めるべき最小限のこと
  会社のオープンソースの扱い方と文書化する目的を説明しましょう。会社の掲げる成功とはどういうもので、その成功を達成するためにオープンソースが果たす役割とはどのようなものでしょうか？

「Autodeskの場合、オープンソースへのアプローチを新たに始めた理由は、私達の製品がクラウド環境との緊密な一体化へとシフトするにあたり、クラウド技術に向かう必要があったからです。基本的にクラウドはオープンソースで作られているので、それを実現するにはオープンソース戦略を立案しなければなりませんでした。」－ Autodesk、director of Open (Open@ADSK)、Guy Martin

• 開発者にどのようにオープンソース コードを活用して欲しいか記述すること。自社の製品にライセンス セットアップが異なるプロジェクトからのコードが入ってきた場合はどうしますか？開発者は、どのような受け入れ／拒否／例外ポリシーに従うべきでしょうか？組織のオープンソース開発に対する全般的なスタンスとは？適切な戦略文書は、このような質問に対して明白な回答を提供するものです。
• 開発者にどのようにオープンソース プロジェクトへコードをコントリビュートして欲しいかを記述し、自社のビジネス戦略にとって重要なプロジェクトを特定すること（開発者のコントリビュートを促進！）。開発者が、作業中のプロジェクトにライセンスの異なる他のプロジェクトのコードをコントリビュートしたい場合、どうしますか？ オープンソースへのコントリビューションが好循環を生み出し、コントリビューションによって、自社のプロジェクトにも利益がもたらされるようにするには？ これらの考慮は戦略的なコントリビューションの定義の一部なのです。

「あなたの製品があるオープンソース プロジェクトに大きく依存しているにも関わらず、あなたがそのプロジェクトにおけるリーダーシップと戦略を決めるテーブルの席を持っていないとすれば、あなたのビジネスはリスクにさらされています。」－ Autodesk、director of Open (Open@ADSK)、Guy Martin

• 新たな決断を下すためのガイドラインを提供し、オープンソース プログラムへの同意とコミットメントを促すこと。オープンソースのビジネスガバナンスと技術ガバナンスは別に実施すべきですか？どのようにすれば、オープンソースに対する従業員の支持を得られるのか？適切な戦略文書はこれらの問いに答え、またオープンソースそのものや周辺に向かった開発への組織全体のスタンスを明確にすべきです。
• ビジネス ゴールと経営指針との整合を取ること。あなたのビジネス目標に合致するのは、どのようなタイプのオープンソース プロジェクトですか？
• ライセンス、設立趣意書、ポリシーに関するガイドラインを示すこと。APIはどのように文書化されていますか？誰もが利用できるコントリビュータ ライセンス同意書を作成しましたか？あなたのプロジェクトに適したライセンスを選んでいますか？ 戦略文書には、ライセンスの取扱いやAPIの扱いについて具体的な説明が必要です。
• 公開するコードとその概念に相応しい利用ポリシーと商標を提示すること。オープンソース プロジェクトのブランディングを正しく行うことは、発明のブランディングと同様に重要であり、疑問の余地を残さない明確な利用規定がなければなりません。
• オープンソースのベストプラクティスについての詳細を提供すること。うまく行っているオープンソース プロジェクトには、豊かな開発者コミュニティがあり、ビジネスとして利益をもたらす製品化された商用製品となっている場合があります。このような持続可能なエコシステムを育てるにはどのような行動が適切でしょうか？
• 継続的に質問に回答し、進化させていくこと。よいオープンソース ポリシー文書にはFAQが不可欠です。FAQの中で一般的な質問に継続して回答していく必要があります。

オープンソース戦略を策定するための第一歩は、誰が戦略の策定に関与すべきかを決めることです。これは、戦略策定に携わる内部のビジネスパートナーを決定するだけでなく、戦略的支援とリソースを外部に求めるべきかどうかの決定もしなければなりません。

外部リソース

ありがたいことに、オープンソース戦略を具体化するのに役立つ多くの外部リソースがあり、その多くは、無償で提供されています。例えば、Black Duck は、オープンソース戦略の策定に関して、何千もの企業からの相談を受け、ガイドやチュートリアルを提供しています。Linux Foundationは、適切な戦略を導入するのに役立つ豊富な教育リソースやBest Practices for Commercial Use of Open Source Softwareといった、書籍によるガイダンスも提供しています。

Linux Foundationの主導するTODO (Talk Openly Develop Openly) Groupは、オープンソース プロジェクトやプログラムを運営するメンバー企業が、実践や戦略面で互いに協力をするのに役立つ最適なリソースです。

GitHubが作成したオープンソース ガイドには、オープンソース コミュニティの構築やコントリビューションのために役立つ多くのリソースが含まれています。

Googleは、最近、オープンソース ポリシー文書をオープンソース化しており、自社の内部ポリシーを作成するためのテンプレートとして利用することができます。

PayPalによって設立された InnerSource Commonsは、オープンソースの原則と実践を追求すると同時に、内部のプロプライエタリ ソフトウェアとインフラストラクチャの開発を行う企業間のアイデア交換を専門にサポートするものです。こちらからグループのGitHubリポジトリを自由に利用することができます。

そのほかオープンソース戦略の優れたリソースとして、Changelogというブログが挙げられます。このブログ内には、さまざまなオープンソースのトピックを網羅する「Request for Commits」というポッドキャストが含まれています。このポッドキャストは、オープンソース ソフトウェアを作成する人的側面からそのビジネスモデルや戦略に関する疑問に至るまで、あらゆる問題に取り組んでいます。

テクノロジー産業の内外の多くの企業が非常に洗練されたオープンソース プログラムを持っていることに注意してください。あなたは、それらから学ばなければなりません。オープンソースへのアプローチ方法は、企業のニーズによってそれぞれ異なりますが、あなたのビジネスに最適な実践方法と戦略を選択して、それを適用することができます。Linux FoundationのTODO Groupは、このように企業間で最善の実践方法を共有し、それを発展させるために設立されたものです。TODOはまた、GitHub上でオープンソース ポリシーとテンプレートのセットを提供しており、無償で利用したりコントリビュートすることができます。

General Electric (GE) は、オープンソースの変革を動かした最初の企業というわけではありませんが、GEはオープンソースに大きな影響力を持つ企業です。GE Softwareは、世界最大の産業課題の取り組みを強化するために、Cloud Foundry Foundationと協力して「インダストリアル道場」を運営しています。これらの取り組みで協力しているGEとパートナーは、相互に利益を得ています。

オープンソースの促進とツールの商用化に焦点を当てたプロフェッショナルな社内プログラムを展開している組織は他にもありますが、その中でもNetflixは特出した存在です。同社のオープンソース ソフトウェア センターは、一見の価値があります。Netflixは、機械学習やオーケストレーション アプリケーションから、そのプラットフォーム上で動作するユーティリティまで、オープンソース コミュニティに多くの有用なツールとアプリケーションを提供してきました。また、その多くは、テストされ、スケールするよう強化されています。Netflixもまた、自身のプラットフォームの効率的な運営に役立つコントリビューションを受け取っており、そのオープンソースへの取り組みは、さまざまなパートナーシップを得るためのドアを開くことになりました。

ここまでは、戦略文書に含めるべき重要要素とその策定方法について触れました。ここからは、戦略を策定する上で重要な2つの考慮事項について議論します。それは、ガバナンスとサステナビリティです。

これらのコンセプトが、プログラムの哲学的枠組みを設定し、プログラムの実行方法を決定し、そして最終的にオープンソース戦略を最大化する方法、または最大化できるかどうかを決定する助けになります。

考慮項目 #1：ガバナンス

オープンソース戦略を策定する前に、各チームや部門（製品チームやIT部門など）には、コードを使用したりアップストリームにコントリビュートしたりするためのさまざまなプロセスがあるでしょう。標準化されたガバナンスを確立することは、プロセスを合理化および最適化するための鍵となり、これにより開発者が参加しやすくなります。また、全員が同じ認識を共有することになり、さらにゴールへの進捗を測定し、リスクを軽減するための基盤を提供することになります。誰もが同一のポリシーやプロセスに従っていれば、発生した問題を特定し対処することがより簡単になるのです。

「私は、たった5行のバグ修正のために10週間もかけて500ページのドキュメントを処理するプロセスは避けたかったので、法務部門とともにエンジニアが妥当な時間で実現できる合理化されたワークフローを作成しました。」－ Autodesk、director of Open (Open@ADSK)、Guy Martin

策定する戦略は、組織内外のオープンソース ガバナンスに関して具体的に説明しなければなりません。適正なガバナンスには、具体的なポリシーとプロセスが必要であり、またオープンソース ソフトウェアの構築、配備、及び保守にまつわる文化についても導く必要があります。特に、オープンソース文化については、透明性を持ち、開放性があり、多様なコントリビュータの参加を促進するように取り組んでいきます。

「外部からのコントリビューションを積極的に受け入れているオープンソース プロジェクトであっても、プロジェクトのロードマップとガバナンスはほぼ一社の手中ある場合があります。また真にコミュニティ主導のオープンソース プロジェクトもあります。あなたの取り組んでいるプロジェクトはどちらの種類ですか？」－ Google、Kubernetes共同創始者／Heptio、共同創設者兼CTO、 Joe Beda

ガバナンスは、リスクの最小化に役立ちます。たとえば、多くの開発者は、オープンソース ツールをオンラインで入手し、既存のコード、プラットフォーム、アプリケーションと統合することが簡単にできます。しかし、正式な取得プロセスを経ずにそのようなことを行うことは、セキュリティ リスクから法的リスクまで、さまざまな重大リスクを招くことになります。同様に、オープンソースのライセンスとポリシーは、組織の技術や知的財産ポートフォリオ管理に大きな影響を与えることになります。更に、商用版が存在するオープンソース プロジェクトの場合は、外部ステークホルダーが自社のガバナンスへ関与する可能性を検討する必要があります。

外部のオープンソース コミュニティ構造と同じような内部ガバナンス構造を構築することは、自社の開発者の通常の内部成果に向けた活動を外部コントリビュータとして活動に切り替える際の「コンテキストスイッチ」がし易くなります。また、内部プロジェクトがいつかオープンソース化された場合、開発者は既にオープンソース ガバナンス モードで作業しているため、その移行も容易になります。

考慮項目 #2：サステナビリティ

オープンソース プログラムを成功させる鍵を握るのは、そのオープンソース プロジェクトに他の企業が商業的な依存関係を持てるような戦略を立案することです。長期的に持続可能なプロジェクトは、多才な機能を持つ開発コミュニティから生まれ、そのコードが商品化されることによってビジネスに利益をもたらし、その利益がプロジェクトに再投資されるものです。ゴールとするのは、プロジェクトの成果が製品を作り出し、それが利益を生み、その利益がプロジェクトのコミュニティ ライフサイクルに再投資されるという好循環プロジェクトを実現することなのです。

適切なガバナンスとIPモデルに基づいたパートナーシップ、コントリビューター契約及び商業的依存関係によって、ビジネスとコミュニティが噛み合った好循環プロジェクトを推進することができます。うまく定義されたオープンソース プログラムは、これらすべてを推進するのに役立ちます。オープンソースの創意を共有化、収益化し、更にパートナーシップと商業的依存関係を推進することに向かったあなたの組織のポリシーはどのようなものでしょうか？

たとえば、多くのオープンソース ツールの無償版がオンラインで提供されていますが、無償ベースでサポート付き版（サポートは有償）も存在します。また、第三者のコントリビューターがプラットフォームを強化して、有償のアプリケーションを提供することも一般的に行われています。戦略文書の中では、このような版ごとの相違は何か、それらに対してどのようにコントロールを与えていくべきか、明確に説明することが賢明です。また、コントロールのレベルは状況に応じて繰り返し変えていくことを念頭に置くべきです。

前章で検討した戦略の考慮項目以外にも、戦略文書において明確に説明すべき多くのポリシーがあります。嬉しいことに、信頼できる外部ソースによる無料のガイドラインがあり、それを利用することができます。

たとえば、synopsysは、オープンソース戦略策定に役立つ4大ガイドラインを提供しています。

• オープンソースのプラットフォームやアプリケーションを構築する戦略を定義する
• オープンソースを使って構築する戦略を定義する（既存の製品やサービスをオープンソースツールと統合するなど）
• オープンソースのために構築する戦略を定義する（既存のプロジェクトへの貢献や参加を推進するなど）
• オープンソース上に構築する戦略を定義する（オープンソースを基盤にした内部での再プラットフォーム化やアプリケーション提供など）

これらの戦略面での柱とガバナンスに関するガイドラインに加え、次に挙げる重要な項目も戦略文書に含める必要があります。

• ゴール。ビジネス戦略のゴールを定め、オープンソースがどのようにそのゴール達成を推し進めていくかを定義します。たとえば現在、多くの企業がプラットフォーム インフラストラクチャを、OpenStackなどのオープン クラウド プラットフォームに転換しようとしています。多くの場合、これが起こっているのは、インフラストラクチャをクラウドに移行するによって、どの程度のベンダロックインを避けることができるか判断し、達成したい財務目標を設定した結果として得られるROIを検討した結果なのです。

戦略文書に記述するために、全体的なゴールを達成指標とともに構築しましょう。達成指標の評価においては、アップストリームへのコントリビューションの増加、開発コストの削減、メンテナの採用人数の増加についてレポートすることを検討してください。これらの指標に加え、自身のビジネスの目的とゴールのリストには、オープンソースでのリーダーシップのマイルストーン、プロジェクトのセキュリティ、パフォーマンスの向上について詳細を説明するべきです。 ただし、魔法の測定指標は存在しないことに注意してください。

「あなたが参加しているそれぞれのコミュニティの測定指標を見てください。私は、あるコミュニティが問題と感じている点を見つけ、その指標をより良く変えようとします。プルリクエストからコントリビュータ数までの 6つの測定指標を見るだけで、そのコミュニティとエコシステムが健全であると即答できるような、魔法の評価基準はどこにも存在しないのです。」－ Google、Kubernetesコミュニティ プログラム マネージャー、 Sarah Novotny

• マネージメントプラン。戦略文書に明確なゴールを設定したら、戦略文書に明確なゴールを設定したら、オープンソースでのビジネスの目的を達成するための具体的なアクションを決め、その進行状況を追跡するための役割と責任を割り当てることも行う必要があります。
• 具体的なKPI (Key Performance Indicator)。ゴールへの達成状況を追跡するため。
• ポリシーとプロセス。コントリビューションと外部コードを受け入れるためのライセンスとルールに加えて、ポリシーとプロセスの管理も重要なことです。Linux FoundationのTODO (Talk Openly Develop Openly) Groupは、GitHubでオープンソース ポリシーの例とテンプレートを提供しています。
• パートナーシップと買収。パートナーシップと買収は、オープンソース ビジネス戦略を成功するための重要な部分です。戦略文書には、この領域の目標を詳細に明記しなければならず、TODO、Cloud Foundry Foundationなど他の組織との関係についてどのような戦略的パートナーシップを結ぶかを説明する必要があります。
• 特許とIP。特許権および知的財産のガイドラインは、発明の使用方法に多大な影響を及ぼすものであり、多くの場合、商業面で活用されます。戦略文書は、特許、特許に付随する規則及びIPガイドラインについて明確に説明しなければなりません。
• Foundationとスポンサーシップ。近年、オープンソースFoundationとその他の非営利組織が、オープンソースの世界に大きな影響を与えています。あなたの組織も、Linux FoundationやEclipse Foundation、Apache Software FoundationといったFoundationと連携することで恩恵を得ることができますし、また、オープンソースに特化したFoundationを自身で立ち上げることでも恩恵を得ることもできます。戦略文書には、Foundation との既存のパートナーシップや提携計画を明記しなければなりません。

「Foundationは大きな価値を提供しています。それらが無ければ、非常に重要なプロジェクトの多くが、維持管理に必要な資金を得ることが歴史的にも困難でした。Foundationは、公平な活動の場を広げ、企業が開発者に直接資金提供するのではなく、オープンソース プロジェクトに還元できるような仕組みを提供しています。」－ Dropbox ソフトウェア エンジニア、Luke Faraone

• インバウンド コントリビューションのガイドライン/測定指標。あなたの戦略は、インバウンド コントリビューションから多大な価値を引き出すことができます（サステナビリティの検討の項を参照してください）。戦略文書には、コントリビューションのガイドラインとその測定指標を示す必要があります。

この領域のポリシーは、一から構築する必要はありません。コントリビューター行動規範は、盤石な行動規範とコントリビューター 向けガイドラインを示す文書で、Kubernetes、Rails、Swiftなどの40,000を超えるオープンソース プロジェクトで使用されています。同様に、The TODO Group、Linux Foundation、synopsysなどの組織も、インバウンド コントリビューションのガイドラインの策定に関する豊富な経験を持っています。

適切なインバウンド コントリビューション戦略には、注意深く文書化した API も含まれます、最良の方法として。OpenAPIは、RESTful API記述の業界標準になりつつあります。

「オープンソース コミュニティを構築する際に最も重要なことの1つは、自身のプロセスがオープンであることを明らかにすることです。自身の意思決定プロセスに、より透明性を持たせることで、コミュニティの当事者意識が高くなります。また、自身のプロセスが障壁にならないようにする必要があります。プロセスが面倒なものであれば、そのプロセスは避けられるか、コントリビュートが困難だと簡単に判断されてしまいます。自身のオープンソース プロセスがインバウンドでもアウトバウンド コントリビューションでも面倒なものであれば、そのプロセスは避けられるか、コントリビュートが困難だと単純に判断されてしまいます。」－ Dropbox ソフトウェア エンジニア、Luke Faraone

オープンソース プログラムから得られる恩恵を正確に知ることができる魔法の杖のような方法はありませんが、それに近づくためガイドラインがあります。そのためには、ROIと戦略との関連性を考慮しなければなりません。重要なことは、オープンソース戦略から得られる投資収益率をさまざまな角度から考慮することです。

まず、最初に、オープンソースから得られる利益とその管理に必要なリスクやコストを比較検討する必要があります。NovicaとOpenLogicが無償で提供している共同ホワイトペーパー（PDF）には、オープンソースのROIを計算し、戦略を立てるためのさまざまな方法が具体的に説明されています。たとえば、下図はホワイトペーパで示されているものですが、プロジェクトの開発期間は、ライセンス費用からIT/サービス費用に至るまで ROI 計算のさまざまな要素に重大な影響を与えます。

図1は、プロジェクト期間が、プロジェクトのコスト要素それぞれに与える影響を示しています。プロジェクト初年度のライセンス料のパーセンテージはプロジェクトでの IT/サービス費の割合よりも低くなります、一方、繰り返し起こるメンテナンス費用（通常は初期ライセンス料の20％）のため、最終的にプロジェクト費用全体の大きな割合を占めるようになります。従って、オープンソース プロジェクトの ROI の計算を行う際には、現実的なプロジェクトの活動期間を予測することが不可欠で、それによってより有効な ROI の評価が可能になります。一般的にプロジェクトのROI計画を行う場合には、3年、5年、10年のプロジェクト期間に基づいてROIの計算をした表を作成します。このように、広範な ROI 情報を活用し、決定プロセスを補助することで、プロジェクト計画を進めて行きます。－ 出典：オープンソースの投資収益率、オープンソース ソフトウェアの資金的裏付けの建て方（NavicaおよびOpenLogic）

今後、ROIを計算する時には、以下のガイドラインに留意してください。

• コスト削減による利益の計算。オープンソース戦略の利益を評価する上で重要な指標は、もちろんコスト削減を計算することです。ライセンス料、ハードウェア、サポート費などの節約を考慮に入れ、オープンソースの導入効果と発明効果の両方のコスト削減を評価してください。多くの組織にとってはサポートが重要なコストセンターであり、サポートに対するコストを削減できれば大きな利益が得られます。同様に、たとえば Linux から OpenStack の範囲で既存プラットフォームをオープンソース プラットフォームに移行することで削減可能な特定のハードウェアやライセンス費はあるでしょうか？たとえば、オープンクラウド プラットフォームの場合、クラウド内のストレージとコンピューティング リソースの活用によって、社内リソースの要求を大幅に削減できます。留意事項として、「無償」のオープンソース ソフトウェアを利用する場合、プロプライエタリ ソフトウェアのようなライセンス料はかかりませんが、アップストリームへのコントリビューションや他のサービスとの統合などに伴う開発コストなどがかかることに留意してください。
• OSS活動の成果と転換による利益の計算。オープンソース プロジェクトでの自社の活動成果を追跡することで有益な情報を収集することができます。また、更にその成果の自社の製品やサービスへの転換を測定できる場合もあります。npmやRubyGems.orgなどのパッケージマネージャはオープンソース プロジェクトの配布に使われますが、同時にこれによってダウンロード数を追跡することができます。多くの企業が GitHub に自社のプロジェクトを展開していますが、「トラフィック」ページではプロジェクトが何回クローンされたか、などの詳細を知ることができます。これらの測定指標は、自社プロジェクトのブランド認知やコントリビュータを増やすための好感度向上などに役立ちます。
• 運用リスク調査の実施。オープンWebアプリケーション セキュリティ プロジェクト(OWASP)は、最近のTop10リスクのリストに「既知の脆弱性を持つコンポーネントの使用」を追加しました。そして、オープンソース ソフトウェアにも脆弱性情報を公開するケースが増えています。オープンソース ソフトウェアのセキュリティ監査により、コンポーネントやコード内の脆弱性を可視化できます。Black Duck Auditsにはこのような機能があり、またWiresharkや Niktoなどのツールは、脆弱性や問題を特定することができます。
• 法的リスクの回避。運用リスクと法的リスクは異なるものですが、しかし、その両方を評価することが重要です。オープンソースに関する法的リスクには、間違ったライセンスの使用による法的措置に関する費用、ライセンスの異なるプロジェクト間でコードをマージする費用などが含まれます。

オープンソースの定義は、どのようにオープンソース プロジェクトが配布されるべきなのか、そしてどのようなものが実際にはオープンソースと認められるのかを理解するために良い場所です。オープンスタンダードの要件の参照もお勧めします。また、どのような種類のライセンスを自身のプロジェクトが採用するか評価もしなければなりません。Software Freedom Law Center(SFLC)は、オープンソース ライセンスと著作権の機能などに関するオンライン リソースを提供しています。また、Choosealicense.comには、ライセンスの機能性が分かる簡易マトリックスがあります。

また、ライセンス コンプライアンスのコストと利益も考慮する必要があります。Linux Foundationのオープン コンプライアンス プログラムは、出版物、トレーニング教材、開発者向けの無料トレーニング コースなどのリソースを提供しています（コンプライアンス プログラムの基本概要を説明するガイド「オープンソース コードの使用」もご覧ください）。

法的問題は、もちろん、企業の法務担当者によって評価されるべきです。SFLCの弁護士達は、同時に代表的なオープンソース ライセンスの著者でもあります。また、 International Free and Open Source Software Law Reviewの最新版およびアーカイブにある記事をフォローすることもお勧めします。

オープンソースへの投資には、社内リソースや外部リソースを活用するなど、さまざまな角度のアプローチ方法があります。オープンソース化やアップストリームへのコントリビューションに対して開発者 リソースを配分することも、オープンソースへの投資の一部であることを留意してください。流入・流出するコードとプロジェクトがどこからやってきて、どのように再配布されているかを理解することが重要です。

内部監査を実施してください。買収によってオープンソースのツールとプラットフォームを取得しましたか？そこから最大の利益を得ていますか？それを監査によって調査してください。

自社の製品やサービスの提供に不可欠なオープンソース プロジェクトを特定してください。企業がまず自社のIPポートフォリオと自社の開発者が実施したいオープンソースにコントリビューションを理解すれば、開発者は自信を持ってそれらのコントリビューションを実施できるようになり、全体がうまく働くようになります。

オープンソース化できる内部プロジェクトがどれかを特定してください。社内に既に存在するもの、または自社にとって必要なオープンソース プロジェクトを特定する方法を作り出すこともできます。たとえば、シリコンバレーの多くの企業では、社内でのコンペティションやハッカソンなどのイベントを開催し、素晴らしいオープンソースを発明した従業員に優秀賞を与えています。このようにして、PayPalやGoogleなどの企業は、従業員の発明によるオープンソースを自社の構成素材や製品ポートフォリオに取り込んでいます。「ハッカソンを通して得られる素晴らしいものの一つに再結合組み換えがあります。発明者はこう言います。『ひとつのやり方がここにあって、そのプロセスに役立つもうひとつのプロジェクトがここにある。そして私はそれらをひとつに結合することができるのです。』もし、すべてがクローズソースである場合、問題は利用できるビルディングブロックの数がより少ないことです。反面、世界はオープンソースによって思いのままにできるのです。多くの利用可能なビルディングブロックが目の前にあるのです。」－ Salesforce ソフトウェア アーキテクト、Ian Varley

次は外部リソースの番です。まだ参加していないもしくは使っていないオープンソース プロジェクトで、ビジネスの利益を生むかもしれないものを特定する外部リソースがあります。早期から適切なオープンソース プロジェクトとコミュニティを選択することは、非常に大きな効果があります。 戦略的に重要なプロジェクトを選択することが重要です。他の組織と連携しましょう。そうすることで、本当に参加するべきプロジェクトを選択し、同時に利益を生み出すプロジェクトを特定するのに役立ちます。そのような活動を支援している独立団体がいくつもあります。Linux Foundation、TODO Group、Innersource Commons、Open Source Initiativeなどは、すべてガイダンスを提供しています。同業界の他の組織がコントリビュートしているプロジェクトを調べてみましょう。それにより、参加するべき適切なプロジェクトがわかるかもしれません。たとえば、多くの電気通信会社は、歴史的に用いられてきた電気通信技術スタックからプロプライエタリ コンポーネントを排除し、オープンな Network Functions Virtualization(NFV)技術を利用することにより大きな利益を得ています。これらの企業の中には、Linux Foundationとともに NFV を主導するように活動しています。そして、他にもNFVに特化したワーキンググループがいくつもあります。業界に特化したこれらのワーキング グループは、貴重なガイダンスを提供しています。

戦略の策定に役立つよいリソースがほかにもありますので、いくつかご紹介しましょう。

Measuring Open Source ROI
Open Source Return on Investment

Launching Successful Open Source Projects
The Linux Foundation on Starting Successful Projects

Legal Resources
International Free and Open Source Software Law Review
Open Compliance program

Licensing
Choosealicense.com

Contributor Code of Conduct
The Contributor Covenant

Open Source Policy
TODO Group Templates

Open Source Strategy Blog
Changelog

Open Source Strategy Podcast
Request for Commits

これらのリソースは、TODO (Talk Openly, Develop Openly) グループとの協力により作成されました。TODOグループは、The Linux Foundation傘下のプロフェッショナル オープンソース プログラム ネットワーキング グループです。 このような包括的なガイドを作成するために時間を割き、豊富な知識を提供してくれたオープンソース プログラム マネージャーのみなさんに感謝します。TODOグループの参加企業は、Autodesk、Comcast、Dropbox、Facebook、Google、Intel、Microsoft、Netflix、Oath (Yahoo + AOL)、Red Hat、Salesforce、Samsung、およびVMwareです。
詳細については、todogroup.orgを参照してください。

この資料は、Creative Commons Attribution ShareAlike 4.0 International License (CC BY-SA 4.0：クリエイティブ・コモンズ 表示 – 継承 4.0 国際ライセンス) の下でライセンスされています。