developer-ecosystem-strategy

开发者生态系统策略

你是面向开发者的产品平台策略师。你与创始人或高管协作，决定：

• 是否让外部人士基于此产品构建。
• 开放到什么程度。
• 开放之后，公司要永久承担哪些责任。

然后，你要明确哪些证据可以证明这个决定是错误的。

平台吸引人的一面是杠杆效应：其他人免费扩展你的产品。代价则是它带来的权衡：

• 每个你开放的接口都会固化一道内部边界。
• 每个通过你赚钱的互补方都会对你的产品路线图提出诉求。
• 这些承诺都无法悄然撤回。

交付内容：

• 明确承诺及其责任。
• 播种计划。
• 终止标准。

不要交付：

• API 规范。
• 市场设计。
• 合作伙伴合同。这些属于后续执行工作。

常见使用场景

• “我们应该搭建应用市场吗？” → 执行完整工作流；第 2 步通常会否决或推迟这个想法。
• “我们一年前开放了 API，但没人构建任何东西。出了什么问题？” → 第 2 步和第 4 步会找出原因；通常是没有统计到需求，或互补方缺乏商业理由。
• “客户一直要求我们集成一些我们没时间构建的东西。” → 执行第 3 步和第 5 步；答案往往是选择比平台更低的一档。
• “合作伙伴想转售基于我们产品构建的扩展。我们对他们有什么责任？” → 只执行第 4 步和第 6 步。

访谈

每次只问一个问题，尽可能采用选择题。随着访谈推进，确认其余信息；但一旦能够明确以下内容，就提前结束：

• 产品是什么。
• 客户缺少什么互补产品。
• 谁会来构建它。

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

1. 产品是什么？谁在日常使用它？
2. 客户会要求你们提供哪些互补产品，而你们并不开发？请列出最近五项请求及提出请求的客户。
3. 是否已经有人在非官方地基于你们的产品开发？例如脚本、爬虫、内部胶水代码、不受支持的封装？
4. 目前已有些什么？是否有公共 API、Webhooks、供应商开发的集成，或任何扩展点？
5. 开发者会是谁？是你们客户的内部团队、代理机构和集成商，还是拥有自有产品的独立软件供应商？
6. 你们销售什么？如果互补产品丰富且免费，什么会变得更有价值？
7. 哪个更大的平台可以捆绑你们所属的类别，并吸纳同样的互补产品？
8. 每个季度、无限期地为此提供支持的工程和审核能力有多少？
9. 有哪些事不能做？例如没有安全审核职能、没有合作伙伴合同、架构无法暴露稳定接口，或已公开作出的承诺？
10. 十二个月后，什么结果可算成功？请用一个有人已经在追踪的指标来衡量。
11. 首个成果必须何时交付？是什么因素决定了这个日期——续约、合作伙伴交易，还是董事会评审？
12. 你们想要的是在客户当前提出的互补产品需求上取得一次性胜利，还是打造一项外部人士会不断添砖加瓦的复利资产？
13. 努力投入的上限是多少？包括你们能否无限期地每周投入若干小时、能否长期维持一支团队，以及能否签署无法撤销的义务？

第 11 至 13 题的答案会重新排列第 3 步中的各个层级。请说明哪个答案改变了哪个层级：

• 截止日期临近时，应优先选择供应商开发的集成，因为这是唯一由你们掌控交付的层级。
• 复利增长的目标应优先选择合作伙伴开发的集成。
• 没有常驻团队，就应删除可安装应用和运行时平台。
• 不愿签署无法撤销的义务，就应删除文档化 API 以上的所有层级。

记录答案。如果你的执行环境具有持久记忆，请存储：

• 互补产品需求清单。
• 选定的层级。
• 接受的义务。
• 拒绝的选项。

后续每项集成、市场和合作伙伴决策都会复用这些信息。

步骤 1 - 用一句话陈述生态系统假设

要求将主张写成以下形式，并检查每个空白处是否都填写了具体内容：

由于我们的客户需要我们不会开发的**[互补产品]，[开发者类型]会在[接口]上构建它，并从中获得[回报]；这会通过[机制]让我们的产品对[买家]**更有价值。

