意思決定するためのルールを決めることで、オープンソースプロジェクトを成長させる助けとなります成長中のプロジェクトの運営方法を理解しようあなたのプロジェクトは成長しており、人々が携わっていて、あなたは物事がこのまま進むように維持することに熱心でしょう。この段階では、あなたはどのようにして通常のコントリビューターをワークフローに組み込むのが良いか悩んでいるかもしれません。誰かにコミット権限を与えるかどうかであったり、コミュニティの議論をどのように収集させるのかであったり。いった疑問があるのであれば、私達は答えを知っています。オープンソースプロジェクトで使われる公式の役割の例はなんですか?多くのプロジェクトでは、コントリビューターの役割は似たようなものを使っています。いった役割が実際の所何を意味するのかは、完全にあなた次第です。コミット権限を持っている唯一の人です。メンテナーとして記載されている人であることもあります。メンテナーはプロジェクトでコードを書いている人である必要はありません。プロジェクトの布教を熱心に行っている人でも良いですし、多くのドキュメントを書くことで他の人がプロジェクトにアクセスしやすくしている人でも良いのです。日常的に何をやっているのかにかかわらず、メンテナーはプロジェクトの方向性に責任を持っていると感じていて、またプロジェクトを改善するのに熱心である人でしょう。「コントリビューター」は誰でもなり得ます。それは、イシューやプルリクエストにコメントを書いている人かもしれないし、プロジェクトに価値を与える(イシューを選別する、コードを書く、イベントを運営するなど)人かもしれないし、プルリクエストをマージしてもらった人(おそらくこれが最も狭義のコントリビューターの定義です)かもしれません。イシューにコメントした人やコードを書いた人は皆コミュニティのメンバーなのです。彼らに会えたということは、ユーザーからコントリビューターへの一線を越えたということを意味しています。コミットアクセスという特定の種類の責務を、他の種類のコントリビュートと区別するために使われるでしょう。あなたの好きなようにプロジェクトの役割を定義できますが、より多くの種類のコントリビュートを奨励するためにより広い定義を検討しましょう。プロジェクトに多大なコントリビュートをしている人に対しては、その人の技術スキルがどうであれ、その人のコントリビュートを公式に認めるために、リーダーの役割を使うことができます。皆さんは私のことをDjangoの「発明者」と認識しているかもしれません...しかし、実際は私は作られてから1年後に採用された人間なのです。皆さんは私のプログラミングスキルのおかげで成功したと思うかもしれません...しかし、私はせいぜい平均的なプログラマーなのです。(video)どのようにしてリーダーシップの役割を明確にするか?リーダーシップの役割を明確にすることで、人々に責任を持たせ、他のコミュニティメンバーが助けが必要な時に誰に聞くべきかが明確になります。ファイルに名前を追加するだけで済むこともあります。大きなプロジェクトでは、ウェブサイトを持っているのであれば、チームページやプロジェクトリーダーのリストのページを作りましょう。各コントリビューターの短いプロフィールを記載しています。あなたのプロジェクトのコントリビューターが非常に活発なのであれば、メンテナーの「コアチーム」を作ったり、異なる問題領域ごと(例えば、セキュリティ、イシューの選別、コミュニティ運営)に責任を持つ分科会を持っているかもしれません。あなたが指名するのではなく、人々が自分の興味のある領域の役割に自律的にボランティアしてくれるように任せましょう。コアチームに対して、幾つかの「サブチーム」で支えています。各サブチームはそれぞれ特定の領域にフォーカスしています。言語設計やライブラリなどです。世界をまたがるコラボレーションと、プロジェクト全体として協力で一貫したビジョンを維持するために、各サブチームはコアチームのメンバーによってリードされています。上で)集まりたいと思うかもしれません。いったミーティングでさえも公にする事で、他の人も議論を聞けるようにしましょう。毎週オフィスアワーを設けています。一度リーダーシップの役割を確立したなら、どのようにして彼らにコンタクトを取れるかドキュメントにまとめることを忘れないようにしましょう。ファイルにそれを記載しましょう。ようなツールは、プロジェクトに対するコントリビュートを誰がやっているのか(やっていないのか)を公にトラッキングするのに役立ちます。いった情報をドキュメント化することで、メンテナーは非公開の場で意思決定を行う派閥を作っているとコミュニティから認識されることを避けることができます。移し、少なくとも一人の管理者をバックアップとして追加することを検討しましょう。使うことで、権限や複数のリポジトリを管理し、所有権を共有することでプロジェクトの資産を守ることがやりやすくなります。いつ他の人にコミット権限を与えるべきだろうか?コントリビュートをするすべての人にコミット権限を与えるべきだと考える人もいます。することで、より多くの人にプロジェクトに対して責任を感じてもらうことができます。その一方で、大きく複雑なプロジェクトでは、プロジェクトに対して熱心に献身している人のみにコミット権限を与えたいと思うかもしれません。あなたが最も良いと思うことをやりましょう。できるのかを管理することができます。誰かがプルリクエストを送ってきたときはいつでも、その人にプロジェクトへのコミット権限を与えましょう。真の力を解き放つことができるようになります。一度コミット権限をもらえば、人々はもはや自分のパッチがマージされるかどうか心配せずにすみます。することで、彼らはより多くの仕事を成し遂げてくれるようになるのです。Hack”オープンソースプロジェクトによくある運営方法はどのようなものでしょうか?オープンソースプロジェクトに関連して、3つのよく使われる運営方法があります。これは、一人の人間(大抵はプロジェクトを立ち上げた人)が、全てのプロジェクトの大きな決断に最終承認を出すやり方です。採用しているでしょう。メンテナーが一人か二人しかいないからです。カテゴリーに入るでしょう。業績主義のもとでは、活動的なプロジェクトコントリビューター(「業績」を出した人)が、公式の意思決定の役割を与えられます。意思決定はたいてい投票によって行われます。プロジェクトは業績主義で運営されています。コントリビュートは、全て企業ではなく代表する個人によってのみ行われます。自由主義的なコントリビュートモデルでは、最も働いている人が最も影響力があると認められますが、これはこれまでのコントリビュートではなく現時点での仕事に基づきます。プロジェクトでの大きな意思決定は、純粋な投票ではなく合意の模索プロセス(大きな不満点について議論する)によって行われます。可能な限りコミュニティ内の多くの知見を集めようと努力します。どのモデルを使うべきでしょうか?それはあなた次第です!それぞれのモデルには利点と欠点があります。はじめはこれらのモデルは全く異なるように見えるかもしれませんが、見かけ以上にこれらのモデルは共通点が多いのです。自由主義的コントリビュートポリシープロジェクトを立ち上げる時に、運営ドキュメントは必要でしょうか?プロジェクトの運営についてドキュメントを書くのに適切なタイミングはありませんが、コミュニティの力学が明らかになってから定義するほうがずっと簡単です。オープンソース運営における最善の(そして最も大変な)点は、コミュニティによって形作られているということです!しかしながら、初期段階でドキュメントを書くことでは必ずプロジェクト運営に寄与するでしょう。書けるものから書き始めましょう。いった行動を期待するかを明確に定義したり、コントリビューターのプロセスはどうなっているかといったものを、プロジェクトの立ち上げ時点に書きましょう。あなたがオープンソースプロジェクトを立ち上げようとしている企業に所属しているのであれば、立ち上げの前にプロジェクトを進めるにあたって何をコミュニティに期待し、どのように意思決定するのかを内部で議論しておくことは価値のあることです。あなたの企業がプロジェクトにどのように関わるか(もしくはかかわらないか)に関して公に説明しておきたいと思うかもしれません。上のプロジェクトの運営担当としています。開発者によって運営されています。Facebook”企業の従業員がコントリビュートを提出したら何が起きますか?成功したオープンソースプロジェクトは多くの人々や企業によって使われるようになります。幾つかの企業では、プロジェクトが最終的な収益への流れに結びつくことになるかもしれません。プロジェクトのコードを商用のサービスの一部として使っているかもしれません。あなた自身もそうかもしれません!そして、プロジェクトでやっている仕事で採用されることも時にはあるでしょう。企業の活動も、普通の活動と同じであり、1つの開発リソースの源であると捉えることは重要です。それぞれのコントリビュートは技術的な功績によって評価されるべきです。企業活動に従事する事を苦痛に感じるべきではありませんし、特定の改善や機能について議論するときにはユースケースを主張することにも苦痛を感じるべきではありません。「商用利用」は、「オープンソース」とは完全に両立可能です。それはソフトウェアが商取引で使われているということで、プロジェクトが多く採用されるにつれてその可能性は増していきます。(オープンソースソフトウェアがオープンソースではない製品の一部として使われる時、プロダクト全体はそれでも「プロプライエタリ」ソフトウェアですが、オープンソースのように商用も非商用のどちらでも利用可能です。)他の皆と同様に、お金を支払われて開発を行っている人もプロジェクト内の影響力を得るのは、コントリビュートの質や量によってです。明らかに、お金を支払われている開発者は支払われていない開発者よりも多くのことをできますが、それで良いのです:お金を得ているかどうかは、その人がどのくらいコントリビュートするかに影響を与える要素が多くある中の1つでしかありません。プロジェクト内の議論では、コントリビュートを行う上での外部要因ではなく、コントリビュート自体に集中し続けましょう。プロジェクトを運営するのに法人は必要ですか?お金を扱うのでなければ、オープンソースプロジェクトの運営に法人は必要ありません。株式会社や有限会社の立ち上げを考えているでしょう。設立することもできます。使うことで)寄付ボタンを設置することができます。)でない場合は課税控除の対象にはなりません。多くのプロジェクトでは非営利団体を設立するという面倒を避けるために、代わりに非営利の財政スポンサーを見つけています。財政スポンサーは、寄付額の一定の割合を受け取ることと引き換えにあなたの代わりに寄付を受け取ります。オープンソースプロジェクトの財政スポンサーとして活動している団体の例です。私達のゴールは、コミュニティが自立して持続可能になるようなインフラを提供することで、コントリビューター、支援者、スポンサーの全員が利益を得ることができるような環境を作ることです。framework”もしあなたのプロジェクトが特定の言語やエコシステムと密接に関係しているのであれば、連携できるソフトウェア財団もあるかもしれません。ベースのフレームワークをサポートしています。すべてのガイドに戻る関連するガイドメンテナーの為のベストプラクティスプロセスのドキュメント化やコミュニティの活用といったことを通じて、オープンソースメンテナーとしての日々をより楽にしましょう。オープンソースメトリクス成功の度合いを計測し続けることで、データをもとにしてあなたのオープンソースプロジェクトに関する意思決定を行おう。貢献する提案したいことがありますか?このコンテンツはオープンソースです。改善にご協力ください。最新のオープンソースに関するヒントや情報をすぐに受け取りましょう。