把自研项目捐进顶级开源基金会：13 个月里要补的到底是什么
一、捐赠的真实含义，是把内部便利一条条还掉
据公开报道，有一个源于企业内部生产实践的开源项目，在顶级开源基金会里从孵化走到毕业只用十三个月左右。这个速度不是通用结论，也不该被当成任何一家企业的路线图；把它拿过来看，只是因为它把”捐赠到底要还什么账”这件事暴露得最清楚。我们作为同时做软件交付和模型服务的乙方，也作为内部工具链的建设者，看这类新闻的落点从来不是”要不要开源”，而是捐出去这个动作，本质上是在把过去几年攒下的内部便利一条条拆掉：内部依赖、单人决策、非标准发布、私有许可证头、只有本公司能跑的持续集成，这五件事在捐赠前都得先还清，一分赊不得。
这件事值得单独写一篇，是因为多数观望的公司把它读反了。他们以为难的是”敢不敢”，实际难的是”配不配”。代码本身开放只是一行配置；把代码从”我们公司环境里跑得起来的东西”改造成”任何陌生人下载后都能跑、能改、能发版、能担责任的东西”，才是一年的工作量。洹拓在服务客户时接过几次类似询问，问是不是把代码丢到 GitHub 打上 Apache 2.0 就算完，答案显然是否。下面按顺序讲这五笔账怎么清、清到什么程度才算过关，以及最后如何用一份自查清单把这一切固定下来。
二、进孵化之前要清的三类账
第一类是许可证账。自己的代码要逐文件核对许可证头，把”我们公司习惯但不合规”的头部（例如只有内部版权声明、缺 SPDX 标识符、混用了与目标基金会不兼容的条款）全部替换；第三方依赖要做完整审计，把每一条传递依赖的许可证、版本区间、以及是否存在 copyleft 传染列出来，冲突的要么替换要么剥离。我们见过的最大坑是间接依赖里藏着一个只允许内部使用的库，直连测不出来，要在别人的构建环境里才炸。
第二类是商标与命名账。项目名、图标、文档里出现的公司标识，在捐赠那一刻就不再属于本公司，需要走一次移交，把命名权与使用规则交给基金会。同时要在内部把这个名字从产品线、市场物料、代码仓库路径里解耦出来，避免出现”改名之后本公司还得追一段尾”的尴尬。这一条纯法务，做不干净会一路卡评审。
第三类是私有依赖账。内部服务发现、内部镜像源、内部构建缓存、内部凭据系统——这些在自己环境里”透明”的东西，捐赠后都会变成”陌生人装不上”的第一现场。要把它们从主干里解耦：默认路径不能依赖任何只有本公司能提供的服务，缺依赖时给出明确的报错和替代说明，而不是超时挂在那里。
三类账的共同点：**它们都不是”改一改”而是”换一层”**。改一改是把许可证头批量替换一下；换一层是把内部服务发现抽象成可插拔接口，开源版本接一个空实现。换不动的那些，就是劝退信号，别硬捐。
三、治理结构的最小可行形态
基金会不会替你决定谁能发版、谁说了算，它只要求这些决定被写下来、被复现得出来。一个捐赠项目在孵化期需要的最小治理形态，其实只有三件：
- 决策记录的位置与格式。不是”某次会议决定”，而是”决策记录在哪个仓库、用什么文件、怎么标注状态（提议、生效、废弃）”。我们建议起步就用架构决策记录那一类文件，一条一段，附上下文与替代方案；口头决定一律不算生效。
- 谁能发版与谁来审核。至少两个具备发版权限的人，其中一位不能是原公司同事——这条看似形式，实际决定了”公司人员流失后项目还能不能自己活下去”。审核路径要写明外部贡献者的改动由谁复核、复核标准是什么。
- 外部贡献者的可见比例。不是硬性名额，而是一种可核对的信号：如果连续几个迭代里全部提交仍来自同一家公司的邮箱域，评审会质疑治理的真实性。这不是政治问题，是证据问题。
四、发布与兼容承诺：从内部习惯切到公开契约
发布节奏和兼容性承诺是捐赠里最反直觉的一段，因为它要求把内部习惯**从”我们能改”翻译成”我们承诺不改”**。
版本号语义要落到能被下游脚本读取的粒度。主版本变化意味着破坏性变更、次版本意味着向后兼容的新增、修订号意味着修复——这三档不是形容词，要具体到”配置字段的删除走主版本、接口新增字段走次版本、依赖版本升级是否算破坏”这一层，写进 CHANGELOG 模板。
废弃策略要有时间线。一个公开接口要下线，从”标注废弃”到”实际移除”中间要预留多久、期间双跑还是给迁移提示、报错信息里能不能给出替代项，这三条要先定好。我们的经验是：内部习惯的”发现有问题就下”在开源里是禁句，因为别人构建脚本会读你的输出、别人的依赖会锁你的版本。
安全公告的时间线也是同一类承诺。收到漏洞报告后多少时间内确认、什么时候发中间版本、什么时候发正式修复、披露窗口多长——每一条都会被拿去做对比。这一条不是”要不要做”的问题，是”能不能兑现”的问题；兑现不了就先别承诺，把节奏放长比放短安全。
五、测试要补的四类，与 CI 从”只有本公司能跑”到”别人也能跑”
内部测试的默认前提是”在我方环境里”，捐赠要改的是”在别人环境里”。这四类要补：
- 平台矩阵：至少覆盖 Linux 主流发行版的两个稳定版本、macOS 当前两个大版本、Windows 服务器与桌面各一个。别默认某一种 libc 或某一种文件系统。
- 外部构建系统：只跑本公司惯用的那一种构建工具是不够的。Maven、Gradle、Bazel、CMake、pip、npm——按目标用户生态各配一条最小构建路径，证明别人不用装我们的东西也能构建。
- 无内网条件下的构建：CI 里必须有一条关代理、关内部镜像、关私有源的裸构建路径，任何走内网解析的依赖都会在这里现形。
- 示例可运行：
quickstart目录里的每一段示例必须能在干净机器上跑通，且在 CI 里被真的执行一次，不是靠 README 里的”我们试过可以”。
持续集成里的凭据也是同一件事。凡是内部凭据才能拉取的容器镜像、才能访问的制品库，都要有一条”公开可获取”的替代；实在拿不到的东西要显式列在依赖清单里，让”陌生人构建失败”是可预期的、可解释的失败，而不是黑箱。能不能把 CI 从”我们公司的 CI”改造成”任何 fork 都能跑通的 CI”，是捐赠前最硬的一道技术分界线。
六、毕业判据读成工程清单，加上退出策略与三条劝退判据
毕业判据听起来是社区叙事，落到工程上是能被证据核对的三组数字：社区活跃度（多少外部贡献者、issue 关闭周期、评审轮次）、独立发布次数（不依赖原公司参与的版本数）、外部贡献者占比（提交与评审两个口径都要看）。这三组数字不需要每天盯，但要按月出一次报表，作为项目是否”真的活着”的凭据，而不是靠感觉。
捐赠前自查的七项清单——这一节是本文的核心交付物，每一项都必须给出证据形态，光勾选不算完成：
| 自查项 | 过关标准 | 证据形态 |
|---|---|---|
| 许可证与依赖审计 | 所有源文件带合规头部；传递依赖许可证冲突为零 | 扫描工具的报告快照与冲突处置记录 |
| 商标与命名移交 | 项目名、图标、域名的使用权归属已书面确认 | 移交文书与仓库路径变更的提交历史 |
| 私有依赖解耦 | 主干代码不含只有本公司能提供的服务调用 | 无内网 CI 的构建日志与外部依赖清单 |
| 治理结构记录 | 决策、发版权、审核路径均以文件形式落在仓库里 | 决策记录目录与角色清单的提交历史 |
| 发布与兼容承诺 | 版本号语义、废弃策略、安全公告时间线均已文档化 | 承诺文档与已发布版本 CHANGELOG 的对齐样本 |
| 测试可外部复现 | 平台矩阵、外部构建、无内网构建、示例可跑四类均通过 | CI 工作流定义与上一次全绿的执行记录 |
| 退出策略 | 明确写出”孵化不毕业时，代码与声誉如何处置” | 决策记录里一份带日期的方案文件 |
退出策略值得单独说一句：多数团队只写了怎么开始，没写怎么结束。捐赠不是单向承诺，孵化期一到如果没达到判据，要么转入长期孵化、要么迁回内部维护、要么归档；三种路径各自要留下的资产（商标回退、贡献者通知、依赖方迁移公告）要提前写清楚。事前不写，事后就是扯皮。
最后给”只是想开源、不想治理”的三条劝退判据，命中一条就别捐：
- 找不到公司邮箱域之外的第二个能签字发版的人——治理撑不过一年。
- 主干代码离了内部服务发现就起不来——解耦量比想象的还大，硬捐只是把内部债搬到公开场合。
- 不愿意写”接口废弃要留多久”这种承诺——那意味着对外发布的每一次改动都得靠运气，别人没法用。
这三条不需要外部评审指出，团队自己就能判。做到这三条之前，把它挂在自己代码仓库上打一个开源许可证标签，比捐进基金会更诚实；做到了再谈捐赠，也不会把这条路当成宣传。所谓治理改造，说到底就是**把”我们心里有数”变成”别人也能查得到”**——查得到的部分是资产，查不到的部分迟早变成事故。