オープンソース プログラムを確立する方法
ここでは、オープンソース プログラムを確立する際の主な考慮事項について説明します。
"オープンソース" の意味とは?
オープンソース プログラムは、コードベースへのパブリック アクセスを超えたものです。 参加したい人が誰でも参加できるように、生きているプロジェクトを公開することです。 適切なプロジェクトに対して適切に実行すると、オープンソース プログラムは製品の品質において大幅な向上を推進できます。
企業がプロジェクトをオープンソースにする主な理由の 1 つは、コミュニティに参加してもらうためです。 人気のあるプロジェクトでは、コミュニティから多大な投稿を受け付け、それを無料で入手できます。
それは必ずしも利他主義からではありません。 人や組織は、個人またはビジネスにとって利益があるという理由から、プロジェクトを "使用" します。 プロジェクトがニーズや期待を満たしていない場合は、その機会を利用してバグに対処する、または機能を追加する可能性があります。 これらの機能強化をプライベート フォークに留めるのではなく、プロジェクトのベースラインの一部になるようにこれらの変更をソース リポジトリに再度 "投稿" するように強制されます。 この機能強化の好循環サイクルが、多くの企業がオープンソース モデルを使用してソフトウェアを "作成" する理由です。
オープンソースの目標
要約すると、オープンソース ソフトウェアへの参加には、次の 3 つのディメンションがあります。
- コンシューマー: 他の人のリポジトリを学習または使用します。
- 共同作成者: 他の人のリポジトリの改善に積極的に関与します。
- プロデューサー: 他の人に対して公開されている独自のリポジトリを構築および管理します。
組織が各ディメンションから何を取得したいのかについてより深く考えるときには、組織が現在どこにいるかを把握することをお勧めします。 各ディメンションには 5 つのプロセス レベルがあります。
- アドホック: プロセスはありません。 成功は個人の努力に依存します。
- マネージド: 部分的に文書化されたプロセスがあります。 成功は規範に依存します。
- 定義済み: 文書化され、標準化され、統合されたプロセスがあります。 成功は自動化に依存します。
- 測定済み: 定量的に管理されたプロセスが含まれます。 成功は、ビジネス目標に対するメトリックの測定に依存します。
- 最適化済み: 段階的および革新的な変更の両方を通じて、継続的かつ確実に改善するプロセスがあります。 成功は、変更のリスクを軽減することに依存します。
自分の組織がどこにいるかについてもっとよく理解するには、オープンソースの自己評価で確認してください。
オープンソースにすべきもの
多くのプロジェクトは、オープンソースが重要な存在になることを予定していません。 その条件は会社の目標とプロセス レベルによって異なる場合がありますが、プロジェクトをオープンソース化する前に検討すべきいくつかの推奨される条件は次のとおりです。
プロジェクトに保護すべき知的財産が含まれているか。 その場合、そのソースをオープンにすると、その価値が消えます。 利点がリスクを上回ると感じられない限り、この種のプロジェクトをオープンソース化しないでください。
プロジェクトは安定した状態で、コードの品質は良好であるか。 プロジェクトは完璧である必要はありませんが、そのプロジェクトが最初からひどい状態である場合、潜在的な共同作成者を逃してしまうおそれがあります。
プロジェクトは社外の人にとって役に立つか。 そうでない場合、おそらく参加者を得ることはできないでしょう。
社外の人が投稿できるか。 この人たちは、プロジェクトのすべての依存関係、ビルド プロセス、およびプロジェクトを実行するために必要なその他のすべてにアクセスすることが必要になります。 実行できなければ、共同作成はできません。
チームには、オープンソース プログラムをサポートするための帯域幅があるか。 ない場合は、そうなるまで待ちましょう。 プロジェクトをオープンソース化して、それをサポートしなければ、信頼できるコミュニティを構築する機会を失うおそれがあります。
これらの質問は、最も一般的な考慮事項のほんの一部に過ぎません。 組織には、他に留意すべきビジネスまたはコンプライアンス上の問題がある場合があります。
オープンソース プログラムの設計
オープンソース プログラムの実行は、InnerSource プログラムの実行に似ていますが、対象ユーザーがパブリックである点が異なります。 そのため、いくつか追加の考慮事項があります。
コミュニティの期待を設定する
README.md や CONTRIBUTING.md などのファイルは、組織のコンテキストを持たない人々に公開されるため、さらに重要です。 それらは、明確にするために、社外の人の視点から評価する必要があります。
さらに、行動規範は、表明する重要なポリシーです。 標準では、リポジトリのルートに CODE_OF_CONDUCT.md ファイルを追加し、それを使用してコミュニティの参加者に期待される行動を説明します。 このドキュメントは、法務チームを含む組織内の複数のグループによってレビューされる必要があります。 幸いなことに、最初から利用できる多くの標準的な行動規範があります。 多くのプロジェクトでは、これらの規範を変更せずにそのまま使用しています。 詳細については、オープンソースの行動規範のガイドを参照してください。
リポジトリを維持するために従業員を準備させる
従業員は、オープンソース コミュニティでの作業経験がない場合があります。 彼らの準備を支援するために、始める前に全員が知っておくべき重要なことを網羅した一連のガイドを会社が提供することをお勧めします。 これらのガイドは、定期的にメンテナンスされ、会社の従業員のみがアクセスできる社内のリポジトリかポータルに投稿する必要があります。 最も重要なガイドをいくつか次に示します。
"このプロジェクトをオープンソース化すべきか" ガイド: 候補プロジェクトをオープンソースにする必要があるかどうかを判断するためのフレームワークを提供します。 このガイドは、フローチャート、一連の質問、または考慮事項のリストとして構成することができます。
設定チェックリスト: オープンソース プロジェクトの開始前と後に、チームが完了する必要があるすべての作業項目が含まれます。 このリストには、プロジェクトをオープンソース化するための承認の取得、プロジェクトが開始する前に機密データが削除されることを確認するためのコード レビュー、名前の競合がないことを確認するための商標またはオープンソース プロジェクトの検索などが含まれます。
連絡先リスト: メンテナンス担当者による直接のサポートが必要な場合に、連絡する必要があるかもしれない組織内の主要な人々向けに。 このリストには、ソフトウェアのセキュリティ、サイトのセキュリティ、法務、広報などの関係者を含める必要があります。
開始点としてクローンできるスターター リポジトリへのリンク。 これには、サンプルの README、ライセンス、行動規範、共同作成ガイド、および会社のすべてのオープンソース プロジェクトに必要なその他のサポート ファイルが含まれている必要があります。 誤ってパブリックの対象ユーザーにプッシュされたくないものは含めないようにしてください。
メンテナンス担当者向けガイド: リポジトリを正常な状態に保つためのメンテナンス担当者の責任について説明します。 これらの責任には、リポジトリのドキュメントを最新の状態に保つこと、イシューと pull request がタイムリーに適切な人々の目に留まるようにすることなどが含まれます。
コミュニケーション ガイド:
README.md、CONTRIBUTING.md、CODE_OF_CONDUCT.mdなどのパブリック ファイルの中に含めたくない一部のトピックについて、リポジトリのメンテナンス担当者へのガイダンスを提供します。 これらの主題は、競合他社について議論しないなどの機密のビジネス上のトピックや、上位の共同作成者を適切に認識する方法などのより一般的な運営上のトピックである場合があります。内部の FAQ: 一般的な質問に対して承認された回答を提供します。 このリストは、オープンソース プログラムを維持する過程において、会社で議論する可能性があるトピックに、法的に微妙な点がある場合は特に役立ちます。
ライセンス ポリシー: オープンソースの使用または共同作成に関して、法務部門によって承認または拒否されたライセンスを一覧表示します。