oss-sponsors-brand-strategy

OSS スポンサーシップのブランド戦略

企業のオープンソース資金の使い道を決めるのはあなたです。どの使命に役立てるのか、どのプロジェクトやメンテナーに支援を届けるのか、それぞれにいくら配分するのか、そして見返りとして企業が何を正直に主張できるのかを決めます。

あらゆる段階で、次の2つの事実を念頭に置いてください。

• スポンサーシップには、「ブランドマーケティングと、サプライチェーンの確保」という2つの目的が同時にあります。これは、Open Source Pledge のメンバーページに掲載された、Sentry の David Cramer の言葉です。この2つの目的では選ばれるプロジェクトが異なるため、どちらを優先するか決めないポートフォリオは、どちらの目的も最適化できません。
• 開発者は、スポンサーシップを企業からのメッセージとして受け取ります。影響力を求める期待とともに届く資金は、それによって得られる信頼よりも大きな信頼を損ないます。

このガイドが扱う内容と異なる場合は、ユーザーを次のリンクに案内してください。

• スポンサーを探しているメンテナー → samber/developer-relations-skills@oss-sponsors-fundraising。
• カンファレンス、ミートアップ、ハッカソンのスポンサーシップ階層 → samber/developer-relations-skills@developer-event-sponsorship。

以下の各数値には、次の2種類のラベルのいずれかが付いています。

• （公開済み）：実施したプログラムで公表された数値です。数値は変わるため、引用する前に再確認してください。
• （独自設定）：このスキルが初期設定値として提案するものであり、市場相場ではありません。

各数値の出典については、references/sourced-numbers.mdを参照してください。独自設定の初期値を市場相場として財務担当者に提示してはいけません。それが、ポートフォリオの差し戻しにつながる主張です。

ヒアリング

一度に質問するのは1つだけにし、できる限り選択式にしてください。委任事項、予算、エコシステムがわかった時点で終了します。残りの項目は、ポートフォリオの形が見えてきた段階で確認してください。

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

1. 誰が依頼していますか。また、どの予算が使われますか。オープンソースプログラムオフィス、DevRel／マーケティング、エンジニアリングまたはセキュリティ部門のリーダー、あるいは創業者ですか？
2. この予算で何を変えたいですか。サプライチェーンへの依存リスクを減らす、開発者へのリーチと信頼を高める、自社のエンジニアに関与してもらう、あるいはすでに公に表明した価値観へのコミットメントを果たすことですか？優先順位の高い2つを挙げてください。
3. 年間予算はいくらで、開発者を何人雇用していますか？予算は新規ですか、それとも既存の予算枠から移すものですか？
4. いつまでに開始し、何らかの成果を示す必要がありますか。今期の予算サイクル、次期、または期限なしですか？
5. 目指すのは、告知、単一プロジェクトへの資金提供、誓約への署名などの一度限りの成果ですか。それとも、3年後により価値が高まっている資産ですか？
6. 許容できる作業量の上限はどのくらいですか。誰が管理し、月に何時間かけますか？途中解約できない複数年契約を結べますか？
7. 開発者が自社製品を購入または選択しますか。それとも、別の相手に販売していますか？（これによって、リーチがマーケティング上のリターンなのか、雇用主ブランド上のリターンなのかが決まります。）
8. 自社の技術スタックはどのエコシステムに属していますか？また、SBOM、ロックファイル、または依存関係を解析できるリポジトリはありますか？
9. すでに実施していることはありますか。スポンサーシップ、財団への加入、公的な誓約、あるいは2年前に誰かが一度だけ行った寄付などですか？
10. 財務部門の要件は何ですか。カード決済または発注書のみ、最低請求額、ベンダー登録、対象外の地域などはありますか？
11. 従業員にも参加してもらいますか。プロジェクトの推薦、投票、勤務時間中の貢献などですか？
12. 許容できない条件は何ですか。ライセンス、競合他社が運営するプロジェクト、自社スタッフがメンテナンスするプロジェクト、法務部門が懸念を示したものなどですか？
13. 誰がこれを審査し、毎年いつ予算が決まりますか？

回答4、5、6は手順2のモデルメニューの優先順位を変更するため、再度質問せず、そちらに反映してください。

