你们想知道的一切，都在这里了。

相信这两天很多社区小伙伴都看到 StarRocks 所谓”开源“的动态了，开源用户群里有很多小伙伴在讨论，也有很多关心 Apache Doris 的朋友来问我们，诸如“如何看待 StarRocks ‘开源' ”、” Apache Doris 跟 StarRocks 是什么关系“、”社区分化的原因是什么“、“为什么 StarRocks 不回馈给 Apache Doris ”的问题。

作为 Apache Doris 主要维护团队，我们觉得有必要给大家澄清一些事情。

关于 Apache Doris 和 DorisDB、StarRocks 的关系

Apache Doris 的前世今生相信很多同学都有些许了解，之前在公众号里有过历史文章阐明关系，在 Apache Doris X Apache Pulsar 联合 Meetup 上也做过题为 “ Apache Doris 的过去、现在和未来 ”的分享。

Doris 最早是解决百度凤巢统计报表的专用系统，随着百度业务的飞速发展对系统进行了多次迭代，逐渐承担起百度内部业务的统计报表和多维分析需求。2013 年，我们把 Doris 进行了 MPP 框架的升级，并将新系统命名为 Palo ，2017 年我们以百度 Palo 的名字在 GitHub 上进行了开源，2018 年贡献给 Apache 基金会时，由于与国外数据库厂商重名，因此选择用回最初的名字，这就是 Apache Doris 的由来。

那么 StarRocks 以及 DorisDB 是什么？

2020 年 2 月，百度 Doris 团队的个别同学离职创业，基于 Apache Doris 之前的版本做了自己的商业化闭源产品 DorisDB ，这就是 StarRocks 的前身。

关于社区分化的原因

按照 Apache License，基于开源产品进行商业化是被允许的。所以我们初期是希望能共同建设 Apache Doris 社区的，个人在职业上的选择与社区无关。在开源社区，每个人的社区身份都是被认可的。

后来我们发现，事情发展与我们的预期背道而驰。

比如 DorisDB 团队在对外宣传时，会宣称自己“是 Apache Doris 的主创团队”、“ Apache Doris 的核心开发人员大部分在任职”等诸类话术。

实际上， GitHub 上公开的数据显示，Apache Doris 贡献代码前三的 Contributor 全部在百度 Doris 团队就职，不知所谓的“大部分”和“主创”从何说起。

最近一年，提交 Commits 数量前二十的 Contributor 中，有一半来自百度 Doris 团队，另一半来自小米、美团、字节跳动、蜀海、网易等 Apache Doris 的开源用户，在此也对所有的 Contributors 表示由衷地感激。

而唯一一个 DorisDB 的 Contributor ，入职 DorisDB 时间为 2021 年 8 月 27 日。没错，入职 DorisDB 快两周了，之前在百度 Doris 团队。

实际上，从 2020 年初起， DorisDB 团队几乎没有向 Apache Doris 提交过一行代码。少部分开发者原本是 Apache Doris 的 Contributor ，在加入 DorisDB 团队后，同样不再向 Apache Doris 贡献一行代码。

比如 DorisDB 团队在人员扩张时，会故意定向挖 Apache Doris 企业用户的员工。开源社区的发展离不开用户的支持，挖用户墙角更无异于自掘坟墓。对于员工个人主动的选择我们不去评判，但这让企业用户对自己员工的培养做了嫁衣。而短视的人是不会看到这些的，更认为与他们毫无关系， Apache Doris 的死活与他们无关，只要自己能招到人就行。

比如 DorisDB 的商标问题，从品牌角度来说，开源项目与商业化产品的品牌必须存在区分度，比如 Linux 和 RedHat 、 Hadoop 与 Cloudera 、Apache Kylin 和 Kyligence 。

而 DorisDB 和 Apache Doris ，相信很多开源用户在初次接触 Doris 的时候都会迷惑这两个产品的区别是什么，甚至以为是同一个产品。这也是 DorisDB 的目的所在，品牌上的混淆可以带来用户流量，这就够了。而 Apache 基金会对此事件有过多次发声， DorisDB 及其团队不管不问，企图继续混淆视听，直到最后在 Apache 基金会的压力下，才不得不通过所谓的“开源”来更名。

