オープンソースガバナンスの5つのモデル

[[392851]]

オープンソースコードプロジェクトに初めて参加する際には、まず多くの参加者の中で誰が貢献する資格を持つのかを判断する必要があります。オープンソースソフトウェアプロジェクトにおいて誰が何をどのように行うべきかを定めたルールと規約は、プロジェクトのガバナンスモデルと呼ばれます。これらのルールと規約を理解することによってのみ、誰もがプロジェクトの運営にスムーズに参加し、貢献を成功させることができます。

すべてのオープンソースプロジェクトとコミュニティはガバナンスモデルに基づいて運営されていますが、これらのモデルの質には依然としてばらつきがあります。この記事では、最も一般的なオープンソースプロジェクトとコミュニティのガバナンスモデルをいくつか紹介し、様々なモデルを採用するプロジェクトのための入門ガイドを提供します。

「権威主義体制」モデル

「権威主義的」なガバナンスモデルを採用するオープンソースプロジェクトは、多くの場合、正式かつ詳細なガバナンス契約を公開せず、意思決定権の大部分を少数の限られたメンバーに集中させています。言い換えれば、権威主義的なプロジェクトのメンバーは、一貫性と安定性のある貢献を通じて権威を獲得する必要があります。このモデルではピアレビューが依然として主流ですが、個々の貢献者は、プロジェクトの特定の構成要素、特に最も関わりのある構成要素に関して、客観的な意思決定権を保持する傾向があります。

そのため、一部のオープンソースプロジェクトは、ガバナンスモデルを全く持たず、ステークホルダーがそれぞれの権限に基づいて意思決定を行うことに頼っていると強調しています。しかし、この「ガバナンスがない」という考え方は明らかに誤りです。すべてのオープンソースプロジェクトには、必然的に独自のガバナンスモデルが存在します。多くの場合、このガバナンスモデルはプロジェクトメンバーの日常的なやり取りに暗黙的に存在しています。その結果、ベテランメンバーは新規参加者を潜在的な脅威と見なし、新規参加者はプロジェクトに溶け込むのが難しく、すぐに参加する方法や、貢献に対する承認を申請する方法さえも分からなくなってしまいます。

プロジェクトにおけるガバナンスモデルを確立するための最初のステップは、改善の余地がある具体的な点を特定することです。プロジェクトの変更履歴を検証することで、長期メンバーにとって私たちの貢献が魅力的に見えるようにすることができます。貢献が受け入れられるようになるにつれて、誰もがコミュニティ内で徐々に影響力を高めていくでしょう。

「創設者/リーダー」モデル

「創設者/リーダー」型のガバナンスモデルは、新規プロジェクトや貢献者が少ないプロジェクトで最も一般的です。これらのプロジェクトでは、創設者/リーダーは、ビジョンの定義、コードマージ権限の管理、そしてプロジェクトを代表して公の場で発言する権利など、プロジェクトマネジメントの責任も負います。一部のプロジェクトでは、創設者/リーダーを「伝達型独裁者」と呼ぶこともあります。これらのプロジェクトでは、権力と権限の境界は通常非常に明確です。創設者/リーダーは、最終的にプロジェクトにおけるすべての重要な決定を下します。

プロジェクトが一定規模に達すると、このモデルの限界が明らかになります。最終的には、創設者/リーダーの個人的な嗜好がプロジェクト設計における最適な決定から乖離し、創設者/リーダーがプロジェクトの意思決定におけるボトルネックとなります。極端なケースでは、創設者/リーダーモデルはプロジェクト内に「カースト制度」を生み出す可能性があり、創設者以外のメンバーは、創設者の意志や考え方を変える力がないと徐々に感じ始めます。この乖離はプロジェクトの断片化につながり、創設者/リーダーが燃え尽き症候群や計画的な退職によってプロジェクトを去った場合、プロジェクトは瞬時に崩壊する可能性もあります。

このタイプのガバナンスモデルを採用しているプロジェクトでは、まずプロジェクトのメーリングリストを閲覧したり、ディスカッションフォーラムに参加したりして、プロジェクトの創設者/リーダーと最初のコンタクトを取り、その後、どのように貢献を提出するかという質問を一つずつ検討していくことができます。これにより、私たちはプロジェクトのニーズを包括的に理解し、私たちが貢献できる最適な分野を分析することができます。さらに、創設者/リーダーのプロジェクトに対する基本的なビジョンを明確に理解する必要があります。そうでなければ、このビジョンに反する変更の提案は即座に却下される可能性があります。初期段階では、創設者/リーダーの根本的な希望を損なうようなプロジェクトの変更を提案することは避けてください。

