开发者工具商业模式选择：从九种原型中选出可落地的变现模型与付…

当创始人或高管问开发者工具该如何赚钱、该选 open core 还是托管云、免费与付费的界线在哪、是否要开源时，用约束条件、付费边界测试和可逆性阶梯产出一份可执行的商业模式决策备忘录。

适用场景

解决思路

1. 先做访谈，一次只问一个问题，尽量给多选题；一旦能确定产品形态、买单方和许可证现状就停止提问，其余边确认边推进。访谈需覆盖：产品是什么（库/CLI/自托管服务/托管 API/平台）；生产环境由谁运行（你的基础设施、客户的、还是两者）；今天是否已开源、用的什么许可证、已发布多少（已发布的永远保持已发布）；谁采用、谁真正签合同（同一个开发者、其工程负责人、平台团队、采购）；今天的收入及来源；单个活跃用户的边际服务成本（近零还是真实计算/存储/出口成本）；有资源的云厂商或竞品能否把你的软件跑成竞争性托管服务、是否已有人开始；今天能可靠计量的东西（请求、席位、构建、数据量、活跃设备、还是什么都还没有）；阶段与约束（跑道、人数、已有企业合同、投资人对增长形态的预期）；收入必须在什么日期前出现（本季度、今年、下一轮融资前）；想要一次性胜利（第一个付费客户、下次董事会的数字）还是逐年增值的复利资产；努力上限（一年内能自建或招聘哪些职能：SRE、支持轮值、外勤销售、计费工程、法务），以及是否愿意做出无法回退的承诺；哪些选项已被排除（招销售团队、转 source-available 许可证、支持自托管，或任何已公开承诺排除的事）。第 10、11、12 题的答案会重排第 2 步的原型菜单，带到那一步而不是重复提问：本季度内的收入日期会提升无需签字的计费模型（consumption metering、hosted SaaS），并删除 embedded OEM 和 marketplace take-rate；复利诉求会提升 open core 和 hosted open source；没有支持轮值的努力上限会删除 support and LTS；没有 SRE 职能会删除 hosted open source；没有计费工程会删除 consumption metering；拒绝做出无法回退的承诺会删除一切许可证变更。记录答案；若环境有持久记忆，存储产品形态、买单方、许可证现状和被排除的选项。
2. 第 1 步，先固定约束再探索任何东西，在提出任何方案前把三条都明确说出来：许可证已经发布（已发布的版本永久保持该许可证；需要项目没有的许可证的模型要求重新许可、取得每位版权持有人的同意，并承担有先例可查的 fork 风险，这是唯一真正不可逆的杠杆）；软件在哪里运行（若合规、数据重力或气隙要求客户侧部署，托管模型出局，support、licensing 和 open-core 模型可行；若由你运营，托管就可变现）；谁签字（个人刷卡和组织走采购买的是不同的东西，下面几乎所有模型变现的都是组织，个人变现靠便利：金额小、流失快）。
3. 第 2 步，明确进入头脑风暴模式并说出来，不要直接跳到答案。先拓宽：走一遍 references/model-archetypes.md 中的九种原型，把每种标为 possible、blocked by a constraint 或 premature，并为每个被否决的原型说出阻塞它的约束——带理由的否决能防止这个想法每季度被重新翻出来。当问题实质是「哪部分该免费、价值往哪一层移动」时，映射整个技术栈：人人需要却没人想拥有的组件会滑向商品化，钱坐在它上面一层；用 Wardley mapping 做这个推理（由 Simon Wardley 于 2005 年在 Fotango 提出），它把组件放在价值链上对照演化轴——产品跨多层时用它，产品是单一组件时跳过。把通过这一轮的原型按「每单位创始人努力所换回的价值」排序，努力指模型迫使你自建或招聘的职能、它产生的长期义务、以及承诺有多难回退。把效率顺序说出来而不是靠行序暗示，并先讲排在最前面的而不是最便宜的那行。每条线各自降序、最高在前：efficiency: consumption metering > proprietary hosted SaaS > dual licensing > open core > hosted open source > support and LTS > embedded OEM > ecosystem take-rate；value（不增加人手就能触达的收入）: consumption metering > proprietary hosted SaaS > open core > hosted open source > ecosystem take-rate > dual licensing > embedded OEM > support and LTS；effort: ecosystem take-rate > hosted open source > support and LTS > open core > embedded OEM > proprietary hosted SaaS == consumption metering > dual licensing；compliance cost: dual licensing > ecosystem take-rate > support and LTS > embedded OEM > proprietary hosted SaaS == hosted open source == consumption metering > open core。努力的量级：dual licensing 近乎零工程（只要 CLA 和完整版权已具备，一个询价页加随叫随到的律师）；hosted SaaS 和 consumption metering 各约四分之一工程用于运营、计量、封顶和计费；open core 是两条发布列车加用于找出谁在跑免费版的遥测的长期工作；support and LTS、hosted open source 是由人组成的长期工作（支持轮值和 SRE 团队）；embedded OEM、ecosystem take-rate 是业务拓展、供应商运营和付款的长期工作。解释努力并列：hosted SaaS 和 consumption metering 都运营厂商侧服务，只是计费对象不同，谁都无法逃避对方必须建的职能。解释合规并列：hosted SaaS、hosted open source 和 consumption metering 都持有客户数据，因此都承担同样的数据处理协议、安全审查和驻留问题；open core 最低，因为客户自己运行软件、什么都不离开其边界；dual licensing 最高，因为版权来源必须在对方律师的对抗下站得住。source-available 被刻意排除在这些线之外：它本身不创造买家，只是保护它下面的某个模型，把它当同级排序是虚假精确；把它当作 hosted 或 open-core 收入的修饰符，在第 5 步连同其不可逆性一起决定。这个顺序会饿死 hosted open source 和 support and LTS：两者都是由人头组成的长期工作，比值把它们埋掉，而它们又是唯一能变现那些永不外发数据或永不跨越功能边界的买家的方式（受监管的、气隙的、买保障而非功能的）——当自托管确实痛苦且买家接受托管时提升 hosted open source；当付费边界只能由赔偿、backport 和电话号码构成时提升 support and LTS。删除而不是降级，并说明删了哪个：今天没有任何可计量之物就删除 consumption metering；部署必须留在客户侧就删除 hosted SaaS 和 hosted open source；已发布宽松许可证或公司未完全拥有版权就删除 dual licensing；今天没有双边流动性就删除 ecosystem take-rate（它几乎从来不是第一个模型）。这个顺序是默认值不是法律，会随情境和执行者变化，呈现前先按你对这家公司的已知信息重排：已经运营服务的团队提升托管模型（昂贵职能已付过钱）；已有企业支持组织同样提升 support and LTS；带已签 CLA 的 AGPL 代码库把 dual licensing 提到最前（其前提是页面上最稀有的）。然后按该顺序呈现两到三个候选模型，绝不只一个；每个都要覆盖：卖什么、谁签字、必须为真的前提、放弃了什么；一个验证实验——在公司围绕它重建之前能证明模型可行的最便宜测试，带成功标准和日期（定价页测试、十次合格对话、三个部署的付费试点、托管等待列表落地页都算，「等等看采用情况」不算）。最后给出你的推荐和理由，让用户先选再展开细节。拒绝用商业模式画布替代这一步：画布填九个格子却从不问已经发布了什么、软件在哪里运行、付费边界能否成立——这三个才是真正决定开发者工具模型的输入。
4. 第 3 步，让每个候选通过付费边界测试。模型的好坏取决于免费与付费之间的那条线；先测试边界能否成立，这决定模型是否可行。用 references/model-fit-scorecard.md 对每个候选逐条书面回答：1) 仅限组织？付费侧必须是公司需要而独立开发者不需要的东西——SSO、RBAC、审计日志、多租户、合规证据、有保证的响应时间、托管运营；个人也想要的任何东西都会被社区重建。2) 无需敌意即可防御？有动机的贡献者能否在一个周末把它上游做出来，而且他们想不想做？如果是，这条边界就是等着被触发的 fork。3) 可观测的触发点？必须有人能看见跨越——第二个团队、生产部署、审计请求、量级阈值；没人看得见的边界没人会为之付费。4) 覆盖服务成本？计算免费用户的边际成本；基础设施重的免费面会让增长变成主动烧钱。5) 许可证兼容？模型是否与已发布的许可证兼容，还是需要你已决定永不做的变更。绝不放在付费侧：安全基础功能（sso.tax，即持续维护的 robchahin/sso-wall-of-shame 目录，点名把单点登录当奢侈品定价的厂商，其明确论点是「安全不应是付费功能」、SSO 是「任何超过五名员工公司的核心安全要求」）；免费版的安全补丁（扣留修复会把免费用户变成敌人）；社区贡献的任何东西（把贡献者自己的作品卖回给他们会招来敌意 fork）；数据导出（开发者把导出锁定读作陷阱并公开惩罚）。
5. 第 4 步，为模型强制的 go-to-market 定价。模型决定你招谁、成交周期多长，承诺前用 references/model-archetypes.md 中每个模型的后果把它讲清楚。让交易规模匹配销售动作：小合同需要无人工介入的自助；中等合同支持内部销售；大合同带安全审查、采购和法务，耗时数月。拒绝经典错配：付费边界只在企业功能处触发，却按自助定价——销售成本会吃掉合同。用单位经济而非交易规模区间来测试错配：没有站得住脚的公开阈值能区分自助、内部销售和外勤销售；建模这笔销售——估算的 LTV 对估算的获客成本，以及收回获客成本所需月数。用 David Skok《SaaS Metrics 2.0》（forentrepreneurs.com）的两个参照点：「最好的 SaaS 企业 LTV 与 CAC 之比高于 3，有时高达 7 或 8」，以及「许多最好的 SaaS 企业能在 5-7 个月内收回 CAC」；两者描述的是泛 SaaS 而非开发者工具，把无法合理达到它们的候选当作承诺前要修的销售动作问题，而不是预测。说出在收入之前先动的领先指标，每个模型一个，见参考文件。
6. 第 5 步，按可逆性排序，然后承诺。可逆性不重排任何东西——第 2 步的效率顺序已经决定了承诺什么；这个阶梯只决定先测什么，是努力轴的一个输入，不是同一批候选的第二次排序。两者冲突时（高效模型需要不可逆杠杆），先跑可逆实验，拿到证据再拉杠杆。一个季度内可逆：价格点、打包、免费层限制、增加托管选项。需要努力才可逆：开放一个原本闭源的组件、增加支持层级、进入云市场。实质不可逆：对已发布代码的任何许可证变更、关闭原本开源的 core、关于什么永远免费的公开承诺。source-available 问题在这里、在这个阶梯上决定，而不是在第 2 步排序里（它被刻意排除在外）：它为其下的模型买来保护，代价是贡献者、打包和采购触达，是本页最难撤销的一行，只有在超大规模厂商威胁已经存在时才值得拉。承诺一个 primary 模型和至多一个能干净叠加的 secondary（hosted open source 加企业支持；consumption 加承诺消费下限）；两个 primary 意味着决策还没做。有意识地叠加而非对冲：Index Ventures 的 Mike Volpi 观察到该领域历史上有三代——第一代发现「仅靠支持服务变现软件更难」；当前一代运营「Open Core / Cloud service 混合业务，有多条产品变现路径」；开发者买家如今接受「开源公司理应有一道『付费墙』」。Andreessen Horowitz 的 Peter Levine 五年前就指出同一转变并给出原因：纯支持与服务模型「无法为持续投入提供充足资金」，解法是把开源打包「成一种服务（如云计算或 SaaS）……一个远更稳健灵活的模型」（2014）。两位 VC 相隔五年指出同一代际转变是相互印证，不是可供权衡的第二种意见。把许可和约束一起接受：付费墙是正当的，而一条诚实的边界胜过两条。
7. 第 6 步，逐节验证地写备忘录，产出团队无需你在场就能执行的决策，模板为：# Business model, <product>；## Constraints（许可证现状、部署现实、谁签字）；## Rejected models（被否决的模型，以及否决各自的约束）；## Primary model（卖什么、卖给谁、依赖的前提）；## Paid boundary（什么永远免费、什么付费、界线为何成立）；## Value metric（计量什么、为什么客户本来就在计量它）；## GTM consequence（销售动作、必须建什么、前三项招聘或投入）；## Leading indicator（收入之前先动的那个数字，以及在哪里读它）；## Risks（前三项风险，各带表明它正在发生的信号）；## Revisit triggers（重新打开此决策的事件）。每节呈现并取得一致后再写下一节——买单方判断错了会传导到下面每一行，在第三个标题处发现远比在第九个处便宜。完整范例（含同一批章节的弱版与强版）见 references/business-model-memo-example.md。
8. 区分组织与个人开发者：两者在每个开发者工具里都存在，混淆它们正是套餐死掉的原因。把组织当作收入基础——他们为风险消除、正常运行时间、支持、合规、控制、有人可打电话而付费，容忍由治理功能和长期支持构成的边界，并要为他们的文书工作做规划（安全问卷、DPA、开票）。把个人开发者当作采用与信誉基础——他们为便利付小钱、流失快，并惩罚任何读起来像陷阱的东西。把个人规划为路径、组织规划为付款方；当某个决策对两者确实一样时，价值计量应是付款方本来就在计量的东西。
9. 测量与通过阈值：备忘录定稿前让所选模型通过此阈值并迭代直到通过——第 3 步的五项付费边界测试全部书面回答且无一为「否」；模型恰好一个 primary、至多一个 secondary，每个被否决的原型都有陈述的阻塞理由；价值计量是客户本来就为自己计量的东西，且能在发票到达前预测；每个免费用户的成本以货币量化而非形容词；交易规模与销售动作匹配，建模的 LTV-to-CAC 比和 CAC 回收期写下来，与上述 Skok 参照点（记住是泛 SaaS）的任何差距都要解释而非忽略；领先指标被命名、可在本季度内埋点或排期，并有带日期的目标；至少写三条 revisit trigger，其中一条是失败条件。最后明确报告阈值检查结果——在成本服务上失败的模型不是需要纪律的模型，而是价值计量选错的模型。
10. 区分来源数字与自有基线，每次引用数字都说明是哪一种：把自设基线当作行业标准呈现会给计划虚假信心。绝不编造的数字：区分自助、内部销售、外勤销售的货币区间，以及开发者工具的免费转付费转化率——两者随市场和产品形态波动太大，无法给出站得住脚的数字；要么从用户自己的队列数据推导，要么在能上网时查最新数据。本技能自有、可调整的基线：推荐前两到三个候选；一个 primary 至多一个 secondary；至少三条 revisit trigger 且含一条失败条件；每个否决都带一个具名阻塞约束。有来源、可带署名引用的：LTV-to-CAC 与 CAC 回收期指南（David Skok，《SaaS Metrics 2.0》，泛 SaaS 非开发者工具专属）；sso.tax 关于安全作为付费功能的论点；open core 由 Andrew Lampitt 于 2008 年提出，以及 Bruce Perens 和 OSI 对把受限许可证称为开源的反对（可引用于造词或知名立场，不足以承载论证）；Mike Volpi 关于商业开源三代的论述（TechCrunch, 2019）；Peter Levine 关于纯支持模型对持续投入资金不足、把开源打包为服务能更稳健变现的论证（《Why There Will Never Be Another Red Hat》, a16z, 2014）；FSL 自身对其许可范围的总结（fsl.software）；references/model-archetypes.md 中的许可证变更结果。
11. 避开常见失败模式：open core 没有边界（core 永远足够好，上游永远不产生付费理由——在选模型前而非招第二个销售后测试边界）；把重新许可当救火（采用之后再转 source-available 许可证是一次 fork 加信任事件且有先例——要么早拉许可证杠杆要么永不拉，且绝不把非 OSI 许可证叫「开源」）；把社区构建的功能商业化（把贡献者自己的作品卖回给他们会招来敌意 fork）；没有护栏的消费定价（无支出上限、告警或预测的计量会产生账单惊吓，开发者受众的账单惊吓会变成公开帖子）；在自动化产品上按席位收费（当使用量通过自动化和 agent 而非人头增长时，按席位定价会崩塌）；生态尚未形成就做市场（对还不存在的市场抽成不是模型）；把赞助当公司模型（捐赠养活维护者而非工资单——把资金问题转给 samber/developer-relations-skills@oss-sponsors-fundraising，不要算作收入）；用形容词给免费层定价（「慷慨」不是数字；如果没人算过免费用户的边际成本，模型就未经测试）；决定模型却不决定什么永远免费（那里的沉默会被读作意图关闭，社区会立刻定价进去）；把基线当基准引用（听起来像行业标准的数字——转化率、交易规模区间、「典型」免费转付费百分比——在这个市场多半是民间传说；说明每个数字的来源，否则删掉）。

适用边界 · 注意事项

• 不适用于价格点、打包或免费层限制的具体设计——那属于 samber/developer-relations-skills@devtools-pricing-strategy。
• 不适用于已选定模型后设计开源/闭源线在资产层面的具体形状——那属于 samber/developer-relations-skills@open-source-company-strategy。
• 不适用于许可证选择本身（模型依赖哪个许可证）——那属于 samber/developer-relations-skills@oss-license-strategy。