开源项目验收：十项能力、四维评分与三种不该开源的项目

判断一个开源项目健不健康，不看 star，看它能不能在没有你的情况下继续跑。

一、一次季度复盘与一张 3.47 分的表

2026 年 10 月，许砚按季度做了一次开源项目体检。他没有看 star，也没有看下载量，而是把项目拆成十项能力，每项打 1 到 5 分，再按四个维度加权。结果是 3.47 分，落在「有保留」区间。

打分之前，他先把十项能力的判定标准写下来，每一项都是一句可验证的话。比如「依赖许可清单」的 5 分标准是「214 个依赖全部标注，且 CI 会拦截新引入的 copyleft」；没有这句话，打分就会变成印象分。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

十项能力覆盖四件事：许可证与边界、维护产能、资金可持续、治理与退出。四件事各自独立，缺一件都会在某个时点变成事故：许可证不清会挡住企业采用，产能不足会让 issue 积压，资金不持续会让你在某个月放弃，治理缺失会让项目在你离开后停摆。

评分的目的不是给自己打分，是找出下一季度唯一该补的那块板。 3.47 不是一个需要骄傲或羞愧的数字；它是一张地图，告诉你哪一项拖了后腿。

地图的用法是「一次只走一条路」。同时补四项，结果通常是四项都补一半；一个季度只补一项，下个季度复测时才能看出这一项是否真的被补上了。

二、十项能力与四个权重

四个维度的权重不是平均分配的。许可证与边界占 0.30，因为它是所有商业采用的前提；维护产能与资金各占 0.25，因为它们决定项目能不能持续；治理与退出占 0.20，因为它的影响最晚出现，但一旦出现就很难补救。

权重可以调，但不能平均。平均权重会让「许可证清晰」和「赞助转化」变成同等重要，而前者决定项目能不能被采用，后者只决定你能多收几百美元；两者的杠杆完全不同。

四个维度的平均分是：许可证与边界 (5 + 5 + 4) ÷ 3 = 4.67；维护产能 (4 + 3 + 4) ÷ 3 = 3.67；资金可持续 (3 + 2 + 4) ÷ 3 = 3.00；治理与退出 2.00。加权之后是 0.30 × 4.67 + 0.25 × 3.67 + 0.25 × 3.00 + 0.20 × 2.00 = 3.47。

最低分不在收入，在治理。 2.00 分的「贡献者与退出」是整张表里唯一低于 2.5 的项，也是下一季度唯一该动的地方。收入结构 3 分可以慢慢改，治理 2 分拖一年，可能就没有机会改了。

这也是评分表最容易误导的地方：它把「分数低」和「该先做」混在一起。正确的读法是看「不可逆性」——治理与退出不可逆，收入结构可逆；先做不可逆的。

三、三档结论与两条最短的板

四维评分之后，用三档给出结论。分档不是为了排名，是为了决定「现在该做什么」。

3.47 落在「有保留」。这个结论的含义不是「不要开源」，而是「开源可以，但别急着推」：先把治理补到 3 分以上，再考虑增长动作。

两条最短的板很明确。第一条是贡献者与退出：发版只有 1 人能独立完成，归档六件套只做了 3 件。第二条是赞助转化：0.55% 的转化率、单一的 3 档结构、没有企业年付选项。第一条决定项目能不能活过你，第二条决定你能不能撑到那一天。

第一条的具体动作是把发版权限交给第二个人，并让对方独立发一次版；第二条的具体动作是加一个企业年付档，并把赞助入口挪到文档末尾。两个动作都能在一个月内完成，前者更重要。

两条板里，先补第一条。原因是它不可逆：赞助转化可以下个月改，发版权限的交接需要几个月培养。评分表的作用就在这里——它把「什么都该做」变成「先做这一件」。

「先做这一件」还需要一个期限。他的做法是把季度目标写成一句话：「本季度结束时，第二个人能独立发一次版」；一句话，可验证，不需要拆成 KPI。

四、三种不该开源的项目与一次复算

有些项目开源之后会带来结构性麻烦。它们的共同点不是「代码不好」，而是「责任无法随代码转移」。三种最典型。

第一种是含独家数据的项目。数据授权只允许你自己使用，开源代码也无法让别人合法运行；用户拿到仓库会发现跑不起来，然后来问你为什么。这类项目可以开源客户端，不能开源数据管道。

数据类项目还有一个折中：开源格式与解析器，闭源数据源与更新流程。用户能读、能校验、能自己接别的数据源，但拿不到你的独家数据；这样既保留了采用面，也不泄露核心资产。

第二种是合规责任无法转移的项目。涉及支付清算、医疗记录、未成年人数据的系统，责任跟着运营主体走；开源不等于免责，反而会让更多人误以为可以用。这类项目适合开源 SDK，不适合开源核心服务。

合规类项目的边界通常在「谁承担责任」。开源代码不转移责任，反而会让更多人误以为可以用；如果一定要开源，要在 README 第一段写清「本项目不构成合规保证」，并且不要用「生产可用」这类措辞。

