オープンソースプロジェクトの運営は簡単です。ソースコードを公開してオープンソース化するだけですよね？まあ、そうかもしれません。実際、オープンソースプロジェクトの成功は、成功の定義によって異なります。定義に関わらず、オープンソースプロジェクトの作成には多くの作業が必要です。すでに目標があるのであれば、投資する覚悟が必要です。オープンソースソフトウェアは無料ですが、作成には費用がかかります。時間や労力といった貴重なリソースをプロジェクトに投入する必要があります。

では、これらのリソースをどのように投資するのでしょうか?

1. 定義成功

オープンソースプロジェクトの運営を検討する前に、成功とは何かを明確に定義する必要があります。考慮すべき要素は数多くあります。コードを公開リポジトリに置くだけで十分なのでしょうか、それともプロジェクトでそれ以上のことを実現したいのでしょうか？コラボレーションと採用は重要ですか？ソフトウェア開発者としての評判を築くことだけが目的でしょうか？成功の定義には長期的な成功も含まれますか？このプロジェクトを中心にコミュニティを構築したいのでしょうか？商業的な採​​用を期待していますか？これらの質問への答えは、次に採用すべき提案の数を判断するのに役立ちます。

2. 透明

これは簡単に理解できます。簡単に検索でき、公開されているソースコード リポジトリの使用、公開されている問題追跡ソフトウェアの使用、コミュニティが見つけられる場所にリリース スケジュールを公開すること、パブリック フォーラム (アーカイブされたメーリング リストなど) での会議の議事録の記録など、コミュニティが皆さんの活動を観察し、理解できるようにしたいのです。

3. 開く

多くのオープンソースプロジェクトでは、「透明性」と「オープン性」は同じ意味を持ちますが、実際にはこの2つの用語は全く異なる意味を持っています。オープン性とは単に「透明性」（本質的には透明性と同じ）のことだけではありません。多くのオープンソースプロジェクトにとって、「オープン性」とは、新しいアイデアや参加を受け入れるオープン性を意味します。オープンソースプロジェクトへの参加ルールは、誰にとっても同じであるべきです（「公平な競争の場」）。単にいくつかのパッチを受け入れるだけでは不十分です。新しいアイデアを受け入れるオープン性が必要です。つまり、他者がプロジェクトに参加できるようにし、プロジェクトに対する絶対的なコントロールを放棄する必要があるということです。

4.「公平な競争の場」を維持する

これは必ずしも誰でもプロジェクトに参加させなければならないという意味ではなく、全員が同じルールに従うようにすることを意味します（環境は公平であっても、独自の方法で勝ち抜く必要があります）。実力主義とは、自身の努力によって差別化を図る必要があることを意味します。例えば、一部のプロジェクトでは、開発者をプロジェクトチームに招待する前に、プロジェクトのコード、ルール、文化への理解を示すために、一定の貢献を求めるなど、実力主義を実践しています。新しい開発者をプロジェクトに追加するプロセスが周知され、透明性が確保されていることを確認してください（例：公開投票）。

5. サプライヤー中立性

真のオープン性を実現するには、開発者の貢献が認められる必要があります。これは、プロジェクトがベンダー中立であれば実現が容易になります。ベンダー中立のプロジェクトは、特定の組織や機関によって主導されるものではありません。人材育成プログラムは、特定の組織の目標や採用方法ではなく、個人の貢献に基づくべきです。ベンダー中立的なホスティングは、これを実現する一つの方法です。

6. 明確に定義され文書化された標準がある。

プロジェクトのコードフォーマットルール（コードフォーマットのプリセットに簡単にアクセスできるようにする）、テストカバレッジに関する期待値、開発方法論、ソフトウェアと必要なツール、プロジェクトチームとのコミュニケーションチャネル、そして潜在的な貢献者にとって重要なその他の情報を文書化します。これらの情報をすべて記録し、可能な限り簡単に見つけられるようにします。プロジェクトのソースコードリポジトリのルートディレクトリに貢献ガイドを含めることは良い習慣です（DVCSを通じて、潜在的な貢献者はリポジトリのコピーを見つけることができます。リポジトリに貢献ガイドがあれば、潜在的な貢献者はプロジェクトに貢献するための適切なパスを簡単に見つけることができます）。

7. プロジェクト コードが常にビルド可能であることを確認します。

プロジェクト コードには、プロジェクト コードをできるだけ簡単にビルドしてテストできるようにするためのビルド スクリプトと手順が含まれています。

8. ユーザーコミュニティとつながる