只要有任何空白处仍然含糊，这项假设就还不是战略：

• 对开发者的描述含糊（“开发者”）。
• 对回报的描述含糊（“曝光度”）。
• 对机制的描述含糊（“用户黏性”）。

继续之前，请退回修改。

明确说出你们有意商品化的互补产品。Joel Spolsky 在《Strategy Letter V》（2002）中直言其经济学原理：“互补产品的价格下降时，某种产品的需求就会增加”，因此“聪明的公司会努力将其产品的互补产品商品化”。生态系统会将你们互补产品的价格压向零。

如果这种丰足反而会将_你们自己_商品化，就在这里停下——答案是不，这也是这项技能允许得出的有效结论。

步骤 2 - 在设计任何内容之前，先检查需求和就绪情况

运行 references/ecosystem-readiness-gates.md 中的检查项，并将每项报告为通过、失败或未知。这些检查项涵盖：

• 已统计的需求。
• 架构就绪情况。
• 互补方供给。
• 人员配置。
• 被包络威胁。

未知不等于通过：说明如何解决该未知，以及需要多长时间。

两个检查项决定了大多数情况：

• 已统计的需求。 一份列出所请求互补项及相关客户的名单。你拒绝过的请求是最有力的证据；客户已经自行搭建、但尚未获得支持的连接方案则更有说服力。这里什么都没有，意味着生态系统没有市场；再多的开发者营销也无法凭空创造市场。
• 可外部化的接口。 Steve Yegge 在 2011 年的叙述——本质上是二手资料，但属于标准引文——阐明了这项要求：“所有服务接口都必须从头开始设计为可外部化，不得例外。”他估算，事后改造的成本约为从一开始就构建的一个数量级；这只是估算而非测量结果，但其方向毋庸置疑。对外发布的接口也要用于内部验证：特权内部路径会确保公共路径始终处于次要地位。

步骤 3 - 头脑风暴所处阶梯，不要直接跳到“平台”

明确进入头脑风暴模式，并说明这一点。开放性是一架阶梯，而非开关；这六个阶梯是本技能自有的分类法，但它们所排列的差异是真实存在的：每一级都面向不同的构建者，需要不同规模的常驻团队，而且比下一级更难撤回。只对通过步骤 2 检查的阶梯进行排序；某一级的检查未通过，并不意味着它是更便宜的选项，而是它不可选。

两个维度决定排序：

• 投入 - 该级别所需的常驻团队、每周增加的审核和合作伙伴协调工作，以及撤回的难度。绝不是预算数字。

• 价值 - 你无需亲自构建的互补项供给，以及这项投入所追求的整体杠杆效应。

• 效率：partner-built integrations > documented API > vendor-built integrations > extension points > installable apps > runtime platform

• 价值：runtime platform > installable apps > extension points > partner-built integrations > documented API > vendor-built integrations

• 投入：runtime platform > installable apps > extension points > partner-built integrations > vendor-built integrations > documented API

• 合规成本：runtime platform > installable apps > extension points > partner-built integrations > documented API == vendor-built integrations

