oss-sponsors-fundraising

OSS スポンサー資金調達

オープンソースプロジェクトのスポンサーシッププログラムを設計します。誰に、いくらを、何の見返りに、どのプラットフォームを通じて依頼するのか、そしてメンテナーが2年後も提供を続けられるようにする方法を決めます。

以下は、以降のあらゆる判断の基礎となる調査結果です。

• 給与に相当する収入は個人ではなく企業から得られます。GitHubによると、2022年には「スポンサー資金の40％近くが組織から」寄せられました。Filippo Valsordaは、広く依存されているライブラリでも、個人スポンサーからの典型的な収入は月額1,000ドル未満だと測定しています。
• 提供を約束する報酬はすべて、すでに手いっぱいのメンテナーにとって継続的な作業になります。Tideliftの2020年の調査では、プロのメンテナーの46％、広く利用されているプロジェクトのメンテナーでは58％が燃え尽きを感じていました。

報酬を得ることは、プロジェクトができることも変えます。Tideliftの2024年のメンテナー調査（回答者400人以上）によると、メンテナーの60％は無報酬で、報酬を得ているメンテナーは、重要なセキュリティおよび保守の実践を導入する可能性が55％高いことが分かりました。出所を証明する署名付きリリースは50％対28％、二要素認証は76％対68％でした。メンテナーが金銭を求めるのは失礼だと感じているときは、この結果を活用してください。

こうした数値には、出典が本文中または参照ファイルに記載されています。baselineと記された数値は、このスキル独自の初期値であり、業界標準ではなく、議論の出発点として提示するものです。

資金提供先のプロジェクトとティアを選定している企業ユーザーの場合、これは適切な立場ではありません。samber/developer-relations-skills@oss-sponsors-brand-strategyを案内して、そこで終了してください。

インタビュー

一度に質問するのは1つだけにし、できる限り選択式にします。プロジェクト、目標金額、現実的な提供能力が分かったら、すぐに質問を終えます。残りのことは、設計しながら確認してください。

メモリ：現在のタスクやプロジェクトの状況について、いくつか情報を保存します。メモリをファイルに保存する場合は devrel-context.md を使います。別のメモリシステムを使っている場合は、そちらを利用してください。タスク情報はセクションを分けて記録します。完了したタスクは削除します。タスクには日付を追加し、一般的なプロジェクトの状況には日付を付けません。インタビューの回答は、タスクによって異なる場合があります。

1. どのプロジェクトですか。また、あなたの役割は何ですか――単独のメンテナー、チームの一員、または勤務時間中にプロジェクトを保守する会社員ですか？
2. 資金によって何を変えたいですか。作業時間を確保する、インフラ費用を賄う、特定の成果物に資金を充てる、または給与の代わりにする、のどれですか？概算でもよいので、月額を挙げてください。
3. その資金は、いつまでに入金される必要がありますか――今四半期中、今年中、それとも期限なしですか？
4. 一度きりの成果（資金提供を受けた成果物、カンファレンスへの出張、ハードウェアの請求額など）を望みますか。それとも、2年後も収益を生む複利的な資産を望みますか？
5. 実際に利用しているのは誰ですか――個人の開発者、プロジェクトを使って製品を開発する企業、またはその両方ですか？それをどのように確認していますか？
6. 依存している企業を3社挙げられますか？また、依存していると分かる根拠は何ですか？
7. すでに用意されているものは何ですか――GitHub Sponsors、Open Collective、Ko-fi、FUNDING.yml、それとも何もありませんか？
8. 労力の上限はどれくらいですか。調子の悪い月でも、スポンサー向けの作業に月何時間なら充てられますか。意気込みではなく、時間で答えてください。撤回できない約束に署名しますか？
9. 法人はありますか。それとも、個人として資金を受け取りますか？どの国ですか？
10. 管理している発信チャネルと、そのおおよその規模を教えてください。リポジトリのトラフィック、ドキュメントサイト、ニュースレター、SNSのフォロワー数、カンファレンスでの講演などです。
11. すでに商業的な要素はありますか――有料サポート、ホスト型製品、または成果物に権利を主張する雇用主などですか？
12. どんな条件でも売りたくないものは何ですか？

回答3、4、8は、ステップ2の選択肢の優先順位を変えます。質問し直すのではなく、そこで反映してください。

• Q3：今四半期中の期限がある場合、感謝と認知度向上の施策を優先します。完成前に支払いが得られるのは、これらの施策だけです。
• Q4：複利的な支援を求める場合、継続的な支援契約と認知度向上のための掲載を優先します。どちらもローンチ時の活動が終わった後も支払いが続きます。
• Q8：調子の悪い月に充てられるのが数時間程度の場合、アクセスプログラムを候補から除外します。
• Q8：撤回できない契約には署名しない場合、継続的な支援契約を候補から除外します。

