點亮 ⭐️ Star · 照亮開源之路 GitHub:https://github.com/apache/dolphinscheduler 參與開源已經快3年了,這次在Meetup上沒有分享純技術的話題,其初衷是想帶這大家從一個開源社區維護者的視角來看開源,希望大家能從中獲取到一些感悟,當然這次 ...
點亮 ⭐️ Star · 照亮開源之路 GitHub:https://github.com/apache/dolphinscheduler 參與開源已經快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需要的時間 有人會說我們 issue 的 PR request 時間長或者是郵件列表/Slack響應不及時,比如有個用戶很著急,可能是個線上問題,可能上手的時候卡住不能往下進行,而社區沒有人第一時間去回覆,可能隔了半天或者是隔了一天才去回覆,大多數情況都是因為時間並沒有大家想象中的這麼多,所以大家可以儘量把時間預留出來。
Issue處理的流程及時間
簡單(1-5min): 通過文檔指引, 文字解釋能解決 中等(6-20min): 本地復現, 困難(20min以上):- 確定各個版本的差異
- 確定環境
- 確定用戶是否能穩定復現
- 定位代碼
- 解決問題
- 判斷原始 issue、修改合理性
- 是否有更好的方式
- 是否影響別的功能
- 單元測試、文檔是否完善
- 中等的全部
- PR拉到本地不斷校驗測試
- 一個 PR 根據修改模塊重要程度, 可能需要多次、多人 review 保證其正確性