Apache DolphinScheduler PMC：開源不一定也要九死一生
參與開源已經快3年了，這次在Meetup上沒有分享純技術的話題，其初衷是想帶這大家從一個開源社區維護者的視角來看開源，希望大家能從中獲取到一些感悟，當然這次的話題有些觀點可能抱有主觀看法，大家多多包涵。
什么是開源
我在這里說的開源特指開源軟件**(open source software, 縮寫 OSS),** 又稱開放源代碼軟件, 是一種源代碼可以任意獲取的計算機軟件，一些開源軟件被發布到公有領進行托管, 如GitHub, GitLab, Gitee 等。
常見的開源軟件有：
操作系統： Linux Kernel, Chrome OS, 基于 Kernel 的各種發行版等。
數據庫：Postgres, MariaDB,MongoDB, Redis 等。
編程語言： JavaScript, OpenJDK, CPython 等。
中間件： Nginx, Apache HTTP, Moby(docker)。
開源的組成形式
一家生產飲料的公司，有一個非常獨特的配方，生產出來的飲料大家都喜歡喝, **配方層層保密，**就是整個區域整個國家甚至是全球，只有它才能生產出這樣的飲料，我說的這家公司就是可口可樂，這種模式導致傳說這個配方比公司的市值還要高。
**我有好的idea。**這個idea在市場上適用性很高，在以前經濟主體中, 會希望將這個idea層層保密, 將它作為我的商業秘密保存, 類似可口可樂。
在開源中卻不是這樣的，比如我開發了一個有趣的東西，我想的更多的是把它開源出去，希望更多人來使用/參與，希望大家對他提點意見。
在這個過程中部分作者認為，**在他將產品開源過程中, 能獲取榮譽感，產出是被人認可的。**而從我的角度來看，是一個既能解決我的問題，又能解決別人問題的過程，讓我的代碼變得更有意義。
**項目的控制力。**飲料公司配方就是集中式的體現，公司不希望有很多人了解這個事情，不希望別人知道有秘方的存在。同時, 之前的軟件行業也是如此，有些軟件會暴露一些SDK讓用戶去基于SDK開發插件 ，但是從來不會把他們的代碼給開源出來，他們希望自己是產品的控制者，其他人只是參與者。
但是開源就不一樣，他不僅會告訴你如何去寫插件，你也可以看項目核心的代碼，可以修改核心的代碼，如果修改是正確，社區維護者會接受你的修改。在開源里控制權不再是一個個體, 公司, 或者國家, 它是被社區控制。這里說的控制指的是發展方面，以及修改合并的審核，并不是對軟件和參與者的控制。
**人員的組成。**在我剛參加工作的時候，有不懂的就會去問我的leader。但參加開源之后會發現，這里更加傾向在公共領域拋出問題，而非點對點交流。當有問題的時，在郵件列表，或者slack/微信群拋問題，你會發現有用戶來幫你解決問題了，社區的貢獻者回復的有時沒有用戶的快，這就是人員組成的問題。
社區往往是一群人在努力奮斗，能收集更多用戶場景，能將產品打磨使其適用性更加廣，在3、5年前，小海豚用戶還沒有這么多，會面臨適用性問題, 隨著用戶數量和反饋越來越多，小海豚的適用性越來越廣，很多公司基本上剛接觸就可以直接一鍵部署，除了一些OA 或者特殊的鑒權，整個業務就能很快就能跑起來。
在局中
很多小伙伴可能都覺得開源可能離你很遠，我個人覺得這是一個錯誤的觀點，其實大部分人都已經身在其中。只要你在使用開源的軟件，無形中你就已經成為整個開源大廈當中的一部分，你是社區的用戶，又或者今天來參加社區技術活動、參加Meetup也是社區的參與方式，開源并沒有離我們很遠。
有庫寫入權
除了Apache基金會旗下的開源項目，Google、Facebook、阿里等企業開源出來的項目，**只要你在里面貢獻代碼，并且有獲取寫入權限，你就算是一個開源項目的維護者了。**甚至自己寫了一個小工具，并且在細分領域非常有用，并且開源出來有人在使用，有人star，你也是屬于開源維護者，算得上是一個在深度參與開源的小伙伴了。
貢獻過代碼
如果你在開源項目中貢獻過代碼，不管是文檔還是代碼，**都是被歸屬為貢獻者人群。**其次是參與社區討論，比如海豚調度會有郵件列表和對應的 GitHub issue，**我們會在郵件列表討論問題，如果參與其中討論問題的討論，甚至是在微信群/slack群討論內容，那你就算是一個深度的用戶，**并且在參與推動開源反饋的過程。
這里補充一點，反饋對一個開源軟件來說很重要，我們需要持續的深入去挖用戶的場景，甚至海豚調度到今天來說還會不斷地去做用戶訪談，挖掘有哪些未解決的痛點，社區從哪些維度優化改善提升！特別是很多用戶都在反饋同一個痛點的時候，開源的維護者就會不斷去推動落實，說不定未來的3.5或者4.0發版的時候，這個痛點問題被解決了。
使用過項目-用戶
還有一類用戶，經常使用但是不參與任何討論。我們看到上面的漏斗圖，會發現這個用戶群體在社區里面是最大的群體，也是最重要的一個群體。我見過有些開源軟件，它代碼寫得不錯，但是沒有用戶使用或者是它的用戶群體太小眾了，我認為它可能是一個開源軟件，但它算不上偉大，用戶群體的多寡很可能會決定產品是否偉大。
貢獻者入權
接下來我們會發現社區里面第二大的群體就是Contributor。如果說用戶是很重要的話，那Contributor可能就是正向推動整個開源的核心力量。比如他在使用DolphinScheduler發現了一些可優化點，提個 PR修改源碼或者文檔，作為維護者或者作為核心貢獻者，都會非常的高興去采納他，并且還會一起溝通、協商如何把這個PR給merge到分支去，這些貢獻者的存在，才能讓社區欣欣向榮。
維護者
開源社區的維護者就是擁有代碼的寫入或者修改權限的人。但是在這里想特別說明一下，漏斗圖里面僅僅是說明了數量的變化，并不上表示區分社區不同角色的重要程度。正如剛剛所說，雖然我是DolphinScheduler的PMC，但我并沒有覺得我這個身份比任一的用戶更重要，海豚調度在早期沒有用戶的話，那海豚調度這個項目也就走不遠了。
開源有趣的事兒
我目前是白鯨開源的數據工程師，就是可能有部分小伙伴了解到白鯨開源主要干的事是基于DolphinScheduler去做商業化。有的小伙伴就會認為你是這個公司的員工，是不是會專注海豚調度社區，應該有更多的時間投入社區，幫大家去解答問題，去實現大家的一些想法。當然這個想法是正確的，但又不完全正確，因為我的時間投入可能不比大家的多太多。
時間分配
其實在一家開源商業化公司做工程師，在時間上并沒有大家想象中的那么充沛。在日常處理中，大家 70% 的時間都是在處理公司的業務需求，只有 30% 時間專注在開源上面。當然這里并不是說我只有 30% 的時間才去貢獻 DolphinScheduler 代碼，日常工作中我和同事大部分代碼是貢獻到 DolphinScheduler 的，但是這也存在時間節點，就如同大家在公司開發項目一樣。比如為了擴展用戶，我們做了部分SaaS 相關組件以及Python API相關的支持，這部分代碼我們全部貢獻到 DolphinScheduler 倉庫中，但是我會將其歸結為公司的日常工作，因為這是公司的業務相關，且又期望時間節點的事情。
現實情況就是，需要將公司分配的任務完成之后，才能去做社區review代碼等一系列事情。
而在剩下的30%時間，我也不都是在看issue跟PR，大部分時間會關注到我個人在社區負責的模塊，我目前主要是負責Python API以及文檔模塊，當這塊有特定的 PR 提交上來的時候，會第一時間@到我，我就會提前去 review 這一個部分，我認為這是我對社區的職責，并不是我對公司或者任何一個人的責任，是我覺得我做了社區一份子應該做的事情，換個角度說，我覺得這是社區每個參與維護或貢獻的小伙伴都需有這種責任心，這樣才能保證社區繁榮發展。
如果有小伙伴往 DolphinScheudler 提交 PR 的時候，會發現你提交 PR 的時候他會立馬去要求幾個小伙伴去看，這就是他們在社區所負責的范疇。
當你發現你的 PR 或者是 issue 沒有被人及時回復的時候，你可以手動 at 他，我相信他也會立馬去幫你 review，如果他看到沒有回復，可能真的是不小心看漏消息。
發版所需要的時間
我還有 20% 時間要處理發版的事情。之前社區有小伙伴說發版的頻率不是很高，**其實社區的發版遠比大家想的要復雜。**首先每個發版人有一定的壓力，因為這個版本是經過他的手發出，他需要保證新版本能夠高效穩定的運行。**其次Apache 基金會發版有一套發版流程。**單投票這一個環節就需要三天，你會發現你可能啥都準備好了，但是走測試流程、走發版流程也可能需要消耗個把星期，才能把版本發出來！
**另外10% 的時間我才會處理大家讓我去做的一些需求，**比如小伙伴在在 slack 或者 微信讓我幫忙看看代碼, 我看到都會點進去瞧瞧, 如果太忙我會在 Github 簡單評論, 并說晚點我看看。然后只有 10% 的時間我會主動地去檢索我們目前 issue PR 列表。
一個issue、PR需要的時間。
有人會說我們 issue 的 PR request 時間長或者是郵件列表/Slack響應不及時，比如有個用戶很著急，可能是個線上問題，可能上手的時候卡住不能往下進行，而社區沒有人第一時間去回復，可能隔了半天或者是隔了一天才去回復，大多數情況都是因為時間并沒有大家想象中的這么多，所以大家可以盡量把時間預留出來。
Issue處理的流程及時間
簡單(1-5min)： 通過文檔指引, 文字解釋能解決。
中等(6-20min)：本地復現。
困難(20min以上)：
- 確定各個版本的差異。
- 確定環境。
- 確定用戶是否能穩定復現。
- 定位代碼。
- 解決問題。
提了一個bug、PR怎么感謝我
這是一個非常有意思的點，我發現會有些人向社區提了一個Bug/PR，他感覺就是說社區應該感謝他。其實這是對開源的理解有誤，并不是說提交一個東西是對誰好，社區是一個團體，而開源軟件是一大群人在干的事情，并不是說個人要解決的事情。當然如果你提了PR去解決特定的問題，我個人的角度會由衷地感謝。但如果你覺得自己提了PR之后，然后可以去邀功的，我覺得大可不必。
提了很久沒有實現
其實我們都會將收集到的問題記錄在issue列表或者是discussion里面。就是你提issue或PR的時候，我們會有一個機制，你可以提前去搜索一下是否有類似的issue，如有的話應該去對應的issue上面評論，社區會定期review，當發現這個需求是很多人都在反饋，可能會在下一個版本實現它。
但如果這是個特定的需求合作只是個別需求，可能只在你們公司幾個小伙伴里面才有的話，那社區可能就不會去實現這一個特別的需求。因為海豚調度的定位就是要做一個通用的平臺，當然也會盡可能滿足大家的需求，而不是全部的需求。如果你想去實現它，我們也是非常歡迎你貢獻代碼的。
PR處理流程及時間
簡單(1-10min)： 一眼看懂并給出建議。
中等(11-30min)：
- 判斷原始 issue、修改合理性。
- 是否有更好的方式。
- 是否影響別的功能。
- 單元測試、文檔是否完善。
困難(30min以上)：
- 中等的全部。
- PR拉到本地不斷校驗測試。
- 一個 PR 根據修改模塊重要程度, 可能需要多次、多人 review 保證其正確性。
開源層級
有意義的開源
**我認為能解決一小部分人的需求，就算一個有意義的開源。**它容錯性非常高，甚至它可以不及時更新或者是幾乎不怎么維護，很少發版。都可以被稱為一個有意義的開源。
前段時間我的個PR，使用了發版頻率很低的一個庫，已經1年沒有發版，但確實能很好地解決我的問題，所以依然會去使用，我覺得這也是一個有意義的開源。
好的開源
**能解決一個領域的問題，解決一大部分人的需求，有一定業界知名度的開源項目。**日常聊天中同行大概知道這個軟件，在用戶中口口相傳了，并且這個開源項目是與時俱進的，就像今天的DolphinScheduler，我們會有更長遠的規劃，比如增加k8s、增加對 SaaS 服務的支持等等，這也是我們最近在做的事情。
成功的開源
**從業者大部分都知道這個開源項目，已經積累到一定口碑，愿意說服公司來使用它，**甚至主動會為這個產品做站臺，包括今天參加 Meetup的各位講師，都是為海豚調度站臺的人，我也非常感謝大家對海豚調度的支持。我認為成功的開源還有個特征，就是它的迭代也會比較快，發版也會持續不間斷，這也象征著項目背后的維護者也會有很多。
我認為，目前DolphinScheduler應該是處在好與成功之間，我們希望能把它做到一個成功的開源項目，希望當有人說到調度，都覺得海豚調度是一個很好的選擇，并且在選型對比的時候，海豚調度一定在對比的行列中。
Flask社區的小故事
Flask社區的維護者在前一段時間，整個 Flask 的倉庫的issue跟 PR 都被清零了，站在我個人的角度上來說，這是個非常了不起的事情，因為這是一個擁有5W+Star和每月7000 多萬下載量的項目，可以說他們的維護者做了很大的努力。
但是我也看到有一些人在下面評論，說有很多時候提了 issue，他們這個社區并沒有很好的解決方案，直接把它 close 掉了，有人覺得這是不對的，我沒有辦法去評論他做得對不對，但是我覺得他這是個非常牛逼非常偉大的舉動，他們付出的努力可能遠比我想象中的多。
Praquet社區PMC的感慨
最近看到這個社區新的 PMC chair 圈已經被選舉出來了，然后新的PMC發圈感謝老一輩的付出。
這也是我前一段時間說在整個開源社區，它是一個不斷疊加、不斷滾動上升的過程。
我們不可能要求幾年前參加社區貢獻的小伙伴還留在社區，因為每個人的發展軌跡或者是成長軌跡，都會有不一樣的關注點，可能他前一段時間還在 A 公司，專注于DolphinScheduler二次開發，去B公司之后可能就干別的活了。
我們不能要求他換了公司之后，你還要投入社區，但我們心里還是非常希望他持續投入，當這些暫時離開的小伙伴再次回歸，我們自然是非常歡迎的。
整個社區是在滾動交替的過程的，我們會有老一輩的貢獻者，**會有新一輩的貢獻者，人才輩出，長江后浪推前浪，**整個社區不斷繁榮，不斷壯大。
以上就是今天的全部分享。謝謝大家。