自任の評議会または取締役会モデル

「創設者／リーダー」モデルの欠点を認識し、自任評議会または理事会モデルは、より円滑で安定したリーダーシップ継承システムを確立し、コミュニティを成功へと導くことを目指しています。このモデルでは、オープンソースプロジェクトのメンバーは、プロジェクトの様々な側面を管理するために複数のリーダーシップチームを任命できます。これらのチームには、運営委員会、コミッター委員会、技術運用委員会、ビルド委員会、または取締役会などが含まれます。各チームは通常、独自の意思決定規約と継承手順を有します。

この自発的な評議会または理事会によるガバナンスモデルは、プロジェクトにスポンサー基盤がなく、選挙メカニズムの構築に苦労している場合、多くの場合うまく機能します。しかし、自発的なリーダーシップチームがプロジェクトコミュニティから孤立していたり、代表者が不足していたりする場合、このモデルの欠点が顕著になることに注意することが重要です。このような場合、選出プロセスは容易に論争を巻き起こし、結果として生じるリーダーシップ文化は抵抗的なものになる可能性があります。さらに、コミュニティメンバーは受動的に選ばれたと感じ、貢献するモチベーションが十分に得られない可能性があります。

このガバナンスモデルを採用しているプロジェクトを検討するには、まず入門ドキュメントから見ていきましょう。まず、このモデルは成熟したオープンソースプロジェクトでは非常に一般的であり、コミュニティが貢献者向けに包括的な入門資料を提供していることが多いことを理解することが重要です。これらの資料をよく読み、プロジェクトのガバナンスドキュメントと併せて、ガバナンスモデルがどのように運用されるかを判断してください。ほとんどの場合、貢献に関する具体的な問題については、評議会または理事会に問い合わせることができます。組織内の専任担当者が貢献を監視し、ご質問にお答えします。

選挙制度モデル

一部のオープンソースプロジェクトでは、ガバナンスのために選挙制度を採用しています。例えば、コミュニティメンバーは様々な役職の選挙を組織し、投票を通じてプロジェクトのポリシーや手順を承認または更新することができます。選挙制度では、コミュニティはメンバーに広く受け入れられる選挙手順を確立し、明確に文書化し、それを定期的な意思決定プロセスに組み込みます。

このモデルは、多数の有能で情熱的な貢献者がガバナンスに参加する大規模なオープンソースコードプロジェクトで一般的です。さらに、安定したスポンサー（財団など）を持つプロジェクトでは、選挙制度が採用されることが多く、これは選挙プロセスによってスポンサーのリソース配分の透明性が高まるためです。選挙によるガバナンスでは、プロジェクト内のそれぞれの役割、手順、参加方法が綿密に文書化される傾向があります。このような明確な制度的枠組みがあれば、新しい貢献者は貢献と熱意を最大限に発揮できます。

しかし、選挙制度にも問題点はあります。プロジェクトメンバー全員にとって、実際の貢献度に関わらず、投票結果は議論を呼ぶ可能性があり、時間の浪費となる可能性があります。一部のコミュニティでは、選挙の際に特定の著名なプロジェクトメンバーに無期限のリーダーシップポジションを求めることもありますが、プロジェクトで明示的に任期制限が定められていない限り、選挙は一般的にマネジメントチームメンバーの変更とは無関係です。

このガバナンスモデルを採用しているプロジェクトに参加するには、プロジェクトのウェブサイトに掲載されている選挙結果とリーダーシップチームリストを参照してください。これらのドキュメントをよく読み、プロジェクトの担当者を特定してください。優れたガバナンス体制を持つオープンソースコミュニティでは、通常、提案の投票プロセスとコミュニティレビューについて、プロジェクトのウェブサイトで説明しています。プロジェクトに貴重な貢献をし、確固たる評判を築いていくと、最終的にはプロジェクト内の特定のリーダーシップポジションの候補者になる可能性があります。他の貢献者と生産的な交流やコラボレーションを行うようにしてください。いつか彼らが投票権を使ってあなたへの支持と敬意を表してくれるかもしれません。

単一サプライヤーモデル

個々の企業や業界団体が、潜在的な開発者やユーザーを引き付けるために、特定のオープンソースコードライセンス条項に基づいてソフトウェアをリリースすることがあります。しかし、これらのプロジェクトは多くの場合、一般からの貢献を受け入れていません。これは、開発の加速、ソフトウェアプラットフォームにおける開発活動の促進、プラグインエコシステムのサポート、あるいはコミュニティが外部開発者の採用に多額の投資をすることを避けるためであると考えられます。

