oss-sponsors-brand-strategy

OSS 赞助品牌策略

由你决定公司的开源资金流向：资金服务于什么目标、哪些项目和维护者会获得资助、每个对象获得多少，以及公司可以据此诚实地宣称什么。

每一步都要牢记以下两点：

• 赞助同时带来两方面的回报：Sentry 的 David Cramer 在 Open Source Pledge 成员页面上将其称为“品牌营销，以及保障我们的供应链”。这两项目标会选出不同的项目，因此，始终不确定优先目标的投资组合两者都无法优化。
• 开发者群体会把赞助视为公司发出的信号。附带影响力诉求的资金，损失的信任比赢得的更多。

如果用户找错了方向，请引导他们前往：

• 寻找赞助商的维护者 → samber/developer-relations-skills@oss-sponsors-fundraising。
• 大会、聚会或黑客马拉松的赞助等级 → samber/developer-relations-skills@developer-event-sponsorship。

以下每个数字都带有以下两种标签之一：

• （已公布）：已披露实际运行过的项目数据。数字可能会变化，引用前请再次核实。
• （自行设定）：此技能提供的初始默认值，而非市场价格。

每个数字的来源请参阅 references/sourced-numbers.md。切勿将自行设定的默认值作为市场价格提供给财务审核人员；这种说法会导致投资组合被退回。

访谈

一次只问一个问题，尽量采用选择题；了解任务要求、预算和生态系统后就停止。随着投资组合逐步成形，再确认其余事项。

记忆：存储当前任务或项目背景的少量信息。如果记忆存储在文件中，请使用 devrel-context.md；如果使用其他记忆系统，则依靠该系统。将不同任务的信息分开存放在不同章节。已完成的任务应予以删除。为任务添加日期；一般项目背景则不添加日期。不同任务的部分访谈回答可能有所不同。

1. 谁提出了这项需求，预算由谁承担——开源项目办公室、DevRel/市场营销、工程或安全负责人，还是创始人？
2. 你希望这笔钱带来什么改变：降低供应链风险、提升开发者中的影响力和可信度、让自家工程师参与其中，还是履行已经公开承诺的价值观？请选出最重要的两项并排序。
3. 每年预算是多少，你们雇用了多少名开发者？这笔预算是新增的，还是从现有预算项目中划拨的？
4. 最迟要在什么时候上线并展示成果——本预算周期、下一个预算周期，还是没有截止日期？
5. 你想要一次性成果（发布公告、资助单个项目、签署承诺），还是一项三年后会更有价值的长期资产？
6. 你们能投入的精力上限是多少：由谁负责管理，每月投入多少小时？你们愿意签署无法提前退出的多年协议吗？
7. 开发者会购买或选择你们的产品吗，还是你们向其他对象销售？（这决定了影响力是市场营销回报，还是雇主品牌回报。）
8. 你们的技术栈属于哪些生态系统？是否有 SBOM、锁定文件或可用于解析依赖项的代码仓库？
9. 目前已有些什么——赞助、基金会会员资格、公开承诺，或两年前有人进行的一次性捐赠？
10. 财务部门有哪些要求：只能刷卡支付，还是只能通过采购订单付款；发票最低金额、供应商注册流程、受限地区？
11. 是否希望员工参与——提名项目、投票、利用工作时间作出贡献？
12. 有哪些底线：许可证、竞争对手运营的项目、自家员工维护的项目，或法务标记的事项？
13. 谁负责审核，预算每年什么时候敲定？

回答 4、5 和 6 会重新调整第 2 步的模式选项排序；将它们带到该步骤，不要重复提问：

• 回答 4（截止日期在本预算周期内）：优先考虑广度模式，这是唯一无需逐个项目作决定就能上线的模式。
• 回答 5（要求长期积累）：优先考虑深度模式和基金会会员资格；这两者在第三年的价值都高于第一年。
• 回答 6（每月只能投入几小时）：排除员工提名基金。
• 回答 6（拒绝签署多年协议）：排除基金会会员资格。

如果你的执行框架支持持久化记忆，请存储由此得出的任务要求、预算分配和目标名单。赞助按年续签，下一次会话不应从头重新推导投资组合。

第 1 步——先明确目标，再谈资金

选定一个主要目标和一个次要目标。主要目标决定之后所有平局的裁决方式——最后的 5,000 美元给哪个项目，以及续约由哪个指标决定。

