Open Core 边界：78% 的代码开源，22% 才收费

边界画错的项目，通常不是开源太多，是把用户跑不起来的那部分也开源了。

一、issue #612：为什么调度器不开源

2026 年 7 月，syncwell 的 issue 区出现第 612 号问题，标题是「为什么调度器是闭源的」。提问者语气不激烈，他说自己只想要一个能定时执行同步的本地版本，不想为托管服务付费。许砚盯着这个问题看了很久，因为它触到了一个真问题：边界画在哪里，决定了谁会觉得被冒犯。

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

这个仓库共有 48,600 行代码：命令行工具与本地同步引擎 37,900 行，用 Apache-2.0 开源，占 78.0%；托管侧的调度、账号、计费与多设备协调 10,700 行，闭源，占 22.0%。这个比例不是设计出来的，是两年里一笔一笔挪出来的结果。

最初的开源版只有 9,000 行，闭源部分 3,000 行；两年里开源侧增加了插件系统、跨平台支持与配置校验，闭源侧增加了调度、多设备协调与计费。两边都在长，比例基本稳定在 8:2 附近。

开源的不是「不重要的一半」，是「用户自己跑得起来的一半」。 命令行工具能在本地跑完一次同步，用户装完就能用；托管侧负责的是「你不用管它在哪跑、什么时候跑、失败怎么重试」，这部分的价值不在代码，在于有人替你值这个班。

这个区分听起来简单，做起来很难。因为「用户跑不跑得起来」不是由代码行数决定的，是由「跑起来需要什么」决定的：一台机器、一个对象存储桶、一条 cron，这三样东西用户都有；一个能对账的调度队列、一套凭据轮换、一条能赔付的 SLA，这三样用户没有。

还有第四样东西：时间。一个能自己搭的用户，通常也能自己维护；一个不能自己搭的用户，即使给了他代码，也不会去读。这条判断比「代码是否复杂」更接近本质。

二、三条判据：把边界画在维护成本上

判断一段代码该开源还是闭源，可以用三条判据。它们不问你「这段代码值多少钱」，只问「谁承担它跑起来的成本」。

第一条判据最容易验证：把项目 clone 下来，按 README 走一遍，能不能在 30 分钟内跑出第一个结果。能，就是可开源的；不能，就要问缺的是文档还是服务。缺文档可以补，缺服务只能闭源。

30 分钟这个阈值不是随便定的。超过 30 分钟，用户会在中途放弃，然后去 issue 区问「怎么跑不起来」；低于 30 分钟，他会在放弃之前先跑出结果。这个数字可以用五个新用户实测，不需要猜。

第二条判据决定你的时间结构。开源的代码，用户改坏了可以自己回滚；闭源的代码，用户改坏了只能找你。把「需要你持续在场」的部分开源，等于给自己签了一份没有报酬的值班表。

值班表还有隐性成本：它会改变你对项目的期待。开源的部分出了问题，你会觉得「这是社区的事」；闭源的部分出了问题，你知道「这是我的事」。边界画清楚，期待才不会错位。

第三条判据最容易被忽略。托管服务意味着数据落在你的服务器上，你就要处理删除请求、备份保留期、跨境传输与泄露通知。这部分代码即使只有几百行，也不能开源给用户「自己托管」，因为责任跟着数据走。

三条判据都指向同一个结论：边界不在代码的重要性上，在责任的归属上。 用户能承担的部分开源，你承担的部分闭源；中间地带用文档与迁移工具补齐。

中间地带最容易被忽略。比如「导入已有数据」这件事，用户自己能做，但需要一份格式说明与一个校验工具；把它做成开源工具加文档，比把整个导入服务开源更实际。

三、180 个付费账号买的到底是什么

许砚在 2026 年 9 月做了一次付费动机调查，180 个付费账号里回收了 180 份回答（续费页必填一项）。结果比预想的更集中。

169 个人为「不用运维」付费，11 个人为「有人响应」付费。这个结构说明：托管服务的定价锚点是运维时间，不是功能多少。如果明天开源了调度器，这 169 人里会有一部分转为自建；调查里表示「如果有官方自建镜像会自己跑」的有 34 人，占 18.9%。

这 34 人的画像很一致：都有运维背景、都在小团队、都已经在用对象存储。他们不是「不愿付费」，是「付费买不到额外价值」；对他们来说，托管省下的不是钱，是一点注意力，而这点注意力他们自己也有。

34 人 × 9 美元 = 306 美元/月，占托管收入 1,620 美元的 18.9%。这是开源调度器的直接收入风险，也是边界讨论里唯一能算清的数字。剩下的 81.1% 不会因为多一个开源组件而离开，因为他们买的本来就不是代码。

剩下的 146 人里，有 61 人明确写了「不想碰服务器」，38 人写了「团队里没人懂这块」，其余没有写原因。前两类是托管服务的核心用户，第三类是沉默的大多数；定价与文案应该先服务前两类。

Open Core 的收入不来自「藏起来的功能」，来自「替你承担的部分」。 把功能藏起来，用户会找替代品；把责任接过来，用户才愿意持续付费。前者是许愿，后者是生意。

这也是为什么 78% 与 22% 这个比例本身没有意义。它可以变成 90/10，也可以变成 60/40，只要边界仍然落在「用户跑不跑得起来」这条线上。反过来，即使只闭源 5% 的代码，如果那 5% 是用户自己能跑的部分，收入也会崩。

四、边界漂移的三种形态与一次复算

边界不是画一次就固定的。项目会长，用户会变，收入结构会变，边界也会跟着漂。常见的漂移有三种，每一种都有前兆。

