オープンソース コミュニティへの参加

オープンソースは、技術系産業だけではなく、広く業界にまたがって、ソフトウェアを作成、構築するための事実上の標準方法となっています。また、企業が商用の製品とサービスを提供するためにオープンソース コードを活用することが広がり、企業はオープンソース プロジェクトにコントリビューションすることに戦略的価値を見出すようになってきました。

しかし、オープンソース プロジェクト、コミュニティ、そしてそれらがどのように運営されているかを理解もせずに参加すると、オープンソース コミュニティだけでなく、参加した企業も失望することになるでしょう。戦略なしでオープンソースへのコントリビューションを試みると、オープンソース コミュニティにおいてその企業の評判が損なわれ、法的リスクが発生することもあります。

このガイドでは、組織としてオープンソースにコントリビューションすることはどのような意味をもつのか、どのようにすれば良き企業市民になることができるかについての指針を提示します。すなわち、どのようにオープンソース プロジェクトが構成されているのか、コントリビューションはどのように行うのか、社内開発リソースを投入することがなぜ重要か、そして、オープンソースに参加し、管理するための戦略の策定がなぜ重要なのかについて学びます。

内容

1. なぜオープンソースにコントリビューションするのか
2. どのようにしてオープンソース プロジェクトは管理されているのか
3. コントリビューションの仕組み
4. どのように組織がコントリビューションするのか
5. 良き企業市民になるために
6. どのようにしてコントリビューション戦略を構築するか
7. 結論
   

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

今日、オープンソース ソフトウェアからどのような利益も得ない組織を見つけるのは不可能でしょう。Intel社、IBM社、Samsung社のように、いくつかの企業は、オープンソース コミュニティにコントリビューションするために、一貫したオープンソース プログラムを持っています。他の企業では、たまたまオープンソース ソフトウェアがシステム管理者や開発者によって導入され、それを契機としてオープンソースのユーザーになっています。

多くの企業のビジネスがオープンソース ソフトウェアに依存していて、オープンソースは企業の成功のために非常に重要なものになっています。そのために、オープンソース ソフトウェア プロジェクトにコントリビューションすることは、必要かつ有益なものになっています。2005年以来、1,300社以上の13,500人を超える開発者がLinuxカーネルにコントリビューションしていますが、なんとそれは単一のプロジェクトなのです。

これらのコントリビューションの一部は、単にコミュニティにお返しをしたいと考える組織から来ているのかもしれません。しかし、組織で使用されているオープンソース ソフトウェア プロジェクトにコントリビューションする強固なビジネス上の理由はたくさんあります。コントリビューションのメリットの一部を以下に紹介します。

• 優秀な人材を引き付ける。オープンソース ソフトウェアに依存している組織が、プロジェクトを知り尽くしている人材を見つけ出すための最良の場所は、そのプロジェクトのコミュニティです。コミュニティで公に仕事をすることにより、自分が好きなオープンソース プロジェクトで働いて報酬を得ることができるということを知った人々を引き付けることができます。あなたの従業員が毎日、彼らと一緒に仕事をする中で、彼らはあなたの会社に合った人材を見つける手助けができます（採用担当者向けのガイド、「オープンソース開発者の採用」を参照）。
• メンテナンス コストを削減する。自身がオープンソース プロジェクトに対して行ったバグ修正や機能追加をアップストリーム プロジェクトに速やかにフィードバックしてこなかった企業は、後にアップグレードする際、アップストリームの新機能を追加したり、セキュリティ フィックスを適用したりすることが非常に高いメンテナンス コストを必要とし、それは悪夢のような作業になることに気づくでしょう。変更をアップストリーム プロジェクトにコントリビューションして戻すことにより、追加のメンテナンス コストを必要とせずに、変更が自動的に将来のアップデートに含まれることになります。
• プロジェクトの方向性に影響を与える。オープンソース プロジェクトでは、新しい機能追加はコントリビューションの形で行われ、これらのコントリビューションがプロジェクトの方向性に影響を与えます。組織にとって重要な機能をプロジェクトに追加したい場合は、それを実現するための変更をコード実装できる活動的なコントリビューターが必要になります。あなたの変更がプロジェクトの目標と一致している限り、あなたはコントリビューションを通して、プロジェクトの方向性にある程度影響を与えることができます。