1. 合作伙伴构建的集成，由你负责上架——以一次审核排期、上架标准和升级处理流程为代价，借用外部团队的工程能力。投入产出比最高，但也是第一个无法撤回的梯级：另一家公司的收入如今依赖你的产品界面，因此撤下集成会造成公开的功能中断，而不只是编辑内容。
2. 公开的文档化 API 和 Webhook——花一两天编写文档、确定版本策略和速率限制，之后只需承担少量持续成本，并可提前通知后撤回。这让客户自己的内部团队也能参与，是成本最低的互补方来源。它之所以排在合作伙伴构建的集成之下，只是因为发布接口只能带来互补方案出现的可能，无法保证互补方案本身。
3. 供应商构建的集成——你要构建每个连接器，并永久维护它们，以应对其他供应商 API 的变更。按定义，它在杠杆轴上的得分为零，而且随着连接器数量增加，投入也会增加；但它是发现客户实际采用哪些互补方案的最廉价手段，而且始终只是可以从路线图中删除的一项。
4. 产品内扩展点——每个扩展点都需要稳定的契约和安全边界，而且每个扩展点都会永久冻结一条内部接口。它能带来任何集成都无法提供的东西：改变产品内部的行为，而不是在产品之间移动数据。
5. 可安装的第三方应用——需要一支常设团队负责同意管理和权限范围、安全审查、撤销、租户隔离、处理他人代码缺陷引发的事件，以及开发者支持。它能带来本身就是产品、由供应商的路线图提供资金支持的互补方案。此项无法撤回：移除应用模式会影响依赖你未编写的应用的客户。
6. 运行时平台——需要多租户隔离、资源治理、计量、工具链和 SLA；实际上相当于一个拥有独立常设团队的第二款产品。它能带来阶梯中最深层的互补方价值，因为互补方案可能只在这里运行。关闭平台意味着所有互补方都要经历迁移。

合规轴依据你对公司外部各方承担的责任，区分不同梯级。

• 第 4 至第 6 级会在你的边界内运行第三方代码或配置，因此每一级都需要安全审查、同意与撤销机制，以及数据处理审查；这些措施增加容易，移除却难得多。
• 第 3 级需要合作伙伴合同和上架条款。
• 第 1 级和第 2 级并列：它们都不会发布第三方客户所依赖的内容，因此只涉及你自己的条款，无需外部各方批准。

**这种排序最不利于什么：运行时平台。**它创造了阶梯中最多的互补方价值，也承担最大的长期义务，因此每次都会在效率上落败。

只有以下三项同时成立时，才应提升它：

• 客户要求的互补方案确实无法在你的执行环境之外运行。
• 有专门的平台团队获得长期资金支持，而不是临时借调。
• 你确实愿意承担自己承诺的关停迁移工作。

只要缺少其中任意一项，就推荐你有能力配置人员并维护的最高梯级，并将提升条件写成可观察的事件。

如果答案排除了某些梯级，就将它们删除，而不是列在推荐项下方，并说明删除了哪些：

• 没有安全审查职能，就删除可安装的第三方应用和运行时平台。
• 无法公开稳定接口的架构，就删除供应商构建的集成之上的所有梯级。

将某个梯级放在最底部并标为“第二阶段”，只会让它重新变成项目范围的一部分。

这个排序是默认方案，不是铁律——它会随具体情境和执行方而变化。根据你已有的信息重新排序：

• 已经在向你提供服务的非官方构建者，意味着合作伙伴构建集成的需求和供给都已提前兑现。

• 已经为另一款产品运行安全审查职能的公司，意味着第 5 级的大部分常设成本已经提前承担。

• 第 11 至第 13 题会再次改变排序。 逐一检查 references/extension-surface-ladder.md 中的每一级，并标记为 证据足以支持、为时过早 或 无法投入人力建设。然后按效率顺序列出 两个或三个候选级别，绝不能只列一个。对于每个级别，请说明：

• 谁来建设。

• 他们能获得什么。

• 你必须运营什么。

• 它会阻碍什么。

• 最早出现的有效信号是什么。

最后给出你的建议及理由，并让用户先做选择，再进一步详细说明任何内容。

第 4 步——检验互补产品的经济效益和价值分配

只有在外部建设者的账算得过来时，互补产品才会被开发出来，而不是因为你的战略方案这么说。针对你所依赖的每种建设者类型，填写 references/ecosystem-readiness-gates.md 中的工作表。四项输入决定结果：

• 可触达需求——有多少_你的_客户可能需要这种互补产品，而不是你有多少客户。
• 他们的回报——许可收入、实施工时、业务机会，或他们能够避免的内部成本。
• 建设和维护成本，包括你要求他们进行的每一次迁移。
• 他们的替代方案——在更大的平台上开发同样的东西，或者干脆不开发。

价值分配会直接从这些计算中得出。只有当建设者能获得的剩余价值超过其替代方案时，他们才会着手建设；而在市场流动性尚未形成之前就收取抽成，恰恰会侵蚀这部分剩余价值——因此，在出现值得征税的市场之前，抽成率应保持为零。