第三种是需要 7×24 值守的实时系统。开源之后，用户会默认「有人在维护」，而一个人无法提供这种保障。可以做开源协议实现，不做开源托管服务。

实时系统还有一个隐性成本：值班。开源之后，用户会在半夜提交 issue，期待有人回应；你不需要回应，但你会觉得自己应该回应。这种心理成本不会出现在任何账单里，却真实存在。

复算：
维度均分：
  许可证与边界 (5 + 5 + 4) ÷ 3 = 14 ÷ 3 = 4.67
  维护产能 (4 + 3 + 4) ÷ 3 = 11 ÷ 3 = 3.67
  资金可持续 (3 + 2 + 4) ÷ 3 = 9 ÷ 3 = 3.00
  治理与退出 2.00（单项）
加权：0.30×4.67 + 0.25×3.67 + 0.25×3.00 + 0.20×2.00
    = 1.401 + 0.9175 + 0.75 + 0.40 = 3.4685 ≈ 3.47
分档：3.47 → 有保留（3.0–3.9）
短板：治理 2.00 < 2.5；赞助 2.00 < 2.5
补板目标：治理 2.00 → 3.00 → 综合 +0.20 → 3.67

复算里最后一行值得单独看：治理从 2 分补到 3 分，综合分只涨 0.20。这个涨幅看起来很小，但它对应的是「项目能在你离开后继续」这件不可替代的事。评分不是为了涨分，是为了识别这类低分高杠杆的项。

低分高杠杆的项通常有三个特征：影响面广、修复一次长期有效、且不依赖外部条件。治理符合三条；赞助转化只符合第一条，所以它的优先级排在后面。

五、行动清单与复算验收

• 按十项能力各打一次分，每项写一句打分依据，不写「感觉」。
• 用四个权重算出综合分，确认落在哪一档。
• 找出低于 2.5 的项，作为下一季度唯一要补的板。
• 检查许可证与依赖清单，确认 CI 会拦截新引入的 copyleft。
• 统计首响中位数与超时比例，和公开承诺比一次。
• 统计收入结构，算出最大一项占比；超过 80% 就写风险备注。
• 检查归档六件套，缺哪件补哪件。
• 用三种「不该开源」的情形对照一次，写下本项目的边界。

验收标准：任取一项能力，都能说出得分、依据、以及补到下一档需要做什么。

前四条是「先把分打准」，后四条是「把分变成动作」。如果只有一小时，先做第三条：找到低于 2.5 的那一项，比把整张表填满更重要。

清单里最容易被跳过的是第八条。很多项目不是不该开源，是不该开源「全部」；把边界写下来，比事后在 issue 里解释省力。

使用边界与实操验收

3.47 是一个样本。 十项能力的打分带主观判断，不同的人会给出不同的分；重要的是打分依据，不是分数本身。

为了让分数可比，他给每一项都配了一个「证据」。比如「首响与分类」的证据是中位 26 小时与 8.4% 超时率；换一个人打分，看到同样的证据，分数通常只会差 1 分以内。

权重不是普适的。 0.30/0.25/0.25/0.20 适用于「想接商业采用」的项目；纯兴趣项目可以把治理权重调低，把维护产能调高。

高分不等于健康。 一个 4.5 分的项目也可能在某个月停更；评分反映的是结构，不是承诺。

结构也会骗人。一个 4.5 分的项目可能只是因为「还没遇到压力」；压力来了，分数会掉得很快。评分时要问一句：这一项在最忙的那个月还成立吗？

低分不等于不该做。 很多优秀的开源项目在治理上只有 1 分；它们靠维护者的热情撑了很多年。评分只是提示风险，不替你决定。

季度复测比单次评分有用。 分数变化的方向，比分数本身更能说明问题；连续两个季度下降，就该减负而不是加功能。

复测的时间最好固定在季度末，和财务复盘放在一起。两次复测之间不要改评分标准；标准一改，趋势就断了。要改标准，就在复测之后改，并注明从哪个季度开始适用。

关键参考与核验范围

• Open Source Guides：领导与治理 ：用于核对治理维度的检查项。
• OSI 许可证目录 ：用于核对许可证清晰度的判定标准。
• CISA Secure by Design ：用于核对安全与责任边界的设计原则。

以上链接于 2026-10-26 实测可公开访问；未核验版本、功能范围与政策更新。核验日期：2026-10-26。

范围上只讨论一个人维护的开源项目如何做四维验收与开源决策，不讨论融资、估值、商业化路线图与团队建设。

系列导航

• 上一篇：治理、fork 与退出：17 位贡献者、82% 的提交与一次改协议的代价
• 回到目录：一个人的开源产品：4,200 个 star、一百八十个付费与一年 612 小时的维护
• 相关阅读：一个人的质量守门：验证预算、回归清单与发布门禁