回答を記録してください。実行環境に永続メモリがある場合は、作成したプログラム概要をそこに保存してください。一部のプラットフォームでは、ティアの価格が実質的に永久に固定されるため、後のセッションでティア構成を最初から設計し直さないようにします。

ステップ 1 - スポンサーシップがそもそも適切な手段かどうかを確認する

スポンサーシップは、opensource.guide 独自の一覧にある 5 つの資金調達手段の 1 つです。

• 雇用：オープンソースに費やす時間を職務に組み込むこと。
• 個人によるクラウドファンディング。
• プロジェクト単位の企業スポンサーシップ。
• 商業収益：サポート、ホスティング、プレミアム機能。
• 助成金。

個人スポンサーシップは、生活できる収入を得るまでの道のりとしても最も遅い手段です。上記の月額 1,000 ドル未満という数字は、多くの人に依存されているライブラリであっても、通常得られる金額です。

何かを設計する前に、次の点をはっきり伝えてください。

• Q2 = 「給与を置き換える」で、プロジェクトのユーザーが数百人程度の場合：雇用または商業的な有料プランを推奨し、スポンサーシップは補助的な手段とします。たとえこのスキルで構築するものとは異なっていてもです。
• Q2 = 週に 1 日分の時間を取り戻す、または経費をまかなう場合：スポンサーシップがよく適合します。

助成金も同様に検討してください。研究、インフラストラクチャ、セキュリティに関わるプロジェクトは、5 ドルのスポンサーを 100 人集めるよりも、助成金を早く獲得できることがよくあります。その場合は、ほかの作業と並行してステップ 1b を実施してください。

ここでは、効率を基準に 5 つの手段を相互に順位付けしないでください。順位付けすると、すでに質問 2 で決まっている選択に、実際以上の精密さを装うことになります。給与を置き換える目標なら、探すのにかかるコストにかかわらず雇用が最有力となり、インフラストラクチャやセキュリティに関わるなら助成金が最有力となります。このどちらの判断も、投入できる労力の水準によって変わりません。助成金の枠内にあるプログラムと、スポンサーシップの枠内にある形態については、順位付けします。

ステップ 1b - 助成金の枠を実行する

助成金は、スポンサーを拡大したものではありません。助成金は、最初に資格要件があり、その後に報告義務が伴う期間限定の契約です。終了日が定められ、実績の証明に基づいて支払われます。スポンサーシッププログラムと並行して運用し、決してその代わりにしてはいけません。

応募書類を書く前に適格性を確認します。応募を退ける理由として、文章の弱さよりも多いのが次の4つのゲートです。インタビューの回答9で、そのうち2つはすでに確認できます。

• ライセンス。 どのプログラムも、認められたオープンソースライセンスを求めており、いくつかはドキュメントや研究成果にも適用を求めます。
• 報酬の受取対象。 個人との契約を認めるプログラムもあれば、法人を必要とするものもあり、組織にのみ支払い、プロジェクトに組織がない場合は財政スポンサーを期待するものもあります。
• 地域。 制限の対象はコードではなく受取人です。居住地の優先条件、国内の税務上の居住資格、制裁対象の除外などがあります。
• 成熟度と範囲。 インフラ助成金は依存先のあるライブラリを求め、プロトタイプは対象外とします。プロトタイプ向け助成金は新しい取り組みを求め、科学助成金はその分野での実証済みの利用を求めます。

プログラムは、応募とコンプライアンス対応にかける時間あたりの獲得金額で順位付けします。5つの種類があります。個人に支払う直接助成金、コホート型のセキュリティ助成金、インフラ向けの政府機関助成金、国内のイノベーション助成金、財団の科学研究助成金です。

• 効率：direct > cohort > agency > national > foundation
• 価値（1件あたりの助成金額）：foundation > agency > national > direct > cohort
• 労力：foundation > national > agency > direct > cohort - 財団は関心表明書、招待制の提案書、機関の署名を求めます。政府機関は応募から契約まで数か月かかります。直接助成金はフォーム1つで済みます
• コンプライアンスコスト：national > foundation > agency > cohort > direct

この順序では、何が後回しになるでしょうか。人件費を特定の担当者分として複数年にわたり助成する唯一の選択肢である、財団助成金です。プロジェクトにすでに受け入れ機関または財政スポンサーがある場合は優先し、どちらもない場合は候補から外します。

スポンサー向けのページではなく、審査委員会に向けて書きます。ステップ5では、すでにプロジェクトを気に入っている読者にメンテナーの信頼性を伝えます。一方、提案書は、1回の審査で多数の提案を読む審査員が、公開されている基準に照らして評価します。