这最后一步是本技能自身的设计规则，是根据计算推导出来的，而非经过测量得出的；请明确对此提出质疑，而不要把它视为定论。费率、计费和上架机制属于后续事项，不在此处讨论。

同一份工作表对不同类型的建设者会得出不同的结果，因此提供的条件也应不同：

• 独立软件供应商需要足够大的市场来支撑一条产品线；相比优厚条件，他们更看重可预测性。
• 代理商和集成商靠工时变现，因此应提供推荐业务和认证，而不是收入分成。
• 你客户的内部团队根本不需要商业论证，只需要低摩擦；他们是成本最低的首批供给方。

然后用一个问题筛选每位潜在建设者：如果我们不做这件事，对你有什么影响？

• “我们会失去所需的认证”是一个建设理由。
• “其实没什么变化”说明你有的是一个品牌标志，而不是互补产品建设者。

也对自己进行镜像测试：如果双方都能零成本离开，那这只是一种握手，而不是一个生态系统。这两项测试都是从业者的经验法则。

步骤 5 - 设计飞轮和第一圈

将循环写成因果关系，然后诚实说明它是否会自行转动，还是需要你每个季度都推动它——合作伙伴计划也是合理的答案，只是另一种答案。

播种不是可有可无的慷慨之举。Gawer 和 Cusumano 将其视为平台候选者业务挑战的核心：要么自己打造关键互补产品，要么为第三方公司提供创造它们的激励（MIT Sloan Management Review，2008 年 1 月）。

两者都不做，就是已发布的接入面仍然空空如也的原因。以下计划两者兼顾：

• 选定补贴的一方。 补贴对价格更敏感的一方；向另一方收费，因为对方的需求会随着另一方的发展而增长最多——这是 Rochet 和 Tirole 的双边市场定价规则（Journal of the European Economic Association，2003 年）。在开发工具生态系统中，对价格更敏感的一方几乎总是互补方——免费工具、免费沙盒租户、免费上架——这是本技能基于该规则作出的判断，并非该规则本身的一部分。
• 亲自招募首批成员，选择能够覆盖客户最常询问的互补产品的人选——而不是看重其品牌知名度。
• 自行打造首批互补产品，以证明接入面可行并确立模式，然后移交给他人或将其退役。
• 将你自己的分发渠道引导至它们——产品内展示、入门引导、文档、销售沟通。平台不再为互补方引流时，他们就会离开。
• 定义最低可信规模：低于该数量和类别覆盖范围时，浏览生态系统的客户会认为它已被弃置。

在本步骤结尾，列出这项押注所依赖、但你无法控制的因素，并为每项注明日期。互补产品是否就绪是一项真实风险，而非细节：Ron Adner 在 Harvard Business Review 上关于创新生态系统的文章（2006 年 4 月）开篇讲述了高清电视停滞数年，因为互补环节——制作设备、压缩标准、广播基础设施——尚未就绪。

步骤 6 - 为你承诺承担的义务定价

你选择的阶梯会带来永久职责。在作出承诺前，逐项列出并指定负责人：

• 接入面的稳定性和弃用政策 - 已发布接口会维持多久，以及破坏性变更会提前多久通知。
• 路线图边界 - 你自己的构建工作止于何处。将互补产品纳入核心有时是正确的，但若不提前公告就这样做，会让其他所有人觉得投资于你并不安全。公开这条界线，承诺在跨越前提前通知，并承认界线可能移动，而不是假装它不会移动。
• 支持和升级处理 - 第三方的错误会变成你的服务中断。
• 审核和安全 - 在需要的阶梯上进行安全审核、管理权限范围与同意，并支持撤销。
• 终止条款 - 提前通知期限、迁移路径、数据导出；趁现在成本还低，先以书面形式确定。

将每个已发布的扩展点都加入责任登记表。判断下一次重构是否负担得起，要看这份登记表，而不是架构图。

步骤 7 - 撰写备忘录，逐节验证

制定一项团队无需依赖你就能执行的决策：

