[[392855]]

オープンソースコードプロジェクトの役割について議論するとき、多くの人はまずオープンソースライセンスについて考えます。一方で、Open Source Initiative（OSI）ライセンスに準拠していないプロジェクトは真のオープンソースとはみなされないと考える人も多くいます。一方で、GNU General Public License（GPL）やMITライセンスなどのパブリックドメインライセンスを選択することは、プロジェクトの利用方法やコミュニティの発展に大きな影響を与える可能性があります。

しかし、Linux Foundationの開発者リレーション担当バイスプレジデントであるクリス・アニシュチク氏は、ライセンス自体はプロジェクトの管理方法を真に導くものではないと考えています。したがって、核心的な問題は、いかにプロジェクトをオープンに管理するかです。アニシュチク氏は、紛争が発生する前にこれらの質問に答え、すべての参加者が意見を表明できるオープンで公平なチャネルを提供することが、プロジェクトの拡大に​​伴う長期的な成功の前提条件であると付け加えました。

オープンソース プロジェクトは、次の 6 つの主要なガバナンス課題に対処する必要があります。誰が意思決定を行うのか？メンテナーはどのように追加されるのか？ドメインの権利は誰が所有するのか？商標権は誰が所有するのか？特定のインシデントはどのように管理されるのか？システムの運用方法を決定する責任者は誰なのか？

前述の課題に直面すると、普遍的に適用可能な単一の解決策は存在しないことが明らかになります。特定のコミュニティのニーズや歴史的要因に駆り立てられたものであっても、様々なプロジェクトやそれらを管理する財団は、それぞれ独自の手法を採用することがよくあります。

そのため、多くのプロジェクトは「委任型独裁者」（BDFL）モデルを採用しています。このモデルでは、主要なプロジェクト決定について、一人の人物（通常はプロジェクト創設者）が最終決定権を持ちます。多くのプロジェクトはデフォルトでここで行き詰まっており、Linuxカーネルプロジェクト自体がその一例です。しかし、Red Hatのジョー・ブロックマイヤー氏は、BDFLが典型的な「アンチパターン」になっていると指摘しています。「確かにBDFLの影響を受けて成功したプロジェクトもありますが、それよりもはるかに多くのプロジェクトが完全に道を見失っています。」

アニシュチク氏は、「財団によって規約、規約、組織構造が異なる場合が多く、組織レベルでは大きな違いがあります。例えば、Apache Wayは非常に有名で、Apacheの運営指針となっています。これは、プロジェクトが自らの努力によって段階的に成長していくインキュベータープロセスです。プロジェクトマネジメントの観点から見ると、これは本質的に『広範囲にわたる』競争的な選考方法と言えるでしょう」と指摘しています。

アニシュチク氏は、プロジェクト管理における最低限の要件をいくつか概説しました。「Linux FoundationとCloud Native Computing Foundation（CNCF）の多くのプロジェクトの中で、私たちはGovernance.mdファイルモデルを採用しています。このファイルモデルには、意思決定の方法、管理方法、メンテナーの追加/削除方法、サブプロジェクトの追加/削除方法、開発成果のリリース方法などが記述されています。これらはほんの第一歩に過ぎません」と強調しました。

第二に、彼は「資産の所有権を中立的に設定しなければ、オープンガバナンスは不可能だ。結局のところ、ドメイン、商標、そして特定の著作権は、必然的に一人以上の人物に帰属する。Apache Foundation、Software in the Public Interest、Software Freedom Conservancyなど、多くの優れた組織は、この点に関して非常に軽量なメカニズムを採用しており、それぞれ独自の試みを行っている」と考えている。

アニシュチク氏はまた、一般的に使用されている多くの手法が、ある程度アンチパターンであると述べました。貢献者ライセンス契約（CLA）を例に挙げましょう。これは、コードなどの知的財産をプロジェクトに提供する際に遵守すべき条件を定義するものです。彼の見解では、「企業が製品を製造したり、デュアルライセンスモデルを採用したりする場合、CLAは間違いなく検討する価値があります。しかし、それ以外のニーズにおいては、CLAは開発者にとって重大な問題を引き起こす可能性があると考えています」と述べています。

一方で、アニシュチク氏はいわゆる「開発者原産地証明書」（CLA）の活用を推奨しています。Linuxカーネルプロジェクトが選択したこのソリューションは、CLAの中核となる内容の多くを包含しています。例えば、「このコードは私が自分で書いたものですか？他のプロジェクトにコピーしないことを約束しますか？この成果物をあなたに引き渡して、承認と廃棄を依頼する権利がありますか？」といった点です。これはLinuxカーネルをはじめとする多くのエコシステムで実装されている、非常に成功したモデルです。厳格なビジネス要件がない限り、私は個人的にCLAの使用を強く推奨しません。

彼はまた、多くの命名ミスを発見しました。「プロジェクトのブランディングは非常に重要です。多くの場合、社内または個人で「Docker」のようなプロジェクトを立ち上げ、それを中心にエコシステムを構築し、Docker企業を設立し、最終的にDocker製品やエンタープライズソリューションへと発展していきます。これらはすべて異なるユーザー層を対象としており、多くの誤解を招きます。ですから、私は個人的に、何かの名前には本質的に付加価値が含まれていると強く信じています。したがって、企業名、プロジェクト名、製品名は区別するのが最善です。」

最後に、アニシュチク氏は、信頼とプロジェクトへの信頼を築く上でのオープンガバナンスの役割についても言及しました。このアプローチにより、企業はプロジェクト内で自社のニーズや計画を一方的に主張しないことを強調することができます。彼は次のように結論付けました。「信頼は、強力なコミュニティを構築するための必須の前提条件です。オープンソースプロジェクトがオープンガバナンス機関の支援を欠いている場合、貢献者は貴重な時間と労力をプロジェクトに捧げることを決意することが難しくなります。」