第一种是核心功能下移。原本开源的本地同步引擎，为了支持增量同步，被一点点挪到闭源侧，最后开源版变成一个只能全量同步的空壳。前兆是 README 里的功能列表开始出现「托管版专属」的脚注。这种漂移最伤社区，因为它改变了已经承诺过的东西。

已经承诺过的东西包括 README 里的功能列表、文档里的示例，以及 issue 里维护者说过的话。改动它们不是不可以，但要配套一次说明；没有说明的改动，会被理解成「先把你骗进来，再慢慢收走」。

第二种是许可证收紧。从 Apache-2.0 换成 BSL，或者给某个目录加一条「禁止商用」。前兆是法务邮件变多、fork 数上升。第 9 篇会算一次这种变更的代价。

收紧的表现不止换协议。给某个目录加一条「禁止商用」、在 README 里写「企业使用需授权」、把某个模块挪到私有仓库，本质都是收紧；它们的共同点是缩小了已公开的授权范围。

许可证收紧的影响比想象中长。fork 会在两周内出现，star 会掉一点，但真正的损失是「下次有人想贡献时会犹豫」。这个犹豫不会出现在任何指标里，却会在两年后表现为「没有新的常驻维护者」。

第三种是托管专属 API。开源版能跑，但要连托管服务才能用某个关键能力，比如多设备冲突解决。前兆是用户开始在 issue 里问「为什么本地跑不了」。这种漂移最隐蔽，因为代码还是开源的，只是跑不起来。

回答这类问题时，最容易犯的错是解释技术原因。用户不关心「多设备协调需要中心化时钟」，只关心「我能不能不连你的服务器」。回答应该先给结论，再给原因；顺序反了，会被读成推脱。

三种漂移有一个共同前兆：issue 里「为什么本地跑不了」「为什么这个功能只在托管版」的问题变多。这类问题不该被当成抱怨；它们是边界正在移动的信号，值得单独建一个标签跟踪。

复算：
总代码：48,600 行
开源（CLI + 本地引擎）：37,900 → 37,900 ÷ 48,600 = 78.0%
闭源（调度/账号/计费/协调）：10,700 → 10,700 ÷ 48,600 = 22.0%
核对：37,900 + 10,700 = 48,600；78.0% + 22.0% = 100.0%
付费动机：169 ÷ 180 = 93.9%；11 ÷ 180 = 6.1%
自建意愿：34 ÷ 180 = 18.9%；34 × 9 = 306/月
收入风险：306 ÷ 1,620 = 18.9%
不流失：180 − 34 = 146 人 → 146 × 9 = 1,314/月 = 81.1%

复算里最值得记住的是 18.9% 出现了两次：一次是人数占比，一次是收入占比。它们相等，因为每个账号的价格相同；如果托管分成多档，两个数就会分开，那时要以收入口径为准。

18.9% 这个风险还有一层：它假设这 34 人会立刻迁移。实际上迁移需要时间，多数人会在下一次续费时才决定；所以真正的收入流失是滞后的，通常出现在 3 到 6 个月后。

五、行动清单与复算验收

• 把仓库按「用户能独立运行」与「需要长期在线」分成两栏，各算行数。
• 对每一栏回答一次：出问题时谁负责修？
• 检查开源部分能否在 30 分钟内按 README 跑出第一个结果。
• 列出托管侧承担的合规义务（删除、备份、跨境、泄露通知）。
• 在续费页加一个必填问题：你为什么付费？
• 统计「如果有自建镜像会自己跑」的人数，算出收入风险。
• 检查 README 有没有「托管版专属」的功能脚注。
• 每季度重画一次边界，记录这一次挪了什么、为什么。

验收标准：任取一个模块，都能说出它为什么在开源侧或闭源侧，以及挪到另一边会损失多少收入。

前四条是「把线画在责任上」，后四条是「盯住漂移」。如果只有一小时，先做第三条：跑不起来的开源版，无论行数多少，都不构成真正的 Open Core。

清单里最容易被跳过的是第五条。付费动机不靠猜，靠问；一个必填的单选问题，比十次社区讨论更能说明边界该画在哪。

使用边界与实操验收

78% 不是目标比例。 它只是这个项目的现状。比例高低与收入没有直接关系，边界位置才有。

Open Core 不是唯一形态。 也可以全开源加赞助，或者全闭源加免费额度。本文只讨论 Open Core，因为它是「一个人既想有社区又想有收入」时最常见的折中。

托管收入不等于利润。 1,620 美元的托管收入背后有 210 美元服务器、64.8 美元支付通道费与 51 小时/月的维护。第 1 篇算过净时薪，这里不再重复。

边界会伤害一部分人。 无论画在哪，都会有人觉得「这部分应该开源」。这不是画错的证据，是边界的本质；能做的是把理由写进 README，而不是每次都在 issue 里重新解释。

不要用闭源掩盖质量问题。 如果某个模块闭源是因为「写得不好看」，那是因为它会一直不好看。闭源应该对应责任，而不是羞耻。

关键参考与核验范围

• Choose a License ：用于核对开源侧许可证与闭源侧的搭配方式。
• Open Source Guides ：用于核对开源项目治理与商业化的常见结构。
• SPDX License List ：用于核对每个模块的许可证标识符。

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

范围上只讨论一个人维护的 Open Core 项目如何划分开源与闭源边界，不讨论双许可的具体合同、云厂商竞争与融资叙事。

系列导航

• 上一篇：许可证选择：四个问题、214 个直接依赖与 12 个 copyleft
• 下一篇：维护者的时间账：1,180 个 issue、148 个 PR 与 612 小时
• 回到目录：一个人的开源产品：4,200 个 star、一百八十个付费与一年 612 小时的维护
• 相关阅读：一个人把价格定对：定价、付费墙与涨价