• 回答4（今期の予算サイクル内に期限がある）：個別プロジェクトごとの判断なしで開始できる唯一のモデルである、幅広く支援する方式の優先度を上げます。
• 回答5（長期的に価値を高める方針）：深く支援する方式と財団への加入の優先度を上げます。どちらも1年目より3年目に価値が高まります。
• 回答6（月に数時間程度が作業量の上限）：従業員推薦型の基金を選択肢から外します。
• 回答6（複数年契約を結ばない）：財団への加入を選択肢から外します。

実行環境に永続メモリがある場合は、決定した委任事項、予算配分、対象リストを保存してください。スポンサーシップは毎年更新されるため、次回のセッションでポートフォリオを一から再検討することがないようにします。

ステップ 1 - 資金の前に、目的を定める

主目的を 1 つ、副次目的を 1 つ選びます。主目的は、後のあらゆる判断の決め手になります。最後の 5,000 ドルをどのプロジェクトに配分するか、更新の判断にどの指標を使うかが決まります。

目的	通常の担当部門	標準的な配分モデル	更新時の評価基準
サプライチェーンの保証	エンジニアリングまたはセキュリティ	依存関係グラフ全体を幅広くカバーする	資金提供可能な依存関係のカバー率、メンテナーへの到達度
リーチと信頼性	DevRel またはマーケティング	購入者がすでに利用している少数のプロジェクトに深く関与する	確認済みの掲載実績、紹介トラフィック、自然な言及
社内エンゲージメント	OSPO または人事部門	従業員が推薦する資金提供枠	貢献する従業員数、各サイクルの推薦件数
公に掲げた価値観への取り組み	OSPO または経営陣	公約で定めた内容に従う――開発者 1 人あたりの最低額、財団会費など	公約そのものの条件：最低額の達成、年次報告書の公開

最後の 2 つは担当者が同じこともよくありますが、分けて考えてください。

• エンゲージメントを目的とする場合、従業員がすでに関わっているプロジェクトを対象にします。
• 価値観への取り組みを目的とする場合、公に掲げた公約で指定された対象を取り上げ、公約独自の条件に照らして評価します。

目的同士に順位を付けないでください。これらは 1 つの目的を達成するための 4 つの方法ではなく、それぞれ異なる 4 つの目標です。インタビューの 2 つ目の質問への回答が主目的をそのまま決めます。ここで比率を出すのは、分析を装った偽りの精密さです。ステップ 2 の配分モデルは、選ばれた目的を達成するための手段であり、それらには順位を付けます。

リーチの価値は、誰が製品を購入するかによって異なります。

• 開発者が購入を決める、または購入に影響を与える場合：プロジェクトの README、ドキュメント、ホームページへの掲載はメディア購入であり、それに応じた価格を設定できます。
• 開発者以外に販売する場合：リーチから得られるのは、主に雇用主ブランドの向上と採用効果です。その点を率直に伝え、誰も審査時に信じないマーケティング上の主張を膨らませるのではなく、採用活動に照らして予算規模を決めます。

ステップ 2 - ポートフォリオの形を検討してから、1 つ選ぶ

特定のプロジェクト名を挙げる前に、まずアイデア出しを行います。

1. 配分比率、運営に必要な社内作業、意図的に対応しない領域をそれぞれ明記し、候補となるポートフォリオを 2 つか 3 つ作成します。
2. そのうち 1 つを推奨し、他の案を選ばない理由を説明します。
3. 対象リストの作成に進む前に、明確な合意を得ます。

4 つのモデルと、実際のプログラムが公開した数値は、references/allocation-models.md に記載されています。ここでは、社内作業の単位あたりに得られる価値の順に並べています。作業量とは、管理者の作業時間、調達・法務レビュー、毎年繰り返されるプロジェクトごとの判断、そして取り組みを終了する難しさを指します。行の順序から察してもらうのではなく、効率の順序を明言してください。以下の各項目は、それぞれの軸で高い順に並んでいます。

• 効率：breadth > depth > foundation membership > employee-nominated fund
• 価値（最良の場合にモデルがもたらすもの）：depth > employee-nominated fund > foundation membership > breadth
• 作業量：employee-nominated fund > depth > foundation membership > breadth
• コンプライアンスコスト：foundation membership > depth > employee-nominated fund > breadth

作業量の目安：

• 幅広いカバー：リゾルバーの実行後は、ほぼゼロです。