しかし、あなたのコントリビューションに対する誤解やその他の問題を避けるために、コミュニティにどのように関わるかについては慎重に考えてください。すべてのオープンソース プロジェクトには、少しずつ異なった行動規範、期待される振る舞い、プロセスがあり、あなたの組織がコントリビューションを始める前にそれらを完全に理解する必要があります。これは、誰かがコミュニティに参加し、暫くの間コミュニティを観察することで達成できます。または、すでにコミュニティに参加した実績のある人を雇うこともできます。

一見すると、オープンソース プロジェクトは無秩序に見えるかもしれません。オープンソース ソフトウェアに初めて接する人は、「雑然とした人々」で構成されるグループがともにコードを投稿して、それがどのようにして結果的に何百万人もの人々が使用する安定した製品になるのか、とても不思議に思うでしょう。そのような見方がオープンソース ソフトウェアの開発方法ではないことに気づくのに多くの時間は必要としないでしょう。ほぼすべてのオープンソース プロジェクトは「体制」が整っており、優れたプロジェクトはその「体制とプロジェクト ガバナンス」をプロジェクトのWebサイトやドキュメンテーションで明確に記述しています。（コントリビューターのためのGitHubのガイド、overview of project anatomyは優れたプロジェクトの組織概要を提供してくれています。）

ガバナンス モデルはプロジェクトによって異なりますが、いくつかの共通点があります。

• リーダー：少なくとも、機能、リリース、その他のアクティビティについて、最終決定を下す責任者がいなければなりません。いくつかのケースでは、これは1人の人物です。例えば、Linus Torvaldsは、Linuxカーネルの原作者であり、それに関連するものについて最終決定権をもっています。Node.jsプロジェクトを統括するコア技術委員会（Core Technical Committee）のように、プロジェクトのさまざまな側面を担当する複数の委員会を設置しているプロジェクトもあります。
• メンテナー：ほとんどのリーダーは、プロジェクトの特定の部分を保守する責任を持つ人々に一部の決定事項を委譲します。大きなプロジェクトでは、これらのメンテナーが、さらに、その中のサブ コンポーネントに対する保守責任を他の人に委譲する場合もあります。例えば、Linus Torvaldsは、Linuxカーネル ドキュメントに関連する決定をJonathan Corbetに委譲しています。
• コミッター：一部のプロジェクトでは、プロジェクトにコントリビューションしてきた、信頼でき、責任感のある人々のグループがあり、サブミットに対するメンテナーのレビューなしに、プロジェクト全体、または一部に直接コミットできるようにしています。コミッターからのコントリビューションは、メンテナーやプロジェクト リーダーのレビューの対象となり、コントリビューションに懸念があれば元に戻されます。
• コントリビューター：多くの人々が、コード、ドキュメント、およびその他のコントリビューションでオープンソース プロジェクトに貢献しています。これらのコントリビューションは、コントリビューションが採用される前に、経験豊富なコミッターやメンテナーからレビューを受けます。
• ユーザー：オープンソース プロジェクトの最も重要なグループは実際に製品を使用しているユーザーだと思います。ユーザーはプロジェクトに目的を与え、成長を助けてくれます。これらのコミュニティの貴重なメンバーは、機能、バグレポートなどについてのフィードバックを提供してくれているでしょう。

コミュニティは、オープンソース プロジェクトを作ることも壊すこともでき、強力で活気に満ちて、多様な人たちで構成されたオープンソース コミュニティを持つことは、プロジェクトの成功にとって重要です。上に挙げた役割を果たしている人々は、ドキュメンテーション、マーケティング、ユーザー サポートなど、プロジェクトの他の重要な役割を果たしている人たちとともにコミュニティを構成しています。

コントリビューションのプロセスは、各オープンソース プロジェクトによって異なります。例えば：