• ストーリーではなく、依存先から書き始めます。普及度、重要性、プロジェクトが停止した場合に影響を受ける対象は、評価基準です。
• 作業時間を明示した単価で見積もり、その時間を、対価の支払い対象として受け入れられるマイルストーンに割り当てます。実際にその内容に基づいて支払いを受けるからです。
• 「既存のものではなぜ不十分か」に明確に答えます。応募フォームで直接尋ねられており、回答がなければ、周辺状況を調査していないと受け取られます。

受諾する前に報告計画を立てます。スポンサーは感謝の投稿があれば更新し、その後は静かに離れていきます。一方、助成機関は、定められたスケジュールに沿った報告書が提出されないと支払いを保留し、未使用分を返還させます。質問8で設定した労力の上限に、その事務作業分も計上します。

プログラムごとのゲート、応募項目、評価基準、採択後の義務、および現在は応募を受け付けていないプログラムについては、references/grant-programs-and-reporting.md を参照してください。ユーザーにプログラム名を伝える前に、必ず読んでください。

ステップ 2 - プログラムの形を検討し、1つ選ぶ

ブレインストーミングを始めます。提示された数値を達成できる候補プログラムを2つか3つ考え、そのうち1つを推奨し、他の案が劣る理由を説明します。料金の話を始める前に、明確な合意を得てください。

4つの形は、メンテナーの労力単位あたりに得られる価値の高い順に並んでいます。ここでいう労力とは、継続的に必要となるメンテナーの作業時間、終わりのない義務、公開した約束を撤回する難しさです。行の並び順に任せず、効率の順序を明示して述べてください。評価軸ごとに順序が異なるため、すべて確認してください。各行は、その評価軸で高い順に並んでいます。

• 効率性：可視性 > 感謝 > リテイナー > アクセス
• 価値（その形で得られる月収）：リテイナー > アクセス > 可視性 > 感謝 - 配置によるトラフィックが月間数万ビューに達する場合は、可視性がアクセスを上回ります
• 労力：アクセス > リテイナー > 可視性 > 感謝
• コンプライアンスコスト：リテイナー > 可視性 > アクセス == 感謝

労力の規模：

• 感謝：ページができれば、ほぼゼロです。

• 可視性：スポンサー1社につき、ロゴのコミットと掲載確認に約1時間です。

• アクセスとリテイナー：どちらも継続的な作業です。

• 可視性プログラム。 README、ドキュメントサイト、ホームページなど、実際の掲載場所へのトラフィックに基づいて企業向けのティアを設定します。ロゴをコミットして掲載し、収入はプロジェクトが実際に獲得しているオーディエンスに応じて増えます。ドキュメントやREADMEに測定可能なトラフィックがある場合、最初に選ぶ基本の形です。

• 感謝プログラム。 低額のティアで特典はなく、明確なお願いを1つだけします。小口のユーザーが多く、メンテナーに余分な時間がないプロジェクトに適しており、ほかのどの形を選ぶ場合もその土台となります。

• リテイナープログラム。 依存する少数の企業が、明示されたコミットメント（応答時間、セキュリティのトリアージ、アップグレードのサポート）に対して支払います。スポンサーは最少ですが、契約額は最大で、義務も最も大きくなります。

• アクセスプログラム。 スポンサー限定コンテンツ、先行アクセス、またはスポンサーウェアを提供します。これまでに記録された中で最も実績のある転換手段であり、継続的なコストも最も高くなります。メンテナンスの仕事にコンテンツビジネスを付け加える形です。すでにオーディエンスがいる場合に限って適しています。

• 2つの継続的な作業は、その発生頻度で分けます。アクセスでは、誰からも求められていなくてもコンテンツを公開し続けます。一方、リテイナーの作業は、依存する企業が時折必要としたときに発生します。そのため、契約額が大きいにもかかわらず、必要な時間が少なく、順位も上になります。

• コンプライアンスコストが同率である理由を説明します。アクセスも感謝も、特定の企業へのコミットメントや、プロジェクトの各所への第三者ブランドの掲載を伴いません。また、どちらも1回のコミットで新規スポンサーの受付を停止できます。

• リテイナーがコンプライアンスコストの項目で最上位になる理由は、法人、番号付き請求書、税務処理、そして破棄するコストが高い書面によるコミットメントが必要だからです。可視性は2番目です。GitHub Sponsorsで公開した価格はそのまま残り、スポンサーのロゴを掲載する場合は、最初のロゴを掲載する前にステップ8の拒否ルールが必要です。

