企业内源与开源协作文化

引言

一家超过两千人的研发组织，几乎必然同时运行着三到五套功能重叠的「用户中心」或「配置中心」，只是它们分别长在不同事业部的代码库里，谁也看不见谁。内源（InnerSource）要解决的就是这个结构性浪费：把开源社区那套「公开代码、异步协作、上游优先」的协作方式搬进企业防火墙之内，让代码的默认可见性从「本团队」变成「全公司」。它不产生新的技术，产生的是新的组织默认值。

这件事真正的难点从来不在工具。拉一套 GitLab Self-Managed、配几个组权限，一周就能做完；难的是当隔壁团队给你的代码提了一个 PR，你有没有义务在三个工作日内回复，谁来决定合不合，合了之后 bug 算谁的，写代码的人绩效里算不算数。内源失败的项目，九成不是死于平台能力，而是死于责任边界没定义清楚：仓库 owner 觉得开放之后要白干活，贡献者觉得提了 PR 石沉大海，于是双方都退回私有仓库，一年后内源门户里躺着一堆 404 死链。

还有一个常被忽略的约束：内源与开源共享同一批人、同一套工具链，但目标函数不同。开源的产出是外部采用者和生态位，内源的产出是内部复用率与交付周期。把两者混为一谈，会出现「为了将来开源而强制内部 PR 走 CLA」这类过度设计，也会出现「既然都内源了何必再学开源规范」这类短视。正确的姿势是让内源成为开源的预科班——流程、署名、许可证纪律先在公司内部跑顺，成熟项目再平滑外发。

本文按落地顺序组织：先讲内源与开源的继承关系，再讲项目分级、权限模型、内源办公室（ISPO）这类制度骨架，然后是激励、协作规范、工具链这些日常运转机制，最后讲与开源治理的衔接和从试点到规模化的路线图。每节都给出可执行的配置片段与可量化的指标，读者可以按自己的组织阶段跳读。

目录

1. 内源与开源的关系
2. 内源项目分级与开放流程
3. 代码托管与权限模型
4. 内源办公室（ISPO）的职责与组织位置
5. 贡献激励与考核挂钩
6. 跨团队协作规范
7. 工具链与自动化
8. 与开源治理的衔接
9. 从试点到规模化

1. 内源与开源的关系

InnerSource 这个词由 Tim O’Reilly 在 2000 年提出，但真正把它沉淀成方法论的是 InnerSource Commons 基金会（2020 年注册为独立非营利组织）。它维护的 Patterns 库收录了三十余个可直接套用的协作模式，其中最核心的是「三角色模型」：Product Owner 负责业务方向与优先级，Trusted Committer 负责代码质量与社区健康，Contributor 来自使用方、以提交 PR 的方式获得所需功能。这套角色划分的意义在于，它把「谁说了算」和「谁写代码」解耦，避免开放代码等于开放 roadmap。

从开源移植过来的实践清单可以列得很具体：

• 默认公开的仓库可见性，搜索即可发现，无需打听谁在做
• 基于 issue 的异步讨论，讨论过程与结论留在可检索的地方
• 拉取请求而非分支直推，所有改动经过评审并留下记录
• 上游优先（Upstream First），能在依赖库改的就不在本地打补丁
• 书面化的贡献指南与行为准则，新人不用靠熟人带路
• 基于信任而非职级的评审权，Trusted Committer 可以不是管理者

企业不需要发明新东西，只需要决定这些实践在内部如何映射到已有的组织层级和审批链条上。

差异同样关键，而且往往决定成败：

• 开源项目的贡献者没有雇佣关系，内源贡献者的绩效由他的直属经理评定，这导致一个独特风险：贡献者的经理可能认为「帮别人写代码」是不务正业
• 开源里 fork 是基本自由，内源里 fork 需要审批，因为内部代码库数量膨胀会带来合规与安全审计成本
• 开源有公开的许可证作为法律边界，内源的边界由保密协议、数据分级和访问审计共同构成
• 开源靠声望驱动，内源必须靠绩效与认可机制驱动，声望在内部流通性差得多

