企业拿到IM源码以后，真正麻烦的通常不是第一次修改。
而是半年、一年以后：
企业自己的源码已经改了几十处，厂商又发布了新版本，这两个版本怎么合并？
源码交付确实增加了企业对代码的控制能力，但同时也意味着企业开始拥有自己的代码分支生命周期。
所以采购源码时，除了问“给不给代码”，还应该问：
以后怎么升级。
假设企业提出20个需求。
其中可能包括：
这些需求并不都值得直接改核心源码。
能够通过API、SDK、配置或厂商标准扩展实现的功能，尽量不要进入企业自有核心代码分支。
小天互连当前开放平台将API用于OA、ERP、门户等业务系统调用IM能力；SDK则用于把聊天、会话、通讯录等能力嵌入企业自研应用。这类开放方式的一个重要价值，就是减少业务集成对核心产品代码的直接修改。
假设厂商V1版本有一段代码：
企业拿到以后进行了修改。
后来厂商V2也恰好重构了这一部分。
这时企业不能简单：
用V2覆盖V1。
因为这样可能直接把自己的定制修改覆盖掉。
反过来，如果始终不升级厂商主线，又可能错过：
漏洞修复、操作系统适配、客户端升级和新版本能力。
所以源码交付以后，企业需要承担持续的分支合并工作。
每次修改核心代码时，都记录：
改了哪个模块？ 为什么改？ 改了哪些文件？ 是否影响数据库？ 是否影响客户端？ 是否可以在未来版本取消这项修改？
这样厂商新版本到来以后，才能逐项判断：
继续保留、重新实现、已经被标准产品覆盖，还是可以删除。
否则几年以后，很容易出现：
没人知道这一段代码为什么被改过。
企业不能只保存：
“这是我们现在运行的源码。”
至少应该知道：
它基于厂商哪个正式版本，企业修改到了哪一次提交。
更规范的方式可以形成：
厂商V5.x正式版本 → 企业内部Base版本 → 企业定制分支 → 正式生产版本
这样后续升级才有可比较的基线。
不要拿到新版本就直接合并。
可以先问：
企业定制过的模块，厂商这次改没改？ 数据库结构是否变化？ API是否变化？ 客户端是否需要同步升级？ 原来的定制功能是否已经进入标准产品？
然后再决定升级范围。
如果企业修改的是：
核心消息、权限、文件、安全或客户端逻辑，
升级以后不仅要看代码能不能编译。
还要重新验证：
登录 → 单聊 → 群聊 → 文件 → 权限 → 历史消息 → 业务接口 → 多端客户端。
修改越接近底层，回归测试范围越大。
企业真正需要谈清楚的是：
源码交付对应哪个版本？ 后续正式版本是否继续提供？ 企业定制代码由谁负责合并？ 厂商是否协助升级？ 定制分支出现问题由谁定位？
这些问题比“源码有多少行”更影响长期成本。
对于只需要连接OA、ERP、自研App和行业系统的组织，更值得优先使用成熟产品的API、SDK和定制扩展能力；小天互连当前已经提供开放API和多端SDK路线。
如果企业确实需要修改核心源码，就应该从第一天开始把：
代码分支、差异清单、版本基线和后续升级
一起纳入项目管理。
拿到源码不是维护责任的结束，而是另一种维护责任的开始。