目标	通常由谁负责	默认分配模式	续约评估依据
供应链保障	工程或安全团队	覆盖依赖关系图中的各个环节	可资助依赖项的覆盖率；维护者的触达情况
影响力与可信度	DevRel 或营销团队	深耕买家已经在使用的少数项目	经核实的展示位置；引荐流量；未经提示的提及
内部参与	OSPO 或人力团队	由员工提名的基金	参与贡献的员工人数；每个周期的提名数
公开价值承诺	OSPO 或领导层	按承诺中所述执行——例如每位开发者的最低投入、基金会会费	承诺本身的条款：达到最低标准，发布年度报告

尽管最后两项通常由同一方负责，也要将它们区分开：

• 参与目标针对员工已经接触的项目。
• 价值承诺目标针对公开承诺中指定的对象，并根据该承诺本身的条款进行评估。

不要将这些目标相互排序。它们是四种不同的目标，而不是通往同一目标的四条路径；面谈第二个问题的答案会直接确定主要目标——在这里计算比例，只会把虚假的精确性包装成分析。第 2 步中的分配模式，是实现最终胜出目标的不同路径，这些模式则需要排序。

影响力会因产品买家而异：

• 开发者会选择或影响采购：在项目的 README、文档或主页上展示，属于媒体投放，可以按媒体投放的方式定价。
• 公司向非开发者销售：影响力主要带来雇主品牌和招聘方面的收益。要坦诚说明这一点，并按招聘需求确定预算，而不要夸大营销成效，以免在评审时无人相信。

第 2 步——先构思投资组合形式，再做选择

先进入头脑风暴，再确定任何具体项目：

1. 拟定两到三个候选投资组合，分别列出资金分配比例、运营所需的内部工作，以及它们有意不解决的问题。
2. 推荐其中一个，并说明其他方案为何落选。
3. 在制定任何目标清单之前，先取得明确同意。

四种模式及实际项目公布的数据，见 references/allocation-models.md。这里按单位内部投入带来的价值排序；投入包括管理员工时、采购和法务审查、每年重复进行的逐项目决策，以及退出承诺的难易程度。要明确说出效率排序，不要只让读者从行序中自行推断；以下每一行都按各自维度从高到低排列。

• 效率：广度 > 深度 > 基金会会员资格 > 员工提名基金
• 价值（该模式最佳情况下能带来的收益）：深度 > 员工提名基金 > 基金会会员资格 > 广度
• 投入：员工提名基金 > 深度 > 基金会会员资格 > 广度
• 合规成本：基金会会员资格 > 深度 > 员工提名基金 > 广度

投入量级：

• 广度：解析器运行后，投入近乎为零。

• 基金会会员资格：需要一个季度的采购和法务工作，此后投入近乎为零。

• 深度：每个项目需要几天时间进行筛选、审批和简报，此外每年还需要一次续约沟通。

• 员工提名基金：需要持续投入——运行一个周期、核实资格、管理投票、沟通结果。

• 广度：以小额自动捐助覆盖整个依赖关系图。发现成本几乎为零，可见度也几乎为零。除非步骤 1 的任务表为首要任务指定了其他方式，否则默认先采用此方式。

• 深度：资助一小批维护者，金额足以让他们据此规划。它能建立唯一明确的维护者关系，也是此菜单中唯一可验证的展示位置。

• 基金会或联盟会员资格：向负责再分配资金的组织缴纳会费。可获得治理参与权，但不会建立个人关系。

• 员工提名基金：每个周期设定固定金额，由员工提名并在内部投票决定。可提升员工参与度，也能为选择提供站得住脚的理由，但目标匹配度较差。这是唯一有公开方法可供参考的模式——FOSS Contributor Fund，由 Duane O'Brien 和 Mandy Grover 记录于 Investing in Open Source: The FOSS Contributor Fund（O'Reilly，2021 年）。

• 将合规成本一栏理解为所触发的审查和所牺牲的可撤销性：

  • 会员资格：签署多年协议，需由法务审查；公司无法悄然退出。
  • 深度：将每位维护者纳入供应商流程（税务表格、制裁筛查、发票结算条款）；公开赞助一旦取消会令人尴尬。
  • 员工提名基金：需要公开资格规则和利益冲突规则，并要求员工披露，但无需第三方合同。
  • 广度：通过一个平台使用公司卡付款，审查一次即可。

