为什么我们坚持官方源码授权，而不是做成 SaaS 订阅墙

在软件行业，"订阅制"几乎成了一种默认的正确。它带来可预测的现金流、更低的交付成本、更快的迭代节奏。对厂商而言，这是效率的选择；对使用者而言，这常常是便利的选择。但便利与效率，并不自动等于合适。

我们选择另一条路：以官方源码授权的方式交付产品——客户可以自行部署，可以二次开发，授权边界写在合同里，而不是藏在服务条款的更新日志里。

这不是对商业模式的道德表态，而是一个基于长期判断的工程与商业决定。下面把我们想清楚的事情摊开来讲。

一、软件交付的两种关系

订阅制 SaaS 的本质，是"租用能力"。客户购买的是某一时间段内对某项服务的访问权。代码运行在厂商的服务器上，客户拿到的是账号与界面。

源码授权加私有化部署的本质，是"移交能力"。客户获得在自身环境中运行系统的权利，以及在授权范围内修改它的权利。代码运行在客户自己的基础设施上。

这两种关系没有绝对优劣，但它们塑造了完全不同的依赖结构。前者，客户与厂商的关系随订阅周期延续；后者，客户与系统的关系在交付完成后仍然独立存在。

我们更愿意建立后一种关系。原因很朴素：我们希望客户选择我们，是因为产品持续有用，而不是因为迁移成本高。

二、可部署：运行权应当在使用方手里

把系统部署在客户自己的服务器、专有云或信创环境中，意味着几件具体的事：

• 数据不出域。业务数据、客户资料、行为日志停留在客户可控的边界内。
• 可用性由客户掌握。网络策略、备份节奏、容灾方案可以与既有体系对齐。
• 生命周期可预期。即使某个版本不再更新，已部署的系统仍然可以继续运行。

这些不是抽象的好处，而是很多组织在采购时必须回答的问题。尤其是在涉及合规、审计与行业监管的场景中，"能不能自主掌控"往往排在"功能多不多"之前。

我们不认为所有场景都需要私有化部署。但对那些需要它的场景，"只能订阅、无法部署"本身就是一种排除。

三、可二开：让能力在使用中生长

没有任何一套通用产品能预判所有业务细节。真实世界的需求是分叉的：同一套流程，在不同组织里有不同的审批层级；同一份数据，在不同业务里有不同的口径。

二次开发不是对产品的否定，而是产品进入真实环境的必然延伸。

我们允许并支持在授权范围内进行二次开发，包括接口扩展、流程定制、模块增减、与既有系统的对接。我们也把边界写在明处：哪些可以改、哪些不建议改、哪些改动会影响后续的升级支持。

坦率地说，开放二开对厂商是有代价的。它意味着更复杂的支持场景、更难的版本管理、更分散的问题反馈。我们接受这个代价，因为封闭换来的"统一"，往往是厂商的便利，而不是客户的收益。

四、授权边界清晰，比"无限自由"更重要

我们强调源码授权，但不主张"无边界"。软件是资产，需要规则来保护双方的预期。

一个清晰的授权通常要回答：

• 使用范围：可部署的实例数量、可服务的用户规模、可覆盖的业务主体。
• 修改范围：可修改的模块、可替换的组件、必须保留的标识与版权信息。
• 分发限制：是否可以对外再分发、是否可以嵌入对外销售的产品。
• 升级与支持：版本获取方式、支持期限、二次开发之后的责任划分。

把这些讲清楚，短期看是麻烦，长期看是减少纠纷。很多合作关系的破裂，不是因为条款太严，而是因为当初没讲清楚。

五、席位制 SaaS 的逻辑，以及它的代价

席位制 SaaS 的计费方式很直观：按账号、按活跃用户、按调用量。它把软件价值与使用规模挂钩，对厂商友好，对起步阶段的使用者也友好——规模小时成本低，扩张时成本同步上升。

它的代价同样清晰：

• 成本随组织规模线性增长。人越多，账单越大，而这未必与系统带来的实际价值同比例。
• 停订即停用。一旦不再续费，账号关闭，历史数据与配置的可用性，取决于厂商提供多大的导出能力。
• 定制空间有限。多数 SaaS 提供配置项与开放接口，但不提供修改内核的权利。
• 路线图由厂商决定。客户可以提需求，但不能决定优先级。

这不是在指责 SaaS。对于标准化程度高、变化快、又不愿承担运维责任的场景，SaaS 是合理选择。我们只是认为，它不应该成为唯一选择。

六、客户资产归属：数据、代码与知识

"客户资产"是个容易被说滥的词。我们把它拆成三部分：

数据——业务数据、客户数据、日志。归属应当明确属于客户，厂商不应用于自身目的，不对外提供，不因合作终止而滞留。

代码——在授权范围内，客户对已交付代码拥有使用权与修改权。二次开发产生的衍生代码，其归属与处置方式应在合同中写明。

知识——实施方法、配置经验、流程设计。这些往往沉淀在文档与人员身上。交付时应尽量以文档、脚本、说明的形式固化下来，减少"只有原厂会做"的隐性锁定。

三者之中，最容易被忽视的是第三项。系统的长期可用性，往往不取决于代码本身，而取决于使用方是否真正理解它。

七、我们不否认订阅制的价值

需要说清楚的是，我们并不认为订阅制是错的。它解决了传统买断制的一些真实问题：版本陈旧、升级昂贵、厂商缺乏持续投入动力。许多优秀的软件正是靠订阅制维持了长期迭代。

我们反对的不是订阅，而是"订阅墙"——把可部署、可修改、可自主掌控的能力，人为地关在付费墙之后，让客户只能在"接受"与"离开"之间二选一。

这是两件事。订阅是一种计费方式，订阅墙是一种权力结构。

八、这是一种判断

回到开头。我们选择源码授权与可部署交付，不是因为它在商业上更轻松——它其实更难：交付更重、支持更复杂、收入更不平滑。

我们选择它，是因为它更符合我们对长期关系的理解：产品的价值应当体现在使用过程中，而不是体现在迁移成本上；客户的信任应当来自持续可用，而不是来自无法脱身。

我们对 AI 能力的判断也是如此。AI 正在成为系统的基础能力，它越深入业务，数据边界、可解释性与可控性就越重要。把这样的能力锁在别人的服务器上，对很多组织来说，并不是一个可以长期接受的安排。

所以我们选择把选择权交出去一部分。这不是让渡，而是判断。

好的软件关系，应该是双方都能体面地继续，也能体面地结束。源码授权与可部署交付，是我们朝这个方向给出的答案。