维护者如何为开源项目设计赞助计划：从目标、层级…

当开源维护者想为项目获得赞助或资金（设置 GitHub Sponsors/Open Collective/FUNDING.yml、写赞助层级与页面、企业赞助、拨款申请）时，设计一套可长期交付的赞助方案。

适用场景

解决思路

1. 先做访谈，一次问一个问题，尽量用选择题，直到明确项目、目标金额和真实交付能力为止；其余信息在设计过程中确认。问题包括：项目与角色（独立维护者/团队一员/公司员工）；钱要改变什么（买回工时、覆盖基础设施、资助特定交付物、替代薪水）并给出月度数字；资金到位期限；要一次性收益还是两年后仍在复利的资产；用户是谁（个人开发者/公司/两者）及依据；能说出三家依赖该项目的公司及依据；现有平台（GitHub Sponsors、Open Collective、Ko-fi、FUNDING.yml、无）；每月能承受的赞助相关工作上限（按小时，而非意愿），是否愿意签不可撤回的承诺；是否有法律实体，收款是个人还是实体，所在国家；可控制的渠道及大致数据（仓库流量、文档站、newsletter、社交粉丝、会议演讲）；是否已有商业元素（付费支持、托管产品、雇主对工作的主张）；无论如何都不愿出售的东西。将答案3、4、8用于重排第2步的方案形态，不要重复提问：本季度内的期限→优先感恩与曝光；复利诉求→优先 retainer 与曝光位；每月仅几小时上限→删除 access 方案；不愿签不可撤回承诺→删除 retainer。记录答案；若有持久记忆，把项目简报存入其中，因为某些平台的层级价格实际上永久不可改，后续会话不得从零重设层级。
2. 第1步：判断赞助是否是正确的工具。赞助只是五种资金工具之一（opensource.guide 的清单）：雇佣（把开源时间写进工作）、个人众筹、项目级企业赞助、商业收入（支持、托管、付费功能）、拨款。个人赞助是通往生活工资最慢的路径：即使是广泛依赖的库，个人赞助收入通常也低于 $1,000/月。在设计前明确说出：若目标金额是“替代薪水”且项目只有几百用户，建议走雇佣或商业层级，赞助只作补充；若目标是买回每周一天或覆盖成本，赞助很合适。同样检查拨款：有研究、基础设施或安全角度的项目往往比一百个 $5 赞助更快拿到拨款；若如此，并行运行第1b步。不要在这里按效率给五种工具排序——那是对问题2已做出的选择施加虚假精确度：替代薪水的目标使雇佣占优，基础设施或安全角度使拨款占优，无论努力程度如何。拨款通道内的项目、赞助内的形态才需要排序。
3. 第1b步：运行拨款通道。拨款不是更大的赞助，而是一份有资格门槛和报告义务的定期合同：有截止日期，按证明付款。与赞助计划并行运行，绝不替代它。写申请前先做资格筛选，四道门槛比文笔差拒绝更多申请，访谈答案9已确定其中两道：许可证（每个项目都要求被认可的开源许可证，部分延伸到文档和研究产出）；谁可被付款（有的与个人签约，有的需要法律实体，有的只付组织并要求无实体时使用财政赞助方）；地理（限制约束收款人而非代码：居住地偏好、国家税务居民、制裁排除）；成熟度与范围（基础设施基金要有被依赖的库、拒绝原型；原型基金要新工作；科学基金要在其领域有已证明的使用）。按“每申请与合规小时赢得的金额”给项目排序，五类：直接基金（付给个人）、队列安全基金、机构基础设施基金、国家创新基金、基金会科学拨款。效率：direct > cohort > agency > national > foundation；价值（每笔金额）：foundation > agency > national > direct > cohort；投入：foundation > national > agency > direct > cohort（基金会要意向书、受邀提案和机构签名；机构从申请到合同要数月；直接基金只需一张表）；合规成本：national > foundation > agency > cohort > direct。这个顺序会饿死基金会拨款——唯一资助多年具名人力的类型；当项目已有机构归属或财政赞助方时提升它，两者皆无时删除。写给评审委员会，而不是赞助页：第5步向已喜欢项目的读者推销维护者信誉，而提案是由一次读几十份的评审按公开标准打分的。以依赖而非故事开头：普及度、关键性、项目停止谁会受影响，都是评分项。按具名费率把工作折算成小时，再把这些小时映射到你愿意按里程碑收款的节点，因为确实会按此付款。明确回答“为什么不用现有方案”，公开表格会直接问，缺失答案会被视为没做调研。接受前先规划报告：赞助方靠感谢帖续费、会悄悄流失；拨款方按固定时间表的具名报告扣款并收回未花完的钱。把这份行政工作计入问题8的努力上限。各项目的门槛、申请字段、评分标准、获奖后义务以及已停止接受申请的项目见 references/grant-programs-and-reporting.md；向用户点名某个项目前先读它。
4. 第2步：头脑风暴方案形态，然后选一个。进入头脑风暴模式，草拟两到三个能达到目标数字的候选方案，然后推荐一个并说明其他为何落选；在定价前取得明确同意。四种形态按“每单位维护者努力换回的价值”排序——努力指经常性维护小时、永不结束的义务、已发布承诺撤回的难度。要说出效率顺序，而不是让它隐含在行序中。各轴不一致，都要读；每行按各自轴降序，最高在前。效率：visibility > gratitude > retainer > access；价值（形态可达的月收入）：retainer > access > visibility > gratitude（当曝光位流量达数万月浏览时，visibility 超过 access）；投入：access > retainer > visibility > gratitude；合规成本：retainer > visibility > access == gratitude。投入量级：gratitude 页面建好后近乎为零；visibility 每个赞助方约一小时用于 logo 提交和位置检查；access 与 retainer 都是长期工作。visibility 方案：公司层级按真实曝光位流量定价（README、文档站、主页），交付是 logo 提交，收入随项目实际受众扩展；只要文档或 README 有可测流量，默认首选此形态。gratitude 方案：低层级、无福利、一个清晰请求；适合用户多而维护者无空闲时间的项目，也是任何其他形态的底层。retainer 方案：少数依赖公司为具名承诺付费（响应时间、安全分诊、升级支持）；赞助方最少、单笔最大、义务最多。access 方案：赞助者专属内容、提前访问或 sponsorware；有记录以来转化最好、经常性成本最高——等于在维护工作旁加一门内容生意；仅在已有受众时适用。按节奏区分两种长期工作：access 无论是否有人要求都发布，retainer 工作由依赖公司的偶发需求触发——所以更大的支票反而花更少小时，排名在它之上。解释合规并列：access 与 gratitude 都不向具名公司承诺，也不把第三方品牌放到项目表面，且都能用一个 commit 对新赞助方撤回。retainer 居合规成本之首：需要实体、编号发票、税务处理，以及一份毁约昂贵的书面承诺。visibility 第二：GitHub Sponsors 上公布的价格是永久的，赞助方 logo 需要第8步的拒绝规则才能出现第一个。这个顺序会饿死 retainer：它是唯一能达到薪水级收入的形态，也是唯一真正承担交付义务的，因此同时居价值线和合规线之首，比例每轮都埋没它；只服从效率线的维护者会永远停在咖啡钱。当问题2答案是“替代薪水”、能说出三家依赖公司、且已有实体或财政主办方时，把 retainer 提升到一切之上。删除而非降级，并说明删哪个：无实体且不愿用财政主办方→删除 retainer；除仓库外无受众（无文档流量、无 newsletter、无演讲）→删除 access；README 和文档无可计流量→删除 visibility，因为无法测量的曝光位无法定价。多数可行方案是 gratitude 底层加另一种形态；仅当维护者能同时服务两半时才推荐组合。这个顺序是默认而非定律，随情境和执行者变化。呈现前按已知信息重排：已有 newsletter 或会议受众→提升 access，因为分发已建好；雇主已为工作付费→移除 retainer 的前提；三人团队→可服务独立维护者必须删除的形态。
5. 第3步：为两类买家搭建层级。层级服务两类行为迥异的买家：个人自掏 $5–$25，几秒内决定，想要感谢或个人福利；公司从预算科目付款，需要发票和具名受益人，想要审批人能辩护的收益。参考文件中的曝光位销售层级（Vue、Sindre Sorhus）把个人/公司分界放在约 $100/月；把该分界当作 baseline，若受众数据不同则调整。以下规则决定大部分层级——前四条来自参考文件中的公开层级，后两条来自 GitHub 文档：按触达受众而非慷慨程度给公司曝光位定价（“README 上 2 万月浏览的 logo”是审批人能签的媒体采购，“金牌赞助商”不是；Sindre Sorhus 公布每个曝光位的月浏览数并据此定价）；按买家命名层级（“The Agency”或“Team”告诉公司这是给他们的，“Platinum”让他们猜——Caleb Porzio 测试后的结论）；绝不在转化层级正下方放部分福利层级（“如果人们可以付 $1–5/月而不是 >$14，他们会付更少的”，Porzio）；无福利的 gratitude 层级放在福利层级之下没问题甚至有用；预期一个层级撑起整个计划（两个有记录的个人层级中，单一层级驱动转化，其他层级承接上下方的慷慨）；把公布价格视为永久（GitHub Sponsors 上已发布层级价格永不可编辑，只能停用并替换，现有赞助者留在旧层级；按两年后定价；平台上限 $12,000/月）；保持层级简短（3–5 个活跃层级作为 baseline；平台允许十个已发布月层级，没人读十个）。Vue、Sindre Sorhus 和 Caleb Porzio 的参考层级（含价格与确切奖励）见 references/tier-ladder-examples.md，其中包括一个弱层级及其失败原因。平台限制、费用、付款和 FUNDING.yml 机制见 references/platform-mechanics.md；命名价格或平台前先读它。
6. 第4步：按交付能力而非吸引力衡量每个奖励。对每个奖励问：在当前赞助者数量的十倍下，它每月要花多少？十倍乘数是 baseline 压力测试，不是实测增长率——它存在是因为最能转化的奖励恰好会膨胀成第二份工作。奖励与形态一样按“赞助者买到什么 vs 持续交付成本”排序：效率：README 或文档曝光位 > 赞助者徽章与感谢帖 > 提前访问发布 > 私有仓库或季度办公时间 > 月度通话、优先支持、定制工作；价值（让公司签约并续费的东西）：月度通话与优先支持 > 私有仓库或办公时间 > 提前访问 > 曝光位 > 徽章与感谢帖——对个人赞助者，该线在提前访问以下反转，因为徽章和感谢就是全部购买物；投入：以下三桶，按量级。近乎为零且安全：BACKERS.md 中的名字或 logo、README 或文档曝光位、感谢帖、赞助者徽章。有界但真实：每层一个私有仓库、季度办公时间、提前访问发布。第二份工作：月度通话、优先支持承诺、按赞助者定制内容、定制集成。这个顺序会饿死最后一桶中的具名承诺——它们是公司唯一愿付 retainer 钱的奖励。不要把它们提升为层级福利，而要把它们完全移出层级，通过第7步出售，让价格匹配义务。任何通不过十倍测试的奖励都砍掉。赞助者专属内容和 sponsorware、先向赞助者发布、达到公布阈值后开源，是有记录以来转化最好的奖励，也是最贵的持续交付。机制、发布触发规则，以及绝不能设门槛的东西（安全修复、核心库、使用所需的文档）见 references/tier-ladder-examples.md。
7. 第5步：把请求写成有边界的承诺。“支持我的工作”不是请求。每个资助方，从 $5 赞助者到拨款委员会，都回答同样五个问题（opensource.guide 清单）：项目为何重要；什么成绩证明它；为什么资助它而非替代方案；钱买什么；如何合法支付。把目标换算成读者能识别的单位——每周一天维护、CI 与代码签名账单、带日期的具名交付物。把首个筹资目标设在本季度能达成：完成的目标比卡在 4% 一年的雄心目标更有价值。刻意选择目标类型：赞助者数量目标可保持收入私密；金额目标会永久公开月收入且不可撤回。若用户有 build-in-public 实践，保持两者一致。用维护者自己的口吻写页面，再用你惯用的人性化技能润色——赞助者买的是维护者信誉，宣传文案会消耗它。
8. 第6步：让请求无法回避，让项目可被机器发现。赞助资金通过三条路径到达，每条需各自配置，且按成本换来的金额不同：效率：FUNDING.yml 与包清单资助元数据 > 用户已接触表面上的资助链接 > 能通过资助方初筛的健康信号；价值（路径能导向项目的钱）：健康信号 > 资助链接 > FUNDING.yml；投入：健康信号 > 资助链接 > FUNDING.yml——Scorecard 驱动的清理是一个季度工作，链接是一小时，文件近乎为零。现在按此顺序做前两项。这个顺序会饿死健康信号工作——企业基金或基金会项目在分配前实际阅读的东西；当此类项目是明确目标时提升它，并把本节其余部分当作其前提。人们会读的请求：在用户已接触的每个表面两次点击内放资助链接——仓库赞助按钮、README、文档页脚、发布说明、适当的 CLI 或错误输出；没人到达的页面转化不了任何人。资助方扫描的图谱：成熟资助方会自动跨依赖树分配——Sentry 的 $500,000 计划以每个 $4–$10 达到“95% 或更高覆盖”其可资助依赖，且对许多项目是“很可能是他们第一个也是唯一的赞助者”。出现在该扫描中只需一个文件：.github/FUNDING.yml，加上生态支持处的包清单资助元数据。项目建立的候选名单：企业基金在任何人看之前按机器可读健康数据排名——OpenSSF Scorecard 与 Criticality Score、依赖数、贡献者多样性。缺失或失效的资助链接在该阶段是硬过滤而非低分：不可资助的项目无论多关键都会被丢弃。验证每个资助链接可解析，并检查组织级回退（{owner}/.github）没有指向过期内容。失效赞助链接很常见，会静默损失整个渠道。扫描器读取的信号、员工提名基金的资格规则及自审流程见 references/funder-scan-and-eligibility.md。FUNDING.yml 键与语法见 references/platform-mechanics.md。
9. 第7步：打开企业通道。个人层级达不到薪水级数字，依赖项目的公司才能。这条通道是不同动作，不是更大的层级。公司通过四种机制付款，各自赢法不同：自动依赖分成——靠可被发现赢得，第6步已完成；基于判断的战略赞助——靠对该公司产品明显承重赢得；员工提名基金——靠已在给你提 issue 的工程师提名你赢得；基金会或承诺成员——靠成为基金会受助方而非推销赢得。只有第二种靠外联赢得；写信前先知道你在瞄准哪一种。效率：dependency-share > employee-nominated funds > strategic sponsorship > foundation membership；价值（每赢得一家公司的支票大小）：strategic sponsorship > foundation membership > employee-nominated funds > dependency-share；投入：foundation membership > strategic sponsorship > employee-nominated funds > dependency-share——成员资格是一个季度或更多流程，战略推销每个目标一周，提名是给已认识你的工程师发一条消息，依赖分成是第6步近乎为零的文件。战略赞助正是第2步排序饿死的形态，在下一层出现：retainer 级支票在此，效率线每次埋没它。只对产品明显依赖该项目的公司花每周一个目标。机制与数字见 references/corporate-sponsorship-path.md。把第二种机制的外联作为序列执行：从依赖图、公开仓库、点名该技术的招聘帖、来自公司域名的 issue 中识别依赖公司；联系有预算和暴露面的人——平台负责人、资深工程师、安全负责人——绝不发通用地址；把请求框在已存在的预算科目上：供应链安全、营销触达或工程支持（Open Source Pledge 成员承诺每名受雇开发者每年超过 $2,000，这笔钱在找可识别的受助方）；卖具名承诺而非善意，Valsorda 列出的公司实际购买物：双因素认证与强制代码审查、生态跟进更新、可靠审查与合并时限、对已提 issue 的支持、谨慎处理安全报告、“甚至继任计划”；推销前先打通采购：实体、税表、编号发票和银行信息才能被处理，捐赠按钮不能；通过 GitHub 的发票赞助每张发票最低 $5,000，更小的请求改走财政主办方；规划续费：预算按年，周期中期的价值证明是计划的一部分而非客套。检查付款路径不仅今天可用还要能持续：财政主办方本身也是连续性风险——Open Collective Foundation 2024 年解散给其 600+ 集体七个月转移资金。多名维护者共享资金时，在第一笔款到账前决定谁授权支出，并区分“为维持运转付费”与“为决定方向付费”——Django Software Foundation 正是为此资助一名负责分诊与行政工作的 Fellowship。财政主办方的公开账本也会暴露每位维护者的报酬；选择前先说明。外联模板、一页 prospectus 形态和可付款清单见 references/corporate-sponsorship-path.md。实体与主办方连续性细节见 references/funder-scan-and-eligibility.md；完整的实体/基金会决策属于 samber/developer-relations-skills@oss-governance。
10. 第8步：写下钱买不到什么。在第一个赞助者到来前，与层级一起公布这些边界：赞助买曝光、感谢和具名承诺——绝不买路线图控制权或合并 PR；贡献无论作者是否付费都按技术价值评判；可出售优先分诊，不可出售优先结果；赞助者名单、路线图和审查队列保持为独立产物；维护者为保护自主权而拒绝资金是正当选择，不是错误。现在就声明任何利益冲突规则：哪些赞助者会被拒绝，谁来决定。
11. 第9步：衡量计划，而非掌声。用表格：是否增长→经常性月金额、6个月趋势，忽略累计筹资总额；谁在付钱→赞助者数量按个人 vs 公司拆分，忽略 stars、followers；是否持久→月流失率、层级中位数、来自最大赞助者的收入占比，忽略一次性峰值；请求是否有效→每个承载资助链接表面的转化，忽略页面浏览；承诺是否兑现→受资助承诺按时交付、奖励已交付，忽略感谢回复。自设通过阈值，90 天检查一次然后每季度：经常性月收入较上季度增长；每个已公布奖励按时交付；单一赞助者不超过收入 50%；若有公司依赖项目，至少一个公司层级被占用。50% 线来自自由职业客户集中度实践而非开源资助规范；若用户把它当规则要说明。未通过是增长前要修的集中度风险；未通过第四条意味着第7步企业通道从未真正打开。按请求失败处诊断收入问题：流量增长而收入持平→请求位置错误（第6步）；请求无处不在而收入仍持平→奖励对买家错误（第3–4步）。
12. 调用示例：常见请求及各自进入工作流的位置：“我维护一个每月 90 万下载的 Rust crate，没有资助页——怎么设置？”→访谈，然后按序第1–6步；能说出依赖公司前暂缓第7步。“三家有资金的初创公司使用我们的库，却没人赞助。”→先第6和第7步；使用已证明而收入为零时，层级很少是问题，可发现性和缺少公司层级通常是。“我该把新 CLI 先向赞助者发布一个月吗？”→第4步，然后 references/tier-ladder-examples.md 中的 sponsorware 规则。“重写我们的层级，最高才 $50。”→第3步，对照 references/tier-ladder-examples.md 中的弱层级及其诊断。“一个赞助者要求优先处理他们的 issue。”→第8步，并在下一个层级上线前公布边界。
13. 交付物：产出一份项目简报，逐节呈现，每节取得同意后再进入下一节。模板：# Sponsorship program - <project>；## Goal 月度目标、买什么、何时；## Instrument fit 为何选赞助，还推荐了什么；## Audience 个人 vs 公司构成、具名依赖公司；## Ladder 层级、价格、奖励、每个奖励的交付成本；## Platform 收款处、费用、实体、付款路径；## Ask 页面文案、筹资目标与类型、承载链接的表面；## Corporate lane 目标清单、联系人、推销、文书状态；## Boundaries 赞助买不到什么、拒绝规则；## Measurement 指标、审查日期、通过阈值。
14. 常见失败模式：发布你会后悔的价格（主平台不可改；$10 最高层级会封顶计划直到停用替换）；只为个人做层级（钱在公司层级，公司买不到不存在的层级）；奖励超出维护者承受（12 个赞助者时月度通话愉快，120 个时终结计划）；没人能到达的赞助页（无赞助按钮、无 README 链接、无 FUNDING.yml——对人和依赖图资助方都不可见）；出售路线图影响力（转化最快、摧毁中立性，并让其他用户不信任审查队列）；永不移动的目标（不可达的首目标读起来像没人支持的项目；设一个本季度能完成的）；给项目本身设门槛（对便利性做 sponsorware 可以；对库、其安全修复或文档设付费墙是对带你到此的用户的许可证式背叛）；钱到后沉默（赞助者靠证据续费；沉默一个季度就是取消赞助）。
15. 参考文件：references/platform-mechanics.md（层级与目标限制、费用、发票最低额、FUNDING.yml 键、财政主办、依赖分成平台）；references/tier-ladder-examples.md（三个真实层级含价格与奖励、一个弱层级及诊断、sponsorware 规则、一个填写示例）；references/corporate-sponsorship-path.md（四种资助机制、目标识别、外联邮件（弱与强）、prospectus 形态、可付款清单、续费说明）；references/funder-scan-and-eligibility.md（资助方工具读取的健康与可付款信号、员工提名基金资格规则、实体与财政主办连续性风险、自审流程）；references/grant-programs-and-reporting.md（各拨款项目的资格门槛与公布规模、常见申请字段、公布评分标准、获奖后报告义务、已关闭项目）；samber/developer-relations-skills@build-in-public（公开收入目标所承诺的透明实践）；samber/developer-relations-skills@readme-optimization（请求所争夺的 README 版面）；samber/developer-relations-skills@oss-distribution-strategy（增长曝光层级定价所依据的受众）；samber/developer-relations-skills@devtools-business-model（赞助收入能否替代收入模型）。

适用边界 · 注意事项

• 用户是决定资助哪些项目、给多少层级的公司方——这是桌子的另一边，应转介到 samber/developer-relations-skills@oss-sponsors-brand-strategy 并停止。
• 目标金额是“替代薪水”且项目只有几百用户时，应推荐雇佣或商业层级，赞助只作补充，而不是本技能构建的方案。
• 完整的实体/基金会决策属于 samber/developer-relations-skills@oss-governance，不在本技能范围内。