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