• プロジェクトには、コーディング スタイル、開発言語、書式、バグ・チケット番号、リリース タイミングなどに関する異なったガイドラインがあります。
• サインが必要なコントリビューター契約が必要なプロジェクトもあれば、GitHubのsigned-off-byなど他の方法を採用しているプロジェクトもあります。
• あるプロジェクトでは、メーリングリストにパッチを投稿する必要がありますが、他のプロジェクトではプルリクエストにすることを求めることもあります。

これらは、コントリビューション スタイルの違いが存在するほんの少しの事例ですので、コントリビューション方法についてのドキュメントを読むことから始めましょう。多くのプロジェクトでは、このドキュメントがCONTRIBUTINGまたはREADMEファイルとしてコード リポジトリのホーム ディレクトリに含まれますが、そうでない場合は、ドキュメントを見つけるためにWebサイトのドキュメントまたはコミュニティのセクションを探さなければなりません。特定のプロジェクトでどのような行動が期待されているかを正確に理解するためには、その他のドキュメント、コミュニティ ガイドライン、行動規範をお読みください。

プロジェクトに初めてコントリビューションする時には、最初の数件のコントリビューションについては、それをレビューし、フィードバックを与えてくれるメンターや経験豊富なプロジェクト メンバーを見つけることを考えるべきでしょう。

ドキュメントに記載されているプロセスに沿って、コントリビューションをサブミットした後、それに対するフィードバックに返信する必要があります。一般的なフィードバックには、どのようそれが機能するのか、特定のアプローチを選択した理由などの質問や、改善の提案、変更要求などが含まれます。このフィードバックは時として厳しいものです。フィードバックはあなたのコントリビューションをより良いものしてくれるものという考え方で対応しましょう。自己防衛的な対応は避けるべきです。あなたのコードが承認される前に、数回の再提出や追加のフィードバックへの対応を行う必要があるかもしれませんし、場合によっては却下されることもあります。何かが受け入れられない理由はいろいろあります。あなたのコードが拒否された場合、それを個人への攻撃ととらえないようにしてください。できることなら、あなたのコントリビューションが受け入れられなかった理由についてもっと学びましょう。それはあなたの次回のコントリビューションが受け入れられる可能性を高めるのに役立ちます。

あなたのコントリビューションが受け入れられれば、あなたがそれを長期にわたって保守することを期待されるだろうということに留意してください。特に、大きなコントリビューション、新機能、またはハードウェアの特定のドライバーのような独立性の高いコードの場合は、これが当てはまります。小規模なコントリビューションやバグ修正に対しては、長期的な保守を期待されることはないでしょう。

いくつかのオープンソース プロジェクトと、それらのプロジェクトを使用したり、プロジェクトにコントリビューションしたりしている企業、組織との間の関係で、長年にわたり問題を抱えているものがあります。多くの組織は、通常、オープンソース プロジェクトでは機能しない手法を用いてビジネス関係を形成することに慣れてしまっているために、いくつかの組織では、生産性の高いコントリビューション方法を理解するのに苦労しています。もう1つの課題は、組織のニーズがオープンソース プロジェクトのニーズに合致していない場合で、コミュニティから見て、組織が利己的で、やっかいな存在にみえる場合です。そのような時、オープンソース コミュニティが組織のコントリビューションの背後にある動機を疑う可能性があります。過去に、プロジェクトの目標に沿っていない大規模なコントリビューションをしようとした組織がいくつもありましたが、ある特定のプロジェクトでは、この歴史のためにコミュニティが組織を信頼することを難しくしています。