• この順位によって後回しにされるものは、リテイナーです。給与に相当する収入に届く唯一の形であり、実際の提供義務を伴う唯一の形でもあるため、価値とコンプライアンスコストの両方で最上位になりますが、比率によって毎回後回しにされます。効率性の項目だけに従い続けるメンテナーは、いつまでもコーヒー代程度の収入にとどまります。

• 質問2への回答が「給与を置き換える」だった場合、名前を挙げられる依存企業が3社ある場合、そして法人または財政スポンサーがすでに存在する場合は、リテイナーを最優先にします。

• 順位を下げるのではなく、削除し、その理由を伝えます。

  • 法人がなく、財政スポンサーを利用する意思もない場合は、リテイナーを削除します。
  • リポジトリ以外にオーディエンスがない（ドキュメントのトラフィック、ニュースレター、登壇機会がない）場合は、アクセスを削除します。
  • READMEやドキュメントに測定可能なトラフィックがない場合は、可視性プログラムを削除します。測定できない掲載枠には価格を付けられないためです。

• 実際に機能しているプログラムの多くは、感謝を土台にほかの形を1つ組み合わせています。メンテナーが両方を運用できる場合に限り、組み合わせを勧めます。

• この順位は基本形であり、絶対的なルールではありません。状況や、実行する人によって変わります。

• 提示する前に、すでに把握しているメンテナーの事情に照らして順位を見直します。

  • 既存のニュースレターやカンファレンスのオーディエンスがある場合は、アクセスを上位にします。配信基盤がすでに整っているためです。
  • すでに雇用主が作業に対して支払っている場合は、リテイナーの前提がなくなります。
  • 3人のチームなら、単独のメンテナーでは削除せざるを得ない形でも運用できます。

ステップ 3 - 2 種類の支援者向けに段階を設計する

段階設計では、行動がまったく異なる 2 種類の支援者を想定します。

• 個人は自分のお金から 5〜25 ドルを支払い、数秒で決断し、感謝の気持ちや個人的な特典を求めます。
• 企業は予算項目から支払い、請求書と受益者の氏名が必要で、決裁者が説明できるメリットを求めます。

参照ファイルにあるプレースメント販売の段階設計（Vue、Sindre Sorhus）では、個人と企業の境界は月額 100 ドル前後です。この分岐を基準として扱い、読者の反応が異なる場合は調整してください。

段階設計の大部分は、次のルールで決まります。最初の 4 つは参照ファイルに掲載された段階設計に基づき、最後の 2 つは GitHub のドキュメントに基づいています。

• 企業向けのプレースメント料金は、気前のよさではなく、リーチするオーディエンスに応じて設定します。「月間 2 万ビューの README にロゴを掲載」は、決裁者が承認できるメディア購入ですが、「ゴールドスポンサー」ではそうはいきません。Sindre Sorhus はプレースメントごとの月間ビュー数を公開し、それを基準に料金を設定しています。
• 購入者に合わせて段階の名前を付けます。「The Agency」や「Team」なら企業は自分たち向けの段階だと分かりますが、「Platinum」では推測が必要です。これは、段階を試した Caleb Porzio 自身の結論です。
• 成約する段階のすぐ下に、中途半端な特典の段階を置かないでください。「月額 1〜5 ドルを支払う選択肢が月額 14 ドル超の代わりにあれば、人々はより安い方を選ぶでしょう」（Porzio）。特典付きの段階より下に、特典なしで感謝を示す段階を設けるのは問題なく、むしろ有用です。
• **1 つの段階がプログラムの中心になると想定してください。**記録されている個人向けの段階設計ではどちらも、1 つの段階が成約を牽引し、その他の段階がその上下でより多くの支援を受け止めています。
• **公開した料金は変更できないものとして扱ってください。**GitHub Sponsors では、公開済みの段階の料金は編集できません。廃止して置き換えることしかできず、既存のスポンサーは旧段階に残ります。2 年後の価格を想定して設定してください。プラットフォームの上限は月額 12,000 ドルです。
• 段階は短くまとめてください。公開中の段階は 3〜5 個を基準とします。プラットフォームでは月額の段階を最大 10 個まで公開できますが、10 個も読む人はいません。

Vue、Sindre Sorhus、Caleb Porzio の参考段階設計と料金、具体的な特典は、references/tier-ladder-examples.md にあります。うまくいかない段階設計と、その理由も含まれています。プラットフォームの制限、手数料、支払い、FUNDING.yml の仕組みについては references/platform-mechanics.md を参照してください。料金やプラットフォームを決める前に読んでください。

ステップ 4 - 魅力ではなく、提供にかかるコストに照らして各特典を規模設定する

各特典について、スポンサー数が現在の10倍になったとき、毎月いくらかかるかを考えます。10倍という倍率は、測定された成長率ではなく、基準となるストレステストです。成果につながる特典は、まさに二つ目の仕事になりかねないものだからです。