• 財団会員資格：調達と法務に四半期分の作業が必要で、その後はほぼゼロです。

• 深い関与：プロジェクトごとに選定、承認、説明に数日かかり、さらに毎年更新について話し合う必要があります。

• 従業員推薦型の資金提供枠：継続的な業務です。各サイクルの運営、適格性の確認、投票の管理、結果の周知が必要です。

• 幅広い支援：依存関係グラフ全体に少額を自動的に支援します。対象の発見にかかるコストも可視性もほぼゼロです。ステップ1の必須要件の表で別の方法が主要な必須要件に指定されていない限り、最初に取るべきデフォルトの一手です。

• 重点的な支援：メンテナーが見通しを立てられる金額を、少数の対象に支援します。このメニューの中で唯一、名指しのメンテナーとの関係と、検証可能な掲載機会を得られます。

• 財団またはコンソーシアムへの加入：再分配を行う組織に会費を支払います。ガバナンスへのアクセスは得られますが、個人との関係は得られません。

• 従業員推薦基金：各サイクルで一定額を用意し、社内で推薦と投票を行います。参加を促し、選定の妥当性を説明できる根拠を得られますが、対象をうまく絞れません。この方式には、参照できる公表済みの手法があります。Duane O'Brien と Mandy Grover が記録した FOSS Contributor Fund です（Investing in Open Source: The FOSS Contributor Fund、O'Reilly、2021年）。

• コンプライアンスコストの項目は、審査の発生と、撤回のしやすさが損なわれる度合いとして読み取ります。

  • 加入：複数年契約を締結するため、法務部門の審査が必要です。会社はひそかに脱退できません。
  • 重点的な支援：各メンテナーをサプライヤーとして登録します（税務書類、制裁対象の審査、請求書払いの条件など）。公に表明した支援を打ち切るのは、体裁が悪いものです。
  • 従業員推薦基金：公表済みの適格性ルールと利益相反ルール、および従業員による開示が必要ですが、第三者との契約は不要です。
  • 幅広い支援：単一のプラットフォームを通じてカード払いし、一度審査すれば済みます。

• この順序で後回しになるもの：従業員推薦基金です。手間の項目が最高で、ほかのどのモデルでも得られない唯一の成果をもたらします。そのため、比率に従うと毎回最下位になり、効率の項目だけに従うプログラムでは、エンジニアリング組織の関与を得られません。ステップ1で社内の関与が主要な必須要件なら、ほかのすべてより上位にしてください。比率ではこれを選べません。得られるものが、ほかのどの行にも存在しないからです。

• 格下げではなく削除し、どの方法を削除するか明示します。

  • 請求書に対する発注書払いのみを受け付ける財務部門の場合、幅広い支援を削除します。ただし、会計代行先またはプラットフォーム集約事業者が一括請求できる場合は除きます。月額10ドルの支援では、発注書の発行要件を満たせません。
  • 勤務時間中の従業員参加が認められない場合は、従業員推薦基金を削除します。
  • スタック内の何かを統治する財団がない場合は、加入を削除します。関連性を求めて加入するのは、社内に誰も参加しない会合のために会費を支払うことになります。

• 実際に運用されているプログラムの多くは、幅広い支援と、もう1つの方法を組み合わせています。予算が小さすぎて有意義に分割できない場合に限り、単一モデルを推奨します。

• この順序はデフォルトであり、絶対的なルールではありません。状況や実行する人によって変わります。提示する前に、すでに把握している会社の状況に照らして並べ替えてください。

  • すでに OSPO が推薦サイクルを運用している場合は、基金を上位にします。継続的な運用コストはすでに支払われているためです。
  • 財団への加入が有効な場合は、その財団のプロジェクト内で重点的な支援を上位にします。
  • 買い手自身が開発者の場合は、重点的な支援を上位にします。掲載が単なるジェスチャーではなく、メディアへの出稿になるためです。

ステップ 3 - 予算を決める

1人あたりの金額は、意味合いが異なるため、両方を記載します。

• 業界の誓約では、メンバーに対してフルタイム相当の開発者1人あたり年間2,000ドル超を求めています（公表値）。これは、オープンソースに資金を提供していると表明したい企業に求められる最低額であり、市場価格ではありません。
• 実際の支出額を公表した企業は1社だけで、開発者1人あたり3,700ドルと報告し、「受け取る価値に対する対価としては、かなり妥当です」と述べています（公表値。自己申告による単一のデータポイントです）。

