參與開源已經快3年了，這次在Meetup上沒有分享純技術的話題，
其初衷是想帶這大家從一個開源社群維護者的視角來看開源，希望大家能從中獲取到一些感悟，當然這次的話題有些觀點可能抱有主觀看法，大家多多包涵。
Apache DolphinScheudler PMC
我在這裡說的開源特指開源軟體
(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 request 時間長或者是郵件列表/Slack響應不及時，比如有個使用者很著急，可能是個線上問題，可能上手的時候卡住不能往下進行，而社群沒有人第一時間去回覆，可能隔了半天或者是隔了一天才去回覆，
大多數情況都是因為時間並沒有大家想象中的這麼多，所以大家可以儘量把時間預留出來。
簡單(1-5min): 透過文件指引, 文字解釋能解決
這是一個非常有意思的點，我發現會有些人向社群提了一個Bug/PR，他感覺就是說社群應該感謝他。其實這是對開源的理解有誤，並不是說提交一個東西是對誰好，社群是一個團體，而開源軟體是一大群人在乾的事情，並不是說個人要解決的事情。當然如果你提了PR去解決特定的問題，我個人的角度會由衷地感謝。但如果你覺得自己提了PR之後，然後可以去邀功的，我覺得大可不必。
其實我們都會將收集到的問題記錄在issue列表或者是discussion裡面。就是你提issue或PR的時候，我們會有一個機制，你可以提前去搜尋一下是否有類似的issue，如有的話應該去對應的issue上面評論，社群會定期review，當發現這個需求是很多人都在反饋，可能會在下一個版本實現它。
但如果這是個特定的需求合作只是個別需求，可能只在你們公司幾個小夥伴裡面才有的話，那社群可能就不會去實現這一個特別的需求。因為海豚排程的定位就是要做一個通用的平臺，當然也會盡可能滿足大家的需求，而不是全部的需求。如果你想去實現它，我們也是非常歡迎你貢獻程式碼的。
-
-
-
一個 PR 根據修改模組重要程度, 可能需要多次、多人 review 保證其正確性
我認為能解決一小部分人的需求，就算一個有意義的開源。
它容錯性非常高，甚至它可以不及時更新或者是幾乎不怎麼維護，很少發版。都可以被稱為一個有意義的開源。
前段時間我的個PR，使用了發版頻率很低的一個庫，已經1年沒有發版，但確實能很好地解決我的問題，所以依然會去使用，我覺得這也是一個有意義的開源。
能解決一個領域的問題，解決一大部分人的需求，有一定業界知名度的開源專案。日常聊天中同行大概知道這個軟體，在使用者中口口相傳了，並且這個開源專案是與時俱進的，就像今天的DolphinScheduler，我們會有更長遠的規劃，比如增加k8s、增加對 SaaS 服務的支援等等，這也是我們最近在做的事情。
從業者大部分都知道這個開源專案，已經積累到一定口碑，願意說服公司來使用它，甚至主動會為這個產品做站臺，包括今天參加 Meetup的各位講師，都是為海豚排程站臺的人，我也非常感謝大家對海豚排程的支援。我認為成功的開源還有個特徵，就是它的迭代也會比較快，發版也會持續不間斷，這也象徵著專案背後的維護者也會有很多。
我認為，目前DolphinScheduler應該是處在好與成功之間，我們希望能把它做到一個成功的開源專案，希望當有人說到排程，都覺得海豚排程是一個很好的選擇，並且在選型對比的時候，海豚排程一定在對比的行列中。
Flask社群的維護者在前一段時間，
整個 Flask 的倉庫的issue跟 PR 都被清零了，站在我個人的角度上來說，這是個非常了不起的事情，因為這是一個
擁有5W+Star和每月7000 多萬下載量的專案，可以說他們的維護者做了很大的努力。
但是我也看到有一些人在下面評論，說有很多時候提了 issue，他們這個社群並沒有很好的解決方案，直接把它 close 掉了，有人覺得這是不對的，我沒有辦法去評論他做得對不對，但是我覺得他這是個非常牛逼非常偉大的舉動，他們付出的努力可能遠比我想象中的多。
最近看到這個社群新的 PMC chair 圈已經被選舉出來了，然後新的PMC髮圈感謝老一輩的付出。
這也是我前一段時間說在整個開源社群，
它是一個不斷疊加、不斷滾動上升的過程。
我們不可能要求幾年前參加社群貢獻的小夥伴還留在社群，因為每個人的發展軌跡或者是成長軌跡，都會有不一樣的關注點，可能他前一段時間還在 A 公司，專注於DolphinScheduler二次開發，去B公司之後可能就幹別的活了。
我們不能要求他換了公司之後，你還要投入社群，但我們心裡還是非常希望他持續投入，當這些暫時離開的小夥伴再次迴歸，我們自然是非常歡迎的。
整個社群是在滾動交替的過程的，我們會有老一輩的貢獻者，
會有新一輩的貢獻者，人才輩出，長江後浪推前浪，整個社群不斷繁榮，不斷壯大。
以上就是今天的全部分享。謝謝大家。
來自 “ 開源社KAIYUANSHE ”， 原文作者：鍾嘉傑；原文連結：https://mp.weixin.qq.com/s/Pvyg5Gn-3OpMFxa0cE6K3g，如有侵權，請聯絡管理員刪除。