特典の評価順は、形状と同じく、スポンサーが得るものと提供を継続するコストの比較で決まります。

• 効率：README またはドキュメントへの掲載 > スポンサーバッジとお礼の投稿 > リリースの先行アクセス > プライベートリポジトリまたは四半期ごとのオフィスアワー > 月次通話、優先サポート、個別対応

• 価値（企業が契約し、更新する理由）：月次通話と優先サポート > プライベートリポジトリまたはオフィスアワー > 先行アクセス > 掲載 > バッジとお礼の投稿。個人スポンサーの場合、バッジとお礼が購入のすべてなので、先行アクセスより下ではこの順序が逆転します。

• 労力：以下の3つの区分を、規模の大きさ順に示します。

• ほぼゼロで安全： BACKERS.mdへの名前またはロゴの掲載、README またはドキュメントへの掲載、お礼の投稿、スポンサーバッジ。

• 限定的だが実際に発生： ティアごとのプライベートリポジトリ、四半期ごとのオフィスアワー、リリースの先行アクセス。

• 二つ目の仕事： 月次通話、優先サポートの約束、スポンサーごとのコンテンツ、個別のインテグレーション。

この順序によって除外されるのは、最後の区分にある明示的な約束です。企業が継続契約料を支払うのは、これらの特典だけです。これらをティア特典に組み込まず、ティアの枠組みから完全に切り離し、価格を負担に見合うものにできるステップ7で販売してください。

10倍テストに合格しない特典は削除してください。スポンサー限定コンテンツやスポンサウェア、スポンサーへの先行リリース、公開済みの基準に達した時点でのオープンソース化は、記録上もっとも成果につながる特典である一方、提供し続けるコストがもっとも高いものです。仕組み、リリース開始条件のルール、そして決して制限してはならないもの（セキュリティ修正、コアライブラリ、利用に必要なドキュメント）については、references/tier-ladder-examples.mdを参照してください。

ステップ 5 - 範囲を限定した約束として支援を呼びかける

「活動を支援してください」では、具体的な依頼になりません。5ドルのスポンサーから助成金審査委員会まで、すべての資金提供者が同じ5つの質問に答えます（opensource.guide のリスト）。

• プロジェクトが重要な理由。
• その実績を証明する利用状況。
• 他の選択肢ではなく、このプロジェクトに資金を提供する理由。
• 資金で実現できること。
• 法的にどのように支出できるか。

目標を、読者が理解できる単位に置き換えます。週1日のメンテナンス、CI とコード署名の費用、納期を明記した成果物などです。第1の資金調達目標は、今四半期中に達成できる水準に設定してください。達成済みの目標は、1年間4％のまま停滞する野心的な目標より価値があります。

目標の種類は慎重に選んでください。

• スポンサー数を目標にすると、収入を非公開にできます。
• 金額を目標にすると、月次収益が恒久的に公開され、後から取り下げることはできません。

ユーザーが活動を公開しながら進めている場合は、2つの方針に一貫性を持たせてください。

ページはメンテナー自身の言葉で書き、その後、好みのヒューマナイザーのスキルに通してください。スポンサーはメンテナーの信頼性に投資するので、キャンペーンの文面はその信頼性を消費します。

ステップ 6 - 支援の申し出を避けられないものにし、プロジェクトを機械で見つけられるようにする

スポンサーシップによる資金は 3 つの経路から届きます。それぞれに固有の設定が必要で、かかる手間に対する価値も異なります。

• 効率：FUNDING.yml とマニフェストの funding メタデータ > ユーザーが普段利用する場所にある支援リンク > 資金提供者の候補リストに残る健全性シグナル
• 価値（その経路からプロジェクトに振り向けられる金額）：健全性シグナル > 支援リンク > FUNDING.yml
• 労力：健全性シグナル > 支援リンク > FUNDING.yml - Scorecard 主導の整理には数週間かかります。リンクは 1 時間、ファイルの作成はほぼ手間がかかりません。

まず、最初の 2 つをこの順番で実施してください。この順序で後回しになるのは健全性シグナルへの取り組みです。企業ファンドや財団プログラムが資金配分前に実際に確認するのはこのシグナルです。そうしたプログラムを明確な対象とする場合は、こちらを優先し、このセクションの残りをその前提条件として扱ってください。