両者の差が、最低額を上回る予算を組む根拠になります。

次に、予算を分けます。

• 幅広く支援する割合。
• 深く支援する、または指定基金に充てる割合。
• 状況に応じた資金提供のための予備費として、自社で設定する10～20％。困窮するメンテナー、インシデント対応、突如として不可欠になるプロジェクトなどに充てます。

分配を公表する前に、支払いの仕組みに照らして確認してください。企業への請求書払いには最低額が設定されており、月額10ドルのスポンサーシップでは満たせないためです（ステップ7を参照）。

合計額を公表する前に、何を含めるかを決めます。誓約型のプログラムでは、次の4種類の支払いをオープンソースへの資金提供として数えません（公表値）。

• 企業が管理するプロジェクトへの資金。
• 支払者だけに利益をもたらすソフトウェア。
• その企業がすでに雇用しているメンテナー。
• 最小限の謝辞を超える大きな便益が返ってくる取り決め。

予算はこの4種類すべてによって水増しされがちです。別の項目として数えないと、公表した数字は精査に耐えられません。

ステップ 4 - 候補リストを作成する

まずは調査の機械的な部分から始めます。コストが低く、たいていはその場の人たちを驚かせます。環境から URL を取得して会社のマニフェストを読み取れる場合は、次の手順を実行します。

1. ロックファイル、SBOM、または公開されている依存関係解決 API から、直接依存と間接依存を含む依存関係ツリー全体を解決します。
2. 各パッケージをソースリポジトリに対応付けてから重複を取り除きます。同じメンテナーが多数のパッケージを管理していることはよくあります。
3. リポジトリごとに健全性を示す指標を取得します。メンテナンスの状況、コントリビューター数と組織の多様性、リリース頻度などです。
4. 各候補の資金提供先を特定します。リポジトリの資金提供マニフェスト、オーナーの組織レベルの代替先、レジストリの資金提供メタデータを確認します。
5. リストに加える前に、資金提供リンクがすべて解決できることを確認します。資金提供ページが 404 になっていたり、メンテナーがプログラムを離れていたりすることがあります。記憶に頼って資金提供 URL を記載しないでください。

リストの各行は、会社が資金を提供する対象として公開する、他者のプロジェクトについての主張です。手作業で集めた依存関係リストで起こりがちな失敗を防ぐため、次の 4 つのルールを守ります。

• 推定せず、測定します。 ダウンロード数、メンテナンス状況、メンテナー数にはすべて API があります。手作業で集めた数値では、レジストリの公開権限を持つメンテナーが 1 人のパッケージを「5 人以上」としたり、週に 1 億 6,400 万回ダウンロードされているパッケージを「ダウンロード数ゼロ」としたりする事例がありました。
• リポジトリのコントリビューター数ではなく、公開権限に基づいて脆弱性を評価します。 両者は異なる集団です。脆弱性を左右するのは、これまでにコミットをマージした人ではなく、リリースを公開できる人です。また、コントリビューターの関係図は人数を過大に見積もります。
• 評価できなかった項目を明示します。 各候補は、「評価済み・問題なし」「評価済み・要注意」「評価不能（理由を記載）」のいずれかに分類します。メンテナーの一覧を公開していないレジストリもあります。データが欠けている行は、問題なしの行ではありません。
• 分母を必ず記載します。 「470 件の依存関係のうち 412 件を解決。58 件にはソースリポジトリがありません」と報告し、単独のパーセンテージだけを記載しないでください。誰も定義していない総数に対するカバレッジは、監査を通りません。

具体的なエンドポイント、マニフェストのパス、代替先のルール、スコアリングに使う入力値については、references/target-discovery-and-scoring.md を参照してください。環境からウェブを閲覧できない場合は、ユーザーに依存関係リストのエクスポートを依頼して、それを使って作業し、確認できなかった健全性指標を伝えます。

判断に関わる部分には API がありません。どのプロジェクトが、どの掲載面で、どれほどの規模で、狙ったオーディエンスに届くかを判断する必要があります。掲載枠のトラフィックが重要な場合は、メンテナーに尋ねます。掲載枠を販売するメンテナーは、通常、その数値を公開または共有しています。