しかし、Linuxカーネルのように、組織が意味のある形でコントリビューションした成功事例も数多くあります。組織がオープンソース プロジェクトにコントリビューションするための最も一般的で、最も簡単な方法は、多くの時間をさいてオープンソース プロジェクトに参加している従業員に（正規の企業活動として）十分な処遇を与えることです。これを上手く進めるためには、従業員がそのプロジェクトのコントリビューションに関するプロセスと規範を理解し、そのコントリビューションがプロジェクトに受け入れられる機会を増やす必要があります。あなたの組織がプロジェクトに新規に参入したり、オープンソースに初めて参入したりする場合は、コントリビューションしたいオープンソース プロジェクト内で、すでにコントリビューションしている人や、そのプロジェクト内で良く知られた人を採用することを検討してください。そうすることで、彼らはそのプロジェクトでより成功する可能性の高いコントリビューション方法について、組織を指導することができます。経験豊かなコントリビューターは、あなたの従業員がオープンソースでキャリアパスを追求するのを助けるメンターの役割もしてくれるでしょう（「オープンソース開発者の採用」を参照）。

ほとんどのプロジェクトには、組織が参加するためのその他の方法（コードのコントリビューション以外の方法）がありますが、その方法はプロジェクトごとに異なっているでしょう。多くの場合、オープンソース プロジェクトとそれらをサポートするファウンデーションは、インフラ、運営資金、マーケティング、法務サービスなど、組織が提供することのできるリソースを必要としています。多くのプロジェクトでは、プロジェクトに助言できる資格（advisory role）の獲得や企業のビジビリティ向上と引き換えにオープンソース プロジェクトに資金や人的資源の形でのコントリビューションをすることによって、企業がよりフォーマルな形でプロジェクトのスポンサーになったり、参加したりすることができます。

たとえば、Node.js Foundation理事会の理事（Node.js Foundation Board of Directors）は、企業会員からの代表者、技術運営委員会の代表者、個人会員クラスで選出された代表者で構成されています。理事会の理事を構成することができる企業のメンバーは、5,000ドル（小規模組織の場合）から250,000ドルを支払います。スポンサーシップやメンバーシップに対するアプローチは、プロジェクトごとに多少異なりますが、オープンソース プロジェクトへの資金提供はプロジェクトの経費を支え、プロジェクトの成功に役立ちます。

多様な組織がCloud Native Computing FoundationのKubernetesプロジェクトにコントリビューションしています。

このガイドおよび一般的なオープンソースで基層をなすテーマがあるとすれば、すべてのプロジェクトは異なっているということです。したがって、あなたがあるオープンソース プロジェクトに参加するたびに、プロジェクトがどのように機能するかを学び、それにあなた自身を適応させていくための時間が必要になるでしょう。

オープンソース プロジェクトに参加する組織は、各従業員が参加するプロジェクトごとに学習プロセスを進める必要があります。コミュニティと良い関係でスタートするためのいくつかの施策を以下に示します。

• まずコミュニティに参加する。各コミュニティでは、参加方法やコミュニケーション チャンネルが若干異なります。ドキュメントを読んでコミュニティについて学び、主要なコミュニケーション チャンネルに参加してください。これらのコミュニケーション チャンネルには、メーリングリスト、フォーラム、インターネット リレー チャット（IRC）、Slack、バグ トラッカー、ソースコード リポジトリなどが含まれます。
• 最初はリードオンリー ユーザーで。コミュニティに参加した後、コントリビューションを開始する前に、まずアーカイブのリードオンリー ユーザーになり、コミュニティ文化を吸収するために相当な時間を費やして、静かにそれを読んでください。あなたが参加する前に、このコミュニティの行動規範や期待される振る舞いを理解しましょう。読んだり、聞いたりするのに費やす時間が多くなればなるほど、最初のコントリビューションが受け入れられる可能性がより高くなります。
• ガバナンスを理解する。コントリビューションを開始する前に、プロジェクト ガバナンスとリーダーシップに関するドキュメンテーション、またはWebサイトの関連セクションを読んでください。プロジェクト内で、どのように意思決定が行われ、さまざまなコントリビューションに対して、誰が意思決定しているのかについて理解してください。
• 小さく始める。簡単なバグやドキュメントの修正から始めてください。あなたの組織のニーズにとって必須とはいえないような重要でない小規模なコントリビューションによってミスを修正したり、プロセスを学んだりするほうが簡単です。組織が必要とする複雑なコントリビューションに取り組むために、小さくて、あまり重要でないコントリビューションでミスを犯してください。