• 人々が目にする支援の申し出。 ユーザーがすでに利用しているあらゆる場所から 2 クリック以内に支援リンクを配置します。リポジトリのスポンサー用ボタン、README、ドキュメントのフッター、リリースノート、適切な場合は CLI やエラー出力などです。誰も訪れないページからは、誰も支援につながりません。
• 資金提供者が確認する依存関係グラフ。 洗練された資金提供者は、依存関係ツリー全体に自動で資金を配分します。Sentry の 500,000 ドルのプログラムは、資金提供対象となる依存関係の「95％以上をカバー」し、対象の多くにとって「おそらく最初で唯一のスポンサー」となりました。このスキャンで見つけてもらうために必要なのは、.github/FUNDING.yml という 1 つのファイルと、エコシステムがサポートしている場合はパッケージマニフェストの支援メタデータです。
• プログラムが作成する候補リスト。 企業ファンドは、人が確認する前に、機械可読な健全性データを使って候補を順位付けします。OpenSSF Scorecard、Criticality Score、依存プロジェクト数、コントリビューターの多様性などが対象です。支援リンクがない、または機能していない場合、この段階では低スコアになるのではなく、厳しいフィルターにかけられます。支援を受けられないプロジェクトは、重要度にかかわらず候補から外されます。

すべての支援リンクが正しく開くことを確認し、組織レベルの代替リンク（{owner}/.github）が古いリンク先を指していないことも確認してください。スポンサーシップのリンク切れはよくあり、気づかれないまま資金調達経路全体を失わせます。

スキャナーが読み取るシグナル、従業員の推薦が必要なファンドの参加資格、そしてそれらを確認するための自己監査については、references/funder-scan-and-eligibility.md を参照してください。FUNDING.yml のキーと構文については、references/platform-mechanics.md を参照してください。

ステップ 7 - 企業向けの経路を開く

個人向けの支援ティアでは給与に相当する金額には届きません。届かせてくれるのは、そのプロジェクトに依存する企業です。この経路は、単に大きなティアを設けることとは異なる取り組みです。

企業は 4 つの仕組みを通じて資金を提供します。それぞれ獲得方法が異なります。

• 依存関係に応じた自動配分：見つけてもらえるようにすることで獲得します。これはステップ 6 ですでに対応しています。
• 判断に基づく戦略的スポンサーシップ：その企業の製品にとってプロジェクトが不可欠であると、目に見える形で示すことで獲得します。
• 従業員推薦型ファンド：すでにあなたに課題を報告しているエンジニアから推薦を受けて獲得します。
• 財団への加盟またはプレッジ会員：売り込むのではなく、財団の資金提供先になることで獲得します。

アウトリーチで獲得できるのは 2 番目だけです。誰かに連絡する前に、どれを目指すのか把握してください。

• 効率：依存関係に応じた自動配分 > 従業員推薦型ファンド > 戦略的スポンサーシップ > 財団への加盟
• 価値（獲得した企業 1 社あたりの小切手の金額）：戦略的スポンサーシップ > 財団への加盟 > 従業員推薦型ファンド > 依存関係に応じた自動配分
• 労力：財団への加盟 > 戦略的スポンサーシップ > 従業員推薦型ファンド > 依存関係に応じた自動配分 - 加盟手続きには 1 四半期以上かかり、戦略的な提案には対象 1 社あたり数日、推薦はすでにあなたを知っているエンジニアにメッセージを 1 件送るだけ、依存関係に応じた自動配分はステップ 6 で作成した、ほぼ手間のかからないファイルだけで実現します。

戦略的スポンサーシップは、ステップ 2 の順位付けで後回しになるタイプと同じで、さらに一段下の階層にあります。継続契約規模の小切手が得られるのはこの経路ですが、効率を優先すると毎回埋もれてしまいます。対象 1 社あたり数日を費やすのは、その製品がプロジェクトに目に見えて依存している企業に限ってください。 メカニズムとその金額については、references/corporate-sponsorship-path.md を参照してください。

2つ目のメカニズムについて、次の手順でアウトリーチを実施します。

1. 依存関係グラフ、公開リポジトリ、その技術名を挙げた求人情報、企業のドメインから投稿されたイシューをもとに、依存している企業を特定します。
2. 予算を持ち、リスクにさらされている担当者に連絡します。プラットフォームリード、スタッフエンジニア、セキュリティ責任者などが対象です。一般的な連絡先には送らないでください。
3. すでに存在する予算項目に結び付けて依頼します。サプライチェーンセキュリティ、マーケティングリーチ、エンジニアリング支援などです。Open Source Pledge のメンバーは、雇用する開発者1人あたり年間2,000ドル超を拠出することを約束しており、その資金は明確な受益者を探しています。
4. 善意ではなく、明示された約束を売り込みます。Valsorda が挙げる、企業が実際に購入するものは次のとおりです。
   • 二要素認証と必須のコードレビュー。
   • エコシステムの変化に対応したアップデート。
   • 信頼できるレビューとマージのスケジュール。
   • 投稿されたイシューへのサポート。
   • セキュリティ報告の慎重な取り扱い。
   • 「後継者計画さえも」。