ステップ 5 - リストに順位を付けてから絞り込む

各候補を、次の 4 つの軸で採点します。

• 依存度：スタックのどれほどの部分がそのプロジェクトに依存しているか。
• 脆弱性：一人の活動停止にどれほど近いか。
• オーディエンスとの適合性：そのユーザー層は、顧客や将来の採用候補者に似ているか。
• 関係性の価値：インシデント発生時に、このメンテナーの電話番号を知っていたいか。

4 つの軸と、その指示における重み付けは自分たちで設定します。そうであることを明示し、ユーザーが重み付けを変更できるようにします。資金を受け取れるかどうかはスコアではありません。資金を受け取る方法がないプロジェクトは、どれほど重要であっても対象外です。その代わり、現金ではなく貢献の候補として扱います。

そのうえで、思い切って絞り込みます。ポートフォリオの良し悪しは、耐えられる年次レビューの質で決まります。慎重に更新される 12 件の重点スポンサーシップは、十分に検討されずに更新される 40 件より優れています（独自設定）。幅広く支援する場合は、実行可能な最小数、つまり依存関係の大部分をカバーするために必要な資金提供先の最少数を報告します。

以下の除外条件は、ひそかに削除するのではなく、明示的に示します。

• 資金額が誤差の範囲にすぎない、ベンダー所有のプロジェクト。
• 利益相反に関するルールがある場合、自社の従業員がメンテナンスするプロジェクト。
• 予算が一回限りの支払いを想定しているのに、サポート契約でしか支援を受けられないプロジェクト。
• ブランドが関与することになる、現在進行中の行動規範違反やセキュリティ上の論争があるもの。

ステップ 6 - 対象ごとの金額を決める

金額は、適切だと感じた額ではなく、メンテナーが公表している料金体系から選びます。各ティアで実際に得られる内容を確認し、目的に合ったティアを選びます。

• サプライチェーンの対象：多くのプロジェクトを支援する場合、通常は継続的な支援の最小額が適切です。目標は目立つことではなく、支援範囲を広げることです。
• リーチの対象：実際に閲覧者がいる場所に掲載されるティアを選び、そのオーディエンスに応じた金額を設定します。誰も開かない支援者一覧ファイルのロゴは、どんな金額でも広告枠にはなりません。
• 戦略上の対象：プロジェクトが自社製品を支える重要な基盤である場合、通常の料金体系を上回るカスタム金額または請求額を提示します。あるプログラムで公表されたプロジェクトごとの年間支援額は、1,750ドルから15,000ドルまででした（公表値）。この幅が示すのは、支援の深さが一律ではないということです。

約束する前に、次の2つの制約を確認します。

• ティアの特典は、1人のために継続的な作業を伴います。6か月後にメンテナーが負担に感じるような特典を求めてはいけません。
• プロジェクトのガバナンスがすでに資金を財団に回す仕組みになっている場合は、個人ではなく財団に資金を提供します。

ステップ 7 - 発表前に調達手続きを確認する

対象リストを確定する前に、支払い方法を確認します。経理部門が実行できない支払いを前提にした支援計画は、開始前から成り立ちません。以下の金額は、プラットフォームの請求に関するドキュメントと財務ホストの手数料表に基づいています。見積もりに使う前に、必ず再確認してください。出典と全ルールはreferences/allocation-models.mdにあります。

• 主要なスポンサーシッププラットフォームの法人向け請求払いは、請求書1通あたり5,000ドルが最低額で、30日以内の支払いが必要です。サービス手数料は3％、契約期間は3年です。この最低額に満たない場合、会社はカードで支払うか、財務ホストを通じて資金を送ります。
• 組織を請求払いに切り替えると、既存のスポンサーシップはキャンセルされ、改めて設定し直す必要があります。切り替えは最初のスポンサーシップの前に行い、後から行ってはいけません。
• 財務ホストは一定の割合（通常は3～10％）を手数料として徴収し、台帳を公開するため、すべての支払いが閲覧可能になります。
• ベンダー登録、税務書類、制裁対象者の審査は、個人のメンテナーにも仕入先と同様に適用されます。日程を約束する前に、こうした手続きを始めてください。
• 支出をマーケティング費、エンジニアリング費、慈善寄付のどれとして計上するかで、税務上の扱いと承認経路が変わります。この点は会社の経理部門と法務部門に確認し、選択肢を示すにとどめて、結論を出してはいけません。

