公司级开源战略：决定哪些资产开源、哪些闭源…

当公司需要制定整体开源边界（而非单个项目的许可证选择）时，逐资产给出开源/闭源结论、价值捕获机制、决策权归属和公开不撤回承诺。

适用场景

解决思路

1. 先做范围检查：若整个问题属于许可证文本/CLA vs DCO、已开源项目的治理、分发、发布公告、收入模型或资助他人项目，则直接转交对应技能；本技能只设定那条线，其他技能执行。
2. 通过访谈收集信息，一次只问一个问题并尽量给出选项，直到能说出：公司在卖什么、候选资产、动机和决策者。访谈问题包括：公司今天卖什么、客户为什么付费；考虑开源什么（产品核心、SDK/客户端库、协议/格式规范、内部工具、基础设施组件、参考实现、数据集、测试/一致性套件）；触发原因（竞争对手动作、招聘问题、客户或监管要求、合作伙伴要规范、收购、成本论证、团队成员想开源）；公司类型（风投支持的初创、上市/后期软件公司、非软件公司）；谁按角色可批准或否决（创始人、产品负责人、评审委员会、CEO）以及是否有人书面声明过；买家是企业（有采购和法律审查）还是个人开发者；已经开源了什么及其表现（外部贡献者、issue 响应、最近发布）；哪个竞争对手或平台可能把开源资产当作服务来运营并以此对抗你，什么还能阻止他们；未来两年由谁按名字维护该开源资产、每周多少小时；固定约束（投资人/董事会期望、现有客户合同、雇主 IP 条款、监管风险、已发布的许可证）；18 个月后成功是什么样、要可观察；是否有必须决定的日期（董事会、发布、客户续约、融资轮）；这是单个资产的发布还是未来所有资产继承的政策；投入上限（维护者每周小时数、年度预算、可接受的不可逆程度）。
3. 在提出任何边界线之前先问第 12-14 个问题，并说明哪个回答影响了哪个候选方案：硬性日期会提升“接口开放”方案（唯一不需要分层矩阵或高管签字的线）；要继承的政策会提升“按买家分层开放核心”方案；低不可逆容忍度会直接删除“按买家分层”方案而不是降级它。
4. 若有持久记忆，存储动机、线两侧的资产、成功目标、决策者和复审触发条件；后续许可证、治理、发布和分发决策都从中读取，重新推导会产生不同的线。
5. 第 1 步——逐项清点资产：把每个候选资产单独列一行（客户端库和 SDK、协议/格式/API 规范、内部开发者工具、基础设施组件、参考实现、数据模式、测试和一致性套件、基准、数据集、产品核心），因为它们很少共享同一结论。
6. 把每个资产再拆一层，分为“差异化层”和它的“使能层”——例如 Sony 为 Android 媒体框架做贡献但保留微笑识别等相机特效闭源；大多数决策发生在这个内部分割处，而不是资产边界处。
7. 第 2 步——在评估任何东西之前先命名动机：从以下短名单中选出一个主要动机并大声说出来，拒绝那些通不过自身检验的动机——商品化你的互补品、成本分摊、阻止竞争对手拥有标准、市场创造、人才、信任与可审计性、通过向上游贡献降低维护成本、外部需求拉动。把需求拉动当作一等动机而非借口（Henkel、Schöberl 和 Alexy 2014 发现客户需求是选择性披露的初始触发因素，远比内部 deliberation 更常见）。不要对动机排序；这是诊断而非投资菜单。
8. 立即指出两个失败信号：“商品化你的互补品”若没有说明哪个产品需求会上升，就是装饰（Spolsky 的反例是 Sun 的 Java 商品化了 Sun 所卖的硬件）；“成本分摊”若没有其他组织愿意共同出资，就只是发布代码。
9. 第 3 步——按公司类型校准：风投支持的初创公司以分发先于变现，原始单位是买家画像，创始人决定，当前反转风险低但采用规模大后极高；上市或后期软件公司要捍卫收入线，原始单位是部署模式（允许自托管、不允许竞争的托管服务），跨职能加高管签字，反转风险三者中最高；非软件公司的动机是成本分摊、人才、外部要求，原始单位是产品内部的使能层 vs 差异化层，由含法务的治理委员会决定，时间尺度与维护者不匹配。
10. 第 4 步——先头脑风暴再画线：明确进入头脑风暴模式并说明，先不提出结论。对每个候选资产问：完全开放、完全闭源、或带特定保留地开放，公司会有什么变化。然后提出 2 或 3 条候选线（绝不要只提一条），排序而非罗列。删除被访谈固定约束排除的线（例如客户合同或监管风险覆盖核心会直接排除按买家分层），并说明是哪个约束删除了它。
11. 按默认顺序排序候选线（`>` 表示该维度上更多）：效率 `interface-open > infrastructure-only > buyer-tiered open core`；价值 `buyer-tiered > interface-open > infrastructure-only`；投入 `buyer-tiered > infrastructure-only > interface-open`；不可逆性 `buyer-tiered > infrastructure-only == interface-open`；合规成本 `buyer-tiered > interface-open > infrastructure-only`。
12. 三条候选线：1. 接口开放——开放规范、SDK、参考实现，接口背后的一切保持闭源；投入是一个库规模的持续工作，没有可撤回的东西；换来集成和采用，不消耗价值捕获面。2. 仅基础设施——开放非差异化基础设施和内部工具，产品保持闭源；每个仓库一周投入，之后每个仓库持续工作（常被低估，是 dump-and-run 的直接路径）；换来人才和成本分摊，不动收入线。3. 按买家分层开放核心——开放核心，付费层级按“谁买这个功能”而非“功能多好”定义；画线需一个季度，之后持续工作来对照线审查每个新功能；是唯一反转会被 fork 者和采购定价的线；换来核心采用加基于它的收入线。
13. 第 1 和第 2 条在不可逆性上真正打平：两者都不发布公司所卖的东西，最坏情况是废弃仓库而非社区定价的反转。它们在其他所有维度上分开，所以这个平局本身不决定什么。
14. 默认顺序会饿死第 3 条线（这里价值最高的线）：投入最大，且是唯一有真正不可逆性的，所以在任何比率决定中都会输。但在以下情况要主动提升它：买家根本不会采用闭源核心（卖给工程师的开发者工具）；竞争对手已经发布了开源等价物；分发是已命名的动机且核心正是必须被采用的东西。
15. 只有按买家分层是已发布的模型（GitLab 的）；另外两条线和上述排序是本技能自己的默认值，会随公司和执行者变化。根据已知情况重新排序：已有平台团队会把第 1 条线定价接近零；唯一开源仓库已被废弃的公司应把第 2 条线的投入读得比写的更高；有内部开源法务的公司会降低第 3 条线的合规成本。
16. 给每条幸存线说明：开放什么、什么捕获价值、每年成本、接受的风险、服务的动机。然后让它经受“根本不画线”的最强论证——Adam Jacob 基于十三年建设 Chef 社区的经验（OSCON 2019）认为价值在于产品的整体而非专有的一小片。问闭源部分捕获了什么整体没有捕获的东西；回答不了的线还不适合呈现。说出你的推荐和理由，让用户选择后再展开细节。
17. 第 5 步——让每个资产通过五道门，按顺序书面进行：1. 不可逆性——假设这永远不能再闭源；如果答案会变，诚实的结论是“还不”。2. 差异化还是上下文——公司是因为这个资产赢单，还是仅仅需要它存在？对使能层和差异化层分别运行。3. 价值捕获——说出什么还能阻止有能力的竞争对手转售它：托管和运营、数据、网络效应、商标、支持、付费层级。“许可证”不是答案；它阻止不了合规的竞争对手，也替代不了商标。4. 贡献可行性——外部人会贡献吗？测试可访问性而非仅透明度：West 和 O'Mahony 发现赞助项目远更愿意让工作可见，而非让外部人参与，这通常是“我们开源了但没人来”的解释。5. 所有权——有具名维护者、发布节奏和 issue 响应承诺，否则资产不发布。这些是门不是排序选项：它们位于第 4 步排序之外，任何比率都不能推翻。未通过第 1、3 或 5 门的资产无论其他门多好看都保持闭源；未通过第 2 或 4 门通常意味着以后开放，或开放更小的一块。
18. 第 6 步——用竞争场景压力测试这条线：写出对抗性场景——点名具体的竞争对手或平台、描述他们会把什么当作托管服务来运营、说明公司还持有什么。如果什么都不持有，线就是错的：移动资产，而不是移动许可证。
19. 仅当场景具体时才提出源码可用和延迟开源工具（BUSL、FSL 等），称它们为“源码可用”而非“开源”，并把工具选择交给 `samber/developer-relations-skills@oss-license-strategy`。
20. 第 7 步——命名决策者和承诺：从两侧约束未来移动线的时刻。决策权控制“谁”能移动线，公开承诺提高移动线的“价格”。大多数战略两者都跳过；两者都要产出。
21. 决策权线：把“我们应该开源这个吗？”（业务上下文判断）与“开源这个合规吗？”（专业审查）分开。Google 把前者交给发布创建者的经理，理由是开源办公室缺乏业务上下文，并把许可、专利和隐私审查作为并行批准者。GitLab 通过具名矩阵路由大型分层决策，其中 CEO 决定。写下谁在这里扮演每个角色，即使两个角色是同一个人。
22. 不撤回承诺：公开声明公司承诺永不闭源什么。GitLab 发布了十一项此类承诺——包括已开源的功能永远不会移到付费层级——并已运营专有层级十年，相对少有持续反弹。Docker 是反例：2017 年把 `docker/docker` 改名为 `moby/moby`，没有许可证变更也没有撤回代码，仍招致严重反弹——有力证据表明社区会单独为治理意外定价。
23. 第 8 步——计算运营前提成本：在签字前说明谁拥有每个职能，即使是一个人 20% 时间：对外代码的发布审查、入站许可证政策、上游优先规则、贡献政策、经常性预算。上游优先比其规模更重要：私有补丁每次升级都要重新付出，上游化的补丁由项目维护。跳过它，支撑战略的维护动机就永远不会实现。
24. 第 9 步——写简报并逐节验证：产出一份高管可行动的文件，包含以下章节：我们卖什么——价值捕获面，一段话；动机——主要动机及它通过自身检验的证据；开放——资产，每个附门结果和所有者；闭源——资产，每个附未通过的门；尚未——推迟的资产及改变结论的条件；竞争场景——对抗性场景和我们仍持有什么；决策权——谁决定、谁审查、谁能否决；承诺——我们承诺永不闭源什么，已发布；运营模型——所有者、政策、年度成本；度量——每个资产声明的目标和复审触发条件。
25. 一次呈现一节，获得同意后再写下一节：错误的动机会传播到下面每一行，在第二个标题处发现远比第十个便宜。
26. 度量：在决策时就在简报中为每个资产声明成功目标（事后补一个总会产生美化决策的数字），对照动机度量，并在每个规划周期重新运行评估。
27. 用以下阈值检查简报并迭代直到通过：每个候选资产恰好出现一次，在开放、闭源或尚未中；命名一个主要动机及它通过自身检验的证据；每个开放资产有具名所有者、发布节奏和 issue 响应承诺；价值捕获答案是机制而非许可证，对抗性场景点名了具体竞争对手；有具名角色决定、具名角色单独审查合规，且至少有一项公司会发布且不撤回的承诺；年度成本已说明且在某人同意的预算内；存在复审触发条件：下一个规划周期，加上强制提前重读的事件（竞争对手的托管服务、收购、融资轮、fork、维护者离开）。
28. 明确报告检查结果。在所有权上失败的简报不是需要纪律的简报，而是多了一个仓库的简报。
29. 避免常见失败模式：开源洗白（只读镜像或源码可用许可证却称为开源）；隐藏或移动线（拒绝公布开放核心线位置是可信度失败，把已开源功能移到付费层级是声誉事件——在线以上添加新功能则不是）；治理意外（把单方面变更当作已完成决定宣布）；dump-and-run 以及把透明度误认为开放；开放错误的互补品，或期望许可证条款做产品、商标或运营优势的工作；把十个资产当作一个问题决定且没有复审触发条件；忽视供给侧反转（前 Chef 员工在 2019 年合同纠纷中移除了他维护的组件，拖垮了公司部分商业业务——没有边界框架覆盖这一点，把它列为残余风险而非假装已处理）。

适用边界 · 注意事项

• 当整个问题属于许可证文本/CLA vs DCO、已开源项目的治理、分发策略、发布公告、收入模型或资助他人项目时，应转交对应技能，而不是用本技能。
• 当问题只是单个项目的许可证选择或发布计划时，本技能是宏观战略技能，不适用。
• 当公司没有可命名的产品、候选资产、动机或决策者时，应先完成访谈，不要直接画线。