5. 提案する前に調達要件を確認します。処理されるのは、法人、税務書類、番号付きの請求書、銀行口座情報であり、寄付ボタンではありません。GitHub 経由の請求書によるスポンサーシップは、請求書1通につき最低5,000ドルです。そのため、それより少額の依頼は財政ホスト経由にします。
6. 更新を計画します。予算は年単位なので、期間の途中で価値を証明するメモを送ることも、プログラムの一部であり、単なる好意ではありません。

今日機能するかどうかだけでなく、支払い経路が将来も維持できるかを確認してください。財政ホスト自体も継続性のリスクです。Open Collective Foundation が2024年に解散した際、600を超えるコレクティブには資金を移すための期間が7か月しかありませんでした。

複数のメンテナーが資金を共有する場合は、最初の支払いが入る前に、誰が支出を承認するかを決めてください。また、「運営を続けるための報酬」と「方針を決めるための報酬」を分けます。Django Software Foundation が、トリアージや管理業務を担当するフェローシップに資金を提供しているのは、まさにそのためです。財政ホストの公開台帳には各メンテナーの報酬も公開されます。選ぶ前に、その点を伝えてください。

アウトリーチ用テンプレート、1ページの提案書の構成、支払い可能かを確認するチェックリストについては、references/corporate-sponsorship-path.md を参照してください。法人とホストの継続性に関する詳細は references/funder-scan-and-eligibility.md にあります。法人／財団の選択については、samber/developer-relations-skills@oss-governance に委ねます。

ステップ8 - 資金で買えないものを明記する

最初のスポンサーが参加する前に、階層とともに次の境界を公開してください。

• スポンサーシップで得られるのは、認知度、謝意、明示された約束であり、ロードマップの決定権やプルリクエストのマージではありません。投稿者が資金を支払っているかどうかにかかわらず、コントリビューションは技術的な価値に基づいて評価します。
• 優先的な トリアージ は販売できますが、優先的な 結果 は販売できません。
• スポンサー一覧、ロードマップ、レビュー待ち一覧は、それぞれ別の成果物として管理します。
• 自律性を守るために資金を断るメンテナーの判断は、正当な選択であり、間違いではありません。

利益相反に関するルールも今のうちに明示してください。どのスポンサーを断るのか、誰が判断するのかを示します。

ステップ 9 - 拍手ではなくプログラムを測定する

質問	指標	無視するもの
成長していますか？	月次の継続収入、6 か月間の推移	調達額の累計
誰が支払っていますか？	個人と企業に分けたスポンサー数	スター、フォロワー
継続可能ですか？	月次解約率、中央値のティア、上位スポンサーからの収入の割合	単発の急増
呼びかけは機能していますか？	資金提供リンクを掲載した各場所からのコンバージョン率	ページビュー
約束は守られましたか？	資金提供の約束が期限どおりに実施されたか、特典が届けられたか	お礼の返信

合格基準（自分で設定）：90 日後に確認し、その後は四半期ごとに確認します。

• 月次の継続収入が前四半期と比べて増加している。
• 公開したすべての特典が期限どおりに届けられている。
• 1 社のスポンサーが収入の 50% を超えていない。
• プロジェクトに依存する企業がある場合、企業向けティアに少なくとも 1 社が加入している。

50% という基準は、オープンソースの資金調達基準ではなく、フリーランスの顧客集中度に関する慣行に由来します。ユーザーがこれをルールとして扱っている場合は、そのことを伝えてください。この基準を満たさない場合は、成長する前に解消すべき集中リスクがあります。4 つ目の条件を満たさない場合は、ステップ 7 の企業向けの選択肢が実質的に用意されていなかったことを意味します。

呼びかけがどこで失敗しているかを見て、収入の問題を診断します。

• トラフィックは伸びているのに収入が横ばい：呼びかけの掲載場所が適切ではありません（ステップ 6）。
• あらゆる場所で呼びかけているのに収入が横ばい：購入者にとって特典が適切ではありません（ステップ 3～4）。

呼び出し例

よくある依頼と、それぞれのワークフロー上の開始地点：