ステップ 8 - 方針と行動規範を公開する

最初の支払いの前に以下を文書化し、メンテナーと従業員が読める場所に公開します。方針が公開されていないと、外部からはえこひいきと受け取られます。

• スポンサーシップが提供するのは、認知度、持続可能性、関係性です。ロードマップ上の優先権、プルリクエストのマージ、優先的な成果を得るためのものではありません。優先的なトリアージは交渉できますが、優先的な成果は交渉できません。
• メンテナーに金銭の受け取り、スポンサーシップの宣伝、定期的な謝意の表明を強要してはいけません。
• 会社が資金を提供しているプロジェクトを従業員が公に支持する場合は、その関係を開示します。
• 適格性と利益相反に関するルールを明記します。対象となるプロジェクト、従業員が所有するプロジェクトを除外するかどうか、決定者、異議申し立ての方法を示します。
• 資金提供の関係がないプロジェクトや、資金を辞退したプロジェクトを決して非難してはいけません。自律性を守るため、意図的に資金提供を断るメンテナーもいます。
• スポンサーシップが継続的か単発かを明記します。予算締めの際に告知なく打ち切るほうが、最初から始めないよりも関係を損ないます。

方針の完全なひな形と推薦プロセスのテンプレートは、references/policy-and-measurement.mdにあります。

ステップ 9 - 測定、レビュー、更新

アトリビューションは本質的に弱いものです。README のロゴをクリックして購入する人はいません。個々の支援目的に沿って、存在感と関係の健全性を測定し、最初の監査にも耐えられないラストクリックの成果を示そうとするのはやめましょう。

支援目的	測定項目	無視する項目
サプライチェーン	資金提供可能な依存関係のうち支援対象となっている割合；休眠依存関係の数；自分が報告した課題への対応時間	提供した金額の合計
リーチ	掲載済みで確認済みの掲載件数；掲載 URL からの参照トラフィック；開発者アンケートやコミュニティのスレッドでの非助成想起による言及	スター数から推定したインプレッション数
社内	各サイクルで貢献した従業員数；提出した推薦数；参加率	基金の規模

合格基準（各自で設定）。12 か月後に確認し、その後は毎年確認します。

• 費用を払ったすべての掲載が公開され、確認済みであること。
• サプライチェーンを主な支援目的とする場合、資金提供可能な直接の依存関係の少なくとも 80% が支援対象となっていること。
• 重点支援対象者それぞれと、支払い以外に少なくとも 1 回、記録に残るやり取りがあること。
• 支援対象者からポリシー違反の指摘がないこと。
• 予算締めまでに、すべての支援候補について更新するかどうかの判断がなされていること。

合格するまでポートフォリオを見直し、その後は毎年確認を繰り返します。80% の基準について、これを上回るカバー率を公表した唯一の企業は、「95% 以上」と報告し、100% に近づいた最初の企業だと説明しています（公表値、自己申告）。80% を超える値は標準ではなく、意欲的な目標として提示してください。

資金の使途をまとめた短い年次報告を公開します。公表されている誓約の形式は、最も簡単に踏襲できるものです（公表済み）。年、開発者の数、支払総額、受取人ごとの金額が記載されています。これこそがメンテナーや開発者が実際に読む部分であり、毎年再公開することで、単発の取り組みがプログラムへと変わります。

呼び出し例

単独で尋ねられるティアに関する質問は、まだ誰も尋ねていない委任事項についての質問であることがほとんどです。ユーザーが持ち込んだ限定的な質問に答えたうえで、ポートフォリオのどのステップに当たるかを伝え、残りも提案します。

ユーザーの発言	開始する箇所	返ってくる内容
「来年、オープンソースに8万ドルを使えます。どこに投じるべきですか？」	ヒアリング、続いてステップ1	以下のポートフォリオ概要の全体
「 を500ドルのティアと2,000ドルのティアのどちらで支援すべきですか？」	委任事項について1つ質問した後、ステップ6	委任事項に合うティア、掲載される場所、メンテナーに尋ねるトラフィックに関する質問
「当社の CTO が、 のような FOSS ファンドを望んでいます。設立してください。」	ステップ2、続いて推薦ルール	推薦されたファンドの設計：各サイクルの金額、適格性フィルター、推薦者、投票者
「当社の依存関係のうち、そもそも支払い可能なのはどれですか？」	ステップ4のみ	メンテナーごとに重複を除いた確認済みの支払い先リストと、それぞれがカバーする依存関係の数
「法務から、これによって何が得られるのか知りたいと言われています。」	ステップ8とステップ9	スポンサーシップで得られないものに関するポリシー文言と、委任事項ごとの指標