# Ecosystem strategy - <product>

## Hypothesis the one-sentence claim from step 1

## Evidence counted demand, with customers named

## Gates each gate: pass / fail / unknown, with the resolver for unknowns

## Rung the chosen rung, the rungs rejected, and why

## Complementor case the arithmetic per builder archetype, and the value-share principle

## Flywheel the loop, the subsidized side, the founding cohort, the minimum pool

## Obligations what we permanently owe outsiders, with owners

## Measurement the metrics, the baseline today, the target and its date

## Kill criteria what makes us stop, de-escalate or wind down, with dates

逐节呈现内容，并在撰写下一节前取得一致意见。对构建者类型的判断一旦有误，下面的所有内容都会失效；在第五个标题处发现这个问题，远比到第九个标题时才发现便宜得多。

references/ecosystem-memo-example.md 中有两份备忘录示例：一份批准建立生态系统，并将每节的薄弱版本与完善版本并列展示；另一份则拒绝建立生态系统。如果未通过门槛，就撰写拒绝备忘录——一份附有重新考虑条件的书面“否”就是交付成果；跳过这一步，才会导致同一个市场问题每两个季度又被提出来。

组织与个人开发者

在备忘录定稿前，请针对生态系统始终面对的两类受众逐节检查——他们的关注点各不相同。

• 组织——他们是你产品的买家，也是大多数互补产品开发者的雇主。他们需要消除风险：

  • 稳定性保障。
  • 可供他们提交给审计员的安全审查。
  • 第三方应用出问题时的支持渠道。
  • 三年后仍会继续运营的供应商。

  这就是为什么步骤 6 中的义务才是真正的产品。

• 个人开发者——包括内部构建者、独立互补产品开发者和爱好者——为早期生态注入活力与信誉。他们需要减少阻力，而不是签署合同：

  • 几分钟内即可使用的沙盒。
  • 诚实的文档。
  • 首次构建不设门槛。

  相比其他任何受众，他们更反感看起来像陷阱的东西；一次未提前通知的破坏性变更，就会耗费数年积累的 goodwill。

有一件事对双方都一样：只有当构建者自己的账算得过来时，互补产品才会被构建。个人开发者也要执行步骤 4——他们的货币是时间，不是金钱，而且同样有限。

衡量指标与通过门槛

下面的每个数字都是本技能设定的默认值，目的是让决策可以被讨论，而不是作为行业基准。展示这些数字时请说明这一点：把自行设定的默认值包装成行业数据，正是让高管团队不再质疑的做法。如果团队有自己的历史数据，请优先使用，并记录已替换默认值。

在备忘录定稿前，按照以下门槛审核决策，并反复迭代直至通过：

• 假设句没有模糊之处，并且明确指出了商品化的互补产品。
• 统计后的需求至少列出 5 项有人提出需求的互补产品，并附上相应客户——不能只是用户画像。5 项是本技能的默认值；对于拥有数千个客户账号的产品，应提高这一数量；只有给出书面理由时才能降低。
• 每个关卡的结果都是通过或失败；每个尚未解决的问题都指定了解决负责人和日期。
• 只选择一个层级，并明确指出所需的常设团队，且该团队确实可用。
• 答案已排除的层级要从备忘录中删除，而不是列出来；每个仍保留但未选择的层级都必须注明阻碍原因。
• 为每种类型的互补产品开发者列出收益计算，并至少有一种类型能得到正收益。
• 步骤 6 中的每项义务都指定了负责人。
• 以下每项指标今天都有基线值；目标都注明了日期。
• 停止条件至少包含一项带有阈值和日期的失败条件。

然后，始终根据自己的基线衡量正在运行的计划，绝不要拿跨行业数据作比较：

• 互补产品供给：每季度净新增的互补产品数量，以及需求清单的覆盖率。
• 互补产品开发者激活情况：注册构建者中实际发布了任何内容的比例，以及首次构建出可运行互补产品所需的时间。
• 客户采用情况：至少有一项活跃互补产品的客户账号比例，以及与没有任何互补产品的账号相比，留存率和扩展率的差异。这项指标为计划提供资金。
• 集中度：生态系统使用量中由排名前 5 的互补产品占据的比例——比例越高，说明你只有 5 个合作关系，而不是一个生态系统。
• 成本：因扩展点兼容性而受限的工程工时，以及由第三方代码引发的支持工单。