判断一个组织是否真的在做内源，看一个指标就够了：跨团队 PR 占全部合并 PR 的比例。低于 5% 说明只是「代码放在了一起」，超过 20% 才算进入协作状态。这个阈值不需要精确，它的价值在于给出一个共同语言，让管理层能区分「我们开放了代码」和「我们在协作」这两件完全不同的事。

三角色模型的落地映射

InnerSource Commons 的三角色模型在企业里需要映射到真实岗位，映射错了就会出现「有人担责但没人干活」或「有人干活但改不动代码」这两类僵局：

• Product Owner 通常由项目的业务归属方负责人担任，他决定 roadmap，也承担项目不被采用的后果
• Trusted Committer 通常由 owner 团队的资深工程师担任，他对代码质量有一票否决权，但没有排期权
• Contributor 是使用方团队的任意工程师，他的诉求是「我的问题被解决」，不关心项目长期方向
• 一个常见错误是把 Product Owner 交给 ISPO，ISPO 既不了解业务优先级也不承担后果，决策必然失真

映射清楚之后，一个 PR 该不该合就有了明确判据：技术上由 Trusted Committer 判断，方向上由 Product Owner 判断，两者意见冲突时先按「不破坏现有用户」的原则保守处理，再走 RFC 讨论。

2. 内源项目分级与开放流程

把所有仓库一键设为「全公司可见」是最常见的自杀式起步。正确做法是先定义分级，让开放程度与项目的成熟度、owner 的准备度匹配。分级不是技术属性，而是治理属性，因此必须由 ISPO 统一命名并写入制度文档，避免每个部门自创一套，最后没人能批量审计。

一个可用的五级模型如下，每级的差别体现在三件事上：谁能读、谁能提、谁负责响应：

• L0 私有：仅团队可见，未做任何开放准备，也是新建仓库的默认状态
• L1 内部只读：全公司可读、可搜索，但只接受 issue 反馈，不接受代码
• L2 内部可贡献：接受 PR，但合并权仅在 owner 团队，owner 承诺响应时效
• L3 共享所有权：引入 Trusted Committer，非 owner 团队的成员可被授予合并权
• L4 可外发：已完成许可证与依赖合规审查，具备对外开源的条件

开放流程建议做成一条有状态的流水线，每一步都有明确的产出物与责任人，而不是一封邮件来回扯皮：

1. 仓库 owner 发起申请并填写复用场景，说明谁在用、用来干什么
2. 架构委员会评估是否与既有能力重复、是否有更合适的既有项目可以贡献而不是新建
3. 法务与安全确认代码中不含第三方受限代码、无硬编码密钥、无客户数据
4. ISPO 登记入库并打上分级标签，同时在门户上生成条目
5. 开放后 30 天做一次回访，确认 PR 响应时效是否达标

整个流程的目标时长是五个工作日以内，超过两周的审批会显著抑制申请意愿。流程慢的根因通常是审批人职责不清，而不是工作量真的大，因此每一步都要指定唯一责任人而不是一个委员会。

责任边界必须在开放时白纸黑字写清楚，这是避免后期扯皮的关键。推荐三条默认规则：

• roadmap 决定权归 owner，贡献者不能通过 PR 改变公开 API 契约，改契约需走 RFC 流程
• owner 承诺对 L2 以上项目的 PR 在三个工作日内给出首次响应，做不到的项目必须降级回 L1
• 贡献者对其提交代码的正确性负责，但集成后的线上事故由部署方负责，因为部署方拥有最终发布决策
• 分级标签必须机器可读，innersource-level:L2 写进仓库 topic，便于批量审计与报表
• 降级机制同样重要，连续两个季度未达 SLA 的项目自动降一级并在门户公示

升级、降级与退出

分级必须是双向可流动的，否则标签会退化成一次性贴纸。升级路径通常是 L1 → L2 → L3 逐级申请，每级要求不同的准备度：升 L2 要求有明确的复用方和通过依赖扫描，升 L3 要求有两名以上非 owner 团队的 Trusted Committer 并完成架构评审，升 L4 要求通过完整的开源外发检查。降级则应当是自动的，触发条件只有一条：连续两个季度未满足本级承诺的 SLA。