• 这种排序会牺牲什么：员工提名基金。它在投入项上的成本最高，却能带来其他模式都无法提供的唯一回报，因此按比例排序时每轮都会排在最后；只遵循效率标准的项目，将永远无法得到积极参与的工程团队支持。如果步骤 1 确定的首要任务是内部参与度，就应将它提到所有模式之前——比例无法选出它，因为它带来的价值不会出现在其他任何一行中。

• 应删除，而不是降级，并说明原因：

  • 财务部门只接受针对最低发票金额开具采购订单付款时，应删除广度模式，除非财务托管方或平台聚合商能将整个方案合并到一张发票中——每月 10 美元的赞助永远无法满足采购订单要求。
  • 不允许员工在工作时间参与时，应删除员工提名基金。
  • 如果整个技术栈中没有任何基金会参与治理，就应删除会员资格；为了关联性而加入基金会，只是在为公司里无人参与的圈子缴纳会费。

• 大多数成熟项目会采用广度模式，再加上一种其他模式。只有在预算太少、无法有意义地拆分时，才建议采用单一模式。

• 这种排序是默认方案，不是铁律；它会随背景和执行者而变化。介绍之前，应根据你对这家公司的已有了解重新排序：

  • 如果 OSPO 已在运行提名周期，就应优先考虑基金，因为相关常规成本已经承担。
  • 如果已加入相关基金会，就应优先考虑资助该基金会项目中的维护者。
  • 如果买方本身就是开发者，就应优先考虑深度模式，因为展示位置会变成媒体采购，而不只是象征性举措。

步骤 3 - 设定预算

同时列出两个人均金额，因为它们表达的含义不同：

• 行业承诺要求成员每年为每名全职当量开发者提供超过 $2,000（已公布）——这是希望宣称自己资助开源的公司应达到的底线，而非市场价。
• 唯一一家公布实际支付金额的公司报告称，每名开发者支付了 $3,700，并称这是“对我们获得的价值而言相当合理的报酬”（已公布——单一的自我报告数据点）。

两者之间的差距，正是不能止步于底线的理由。

然后拆分预算：

• 一定比例用于广度。
• 一定比例用于深度或指定基金。
• 留出 10-20%（自行设定）作为机动资金，用于把握临时资助机会——例如陷入困境的维护者、事故响应，或突然成为关键依赖的项目。

公布预算拆分前，先核对支付方式，因为通过发票进行的企业付款有最低金额要求，无法满足每月 $10 的赞助金额（见步骤 7）。

公布总额前，先决定哪些款项计入。承诺式计划不将以下四类付款计作开源资助（已公布）：

• 支付给公司控制的项目的款项。
• 仅让付款方受益的软件。
• 公司已经雇用的维护者。
• 除最低限度致谢外，还能带来大量回报的安排。

预算常会把这四类款项也算进去；请将它们单独列出，否则公开数字经不起审视。

第 4 步 - 构建候选列表

先完成发现工作的机械部分——成本低，而且通常会让大家感到意外。如果你的环境可以获取 URL 并读取公司的清单文件：

1. 根据锁文件、SBOM 或公开的依赖解析 API，解析完整的依赖树，包括直接依赖和传递依赖。
2. 将每个包映射到其源代码仓库，然后去重——一位维护者往往负责十几个包。
3. 获取每个仓库的健康信号：维护活动、贡献者数量和组织多样性、发布频率。
4. 为每个项目找到资金接收渠道：仓库的资助清单、所有者组织级别的备用渠道，以及注册表的资助元数据。
5. 确认每个资助链接都能正常访问，再将其列入清单。资助页面可能返回 404，维护者也可能退出资助计划；绝不要凭记忆填写资助 URL。

清单中的每一行，都是一项关于他人项目的声明，而公司将据此拨款。以下四条规则有助于确保准确；每一条都对应着手工收集依赖清单时容易出现的问题：