比如所谓的“致 Clickhouse 的一封信”。Apache Doris 与 Clickhouse 都是 MPP 数据库领域的优秀产品，各自擅长的领域或适用的场景存在差异，所有用户可以基于技术认知和业务需求来抉择到底该选择哪一款产品，甚至在大多场景里两者是可以并存和相互补足的。

Apache Doris 不会、也十分不认可，通过贬低 Clickhouse 来达到推广自己的目的，这与开源的精神十分不符。而 DorisDB 选择向 Clickhouse 开战的行为，也使 Apache Doris 承受了许多本不应该由我们承担的骂名和非议。

比如 Apache Doris 的向量化执行引擎，本来至少提前一个季度就可以与用户们见面。DorisDB 已经有接近两年没有参与过一次社区讨论，唯独在我们把向量化引擎的代码提交 PR 并发起 Veto 这一关键的时间点，给了唯一的 -1 。DorisDB 给 -1 的理由我想不言而喻，无非是为了自己的商业化利益来阻拦社区的关键发展。

尽管无意义的 -1 可以忽视，但我们仍遵守社区规范，这无疑带来了我们许多额外的工作量，也打乱了我们原定的发版节奏。不过幸好最晚 9 月中旬，我们自己的向量化引擎就会提交到社区了，欢迎所有小伙伴关注。

………

诸如此类的事情日积月累，我们明白其实社区的分化已经无可避免。作为 Apache Doris 的维护团队，我们其实不愿意面对这样的局面，但当少数人想要凌驾于社区规则之上并持续向社区吸血时，附骨之蛆不要也罢。

关于如何看待 StarRocks  “开源”

两个方面来看。

对于改名。

从 2021 年下半年开始，我们就在努力地筹备 Apache Doris 毕业的事宜，横在我们面前的阻碍，其中最重要的事情之一就是 DorisDB 对 Apache Doris 的品牌侵权问题。

因为他们最初将产品命名为 DorisDB 就受到了 Apache 基金会的质疑，进而阻碍了 Apache Doris 的毕业进程，也给 Apache Doris 社区带来了困扰。最终在 Apache 基金会的施压和我们的抗议下，不得已作出了改名的行为。

改名对我们来说，意味着 Branding 问题不复存在，意味着扫清了毕业路上最大的一个障碍，我们也会继续尽全力投入在 Apache Doris 的毕业筹备工作上。

对于“开源”

注意“开源”这个地方打了引号，其实可以给大家科普一下开源许可协议的背景和差异。

开源促进组织 OSI （Open Source Initiative，也被译为开放源代码促进会，官网地址 https://opensource.org/ ）是一个推动开源软件发展的非盈利组织。OSI 定义了近百种开源协议，这已经成为了开源协议的事实标准。换句话说，不被 OSI 认可就不是开源。

Apache License 2.0 作为最主流的开源协议，被 OSI 认定为“受欢迎且被广泛使用或具有强大社区的许可证“（The following OSI-approved licenses are popular, widely used, or have strong communities）。

有关 Apache License 2.0 的具体内容，可以在 Apache 官网（  http://www.apache.org/licenses/LICENSE-2.0 ）查阅。简单来说，分发完全自由、允许项目代码被修改、允许作为开源或商业化软件再次发布，一旦授权永久有效，在修改代码或有源代码衍生的代码中需要带有原来代码的协议、专利声明等。这是对于任何商业化公司和开源用户都极其友好的协议，而 Apache Doris 作为 Apache 基金会的项目，遵守的就是 Apache License 2.0。

StarRocks 呢？遵守的是 Elastic License 2.0。

Elastic 和 AWS 的纷争我们不再去重提。Elastic 修改开源协议为 SSPL 和 Elastic License 双许可，其本意是保护自身原厂的权益，要求未对项目作出贡献的情况下不得发布自己的开源及商业化产品。StarRocks Fork 的是 Apache Doris ，这身份已经本末倒置了，请问 DorisDB 是否有回馈上游？这不仅不遵守基本的 Upstream First 原则，还声称要保护 StarRocks 的知识产权，这也是十分双标了。