退出机制最容易被忽略。当项目被更好的方案取代、或业务下线时，必须有一个正式的归档流程：仓库设为只读并打上 archived 标签、门户条目标注「已归档」并指向替代方案、向所有引用方发送迁移通知、保留六个月后移入冷存储。没有退出机制的内源门户，两年后一定会变成一个既有死链又有僵尸项目的沼泽，反而降低了整个内源体系的可信度。

3. 代码托管与权限模型

内源的技术底座通常是 GitHub Enterprise Server 或 GitLab Self-Managed，少数公司用 Bitbucket Data Center。选型差异不大，真正决定体验的是权限模型是否与 HR 系统打通。理想状态是 LDAP/SCIM 同步组织架构，团队即组，人一入职自动进组，一离职自动踢出，中间不经过任何人工操作。手工维护的权限表在半年内必然腐化，最终表现为离职员工的 token 还能推代码。

权限层级建议压在四层以内，层级越多越难审计：

• 组织（org）：决定最粗粒度的可见性，内源通常给全员 read
• 组（team）：决定写权限，由 HR 系统同步而来，不手工维护
• 仓库（repo）：在组的基础上按项目调整，是唯一允许例外的层
• 分支保护规则：决定主干与发布分支的写入条件，通常全公司统一

内源的核心诉求是「读权限放宽、写权限收紧」，因此 org 层面给全员 read，写权限通过 team 精确授予。GitLab 里对应的是 visibility: internal 加上 protected branch 的 allowed_to_push 白名单；GitHub 里对应的是 internal repository 加上 team 的 write 权限。

CODEOWNERS 是内源里最重要的一个文件，它把「谁负责这个目录」变成机器可执行的规则，让 PR 自动路由到正确的评审人。写法上支持按路径、按文件后缀、按通配符匹配，后面可以跟团队名。文件放在仓库根目录、docs/ 或 .github/ 下均可被识别：

*                       @platform/core-team
/docs/                  @tech-writers
/api/v2/                @platform/api-owners @security/reviewers
*.proto                 @platform/api-owners
/infra/terraform/       @sre/terraform

