OceanBase ODC 开源，从想法的产生到不断否定到最终决定并开源的过程。
2023 年 8 月 17 日晚，在望京浦项中心 23 楼的一个安静会议室里。这个房间里充满了平静，就像现在内心的情绪一样。我知道，必须写下一些文字，记录我们对于 ODC 开源过程的感想和思考。ODC 的开源对我们来说，不仅仅是一个项目的里程碑，更是一个充满思考和讨论的旅程。
ODC（OceanBase Developer Center）开源是众多商业产品开源里的小小的代表。在如今这个大环境下，大厂开源工具产品也常常受到质疑的声音，也希望通过这篇文章，向大家分享一些对于ODC开源意义的深入思考，同时也欢迎大家的建议和讨论。
大概在一个月之前，我们决定 2023 年 8 月 18 号，是 ODC 4.2.0 版本发布并开源的日子。ODC 4.2.0 是一个很激进的版本，ODC 的风险管控核心领域模型、页面信息架构做了重新设计，并且增强了几乎所有模块的功能。按照以往的经验，一个大规模的新版本如果决定了 Release 日期，那么一定是会延期的。为了避免延期，我们把 dead line 定在了 8 月 16 号，果然很有效，今天版本发布相关的全部工作都顺利完成了，代码安全扫描、合规扫描、对外披露、代码同步到 github、docker 镜像推送到 docker hub，一切都丝般顺滑。发布前夜的丝般顺滑，背后是团队几个月的付出，不仅是 ODC 项目组，还有非常多同学参与其中。
有些问题团队最近一年持续在思考，比如 ODC 开源的价值、必要性、竞争力，问题的答案始终存在，但也在逐渐演变。今天遇到阳老师又讨论了一番，阳老师没有正面回答我，但是讲了 OceanBase 为什么要开源的逻辑，其实逻辑很简单，在当下数据库市场竞争格局中，一个新的数据库产品商业化要取得成功，如果不走开源路线，成功的可能性几乎不存在。
去年开始，ODC 的客户越来越多的提出支持多数据源的需求，ODC 的想法很简单，既然有那么多客户有需求，那就安排。但是没有那么简单，ODC 作为数据库厂商自研的 开发工具，其最初定位是让 OceanBase 的 开发者有一个图形化开发工具，支持 SQL 开发、数据导入导出、PL 执行调试 等开发过程的必须功能。ODC 之于 OceanBase，类似 Oracle 自研的 SQL Developer，SQL Server 自研的 SQL Management Studio。数据库厂商为什么要去适配其他数据库产品呢，要投资也应该是把如何从其他数据库产品迁移到自家数据库产品的工具做的更加好用。去年上半年我们觉得很快会支持 MySQL，但是到下半年还是没启动。
又过了一段时间，一些客户提出希望能够得到源代码，也就是定向开放代码，这个需求对于研发团队而言其实就是一件单纯比较辛苦的事情了。代码要做到能够定向开源的程度，改造成本就很高，内部的依赖组件要做剥离，全部源码要经过严格的数据安全和合规扫描。然后定向开源又是一个一锤子买卖，每一次定向都要做一次改造，代码还有可能在开源的同时产生分叉，对后期版本的维护带来持续的成本。后来我们了解到，其实 OceanBase 内核也曾经遇到类似的问题，那么解法也就很清晰了，为什么不干脆就真的开源呢？如果 ODC 开源了，那么支持多数据源就很合理了，比如支持 MySQL 的需求确实很强烈，客户也是可以参与到产品共建的。
于是就开始讨论 ODC 开源，价值是什么，目标是什么，如何衡量？ 从 OceanBase 整体来看，ODC 是否开源对于支持好当前 OceanBase 客户没有什么关系，就是给 OceanBase 开源社区增加一个组件，并且通过社区运营区吸引到一些外部的参与者。确实 OceanBase 内核 500万行 C++ 代码，对于感兴趣的参与者而言，需要比较长时间的投入才能开始参与到社区贡献。ODC 的技术架构是基于 WEB 的，从编程语言角度来说 Java 和 JS 也相对 C++ 更容易上手。但是为了这个好处就把 ODC 开源，理由还是不够充分，一位开源前辈告诉我，相同规模的功能开发，相比不开源做好 2~3 倍投入的预期，投入产出比就太低了。
ODC 很确定的一个方面是，开源对于 ODC 的价值在于拉近用户和产品研发团队的距离，通过更广泛的用户触达和沟通，筛选出更加确实的产品价值需求，也能帮助核心功能的易用性打磨。这几年做工具产品的经验告诉我们，用户比我更知道当前工作场景中的问题是什么，一件事情到底是那几个角色如何协作完成的。所以现在 ODC 的研发流程，从 PRD、设计稿 阶段就会邀请用户参与进来，和产品研发团队一起讨论，然后成型到发布产品里。相比之前单向的信息传递，需求从 客户到前线到产品再到研发过程，用户重度参与的方式可以实现重量级功能第一次发版就能在客户环境完整的使用起来，再经过一两次小迭代就能做到比较顺滑。
去年的时候我们找了一些 ISV 沟通，大家表达了对 ODC 开源兴趣但是都没有参与共建代码的意愿，然后兴趣的根因其实是对开放 OpenAPI 和基础组件库比较感兴趣，今年我们知道其实是目标对象没找对，一个开源项目能够吸引到合作者，一定是参与项目能够给合作者带来价值。所以很重要的一点，项目本身的吸引力要够，然后能够和合作者当下的业务诉求产生互补。那么今年其实是时机已到，一方面 ODC 的产品成熟度相比去年有很大提升，另一方面数据库协同开发的理念也已经得到普及，并且行业内足够开放、易用的产品其实选择并不多。
今年年初，ODC 开源项目在 OceanBase 技术部、蚂蚁集团开源委员会 范围都做了充分的讨论，我们认为 ODC 开源的必要性在于让 ISV 和客户的自建系统集成 OceanBase 更容易，从而提升 OceanBase 生态活跃度、降低 OceanBase 交付支持成本。这是为什么这次 ODC 开源，不仅是开放了 ODC 的代码，同时 ODC 开发过程中积累形成的基础组件同步开源，比如 db-browser 对数据库字典视图的访问做了封装，比如 ob-sql-parser 对 SQL 解析做了封装，这可能是 Java 开源生态里功能最全面的 SQL 解析库，接下来还有更多组件会逐步开放。把 ODC 产品开源，是对 OceanBase 开源社区的重要补充，作为一个 开发者产品，源码开放还是对 OceanBase 文档的高质量补充。
2023 年 2 月 17 日，ODC 开源审批流程正式提交，经过半年时间，终于到了和大家见面的一天。有个笑话是大厂为什么不开源，不是不想开源，而是代码写的太烂不好意思开源。我们是一个乐观皮实的团队，代码既然开出来了就不怕被喷，被批评是快速成长的重要途径。有一点小可惜的是，ODC 代码仓库的提交历史是我见过世界上全部代码仓库里面第二整洁清晰的，因为历史 commit 包含一些敏感数据的缘故，这次开源没有办法带上。
为什么一个软件做开源的改造过程会持续半年时间，这里有多方面的原因，成本主要包含三个部分。一是安全合规改造，需要确保每一行代码都是合规的，并且在发布前还需要确认不包含任何敏感数据，验证产品本身足够安全。二是剥离公司内部的依赖，包括内部的基础类库的依赖剥离和 CI/CD 基础设施内部依赖剥离，内部的基础类库需要改为开源依赖或者把之前的内部依赖库也公开，CI/CD 和研发协同流程需要在 Github 上实现替代方案。三是产品和代码的改进，为了方面感兴趣的开发者能够参与进来，我们对产品技术架构都做了调整，降低了功能扩展的成本，提升了代码的可读性，还补充了大量文档。
需要付出这么多成本 ODC 团队仍然选择坚定的走开源社区路线，最根本原因是我认为这件事情是对用户和产品有益的。长期来看，我们看到了数据库协同开发能够切实解决数据增长带来的新挑战具备普遍性，从开发阶段开始保障数据库稳定运行、数据安全和合规、协同效率等问题都还没有得到完整的解决，这个领域需要解决的问题规模还很大，并不是一个厂商可以搞定的，所以 ODC 开源是必然选择。
关于产品名字，你可能会问，为什么要用 OceanBase Developer Center 连别的数据库，岂不是很奇怪。我们也深有同感，甚至都发起过两轮大规模的换名字投票。但是因为还没找到那个命中注定的好名字，如果你有好建议，请给我们提 Github issue。
关于开源协议选择，ODC 开源选择了足够开放的 Apache 2.0 协议，如果和您的产品矩阵能够互补，我们鼓励基于 ODC 开源项目打造自己的完整解决方案提供给客户。对于 OceanBase 而言，这其实也有助于实现最理想的企业级软件销售模式“分销”，从数据库厂商角度来说，如果能帮助更多合作厂商获得商业利益，销售和交付成本的问题就可以比较彻底的解决。
ODC 的开源之旅才刚刚开始，如果你对这个开源项目感兴趣，希望深入了解更多细节，我们欢迎以任何形式参与 ODC 社区。吐槽、问题、建议、Issue、Discussion、Pull Request、Star 都欢迎！
我们已经做好准备，你有兴趣参与进来吗，一起打造企业级数据库协同开发工具， By Developer, For Developer！
See you at github.com/oceanbase/odc ！
