深度思考: 如何做好一個開源項目?

作者：徐小夕 2022-01-04 09:01:10

開源

做開源項目能帶給我什么呢? 這也許是大部分想做開源項目的人的一個疑問. 大部分人也會走入一定的誤區, 雖然這個問題很簡單, 但是簡單的問題往往更復雜.

接下來我會按照如下目錄大綱和大家分享我自己的感悟:

我對國內開源項目的思考
國內開源項目/社區的不良風向, 是如何加速招聘的“內卷”?
做開源項目能帶給我們什么?
從零到一, 如何打造一個高執行力,快速迭代的開源項目?
分享幾個有價值的開源方向

我對國內開源項目的思考

首先在闡述任何觀點前, 大家都應該以一種批判的角度來看待和消化, 因為任何人的思考和觀點都可能是局限的.

項目開源是一件非常崇高且有意思的事情. 這是我曾經一直持有的看法. 國外的開源大佬TJ等人, 國內的湯姆大叔等, 一直是我的技術偶像.

他們和我的唯一共同點就是不及格的發量, 這讓我找到了些許安慰.

閱讀這些大佬們優秀的開源項目讓我成長很多, 也學到了真正有價值的開源項目該如何去做.

但是最近2年, 我在看github的trend的時候, 不免有點尷尬, 同時夾雜著些許的力不從心. 當我看到大量國內割韭菜式的開源項目之后, 不禁在草稿紙上寫了一句:

好了, 不吐槽了, 接下來總結一下我對優秀開源項目的一些感悟.

從項目自生結構的角度

項目目錄結構清晰

文件/文件夾命名規范, 可讀性強

清晰完整的readme介紹

簡潔的項目描述
項目版本信息, 辨識度高的logo
項目應用場景介紹, demo案例
api使用文檔
清晰的todo和undo清單
貢獻指引和相關生態

規范而詳細的package.json文件(或者項目描述文件)

從項目實用性角度

解決了當下開發環境的某一痛點(比如模塊化解決方案amd,cmd等)
能快速提高開發效率(提效工具, 工具/類庫等)
能很好的解決某一框架遇到的瓶頸(比如vue/react之于jquery)
能很好的降低使用某一框架開發項目的難度(比如vue/react/jq等的插件)
能很好的解決企業通用業務需求(比如antd-pro, egg, H5-Dooring)
能讓程序員快速理解開源項目的開源(比如翻譯類文檔, 技術思考性穩定, 能快速磨平認知差異)

當然還有一些方向可以去思考, 比如底層技術方案(操作系統, 基礎語言等), 離我太遠, 暫時擱置.

國內開源項目/社區的不良風向, 是如何加速招聘的“內卷”?

內卷: 本意是一類文化模式達到了某種最終的形態以后，既沒有辦法穩定下來，也沒有辦法轉變為新的形態，而只能不斷地在內部變得更加復雜的現象。

最近兩年大家有沒有發現, 各大技術社區內充斥著大量求職面試相關的文章, 層次不齊, 千篇多少有點一“綠”. 想認真看看技術文章, 還得花時間往下多翻幾次, 因為頂部推薦基本被面試文, 進大廠文霸占了.

雖然求職找工作需要準備, 但是我個人覺得沒必要過渡準備, 否則必然會遭遇我們最熟悉的名場面: "卷王面試官" 和“卷心菜求職者”的相愛相殺.

這里我來給大家伙分析一下為什么過度釋放面經導致越來越卷的原因.

面試官想: 出什么面試題呢, 社區上這么多面經, 想必大家一定有所準備, 那就來點剛的(有難度的).

求職者想: 最近看各種面經, 不管是大廠小廠, 面試題都這么難, 我要多刷幾道題.

好的, 還沒完, 接下來就是 github上的1000+筆/面試題, 刷去吧, 刷完了你沒進大廠, 不是題的原因, 是你的原因.

好家伙, 被這樣的環境培養出來的程序員, 未來對技術能有多大的想象空間呢? 這里不經讓我想到我另一位偶像的經典名言:

想象力比知識更重要. —— Albert Einstein

同時想到一位想象力觸及火星的國外老鐵:

所以說這一節我主要想表達三個觀點:

被刷題榨干的求職者未來會對技術還產生多大的長遠興趣?
國內開源環境充斥著大同小異的面試題, 國內個人開源項目未來還會有多大的想象空間? 難道國內有價值的開源真的是有大公司才能玩的起?
沒有持續的興趣和想象力, 永遠做不出好的有價值的開源項目.

這里當然不是不鼓勵這些, 意在不要過渡重視刷題, 其實偶爾做做有價值的開源項目, 也會為面試加分. 畢竟在近3年的求職面試中, 我是從來沒有為面試做過任何準備的.

做開源項目能帶給我們什么?

在上面幾小節的觀點中, 各位提煉有價值的觀點即可. 我們接下來進入今天的正題.