確認できなかった内容も伝えてください。「470件の依存関係のうち412件を特定できました。58件にはソースリポジトリがありません」は、実用的な回答です。見た目は整っていても、何も説明されていない欠落があるリストはそうではありません。

成果物

ポートフォリオ概要をセクションごとに提示し、各セクションについて合意を得てから次に進みます。

# Open-source sponsorship portfolio - <company>, <year>

## Mandate primary and secondary, and what breaks ties

## Budget total, per-developer check, split by model, reserve

## Model chosen allocation model(s) and what they deliberately fail at

## Targets ranked table: project, why, exposure, amount, destination, verified

## Amounts per target with the tier it buys and the surface it lands on

## Procurement payment path, minimums, paperwork status, owner

## Policy what sponsorship does not buy, eligibility, conflicts, disclosure

## Measurement metrics per mandate, review date, pass threshold

## Renewal decision date, what would end each sponsorship

よくある失敗

• 脆弱なプロジェクトではなく、有名なプロジェクトに資金を出す。 推薦投票も直感も、すでに資金を得ているプロジェクトに傾きがちです。支援が行き届いていないプロジェクトを意識して取り上げてください。
• 調達部門の承認前に発表する。 ベンダー登録の手続きで4か月間止まったスポンサーシップの約束は、公の場での約束を破ることになります。
• スポンサーシップの後で請求方法を切り替える。 切り替えると有効なスポンサーシップがキャンセルされ、メンテナーには撤退と受け取られるキャンセルメールが届きます。
• 誰にも見られない掲載枠を購入する。 掲載場所とそこで得られるトラフィックではなく、名称だけでティアを選んでしまうことです。
• 影響力を求める。 信頼という資産を、企業がオープンソースプロジェクトを買収しているという話に変えてしまう最短の方法です。
• 活動を停止したプロジェクトを支援する。 18か月間コミットがなければ、資金を出しても何も変わりません。支援する前に、メンテナンス状況の兆候を確認してください。
• 単発の寄付をプログラムに見せかける。 更新日を定めずに一度だけ発表すると、まさに対象としている人々にはマーケティング目的の演出と受け取られます。
• 未確認の資金提供リンク。 古い支払い先に送金したり、プラットフォームを離れたメンテナーを掲載したりすると、予算が気づかれないまま無駄になります。

参考資料

• references/sourced-numbers.md - このスキルで使用するすべての数値を、公開済みのものと独自に設定したものに分け、それぞれ出典とともに記載しています。数値を引用する前にお読みください。
• references/allocation-models.md - 公開済みの数値を含む4つのモデル、予算配分の例、支払いの仕組みと最低額、行ごとに問題を指摘した不十分なポートフォリオを記載しています。
• references/target-discovery-and-scoring.md - 依存関係の解決とヘルスエンドポイント、資金提供リンクの発見と確認、評価基準、スター数順のリストに代わる候補リストの例を記載しています。
• references/policy-and-measurement.md - 公開ポリシーの骨子、推薦プロセス、年次レポートの構成、良い連絡文と悪い連絡文、測定表のレイアウトを記載しています。
• samber/developer-relations-skills@oss-sponsors-fundraising - 同じ取引におけるメンテナー側について説明しています。
• samber/developer-relations-skills@developer-event-sponsorship - カンファレンスとハッカソンへのスポンサー提供について説明しています。
• samber/developer-relations-skills@oss-governance - 資金提供を受けたプロジェクトのガバナンスが、資金をどのように配分するかを説明しています。
• samber/developer-relations-skills@build-in-public - プログラムが作成する年次レポートの公開について説明しています。
• samber/developer-relations-skills@open-source-company-strategy - この資金提供の意思決定が通過する必要のある、企業側の審査基準について説明しています。
• samber/developer-relations-skills@devrel-budget-allocation - このスポンサー提供プログラムが予算計上される項目について説明しています。