再者，Elastic License 的内容如果有心去看，可以发现有“不得将产品作为托管服务提供给其他人”、“不得规避许可证密钥功能或删除/隐藏受许可证密钥保护的功能”、“不能更改许可证”等条件，简单来说就是，你想在云上用？不行！如果有些商业化功能我屏蔽了不让你用，你想不花钱就用？不行！你只能遵守我的协议，如果分发后想换成别的协议？不行。

种种限定的孰是孰非我们不去细究，至少 OSI 不认可 Elastic 协议，认定其是“伪开源协议”，充其量叫“源代码可获取”。不信？可以去看看 Apache Skywalking 是如何回应 Elasticsearch 修改开源协议的。

为什么 StarRocks 不回馈给 Apache Doris ？

说完了如何看待 StarRocks “开源”，再说下他们为什么不回馈上游的 Apache Doris。

我们之前一直是希望能够共同建设 Apache Doris 社区的，至少在他们所谓的“开源”之前，但是多次沟通没有任何结果。

至于 StarRocks “开源”之后，那就更不可能了，因为 StarRocks 选择的 Elastic License 开源协议不被认可， StarRocks 的代码也无法被引入到任何 Apache 以及所有 OSI 认可的项目中，这包括了大数据领域几乎所有耳熟能详的项目，诸如 Hive、Spark、Flink、Pulsar、Kafka、Impala、Kylin、Clickhouse、Hudi 等等。换句话说，基本上已经被主流的开源大数据项目隔绝开来。当然，Apache Doris 也引入不了任何 StarRocks 的代码，这也是 StarRocks 选择 Elastic License 开源协议的出发点之一。

作为 Fork 自 Apache Doris 的项目，StarRocks 开出新的分支后不仅分裂了社区，而且不回馈上游，甚至还修改了开源协议、誓要与上游彻底决裂，这种所谓的 “开源”行为本身就很违背开源精神。

诚然，法无禁止即可为。Apache License 上约束不了这样的恶意行为，但大多社区用户是知道的，真正理解开源的人也是知道的，到底有何是不可为的。

总结一下

OK，前面讲的东西比较多，大家消化消化，话题收敛。

谴责也好，澄清也好，抱怨也好，在既定的事实面前都没有任何作用，说点实际一些的。

这个时代不会阻止任何一朵星光闪耀，每个人都有自己的星辰大海。

只不过未来各自朝着各自的启明星和灯塔航行而已。

祝未来一切都好，毕竟 StarRocks 飞得再高，也是站在了巨人肩膀上。

话题回到 Apache Doris。

作为 Apache Doris 的创始和维护团队，我们一直坚持在做，也会持续去做，会更加开放地拥抱开源，不会因为任何人的任何行为改变自己的方向。

我们很清楚接下来该如何开展后续工作，将会持续在社区用户的支持、产品性能的增强以及功能边界的拓展上投入更多人力和精力。我们希望能帮助更多社区用户，解决数据分析的痛点与难题，这是 Apache Doris 开源之初的愿景，一路走来，从未改变。我们也希望，能让 Apache Doris 进一步完善，向世界顶级的分析型数据库产品之路上再进一步。

说几点我们最近在做的事情吧。

Apache Doris 向量化执行引擎， 9 月底会出第一版，预计在单表上性能会有数倍提升，年底向量化执行引擎就会全面推出，敬请期待。

Doris Manager 可视化运维监控平台，我们也会尽快推出并开源，让运维更便捷和简易。

还有很多事情都在之前的开发者会议上提到了，可以查看之前的开发者会议总结 社区活动｜ Apache Doris 社区开发者会议总结

社区活动方面，不管是 SIG 、征文活动、开发者会议还是即将举办的 Meetup ，希望大家多多参与，希望每个人都能在社区获得成长、有更多收获。

最后，感谢陪伴。

以上。

欢迎扫码关注：Apachedoris 官方微信公众号

相关链接：

Apache Doris 官方网站：

http://doris.incubator.apache.org

Apache Doris Github：

https://github.com/apache/incubator-doris

Apache Doris 开发者邮件组：

dev@doris.apache.org