相信這兩天很多社區小伙伴都看到 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 ，希望大家多多參與，希望每個人都能在社區獲得成長、有更多識訓，

最后，感謝陪伴，

以上，

歡迎掃碼關注：

Apache Doris(incubating)官方公眾號

相關鏈接：

Apache Doris官方網站：

http://doris.incubator.apache.org

Apache Doris Github：

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

Apache Doris 開發者郵件組：

dev@doris.apache.org