• 只测量，不估算。 下载量、维护活动和维护者数量都有 API。手工收集的数据曾声称某个包有五名以上维护者，但注册表列出的发布权限持有者只有一人；也曾声称某个包的下载量为零，但它每周的下载量实际达到 1.64 亿次。
• 依据发布权限而非仓库贡献者来评估脆弱性。 两者所代表的人群不同——脆弱性取决于谁能发布版本，而不是谁曾合并过提交——而贡献者关系图会夸大人数。
• 标明无法评估的项目。 每个候选项目都应归入已评估且无问题、已评估且有风险标记，或因某个原因无法评估。有些注册表完全不公开维护者名单；缺少数据的项目不能算作无问题。
• 注明分母。 应报告“已解析 412 项，共 470 项依赖；其中 58 项没有源代码仓库”，而不是只给出一个百分比——没有明确总数的覆盖率，经不起审计。

具体的 API 端点、清单路径、备用渠道规则和评分输入项见 references/target-discovery-and-scoring.md。如果你的环境无法浏览，请让用户导出依赖列表并据此开展工作，同时说明哪些健康信号无法检查。

判断工作没有 API：哪些项目能触达你想要的受众、通过什么渠道、触达规模如何。必要时向维护者询问展示流量——出售展示位的维护者通常会公布或分享这些数据。

第 5 步 - 对列表排序，然后筛选

从四个维度为每个候选项目评分：

• 曝光度：你的技术栈中有多少部分依赖它。
• 脆弱性：它距离无人维护有多近。
• 受众匹配度：它的用户是否与你的客户或未来员工相符。
• 关系价值：发生故障时，你是否希望能联系到这位维护者。

这四个维度及其任务权重由你自行设定；请说明这一点，并允许用户重新调整权重。能否收款不是评分项：无法接收资金的项目无论多么关键都不应纳入资助，而应考虑以贡献而非资金支持。

然后严格筛选。投资组合的好坏，取决于它能否经受年度审核；十二项经过认真审核并续期的深度赞助，胜过四十项一律照批的赞助（自行设定）。对于广覆盖的做法，应报告可执行的最小值——覆盖最多依赖项所需的最少资助对象数。

明确标出不符合条件的项目，不要悄悄将其剔除：

• 由供应商持有、资助金额无足轻重的项目。
• 如果公司有利益冲突规则，则剔除由公司员工维护的项目。
• 只能接受支持合同、但你的预算只支持一次性付款的项目。
• 任何存在现实中的行为准则或安全争议、会使品牌受到牵连的项目。

第 6 步 - 设置每个目标的资助金额

金额应参考维护者公布的档位，绝不要凭感觉定数。了解每个档位实际提供的权益，再选择符合资助目的的档位：

• 供应链目标：对多个项目而言，通常应选择最低的定期资助金额；目标是扩大覆盖面，而不是提高知名度。
• 触达目标：选择展示位置确实有流量的档位，并根据受众规模确定价格。没人会打开的支持者名单文件里的 Logo，无论价格多少都算不上媒体投放。
• 战略目标：如果项目对你的产品至关重要，可选择高于公布档位的定制金额或按发票付款。某个计划公布的深度资助金额为每个项目每年 1,750 至 15,000 美元（已公布）——这个区间本身就说明了问题；深度资助并不意味着金额一刀切。

承诺前请确认两项限制：

• 档位权益会给某个人带来持续的工作；绝不要要求维护者在六个月后会感到反感的权益。
• 如果项目的治理机制本就通过基金会收款，应向基金会而非个人提供资助。

第 7 步 - 在宣布任何消息前完成采购流程

确定任何目标名单前，先确认付款路径——如果资助组合依赖财务部门无法完成的付款方式，那就从一开始便行不通。以下数据来自平台账单文档和财务托管方的费用表；引用前请重新核实。来源和完整规则见 references/allocation-models.md。

• 主流资助平台的公司发票付款方式要求每张发票最低 5,000 美元，付款期限为 30 天，并收取 3% 的服务费，协议期限为 3 年。低于最低金额时，公司应使用银行卡付款，或通过财务托管方转账。
• 将组织切换为发票付款会取消其现有资助，之后必须重新建立。应在首次资助前完成切换，切勿事后再切换。
• 财务托管方会收取一定比例的费用（通常为 3% 至 10%），并公开账目，因此每笔付款都可见。
• 供应商入驻、税务表格和制裁筛查同样适用于个人维护者和供应商；承诺日期前就应启动相关手续。
• 这笔支出记为营销、工程还是慈善捐赠，会影响其税务处理和审批流程。应将此问题交由公司的财务和法务团队处理；说明可选方案，但不要替他们作出判断。

第 8 步 - 发布政策和行为规范