首先一部分人會覺得, 開源項目可以給自己積累項目經驗, 簡歷上加分, 鞏固自己的知識體系, 積累人氣等等. 我之前也是怎么認為的. 但是這種開源思維只適合初級開源, 一般的結果是: 雖然開源項目讓自己加深了對技術的熟練度, 簡歷上也可以寫寫了, 但是隨著時間流逝, 最終會被遺忘.

所以現在的我, 在思考這個問題前, 一定會先問自己幾個問題:

我做這個開源是為了解決什么問題?
目前已有的解決方案有哪些?
我怎么做, 才能做的比已有的方案更好?
我如何才能讓我的項目持續發展下去, 而不是過眼云煙?

在解答了以上4個問題之后, 我們做開源項目會更有目標和框架感, 也更能明確自己能得到什么:

獨一無二的解決方案
對該領域有更深度的研究和了解
對未來職業發展更有談資
收獲了更多技術方案和開源小伙伴
通過項目價值體現個人價值和某一領域影響力
收獲money, 流量, 企業offer

所以我們不要過度的追求結果, 我們在做有價值的開源項目的過程中, 自然會讓自己變得更有價值. 從做H5-Dooring這個項目之前, 我就已經充分回答了自己提的上述4個問題, 所以項目最終的結果, 大家也有目共睹. 在我做完H5-Dooring第一版之后, 為了解決第四個問題, 我就篩選了幾個志同道合的朋友, 和我一起迭代, 讓項目按照提前規劃持續推進下去.

從零到一, 如何打造一個高執行力,快速迭代的開源項目?

就以我自己實際經歷作為佐證, 來談談開源項目的打磨過程.

不要問我這個流程為什么像個“心”形, 我只是想表達開源作者們10個有7個都是為“愛”發電. (所以默默為這些優秀的人👏)

1.目標規劃期

首先在明確了為什么要做這個項目之后, 我們需要對自己的開源項目有個清晰完整的規劃路線. 比如1.0版本需要做哪些功能, 哪些功能是高優先級一定要完成的,哪些是不緊急的, 可以后期在完成. 所以我們要充分利用好四象限法則.

其次就是明確的功能拆分, 需求池管理, 學會過濾需求, 而不是一股腦的全盤接收, 因為有時候用戶提的需求他自己也不知道, 所以需要評審.

有了以上目標規劃和管理法則, 我們就能有一個清晰而高效的目標規劃了.

2. 項目基建期

項目基建期主要是項目的雛形, 這個階段一定是項目負責人搭建, 需要對項目的整體技術選型, 架構, 解決方案設計等有完整的思路和落地方案. 這樣才能為以后團隊開發, 迭代和項目優化打下基礎, 否則最終會亂成一片. H5-Dooring在項目初期也是按照這個思路走的, 我先把項目完整流程設計出來, 并在github上開源, 后面才能找到一批直觀且感興趣的朋友來維護和優化.

3.團隊組建期

團隊組建也是非常關鍵的環節. 首先創始人需要具備一下特質:

具備一定的技術實力(能獨立做出解決方案, 把控整個項目)
對項目有一定研究深度并且有明確的目標規劃
絕對的執行力, 發揮領頭羊作用
格局放大, 接受能力比你強或者比你弱的朋友, 發揮其長處
對項目有堅定的信念
謙虛 + 追求極致
相互學習和共同成長的態度和團隊相處

只有具備以上3點以上, 才能打造高效且有凝聚力的團隊.

同時, 我們只有選擇價值觀相同, 對項目感興趣, 且有一定執行力的協作者, 開源項目才能穩步發展下去. 所以團隊人數多不一定做的就快, 團隊人數少, 也不一定做的就慢. 所以之前有很多朋友想加入dooring, 我都會請自和他們聊一下, 做一些基礎性的考核和篩選. 目前我們DooringX的團隊雖然人不多, 但是個有專長, 相信未來一定會把項目做的非常出色.

4.團隊協作/磨合期

團隊協作/磨合也就是我們在任務分工時, 相互之間做的一些交流, 溝通等.

我們需要讓每個共建者明確我們共同的目標, 以及各自的分工. 這個階段往往也是考核團隊的最佳時期, 我們可以發現團隊不同的成員擅長什么,可以勝任哪些工作, 哪些任務可以讓他通過項目來獲得提高和成長.

所以定期交流必不可少. 在dooring的磨合期確實也發現了一些不合適的朋友, 有些可能時間緊, 有些是價值觀問題, 這些都需要溝通解決, 解決不了就要果斷處理. 項目發起人不用過渡考慮個人感情問題, 彼此創造相對舒適的環境才是最重要的. 畢竟各自都有需要奔赴的彼岸.(有點談戀愛分手論的感覺, 就此打住🐷)

還有一點就是善用人才, 虛心聽取優秀的建議. 每個人都是團隊的貢獻者, 各司其職, 我們需要沿著我們目標的主線不斷前進, 所以需要給合適的人分配合適的任務, 讓優秀的人帶動大家一起成長. 創始人是讓項目成功的助推器,所以需要接納優秀的建議和發展方向, 從而審視自身的局限. 畢竟, 每個人都有閃閃發光的地方.