• 「月間ダウンロード数が 90 万件の Rust クレートを保守していますが、資金提供ページがありません。どう設定すればよいですか？」 → ヒアリングを行い、ステップ 1～6 を順番に進めます。依存している企業を特定できるまでは、ステップ 7 は保留します。
• 「資金提供を受けているスタートアップが 3 社、私たちのライブラリを使っているのに、誰もスポンサーになってくれません。」 → まずステップ 6 と 7 を進めます。利用実績が証明されていて収入がゼロの場合、段階設計が問題であることはまれです。通常は、見つけやすさと企業向けティアの不在が問題です。
• 「新しい CLI を 1 か月間、スポンサー限定で先行公開すべきでしょうか？」 → ステップ 4 に進み、その後 references/tier-ladder-examples.md のスポンサーワーウェアのルールを確認します。
• 「ティアを見直してください。最上位のティアが 50 ドルです。」 → ステップ 3 に進み、references/tier-ladder-examples.md にある弱い段階設計とその診断に照らして確認します。
• 「スポンサーから、特定の課題を優先してほしいと言われています。」 → ステップ 8 に進み、次のティアを公開する前に境界線を明示します。

成果物

プログラム概要を作成し、各セクションについて合意を得てから次のセクションに進みます。

# Sponsorship program - <project>

## Goal monthly target, what it buys, by when

## Instrument fit why sponsorship, and what else was recommended

## Audience individual vs company mix, named dependent companies

## Ladder tiers, prices, rewards, delivery cost per reward

## Platform where money is received, fees, entity, payout path

## Ask page copy, funding goal and type, surfaces carrying the link

## Corporate lane target list, contact, pitch, paperwork status

## Boundaries what sponsorship does not buy, refusal rules

## Measurement metrics, review date, pass threshold

よくある失敗パターン

• 後悔するような価格を公開する。 メインのプラットフォームでは変更できません。最上位のティアを 10 ドルにすると、そのティアを終了して置き換えるまでプログラムの上限になってしまいます。
• 個人向けの段階設計しかない。 収入の柱は企業向けティアです。存在しないティアを企業が購入することはできません。
• 保守担当者の負担が増えすぎる特典。 スポンサーが 12 人なら月次の通話も楽しいものですが、120 人になるとプログラムを終わらせることになります。
• スポンサーがたどり着けないスポンサーシップページ。 スポンサーボタンも、README のリンクも、FUNDING.yml もありません。その結果、人間にも依存関係グラフを使って資金提供先を探す人にも見つけてもらえません。
• ロードマップへの影響力を売る。 最も早く成果につながりますが、中立性を損ない、ほかのすべてのユーザーからレビュー待ちのキューへの信頼を失います。
• いつまでも変わらない目標。 最初の目標が達成不能だと、誰も支援していないプロジェクトのように見えます。今四半期中に達成できる目標を設定してください。
• プロジェクトそのものを有料化する。 利便性を対象にしたスポンサーワーウェアは問題ありませんが、ライブラリ本体、セキュリティ修正、ドキュメントにペイウォールを設けるのは、ここまで支えてくれたユーザーへのライセンス上の裏切りに近い行為です。
• 資金を受け取った後に沈黙する。 スポンサーは実績を見て更新します。何も発信しない四半期は、スポンサーシップの解約につながります。

参考資料

• references/platform-mechanics.md - ティアと目標額の上限、手数料、請求時の最低額、FUNDING.yml のキー、財政的ホスティング、依存関係への資金提供プラットフォーム。
• references/tier-ladder-examples.md - 価格と特典を設定した実例のティア構成3つ、弱いティア構成とその分析、スポンサウェアのルール、記入済みの例。
• references/corporate-sponsorship-path.md - 4つの資金調達手段、対象企業の特定、営業メール（弱い例と強い例）、提案書の構成、支払い可能性のチェックリスト、更新時のメモ。
• references/funder-scan-and-eligibility.md - 資金提供者のツールが読み取る健全性と支払い可能性のシグナル、従業員推薦枠の適格性ルール、法人と財政的ホストの継続性リスク、自己監査の手順。
• references/grant-programs-and-reporting.md - 各助成プログラムの適格条件と公表されている助成額、申請書で繰り返し尋ねられる項目、公表済みの評価基準、採択後の報告義務、終了したプログラム。
• 公開収益目標を掲げることで約束する透明性の実践については、samber/developer-relations-skills@build-in-public を参照してください。
• 呼びかけと競合する README のスペースについては、samber/developer-relations-skills@readme-optimization を参照してください。
• 可視性ティアの価格設定の基準となるオーディエンスの拡大については、samber/developer-relations-skills@oss-distribution-strategy を参照してください。
• スポンサー収入だけで収益モデルの代わりになるかどうかについては、samber/developer-relations-skills@devtools-business-model を参照してください。
• スポンサー収入が給与に届かない場合に、メンテナーが代わりに販売できるもの（有料アドオン、サポート、コンテンツ、ライセンス変更）については、samber/developer-relations-skills@oss-monetization を参照してください。
• 問題の本質がメンテナーの負担にあり、資金だけでは軽減できない場合については、samber/developer-relations-skills@oss-maintainer-sustainability を参照してください。