オープンソース コミュニティのメリットについて説明する
ここでは、GitHub のオープンソース コミュニティのメリットをいくつか説明します。 イノベーションは、オープンソース ソフトウェアを基にして築かれます。現在作成されている新しいアプリケーションの 80 から 90% は、オープンソース コードによって構成されています。 残りの 10 から 20% は、ビジネス価値の実現に注力できる部分です。 市場で競争するためには、オープン ソースを使用する必要があります。そうしないと、独自のソリューションを開発することによって、スタート時点での有利な立場を失うことになります。
成功するためにプロジェクトとコミュニティを設ける
将来に向けて、所属する組織でオープンソース プログラムを作成することを決定したとします。 数か月後に、契約した共同作成者のコミュニティに魅力を感じました。 お疲れさまでした。 次に何をすればよいのでしょうか。
プロジェクトのために快適なコミュニティを構築することは、オープンソース プログラムにおける長期的な投資になります。 健全かつ安全で快適なコミュニティは、オープンソースのエコシステムを背後から支えてくれます。 多くの場合、参加者がオープンソース プロジェクトに貢献するか貢献しないかの主な理由は、人やコミュニティです。
重要なインフラストラクチャやよく使用される依存関係の作業を進めるには、個人ではなくチームが必要です (たとえ、メンバーが地域やタイムゾーンを超えて分散していたとしても)。 そのため、プロジェクトが商用にサポートされておらず、SLA がない場合でも、プロジェクトのメンテナンスに引き続きコミュニティのサポートを期待することができます。 同様に、ビジネス プロセスが個人に依存してしまうことは避けたいと考えるはずです。 もし、会計担当の Bob が病気になり、ソフトウェアの運用方法を知っている人が彼だけであるために、彼が戻って来るまで給料を支払うことができないとしたら、どうでしょう。
参加者がオープンソース プロジェクトに関わってやり取りするにつれ、ユーザーから共同作成者やメンテナンス担当者に一部が移行されます。 ここでは、この移行に関連する手順を "共同作成者の作業" と呼びます。 共同作成者の作業はオープンソース プロジェクトの持続性にとって重要であるため、プロジェクトのメンテナンス担当者がこれに配慮することが大切です。
オープンソース プログラムを実行するときの目標は、摩擦を減らして共同作成者のエクスペリエンスを向上させることです。 熱心ではない共同作成者や一度きりの共同作業者であっても、プロジェクトへの投稿を簡単にすることが仕事です。 オープンソース コミュニティは、効果的に参画する方法や、共同作成者間で期待される行動など、プロジェクトに関するメタ情報を共有するための非公式な方法を発展させてきました。 これらの方法は通常、README および CONTRIBUTING というファイルに追加されます。 プロジェクトの README は、ツールまたはフレームワークをインストールするための一連の手順ではなく、プロジェクトのランディング ページと考えてください。
求めている共同作成者のタイプや彼らを確認して受け入れる方法に関して、詳細情報を提示するには、CONTRIBUTING ファイルを使用します。 また、トリアージを採用する際の条件やリポジトリに対するコミット権限についても説明します。
オープンなコミュニケーション
オープンソース プロジェクトに取り組む際、多くの場合、ドキュメントの焦点は技術ドキュメントにあります。 コミュニティをプロジェクトに取り込むための優れた方法は、技術的なドキュメントを超えたところにあります。オープンにドキュメント化できる項目には、プロジェクトのロードマップとガバナンス、共同作成のプロセス、および議事録があります。
GitHub ディスカッションを使用して、重要なディスカッションをドキュメント化し、コミュニティや共同作成者のフィードバックを集めることができます。 この方法によって、チームやより幅広いコミュニティとのディスカッションを開始できます。 issue および pull request でも、これらのディスカッションを参照できます。
行動規範の問題など特定のケースを除いて、コミュニケーションが公開された状態を維持します。誰もが同じ情報を持てるようにします。
GitHub 上のプロジェクト コミュニティ プロファイル
プロジェクトをコミュニティ規範に照らして確認するには、リポジトリのメイン ページに移動します。 リポジトリ名の下にある、[Insights](インサイト) を選択します。 左側のサイド バーで [Community Standards]\(コミュニティ規範\) を選択します。 ほとんどすべてのファイルは、ここで追加することが適切です。 issue や pull request 用のテンプレートを追加して、ユーザーがバグを報告したり、コードを送信したり、単にプロジェクトに参加したりする際の障壁をさらに取り除くことを考えます。
コミュニティのベスト プラクティスに関する詳細については、GitHub のオープン ソース ガイドをご覧ください。