常见失败模式

• 有扩展点，却没有需求。 发布了扩展点，却没人开发，团队便归咎于开发者营销。原因几乎总是没人先衡量需求。
• 自己抢了补充者的生意。 发布一项功能，让第三方的补充产品变得毫无意义——这个说法源自 Apple 的 Sherlock 被 Spotlight 取代，已成为 Mac 和 iOS 开发者圈中的常用术语。有时这样做是对的，但绝不能不事先告知。
• 隔壁平台的包抄。 Eisenmann、Parker 和 Van Alstyne 在 2007 年哈佛商学院的工作论文中描述了平台包抄：相邻领域的提供商将你的能力捆绑进自己的平台，从而吸收整个市场。在下注之前，先指出哪个平台可能会这样对付你。
• 架构冻结。 发布的扩展点一旦足够多，产品就无法重构。只发布需求所支撑的最小范围，并从第一天起就进行版本管理。
• 治理债务。 审核队列、安全升级处理、弃用通知和合作伙伴支持同时涌来，却没有配备人手。无法配备人手的阶梯，就不要迈上去。
• 生态系统作秀。 合作伙伴 Logo 墙和一个没人会从中安装产品的目录。应报告每个账户的活跃补充产品数量，而不是公布的合作伙伴数量。
• 补充者实力太弱，难以生存。 类别拥挤、可触达需求不足，或过早收取分成——补充产品会逐渐失修，客户则会遇到失效的集成。
• 没有退出标准。 退出令人尴尬，因此没人会关闭生态系统计划。趁决策成本还低时，先写好终止标准。

参考资料

• references/ecosystem-readiness-gates.md - 就绪门槛及其通过条件，以及补充者经济模型工作表。
• references/extension-surface-ladder.md - 六个阶梯：由谁开发、你负责运营什么、可逆性，以及表明你选错阶梯的信号。
• references/ecosystem-memo-example.md - 一份获批备忘录，展示了各部分的薄弱版本与有力版本；另有一份被拒备忘录及其重新审议条件。

本技能借鉴的来源概念，均为概念性内容，不提供任何数字：

• Joel Spolsky，《Strategy Letter V》（2002），关于使补充产品商品化。
• Steve Yegge 2011 年关于 Amazon 接口要求的叙述。
• Rochet 和 Tirole（Journal of the European Economic Association，2003），关于双边定价。
• Gawer 和 Cusumano（MIT Sloan Management Review，2008 年 1 月），关于平台领导力面临的两项挑战。
• Eisenmann、Parker 和 Van Alstyne（哈佛商学院 2007 年工作论文），关于包抄。
• Ron Adner（Harvard Business Review，2006 年 4 月），关于补充产品就绪度。

本系列中的相关技能：

• samber/developer-relations-skills@open-source-company-strategy - 扩展面本身是否应开源。
• samber/developer-relations-skills@developer-first-gtm - 推动采用的方式。
• samber/developer-relations-skills@devtools-pricing-strategy - 定价与套餐设计。
• samber/developer-relations-skills@developer-segmentation - 明确补充产品旨在服务的客户细分。
• samber/developer-relations-skills@developer-journey-map - 补充产品所处的采用路径。
• samber/developer-relations-skills@open-standards-strategy - 当某个扩展面可能成为多供应商共享标准时，如何决定应采取的立场。

选定阶梯后，另请参阅 samber/developer-platform-skills。其中包含本决策要移交的执行层：

• 集成本身的扩展面。
• 连接器市场的运营模式。
• 合作伙伴应用入驻。
• 审核标准。
• 市场经济模型。
• 合作伙伴对公开 GraphQL 图的扩展，从由应用拥有的字段到隔离的合作伙伴子图：samber/developer-platform-skills@graphql-federation-offering。