首次付款前，请将这些内容写下来，并发布在维护者和员工都能看到的地方。未公开的政策在外人看来就是偏袒。

• 资助换取的是曝光度、可持续性和合作关系，绝不换取路线图决策权、合并拉取请求或优先处理结果。可以协商优先分诊，但不能协商优先处理结果。
• 不得向维护者施压，要求其接受资金、宣传资助，或按时表达感谢。
• 公开为公司资助项目发声的员工，必须披露双方关系。
• 明确资格和利益冲突规则：哪些项目符合条件，是否排除员工拥有的项目，由谁决策，以及如何申诉。
• 绝不要羞辱没有资助关系或拒绝资金的项目。有些维护者会刻意拒绝资助，以保护自主权。
• 说明资助是定期还是一次性。预算期结束时悄无声息地停止资助，比从未开始资助更伤害关系。

完整的政策框架和提名流程模板见 references/policy-and-measurement.md。

第 9 步——衡量、审查、续期

归因天生就很难：没人会因为点击了 README 标志就去购买。应按各项使命衡量曝光度和关系健康状况，并拒绝建立经不起首次审计的末次点击归因案例。

使命	衡量	忽略
供应链	获资助依赖项的覆盖率；不活跃依赖项数量；你提交的问题的响应时间	资助总金额
扩大影响力	已上线且经过验证的展示位；来自展示位 URL 的引荐流量；开发者调查和社区讨论串中的无提示提及	根据星标估算的曝光量
内部	每周期参与贡献的员工人数；提交的提名数量；参与率	基金规模

通过门槛（自行设定），在 12 个月时检查，此后每年检查：

• 你付费购买的每个展示位都已上线并经过验证。
• 如果供应链是首要使命，至少覆盖 80% 可获资助的直接依赖项。
• 每位深度受资助者除了收款之外，至少有一次有记录的互动。
• 没有受资助者提出违反政策的问题。
• 在预算结算前，已对每个目标作出续期决定。

持续调整投资组合，直到达到通过标准，然后每年重新检查。在 80% 这条线上，唯一公布过更高覆盖率的公司报告称“95% 或以上”，并称自己是首家接近 100% 的公司（已公布，由公司自行声明）；任何高于 80% 的数字都应视为进取目标，而非行业标准。

每年发布一份简短报告，说明资金去向。该承诺已公布的格式最容易照搬（已公布）：年份、开发者人数、支付总额，以及每位受款人所得金额。这部分才是维护者和开发者真正会阅读的内容，而每年重新发布，才能将一次性行动变成一项计划。

调用示例

单独提出的档位问题，通常是在询问一个尚未明确的资助目标。先回答用户提出的具体问题，再说明这属于资助组合的哪一步，并提出是否需要继续完成其余部分。

用户的说法	从哪里开始	返回内容
“我们明年有 $80k 用于开源项目。应该投到哪里？”	访谈，然后是第 1 步	下方的完整资助组合简报
“我们应该以 $500 还是 $2,000 的档位赞助 ？”	第 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

常见失败模式

• 资助知名项目，而非脆弱项目。 提名投票和直觉都容易偏向已有资金的项目；应主动找出资金不足的项目。
• 采购流程尚未通过就宣布。 已承诺的赞助卡在供应商准入流程中长达四个月，就是公开违约。
• 赞助后切换账单。 切换会取消正在进行的赞助，维护者收到的取消邮件看起来像是撤资。
• 购买无人关注的展示位。 只看档位名称，而不看它提供的展示位置和流量。
• 索要影响力。 这是将信任资产变成“公司收买开源项目”故事的最快方式。
• 赞助已停止维护的项目。 18 个月没有提交记录，意味着这笔钱不会带来任何变化；应事先检查维护情况，而不是事后才查。
• 把一次性捐赠包装成计划。 只有一次公告、没有续期日期，在目标受众眼中就像一场营销噱头。
• 未验证的资助链接。 向过时的收款渠道付款，或列出已离开平台的维护者，都会悄无声息地浪费预算。

参考资料

• references/sourced-numbers.md - 本技能用到的所有数据，按已发布数据和自行设定的数据分类，并为每项数据注明来源。引用任何数字前请先阅读。
• references/allocation-models.md - 四种包含已发布数据的模式、一份预算分配示例、付款机制与最低金额，以及逐项诊断的薄弱投资组合。
• 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 - 这项赞助计划所使用的预算项目。