ユーザーコミュニティとは、オープンソースプロジェクトの製品を使用する人々のグループです。ユーザーコミュニティがプロジェクトのコードに直接貢献することはほとんどありませんが、多くの質問をしてくることがよくあります。これらの質問には必ず回答してください。健全なユーザーコミュニティは、採用コミュニティに情報を提供します。

9. 採用者コミュニティとつながる

オープンソースプロジェクトの成功の明確な兆候は、他の組織が自社製品でそのプロジェクトを利用したり、拡張機能を開発したりし始めることです。このコミュニティはプロジェクトへの貢献意欲が高まり、最も貴重な貢献源となります。貢献者の中には、プロジェクトチームへの最有力候補となる人もいます。開発者、採用者、そして拡張者からなるエコシステムは、プロジェクトの寿命を延ばすための優れた方法です。

10. 開発者コミュニティとつながる

開発コミュニティは、プロジェクトチームメンバーと貢献者で構成されています。コミュニティ内でのコミュニケーションには、よく知られたチャネルが用意されています。明確なコミュニケーションチャネルは、開発者間のコラボレーションを促進します。

11. 計画済み

ソフトウェア開発だけに集中してしまいがちですが、あらゆるプロセス（特にソフトウェア開発）と同様に、特定の方法論が不可欠です。プロジェクトで開発方法論を採用し、そのプロセスに誰か（例えばプロジェクトリーダー）が関与していることを確認してください。計画を立てることで、開発者は自分が最も価値を提供できる領域を把握しやすくなり、採用者や拡張者がそれぞれの目標を達成しやすくなります（ひいては成功につながります）。オープンソースプロジェクトを他のソフトウェア開発プロジェクトと同様に扱ってください。

12. ブランド管理

プロジェクトにはブランドが存在します。プロジェクト名はプロジェクトのアイデンティティであり、プロジェクトロゴや製品名も同様です（オープンソースプロジェクトは多くの場合プロジェクト名を共有しますが、複数の製品を開発するプロジェクトもあります）。プロジェクトのブランドを商標として宣言し、登録を検討してください。商標使用ガイドラインを作成し、採用者がブランドの使用方法を理解できるようにしてください。これは、オープンソースソフトウェア財団との連携が付加価値をもたらす分野です。財団はコミュニティを代表してプロジェクトの商標を保有し、保護することができます。これにより、特定の個人や組織がオープンソースプロジェクトの名前を乗っ取るのを防ぐことができます。

13. 知的財産と著作権の管理

プロジェクトに提供されたコード、ドキュメント、その他の成果物は知的財産です。これらの知的財産の所有者は誰でしょうか？作成者が所有権を保持するのでしょうか、それとも他の組織に譲渡するのでしょうか？すべての貢献者がそれぞれの権利と責任を理解していることを確認してください。貢献者に開発者証明書（DCO）または貢献者ライセンス契約（CLA）に署名してもらうことを検討してください。ソースコードと通知には著作権表示が含まれていることを確認してください。

プロジェクト自体は著作権を保有する法人にはなり得ないことにご注意ください。これは、オープンソース財団が価値あるサービスを提供できるもう一つの分野です。

14. OSI 認定のオープンソース ライセンスを選択します。

独自のカスタムライセンスを作成しないでください。コードを使用する人にとって法的障害となる可能性があります。選択したライセンスが、コードの使用方法と互換性があることを確認してください。さらに、プロジェクトコードに必要なサードパーティコンテンツ（ライブラリなど）とも互換性があることを確認してください。すべてのソースファイルのヘッダーに、ライセンスのSPDXコードを含めてください。

15. プロジェクトをオープンソース財団に移行します。

財団については既に何度か触れてきました。まず、財団はプロジェクトのベンダー中立性を維持するのに役立ち、採用を促進します。オープンソースソフトウェアの魅力の多くは、採用者が特定の組織の監視を回避できる点にあります。財団は、プロジェクトの商標を擁護し、ガバナンスモデルを確立し、ブランド管理を支援し、知的財産管理サービスを提供し、オープンソースプロジェクトの成功に向けた共通の支援とアドバイスを提供することができます。オープンソース財団に加盟することで、貴重なフィードバックループを構築できます。財団はオープンソースプロジェクトの信頼性を高め、ひいては財団の信頼性を高めることができます。

オープンソースプロジェクトの運営には多くの作業が必要です。しかし、既に述べたように、必要な作業量は「成功するプロジェクト」の定義によって異なります。つまり、オープンソース開発の中核原則は、透明性、オープン性、そして実力主義です。他のすべては、これらから生まれます。