あなたの組織は、最初の小さなコントリビューションでその方法を理解すると、さらに大きなコントリビューションを行い、プロジェクトにより大きな影響を与えるコントリビューションができるようになります。

• イベントで良い関係を構築する。個人レベル、組織レベルで構築される人間関係は、オープンソース コミュニティに参加する上で重要な側面を持っています。他のプロジェクト メンバーとの継続的な人間関係を構築する最善の方法の1つは、イベントに出席することです。メール アドレスやオンラインのハンドル名の向こう側に存在している人間として彼らを理解するための方法としては、直接会うことがやはり一番です。これらのイベントには、プロジェクト リーダーや情熱的な製品ユーザーから、組織のコントリビューションを示すスポンサーシップ、ブース、デモなどで参加する多くの組織の人まで、多様な構成の人々が集まっています。これらのイベントのほとんどは、プロジェクトの目標を達成するのを助けながら、ともに集まり、互いに学ぶことを可能にしてくれますが、それらはスポンサー組織からの財政的支援なしには成り立ちません。
• 早めに、高頻度でコミュニティを巻き込む。一部の組織では、大量のコードを社内で開発してから、オープンソース プロジェクトに投入するという間違いを犯しています。このやり方は、コミュニティに参加するための良い方法ではありません。実際、オープンソース プロジェクトは複雑なもので、明快な変更のように見える修正でも、プロジェクトの他の部分で大きな副作用を引き起こすことがあります。重要な変更は、副作用がないこと、そしてソリューションがプロジェクトの幅広い目標に沿っていることを確認するために、実装する前にコミュニティで議論する必要があるでしょう。コードの作成に時間をかけすぎる前に、その問題をコミュニティと議論することにより、特定のソリューションではなく、本来の問題に焦点を当てて議論することができます（Linuxカーネル コミュニティへの参加方法に関するJonathan Corbetのガイド: How to Participate in the Linux Kernel Communityを参照）。
• アップストリームにコントリビューションする。これは、オープンソース プロジェクトに加えた修正変更をプロジェクトのメンテナーに送り、今後のソフトウェア リリースにその修正変更を含めるようにすることを意味しています。あなたの組織がオープンソースにまだ不慣れな場合は、アップストリームへのコントリビューションの重要性を従業員に教えるために、しばらく時間を費やす必要があります。場合によっては、あなたのインフラで使用しているソフトウェアを動作させるために、「素早くて、きたないパッチ」を作成する方が簡単で、アップストリームのプロジェクトに受け入れられるようなプロセスを通して、パッチをきれいにする手間を省きたいと考える人もいるかもしれません。

けれども、長期的には、アップグレード サイクルごとにテスト、更新、再適用が必要な「素早くて、きたないパッチ」の保守は、ほとんどの場合、アップストリームで保守されるパッチより時間も労力も必要とします。他の人もあなたの修正から恩恵を受ける可能性があることを考慮すると、このような行動はコミュニティ内で、利己的であると認識され、組織のオープンソース コミュニティでの評判にも悪影響を与えることがあります。

組織にとって最も重要な課題の1つは、オープンソース プロジェクトに影響力を与える方法を理解することです。重要な組織であっても、オープンソース コミュニティから尊敬されていなければ、重要な組織として扱われることを期待するべきではありません。影響力はプロジェクトへの参加から始まります。そして、オープンソース プロジェクトにコントリビューションする人の中で、信頼され、責任感が認められた一部の人が最終的に大きな影響力とリーダーシップを発揮する立場になります。

また、対立が起こることもあるでしょうが、それをプロフェッショナルに処理できる必要があります。決定、アプローチ、またはコントリビューション スタイルで同意が得られず、レビュー プロセスがかなり白熱したものになることもあります。フィードバックが個人攻撃的なものになるのではなく、コントリビューションに焦点を当てて、冷静でプロフェッショナルに対応することが重要です。オープンソース プロジェクトに参加する行為はすべてが公になっており、それがインターネット上に永遠に残っている可能性があることを忘れないでください。抑制の効かなくなった白熱した議論は、一組織や一個人が行った行為として後々あなたについて回ることもあります。参加行為がすべて公になることを考慮して、「扱いづらい人に対する対応方法」や「対立の解決方法」に関するトレーニングを従業員に提供するのも良案でしょう。

