回到 [72讲] 提到的认知：一个软件工程的生命周期中，包含着很多个彼此完全独立的子软件工程。这些子软件工程中，绝大多数并非自研——它们可能是开源软件、云服务或外部团队外包的模块。
这意味着，跨组织的分工与协同不仅常见，而且不可避免。本节关注的核心问题是：什么自己做？什么交给别人做？交给谁？
交叉参考：[72讲] 建立了发布单元与版本管理的确定性基础，本节讨论跨组织依赖的管理。[75讲] 将在此基础上讨论版本迭代的规划——自研与外包的决策直接影响迭代节奏。
| 依赖类型 | 本质 | 自主可控 | 成本结构 | 适用场景 |
|---|---|---|---|---|
| 开源软件 | 社区驱动的公共基础设施 | 高——源代码可见、可改 | 零授权费 / 维护成本 | 通用性强的底层能力 |
| 云服务 | 供应商托管的服务 | 低——黑盒调用、依赖 SLA | 按用量付费 | 非核心业务的基础设施 |
| 外包 | 定制化开发 | 中——可约定交付物 | 合同约定 | 非核心业务的功能模块 |
开源软件是公司参与行业竞争的生态战略。公司与公司之间的竞争越来越像国与国之间的竞争，更像两大生态之间的竞争。大量的软件被开源出来，目的是：
云服务本质上是"基础能力的社会化"。随着公有云越来越成熟，越来越多的基础能力被纳入云服务范畴：
不要排斥外包。 很多人对业务外包有天然的排斥心理，这是不理性不客观的。原因有二：
所有围绕目标用户群体需求而产生的业务子系统，都应该自研。 原因有二：
引入开源软件不是"下载使用"那么简单：
外包的本质是"以接口为边界的分工"。外包管理的关键是：
云服务是黑盒调用，自主可控程度最低。关键风险点：
| 维度 | 开源软件 | 云服务 |
|---|---|---|
| 自主可控 | 高 | 低 |
| 运维成本 | 高——自行维护 | 低——供应商托管 |
| 灵活性 | 高——可改源码 | 低——黑盒调用 |
| 前期投入 | 中——学习成本 | 低——开箱即用 |
| 长期成本 | 低——无授权费 | 高——按用量付费 |
| 适用阶段 | 早期 / 有定制需求 | 快速验证 / 非核心能力 |
| 维度 | 外包 | 自建团队 |
|---|---|---|
| 成本弹性 | 高——按需增减 | 低——固定人力成本 |
| 质量可控性 | 中——依赖合同约束 | 高——直接管理 |
| 知识积累 | 低——知识在外包团队 | 高——知识在内部积累 |
| 响应速度 | 低——需求传递链路长 | 高——直接沟通 |
| 适用场景 | 非核心业务、短期需求 | 核心业务、长期迭代 |
七牛云作为云服务提供商，本身就是"基础能力社会化"的实践者。同时，七牛也开源了大量基础设施软件，参与构建行业生态。这种"使用开源 + 贡献开源"的双向参与，是现代科技公司的标准范式。
典型架构决策：
将核心业务外包是最常见的战略错误。外包团队不会对目标用户产生同理心，做出的产品往往缺乏灵魂。短期看节省人力成本，长期看丧失核心竞争力。
引入开源软件后不建立治理机制：
正确做法：建立开源软件的引入评估和持续治理流程。
所有基础设施都依赖云服务，没有降级预案：
正确做法：核心能力自建，非核心能力使用云服务，始终保留降级预案。
跨组织分工不可避免：软件工程的生命周期中包含大量外部依赖。正确处理开源、云服务、外包的关系，是架构师的核心职责。
核心业务必须自研：围绕目标用户群体的业务不可外包。外包团队缺乏对目标用户的同理心。
开源软件需要治理：License 合规、Fork 管理、安全漏洞跟踪、社区参与——引入不是终点，治理才是关键。
云服务是基础能力社会化：非核心业务优先选用云服务，但需关注 SLA、数据安全、供应商锁定风险。
外包的关键是接口契约：明确的交付物规格和验收标准，是外包管理的基础。
公司与公司的竞争是生态的竞争：开源不仅是技术选择，更是生态战略。
下一篇 [75讲 - 软件版本迭代的规划] 将讨论如何规划自研与外包模块的迭代节奏——哪些先做，哪些后做。