分支保护是权限模型的最后一道闸。必须开启的项包括：禁止直接 push 到主干、要求至少一名非作者审批、要求 CI 通过、禁止 force push、对 release/* 分支额外要求 owner 审批。这些规则应当用策略即代码的方式管理而非在 UI 上手工勾选，这样新仓库可以批量继承基线，审计时也能一键导出全量配置——具体做法可参考策略即代码治理 的实践。

分支保护基线

把所有仓库的分支保护收敛到一份可版本化的基线，是新仓库能快速达到「可接受贡献」状态的前提。下面是一份 GitHub ruleset 的最小可用形态，用 YAML 表达便于放进 IaC 仓库统一管理与批量下发：

name: innersource-main-baseline
target: branch
enforcement: active
conditions:
  ref_name:
    include:
      - refs/heads/main
      - refs/heads/release/*
rules:
  - type: pull_request
    parameters:
      required_approving_review_count: 1
      require_code_owner_review: true
      dismiss_stale_reviews_on_push: true
      require_last_push_approval: true
  - type: required_status_checks
    parameters:
      strict_required_status_checks_policy: true
      required_status_checks:
        - context: ci/build
        - context: ci/lint
        - context: ci/license-scan
  - type: non_fast_forward
  - type: deletion

其中 require_code_owner_review 与 CODEOWNERS 联动，是内源评审路由的关键：它保证 PR 一定被路由到正确的团队，而不是靠贡献者自己去找人。dismiss_stale_reviews_on_push 与 require_last_push_approval 则堵住「先批准、后偷偷改代码」这个在开放协作里出现频率很高的漏洞。

只读镜像与 fork 策略需要单独决策。跨时区或跨网络域的团队读远端仓库体验差，可以在办公网内建只读镜像（GitLab Geo 或 GitHub 的仓库缓存）。fork 则应默认禁止或限制在团队空间内，因为内源 fork 会把代码复制出访问审计范围，形成影子资产，季度审计时需要专门的扫描脚本才能发现。

4. 内源办公室（ISPO）的职责与组织位置

ISPO（InnerSource Program Office）是让内源从「一群热心人的自发行为」变成「可持续的组织能力」的那个机构。它不该是权力部门，而应是服务与协调部门，规模通常 2 到 5 人，可以是兼职集合体。它的职责边界建议明确写下来，避免膨胀成审批衙门，也避免被当成万能背锅位。

职责大致五块，每块都要有可交付的产出物：

• 制度建设：维护内源章程、分级标准、SLA 承诺、贡献者行为准则，产出是版本化的制度文档
• 平台运营：管理代码托管、门户、机器人、模板仓库，是平台工程团队的需求方而非实现方
• 度量与报告：每季度产出内源健康度报告，向工程管理层汇报跨团队 PR 占比、活跃项目数、贡献者数
• 赋能培训：组织 Trusted Committer 培训、内源宣讲、新人上手工作坊，产出是认证过的 TC 名单
• 争议仲裁：当两个团队对项目归属或某个 PR 该不该合产生分歧时出面调停，并留下裁决记录供后续援引

组织位置上，ISPO 汇报给 CTO 或平台工程负责人最为常见，因为它需要跨部门的协调权，挂在某个业务线下面会立刻失去中立性。人员构成上，建议包含一名平台工程师（负责工具链）、一名技术项目经理（负责流程与度量）、一名法务或合规联络人（兼职即可），以及一名来自业务线的资深工程师作为代表，保证制度不脱离一线体感。

与开源办公室（OSPO）的关系要提前设计。两者可以是一套人马两块牌子，但必须区分目标函数：OSPO 对外，关注许可证合规、社区声誉、生态位；ISPO 对内，关注复用率与交付效率。合署办公的好处是 CLA、DCO、许可证纪律这些能力可以复用，坏处是容易把对外的重流程错加到内部协作上，所以制度文档必须分开维护，避免「内部提个 PR 还要签 CLA」这类摩擦。两者的职责切分可以固化下来，减少日常扯皮：

一个常见的失败模式是 ISPO 被赋予「内源 KPI 达成率」的考核指标，于是它开始向下摊派任务，变成又一层汇报负担。正确做法是 ISPO 的考核看的是「内源机制是否被使用」，即门户访问量、模板仓库使用率、跨团队 PR 占比这类过程指标，而不是「必须完成多少内源项目」。机制被使用，项目自然会长出来；项目被摊派，机制反而会被绕开。

5. 贡献激励与考核挂钩

内源最大的敌人不是技术债，是「做了没好处」。如果一名工程师花两周帮另一个团队修了一个阻塞性 bug，而他的绩效评估里只体现自己团队的交付，那么内源在个人层面就是负收益。激励机制的设计必须解决这个问题，而且要解决在明面上，不能靠「大家觉悟高」这种默认假设。

推荐三条并行的激励线，分别作用于个人、职级和管理者：

• 显式认可：设置 Trusted Committer 头衔并在内部门户公示，季度评选内源贡献奖，把贡献记录写进员工的内部档案
• 绩效挂钩：在工程师职级的晋升标准里加入「跨团队技术影响力」这一项，并明确把合并到非本团队仓库的 PR 作为可验证证据
• 管理侧约束：把「本团队项目是否按 SLA 响应外部 PR」纳入技术负责人的考核，从供给侧保证贡献者不会白干
• 反向约束：对长期不响应外部 PR 的项目强制降级，让「开放但不管」比「不开放」代价更高

考核指标要防止异化，因此必须慎选。可选的过程指标包括跨团队 PR 占比、内源贡献者人数、贡献者留存率（提交过一次的人半年内是否再次提交）、项目复用数。不推荐的指标是「每人每季度必须提交 N 个内源 PR」，这种摊派会直接催生大量无意义的文档微调 PR，污染所有仓库的评审负担，还会让真正需要评审的贡献被淹没。

在 OKR 层面，建议把内源写进平台工程或架构团队的 O（如「建立可复用的内部技术资产网络」），把上述过程指标写进 KR，但不要给业务研发团队下内源 KR。业务团队的正确姿势是被服务方，通过 issue 和 PR 表达需求，而不是被要求产出内源项目。一个可参考的 OKR 写法如下，注意 KR 全部是过程指标而非摊派指标：

objective: 建立可复用的内部技术资产网络
key_results:
  - 跨团队 PR 占比从 8% 提升到 20%
  - 贡献者半年留存率从 15% 提升到 35%
  - L2 及以上项目数从 6 增长到 20
  - L2 及以上项目 SLA 达成率不低于 85%
  - Trusted Committer 认证人数达到 30 人

6. 跨团队协作规范

跨团队协作与同团队协作最大的差别是「信任半径」变小：你既不了解对方的代码风格，也不知道对方的排期压力，更无法走过去拍肩膀。因此内源必须把一切默认隐式的东西显式化，用书面规范替代熟人默契。这套规范与开源社区的运营方法高度同源，区别只是规模小、闭环快，具体可对照社区运营与贡献者漏斗 里关于分诊与响应时效的讨论。

Issue 是第一接触面，模板的质量直接决定后续沟通成本。内源项目的 issue 模板应强制包含四项：使用场景与业务背景、期望行为与实际行为、复现步骤、影响范围（是否阻塞交付）。缺任何一项都应在分诊时退回补充，因为一次退回的成本远低于来回追问三轮的成本。

标签体系建议固定一套，并写进机器人配置：

• good-first-issue 标记适合新人上手的任务，通常附带明确的验收标准
• help-wanted 标记欢迎外部贡献的任务，表示 owner 团队当前没有排期
• needs-triage 表示尚未分诊，由机器人自动加上，分诊后移除
• upstream-first 标记需要先改上游依赖的任务，禁止在本地打补丁绕过
• breaking-change 标记会影响公开 API 的改动，触发额外的架构评审

分诊由 Trusted Committer 每工作日批量处理一次，超过 48 小时未分诊的 issue 应由机器人自动提醒并在门户上标红。

PR 流程要把「评审期望」前置。提交方在描述里写清改动动机、测试方式、对公开 API 的影响；评审方按四个维度给意见：正确性、向后兼容性、测试覆盖、文档更新。这四个维度建议做成 PR 模板里的勾选项，让评审人有统一的表达框架，也让贡献者知道评审不是凭个人喜好。

PR 模板的最小字段

模板的作用是把评审期望前置到提交时刻，下面是一份可直接放进 .github/pull_request_template.md 的骨架，字段与前面四个评审维度一一对应：

### 改动动机
（这个 PR 解决什么问题，关联的 issue 编号）

### 改动内容
（一句话概括；涉及公开 API 时列出变更前后的函数签名）

### 测试方式
（新增或修改了哪些测试，如何本地复现验证）

### 兼容性影响
- [ ] 无公开 API 变更
- [ ] 有变更，已更新文档与 changelog
- [ ] 有破坏性变更，已附迁移说明

### 文档
- [ ] README / docs 已同步更新
- [ ] 无需更新

Signed-off-by 由 DCO 机器人自动校验，缺失时 CI 直接失败，这比人工提醒可靠得多。模板里保留「兼容性影响」这一节尤其重要，它是内源项目判断一次改动是否需要走 RFC 的唯一依据。

SLA 建议定为首次响应 3 个工作日、终审 7 个工作日，超期未响应时贡献者有权升级到 ISPO 协调。分支模型上建议采用简单的 trunk-based 或 GitHub Flow，避免引入复杂的分支策略增加外部贡献者的认知成本，分支策略的取舍可参考团队既有的 Git 工作流规范。

上游优先（Upstream First）是内源与开源共享的一条铁律：如果所需改动在依赖库里更合适，就必须先向上游提交，而不是在自己的仓库里打补丁。内部实现上，这意味着每个项目都要维护一份「本地补丁清单」，记录为什么偏离上游、何时可以回归。偏离超过三个版本仍未回归的补丁，应在季度评审中被强制处理，否则技术债会以复利方式累积。

沟通渠道要收敛，避免同一件事在四个地方讨论。原则是：所有技术讨论留在 issue 或 PR 的评论区，即时通讯只用于通知和拉人，决策结论必须回写到 issue。这条规则的收益在半年后才会显现——当有人想了解「为什么当初这么设计」时，答案在仓库里而不是在某个人的聊天记录里。

7. 工具链与自动化

内源的日常摩擦大半来自工具链割裂：跨团队贡献者不熟悉目标仓库的构建方式、CI 配置各不相同、提交前要读三千字贡献指南。平台工程的任务就是把这些摩擦降到接近零，让「提一个 PR」的成本与在本团队仓库里提 PR 没有区别。

CI 复用是第一优先级。GitHub Actions 的可复用工作流（reusable workflow）可以把标准流水线抽到中心仓库，各项目用三行 YAML 调用，避免每个仓库复制粘贴一份需要同步维护的构建脚本：

name: ci
on: [push, pull_request]
jobs:
  build:
    uses: platform/ci-templates/.github/workflows/go-build.yml@v3
    with:
      go-version: "1.22"
      run-integration: true
    secrets: inherit

把模板仓库按语义化版本发布（@v3）而不是指向 @main，是为了让内源项目升级 CI 成为一次显式决策，避免上游一改所有仓库同时挂掉。

模板仓库（template repository）是第二优先级。新建内源项目时一键生成包含 CODEOWNERS、CONTRIBUTING.md、SECURITY.md、LICENSE、issue/PR 模板、行为准则、以及上述 CI 调用的完整骨架。骨架里预先填好的字段包括默认 SLA、默认分级标签、默认评审人组。经验值是模板能把项目从「申请开放」到「可接受贡献」的准备时间从两周压到半天。

模板仓库骨架

模板仓库的价值在于把「一个内源项目应该长什么样」固化下来，下面这份目录结构可以直接作为组织级模板的内容清单：

repo-template/
  .github/
    CODEOWNERS                评审路由，新建时必须替换为真实团队
    pull_request_template.md
    ISSUE_TEMPLATE/bug.md
    ISSUE_TEMPLATE/feature.md
    workflows/ci.yml          调用中心仓库的可复用工作流
    dependabot.yml
  docs/
    CONTRIBUTING.md           环境准备、提交规范、SLA 承诺
    GOVERNANCE.md             分级、责任边界、升级与降级规则
    CODE_OF_CONDUCT.md
  SECURITY.md                 漏洞报告渠道与响应时效
  CHANGELOG.md
  LICENSE
  README.md                   一句话定位 + 五分钟上手 + 引用方式

README.md 的结构值得单独规定：第一段用一句话说明项目解决什么问题、适合谁用；紧接着一个五分钟内能跑通的最小示例；最后是引用方式与维护者联系方式。跨团队贡献者判断「要不要用这个项目」的决策时间通常不超过三分钟，README 写不好，后面的工具链再完善也没用。

机器人承担重复劳动，每台机器人只做一件事：

• 欢迎机器人给首次贡献者自动留言，说明评审流程与响应预期
• 标签机器人根据改动路径自动打上组件标签并路由评审人
• stale 机器人关闭 90 天无活动且非 pinned 的 issue，关闭前先提醒
• 同步机器人把门户索引与仓库 topic 对齐，发现不一致时自动修复并告警
• 分诊提醒机器人对超 48 小时未分诊的 issue 打红标并 @ 值班 TC

内源门户是发现层。它的核心功能只有三个：按语言、领域、分级、活跃度搜索可复用项目；展示每个项目的 SLA 达成率与最近一次合并时间；一键生成「引用此项目」的说明片段（含依赖坐标与示例代码）。门户最忌讳做成静态清单——一旦需要人工更新，三个月后必然与现实脱节，因此索引必须从代码托管平台的 API 自动同步，并配一条死链巡检任务。

工具链的验收标准可以用一句话概括：一名从未接触过目标项目的工程师，能在不询问任何人的情况下，在半天内完成「找到项目、跑通构建、提交一个通过 CI 的 PR」这一完整闭环。达不到这条，就说明自动化还有欠账。

8. 与开源治理的衔接

内源与开源不应是两套体系，否则成熟项目外发时要把所有流程重做一遍，成本高到没人愿意做。正确做法是让内源成为开源治理的「内测环境」：同一套署名与贡献者协议、同一套许可证纪律、同一套依赖合规检查，只是执行强度按分级递进。

最值得提前统一的是贡献者协议。内源项目从第一天就要求 DCO（Developer Certificate of Origin）的 Signed-off-by 行，或者签署内部 CLA。这样当项目决定外发时，历史提交的版权链条是干净的，不需要回溯去找每一位贡献者补签——这在实际操作中几乎不可能完成，是很多公司开源受阻的直接原因。DCO 与 CLA 的选择逻辑与实施细节，可参考贡献者协议与 DCO 的对比。

许可证策略上，内部项目默认使用公司专有许可（LicenseRef-Proprietary），在仓库根目录用 LICENSE 文件声明。外发时切换到具体开源许可证，这一步需要法务参与，因为它同时牵涉商标、专利授权和第三方依赖的兼容性。依赖扫描应在内源阶段就常态化运行，目的不是为了让内部项目合规，而是为了外发时不会突然发现某个依赖的许可证与目标许可证不兼容。

外发流程建议做成一份清单，与内源分级联动。L4 申请外发时依次完成：

1. 依赖许可证全量扫描与冲突消解，产出许可证清单并归档
2. 商标与命名检查，避免使用公司未注册为商标的产品名或与既有项目重名
3. 文档与 README 重写，去掉内部链接、内部术语、内部人名与工单编号
4. CI 从内部 runner 切到公有 runner，确认不依赖任何内网资源
5. 向开源办公室报备并纳入 OSPO 的统一治理，指定对外维护者与安全响应联系人

这套流程与公司整体开源治理框架的关系，可参照开源治理总览 中的分层模型。核心思想是外发不是一次性的发布动作，而是项目治理责任的转移，因此必须在转移前把责任接收方指定清楚。

反向流动同样重要：内源项目可以 fork 一个成功的开源项目作为基础，这时必须保留原有的许可证文件与版权声明，不得移除 NOTICE 文件，也不得把上游代码重新标注为公司专有。这类「吸收式内源」是合规事故的高发区，应在开放流程的审批环节由法务强制检查。反过来，内源项目若大量复制了某个 GPL 类许可证的代码，也会给未来的外发留下无法绕开的约束，因此这类检查必须前置到 L1 升级 L2 的卡点上。

9. 从试点到规模化

内源最忌讳的做法是「先建平台再找项目」，平台做完了没人用，一年后沦为演示环境。正确顺序是从一个真实痛点出发，做出一个可被复制的样板，再谈规模化。

选试点项目有四条硬标准，建议逐条打分而不是凭直觉拍板：

• 需求来自三个以上团队，只有两个团队用说明复用小，做出来也是另一个私有库
• owner 团队有真实的开放意愿，至少有一名成员愿意承担 Trusted Committer 的职责并为此留出工时
• 项目不是核心交易链路，试点期允许试错，避免一次线上事故把整个内源运动打死
• 代码具备可复用的边界，不是一坨与业务强耦合的泥球，抽出接口的成本可控

试点期（0 到 3 个月）的目标不是推广，而是跑通流程并产出可复制的模板：分级怎么定、CODEOWNERS 怎么写、SLA 定多长、门户条目长什么样。这个阶段只做 3 到 5 个项目，全部由 ISPO 手把手陪跑，每周复盘一次。衡量成功的标准是至少出现一个非 owner 团队的合并 PR，且贡献者的经理知道这件事并认可——第二条同样重要，它验证了激励机制是否真的落地。

扩展期（3 到 6 个月）把项目数扩到 10 到 20 个，同时启动 Trusted Committer 培训，把陪跑从 ISPO 转移到各个 owner 团队。这个阶段最容易出问题的是质量滑坡：项目数涨了，但每个项目的响应时效掉下来，贡献者体验反而变差。因此扩展必须与 SLA 监控同步上线，任何连续两月不达标的项目降级公示，宁缺毋滥。这个阶段的另一个常见错误是同时启动门户、机器人、模板三条战线，正确顺序是先模板后机器人最后门户，因为模板是前置依赖。

制度化期（6 到 12 个月）把内源写进研发流程本身：新项目立项时默认评估是否可作为内源项目、晋升评审材料要求跨团队影响力证据、平台工程的年度 OKR 包含内源健康度指标。到这个阶段，ISPO 的角色应从运营转向治理，日常事务交给自动化与各项目 owner。文化层面的推广（内源日、案例分享、内部技术大会的内源专场）在这个阶段性价比最高，因为此时已有真实故事可讲，而不是空洞的口号。

需要提醒的是，内源不是所有组织都值得做。如果公司规模小于 200 名工程师，团队之间靠口头沟通就能对齐，引入完整的内源制度只会增加流程负担。内源的收益随组织规模超线性增长，成本却相对固定，因此规模是判断是否启动的第一变量。第二个变量是组织结构：如果公司本身是按职能划分的强矩阵，跨团队复用需求天然旺盛，内源的收益会来得更快；如果是多个独立业务单元各自核算盈亏，内源往往需要自上而下的推动才推得动。

权衡取舍

常见坑清单

1. 现象：内源门户上线半年后大量 404。原因：索引靠人工维护，仓库改名或归档后无人同步。规避：门户必须从托管平台 API 自动拉取，并加死链巡检告警。
2. 现象：跨团队 PR 堆积数周无人评审。原因：owner 团队没有为评审预留工时，SLA 只是一纸承诺。规避：把响应时效写进技术负责人考核，并设置自动升级到 ISPO 的机制。
3. 现象：内源 PR 数量虚高但复用率不涨。原因：下达了「每人每季度 N 个内源 PR」的摊派指标，催生文档微调类凑数提交。规避：改用贡献者留存率与项目复用数等难以造假的指标。
4. 现象：贡献者的经理在绩效沟通中批评其「不务正业」。原因：激励只在公司层面宣导，没有进入具体团队的绩效口径。规避：在晋升标准里显式写入跨团队影响力证据，并要求经理知晓。
5. 现象：项目外发时发现历史提交版权链条不干净。原因：内源阶段未要求 DCO 或 CLA，贡献者已离职无法补签。规避：内源第一天就启用 DCO 的 Signed-off-by 校验。
6. 现象：内源仓库被大量 fork 后失去审计视野。原因：未限制 fork 权限，代码被复制到个人空间或团队私有空间。规避：默认禁用 fork 或限制在受管组织内，定期扫描影子仓库。
7. 现象：本地补丁越积越多，升级上游依赖时冲突爆炸。原因：上游优先原则没有落地为可追踪的补丁清单。规避：每个偏离上游的改动登记原因与回归计划，超过三个版本强制处理。
8. 现象：所有仓库一夜之间开放，随后收到大量合规告警。原因：开放前未做依赖许可证与密钥扫描。规避：开放流程里设置法务与安全卡点，扫描通过才能升级到 L2。
9. 现象：内源制度推行一年，只有 ISPO 的三个人在提 PR。原因：把内源做成了自上而下的行政任务，没有从真实痛点起步。规避：试点必须由三个以上团队的真实需求驱动，且先跑通样板再推广。
10. 现象：新项目准备周期长达两周，贡献者还没提 PR 就流失。原因：没有模板仓库，每个项目从零写贡献指南与 CI。规避：用模板仓库把准备时间压到半天，并预置默认评审人与分级标签。
11. 现象：同一设计在 issue、群聊、邮件三处讨论，结论互相矛盾。原因：没有约定决策落盘位置。规避：强制技术讨论留在 issue/PR，决策结论必须回写 issue 才算生效。
12. 现象：小公司照搬大厂内源制度后交付变慢。原因：团队规模不足以产生重复建设的浪费，制度成本大于收益。规避：工程师少于 200 人时先用轻量约定，规模上来再引入正式分级与 ISPO。

小结

内源的本质是把「代码可见性」和「协作权限」当成需要设计的组织变量，而不是顺其自然的结果。制度骨架只有四件事：分级决定开放到什么程度，权限模型决定谁能写，SLA 决定响应有多快，激励决定值不值得参与。四者缺一，内源就会退化成「代码放一起但没人管」的半成品，门户里的死链就是它的墓碑。

落地路径上，先从一个由三个以上团队共同需要的真实痛点起步，用手把手陪跑跑通流程并沉淀模板，再用模板与自动化扩到十到二十个项目，最后把内源写进立项、晋升与平台 OKR 这些常规流程。指标只盯两三个难以造假的：跨团队 PR 占比、贡献者留存率、项目复用数。其余指标用来诊断，不用来考核。规模不足两百名工程师时，先用轻量约定替代正式制度，避免为了形式而付出流程成本。

如果想把这条路径与更大的治理体系接起来，建议接着读开源治理的分层模型与贡献者协议的具体选择逻辑，前者帮你厘清内源、开源、合规三者的边界，后者决定项目外发时版权链条是否干净。内源做对了，开源只是把仓库可见性从 internal 改成 public 的最后一步。