慎重に検討されたオープンソース コントリビューション戦略を持つことは、オープンソース プロジェクトに参加する際の従業員指導に役立つだけでなく、組織内の上級管理職に参加の正当性を示すのにも役立ちます。まず、組織の全体的なビジネス目標を見て、オープンソースの取り組みが組織の幅広い戦略にどのように適合しているかを把握することが重要です（Setting an Open Source Business Strategyを参照）。オープンソース コントリビューション戦略を組織の戦略的な取り組みと明確に結びつけることで、上級管理職に、なぜコントリビューションがその組織にとって重要なのかを示し、従業員がコントリビューションの与える影響力を理解できるようになります。

ビジネス目標に沿った目標や戦略を立てたら、その実施計画を立てる必要があります。以下の質問は、あなたの計画に取り入れるべきいくつかの項目を示唆するでしょう。

• なぜ、これらのコントリビューションが重要なのですか。あなたが計画しているすべての素晴らしい事柄について話を始めることは難しくはありませんが、なぜこの仕事が組織にとって重要で、戦略的なのかについて説得力のある議論をすることを忘れないでください。
• どのオープンソース プロジェクトを組織内で使用していますか。どのオープンソース プロジェクトがビジネスにとって戦略的であるかを判断するために、組織全体で使用されているオープンソース プロジェクトを、ある程度時間をかけて評価してください。重要なビジネス インフラ（運用）、製品のリリースに強い影響を与える開発ツールや配布ツール、顧客に直接関係する製品やサービスに重要なソフトウェアなど、焦点を当てて評価しなければならないところがいくつかあるでしょう。
• どのプロジェクトにコントリビューションすべきでしょうか。ほとんどの組織は数多くのオープンソース プロジェクトを活用しているので、あなたの計画が最も重要なものに焦点を当てていることを確認する必要があります。あるプロジェクトがターゲット リストに載っていないからといって、人々がそのプロジェクトにコントリビューションできないというわけではありません。そのプロジェクトはあなたの組織にとって重要なプロジェクトではないというだけです。企業のビジネスにとって不可欠で、深刻なダウンタイムや顧客へのサービス提供の妨げをもたらす可能性があるオープンソース プロジェクトは、コントリビューションの候補として適しているでしょう。
• どのようなコントリビューションをすでに実施していますか。場合によっては、すでにオープンソース プロジェクトの修正・変更をしている社員がいるかもしれません。内部で使用されるパッチを作成している場合や、パッチの保守を避けるためにアップストリーム プロジェクトにそれらを戻してコントリビューションしている場合があります。社内のチームと話をする時間をとり、コントリビューションできるスキルや興味を持っているスタッフがすでにいるかどうかを評価しながら、あなたが将来できそうなコントリビューションを見つけてください。
• 私たちはすでに関連する専門知識を持っていますか、あるいは、それを得るために人を雇う必要がありますか。このガイドですでに説明したように、コントリビューションが受け入れられるには、コントリビューションを作成するスキルと、コミュニティと協調する対人関係スキルの両方を持つ人を見つけることが重要です。すでに、プロジェクトにコントリビューションしている人があなたの企業にいる場合、そのスタッフを活用することができます。そうでない場合は、すでにそのプロジェクトにコントリビューションすることで地位を得ている人を雇うことを検討すべきです。どんな計画でも、成功のためにはそれに必要なリソースと採用予算を確保しておく必要があります。
• プロジェクト スポンサーや企業会員になるためにはどのような資金が必要になりますか。あなたが選んだプロジェクトのガバナンス モデルをチェックして、そのプロジェクト、またはそのプロジェクトに責任を持っているファウンデーションの企業会員やスポンサーになることができるかを確認します。これはプロジェクトが成功するための資金を提供し、場合によっては、組織がプロジェクトに助言を与えたり、影響力を与えたりするために役立ちます。ほとんどのオープンソース プロジェクトはカンファレンスを実施します。プロジェクトに対する直接的な資金提供に加えて、プロジェクトのカンファレンスのスポンサーになること考慮してください。カンファレンスはあなたの仕事について情報発信できる素晴らしい機会であり、あなたが採用したい人に出会える場所でもあります。
• オープンソースに対する取り組みをどのようにプロモーションすべきでしょうか。組織によっては、オープンソースへのコントリビューションをマーケティングやプロモーションすることが難しい場合があります。したがって、あなたのコントリビューションについて、どのように公に説明するつもりなのかを組織のすべての人が知ることができるようにすることを実施計画の中に含めることが重要です。プロジェクトのカンファレンスなどのイベントでスポンサーになったり、講演したりすることは、あなたの仕事のプロモーションや、コントリビューターの採用のための良い方法です。特に、従業員がいる地域のユーザー グループへの参加を見逃さないでください。地域のグループのスポンサーになり、コントリビューターを派遣して講演することは、特定のオープンソース プロジェクトに情熱を持っているその地域の人を採用するのに非常に良い方法です。
• どのようなコントリビューション ガイドラインやプロセスが必要でしょうか。これらのガイドラインとプロセスでは、ルールや規制に関連する部分はなるべく減らして、オープンソース プロジェクトへのコントリビューションを成功させるために役立つ部分をより多くすべきです。ガイドラインとチェックリストが、ライセンスや秘密保持の問題に深入りせずに、コントリビューションを成功させるために必要なものをすべて含んでいれば、非常に有益なものになります。特に、新しいコントリビューターにとっては、コミュニティへのコントリビューションを行う前にフィードバックを受け取る安全な場所として、内部レビュー プロセスを利用できれば非常に助かります。
• どのようなトレーニングを提供すれよいのでしょうか。オープンソース コミュニティへの参加に関連したライセンス、ガバナンス、および行動規範に関する一般的なオープンソース トレーニングに加えて、コントリビューションするためのベスト プラクティスのトレーニングも有用でしょう。対立の解消方法、扱いの難しい人への対処方法、対人関係に関するスキルなどのトレーニングは、後々問題を回避するのに役立つでしょう。また、経験豊富なオープンソース コントリビューターが新しいコントリビューターのメンターとして指導するプログラムをトレーニング プランに含めれば、時の経過とともに成果が高まります。
• 計画が成功したかどうかはどのように判断するのでしょうか。すべての計画には達成基準と目標を達成したかどうかを評価するステップが含まれていなければなりません。これは、あなたの戦略から直接導かれたもので、組織にとって最も重要な活動を確実にトラッキングするものであり、最も簡単に測定できるものをトラッキングするものではありません。オープンソースのGrimoireLab プロジェクトは、測定ツールやメトリクス ツールが必要な場合に最初に訪問すべきサイトです（本ガイド集の1つ、「オープンソース プログラムの成功度を測る」を参照）。
• これらすべての取り組みを管理するためにオープンソース オフィスが必要でしょうか。すべての取り組みは、考えなければならないことがたくさんあるものです。オープンソース プログラム オフィス、または計画の実行を担当する専任のスタッフを持つことは助けになります。少なくとも、プロセスとトレーニングを整備・導入し、ライセンス ガイダンスを提供し、上級管理者やコントリビューターからの質問に応え、組織全体に最新状況を報告することなどに責任を持つ人が必要でしょう（「オープンソース プログラムの作成」を参照）。

オープンソース プロジェクトは社会に浸透しており、ほとんどの組織で製品やサービスを顧客に提供するために使用され、重要な役割をはたしています。組織として、ビジネスの成功を促進させるオープンソース プロジェクトに影響を与えたいと考えるなら、オープンソース プロジェクトに参加する必要があります。組織の確固としたコントリビューション戦略と実施計画を持つことが、良きオープンソース企業市民になる道につながります。がんばりましょう。

これらのリソースは、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 国際ライセンス) の下でライセンスされています。