このモデルでは、管理組織は通常、外部からの貢献を一切受け入れません。その代わりに、オープンソースコードとクローズドソースコードの両方におけるイノベーションは、プロジェクトの周辺部でのみ発生します。そのため、一部の評論家はこのガバナンスモデルを「ウォールドガーデン」と呼んでいます。このモデルに従うプロジェクトでは、ベンダーが他の商業的競合他社の参入を阻止しようと、より厳格なパブリックドメインライセンスを採用する場合があります（つまり、製品化準備が整った競合他社や顧客に非オープンソース版のソフトウェアを購入させることです。これはデュアルライセンスとも呼ばれます）。しかし、このモデルでは、プロジェクトは企業またはコンソーシアムによって完全に所有されているため、実質的にオープンコミュニティが欠如しています。

このガバナンスモデルを採用しているプロジェクトに参加するには、まず、雇用主とプロジェクトを立ち上げた企業との関係性を検討する必要があります。次に、プロジェクトのライセンス条項を評価し、変更履歴とバグ追跡の仕組みを確認して、プロジェクトの特定の側面に自分の好みに合った方法で貢献できるかどうかを判断します。プロジェクトの具体的なルールによっては、これらの特定の側面にアクセスできる場合もありますが、必ずしもプロジェクトへの直接的な貢献とはなりません。

財団サポートモデル

リソースとプロジェクトコードをより適切に管理するために、一部のオープンソースプロジェクトは、慈善活動を行う非営利団体や業界団体などのNGO（非政府組織）による管理を選択しています。このアプローチにより、プロジェクトは関連サービスプロバイダー、商標、特許、保証などのリソースの明確な所有権を持つことができます。

場合によっては、財団のリーダーシップとプロジェクトのリーダーシップが単一のガバナンス構造を形成し、オープンソースプロジェクトのあらゆる側面を共同で管理します。ただし、商標やオフラインイベントなど特定の側面は財団が直接管理し、コード承認などのその他のガバナンス事項はプロジェクトリーダーシップチームが担当する場合もあります。

大規模なオープンソースプロジェクトは、多くの場合、様々な資金調達や法的要件を遵守する必要があります。しかし、一部の小規模プロジェクトは、Software Freedom ConservancyやLinux Foundationといった、より大規模で保護的な財団に加盟し、支援的なガバナンスモデルのメリットを享受することを選択します。このガバナンスモデルは、第三者との法的関係を構築する必要があるプロジェクトや、主要メンバーの退任後も円滑な移行と継続的な運営が必要なプロジェクトにとって、間違いなく最適な選択肢です。このアプローチは、単一ベンダーの支援を受けるプロジェクトが過度に商業化されるのを防ぐのにも役立ちます。

しかし、財団支援によるガバナンスモデルの大きな欠点は、運営コストの高さにあります。これは、厳しい財務上の制約だけでなく、寄付者にも多大な時間的投資を強いることになります。一部の財団は業界団体の形態をとり、スポンサー企業によって内部運営されています。また、寄付者の参加要件は団体によって異なり、比較的オープンな団体もあれば、企業経営者の権限を厳しく制限している団体もあります。

このモデルを用いてオープンソースプロジェクトに参加する場合、財団が日々のプロジェクト貢献の管理に関与していない場合は、導入ドキュメントを直接参照し、コンテンツ要件に従ってください（詳細は「自任評議会または理事会」セクションを参照）。ただし、財団が管理するすべてのプロジェクトは一定の基本的な貢献プロセスに従いますが、財団内のプロジェクトごとに専任のマネージャーがいる場合があることにご注意ください。プロジェクトリーダーを見つけるには、財団のメンバーメーリングリストに申請書を送信してください。また、プロジェクトの過去の変更ログを確認して、どのメンバーが最も頻繁に貢献しているかを特定し（「権威主義体制」セクションを参照）、連絡を取ることもできます。ほとんどの財団は貢献に基づく投票システムも導入しているため、財団の正式な投票メンバーになるために必要な手順を理解しておきましょう。財団が会員制の業界団体である場合は、あなたの雇用主が会員であるかどうかを確認してください。会員でない場合は、上司にプロジェクトの重要性について説明し、雇用主が参加を検討するかどうかを尋ねてください。いずれの場合も、財団プロジェクトでは、署名済みの貢献者申請書が必要となる場合があります。法務部門のサポートを受けてこの文書を確認し、署名してください。

DUICUO