本文討論了 商業(yè)項目 vs 開源項目 在多個方面的差異，關(guān)鍵要點包括：

• 交付品：開源項目交付品更復(fù)雜，源碼、開發(fā)過程等都需透明，對各方面要求更高。
• 工程化：開源項目人力緊缺，對工程化、自動化需求更高，需預(yù)先設(shè)計搭建適用環(huán)境。
• 自動化測試：開源項目對自動化測試要求高，需體系化設(shè)計測試系統(tǒng)。
• 依賴管理：開源項目依賴管理需更嚴(yán)格，要合理設(shè)計依賴結(jié)構(gòu)，降低復(fù)雜性。
• 溝通：開源項目多使用異步溝通工具，如 Github Issue 等，可配合工程化手段提升效率。

前言

在正式開始討論之前，需要各位讀者先思考一個問題：開源的收益是什么？具體答案在不同上下文中可能略有偏差，但大致上至少有這兩方面的收益：

1. 擴大個人或團隊影響力：讓社區(qū)更多人了解到有這么個擅長解決某一問題的個人或團隊，甚至成為這個方向的權(quán)威人物，擁有更大話語權(quán)，參考 @evan、@zack、@Langchain 等；
2. 生態(tài)共建：理想情況下，開源方式更容易引入更多優(yōu)秀工程師參與到產(chǎn)品開發(fā)中，群策群力，對需求與問題更敏感，因而迭代速度可能更快，相比人數(shù)有限的商業(yè)團隊更有可能開發(fā)出滿足諸多長尾需求的技術(shù)產(chǎn)品；

這些收益能切實解決許多現(xiàn)實問題，因而對許多從業(yè)者而言“開源”似乎已經(jīng)某種程度上成為“政治正確”的默認選項，于是經(jīng)常出現(xiàn)一些團隊或個人，在沒有做好充分調(diào)研的情況下，匆忙進入開源領(lǐng)域，“天真”(這個詞確實不太好聽)地認為只要將代碼掛載在 Github 上“開放”給社區(qū)就算是達到開源狀態(tài)了，但通常 后繼乏力，即使堅持投入時間精力許多時候也很難達到預(yù)期目標(biāo)，究其根本，我認為主因在于：許多人并沒有意識，商業(yè)開發(fā)與開源開發(fā)是兩件差異極大的事情！

說來慚愧，雖然我已經(jīng)從事前端超過 10 年，但從未正式參與過稍具影響力的開源項目，因此我個人更熟悉商業(yè)項目的運作方式 —— 相信這也是大多數(shù)讀者的真實狀態(tài)，好在工作關(guān)系日常需要深入理解各類開源產(chǎn)品的底層實現(xiàn)，多多少少也摸索出了一些門道，對商業(yè)項目與開源項目的區(qū)同點有了一些自己的看法，拋磚引玉吧。

商業(yè)項目 vs 開源項目

首先，商業(yè)項目通常只需要交付應(yīng)用的最終執(zhí)行界面即可，因此相對更著重于滿足功能、穩(wěn)定性、性能等方面的需求，具體實現(xiàn)細節(jié)從外部視角看完全是個黑盒。但開源項目的交付品要復(fù)雜的多，在功能基礎(chǔ)上，所有源碼、開發(fā)過程、工程設(shè)施甚至溝通討論過程都是對外透明的，因此開源產(chǎn)品不僅僅要對結(jié)果負責(zé)，還需要對過程負責(zé)，也因此對于優(yōu)秀的開源項目而言，代碼質(zhì)量、穩(wěn)定性、接口易用性、可擴展性、分支模型、開發(fā)規(guī)范、版本管理、工程化設(shè)施等等維度，都是產(chǎn)品的一部分，都需要仔細斟酌維護的。

舉一個非常細節(jié)的例子：分支模型，分支應(yīng)該如何命名？那些分支可以往那些分支合并？特性分支何時合入主干分支？那些分支必須確保穩(wěn)定，又如何確保穩(wěn)定？進一步的，那些分支可以發(fā)布正式版本？什么時候應(yīng)該打什么 Tag？是否需要保持 Linear-history ？等等。

并且分支模型規(guī)范還必須足夠簡單，讓各類背景的開發(fā)者能迅速參與到項目；最好還可以補充一些自動化工具，確保參與者不犯低級錯誤。國內(nèi)許多商業(yè)團隊可能已經(jīng)習(xí)慣于火車模型 —— 本質(zhì)上是 FBD 的變種，但這種方式太過復(fù)雜，理解、操作成本過高，多數(shù)情況下并不適配開源環(huán)境，因此多數(shù)時候會轉(zhuǎn)而采用 TBD，但 TBD 模型對穩(wěn)定性要求極高，進而又催生非常復(fù)雜而重要的自動化測試需求。

圖片

再比如說，版本管理，我們都知道 semver 模型(參考：NPM 依賴管理的復(fù)雜性)，但什么時候應(yīng)該發(fā) patch，什么時候應(yīng)該發(fā) minor 呢？判斷標(biāo)準(zhǔn)是什么？誰來做這個判斷？什么時候能從 0.x 切換到 1.0 呢？是否需要保持向后兼容？又有哪些特性、接口需要保持向后兼容？總之，當(dāng)你預(yù)期開發(fā)一個優(yōu)秀的開源項目時，你必須仔細思考這些平時并不需要關(guān)注的問題，否則在未來總會引發(fā)一些技術(shù)、PR 風(fēng)險。

當(dāng)然，這并不是說開源就必然比商業(yè)項目更難更復(fù)雜，相反，許多優(yōu)秀開源項目通常只聚焦于解決某個具體問題，并在架構(gòu)上留出足夠靈活的邏輯插槽，交由社區(qū)按需擴展實現(xiàn)各類長尾需求，例如 Webpack、ESLint、 RSPack、Vite 等等，因此開源項目通常有比較高的技術(shù)復(fù)雜度，但功能通常是非常收斂的。反觀商業(yè)產(chǎn)品的功能復(fù)雜度幾乎沒有上限，例如淘寶、抖音、火山引擎等，當(dāng)功能足夠復(fù)雜時，也必然會反推整體架構(gòu)、技術(shù)復(fù)雜度的非線性增長，雖然可能內(nèi)在的許多技術(shù)細節(jié)并不是最優(yōu)，也不具備可遷移復(fù)用性，但也不能否認這里面存在深層次的技術(shù)難度。因此，我認為兩者并沒有絕對優(yōu)劣之分，歸根結(jié)底只是在解決不同場景下的不同問題罷了，并沒有明顯的優(yōu)劣之分。

我認為更重要的，在進入開源之前一定要理解這件事情的成本與收益，理解各類工程處理細節(jié)的差異，評估 ROI 是否能打正，團隊是否有足夠能力與技術(shù)品味等等，切忌為了開源而開源。

工程化

開源項目通常有一個非常突出的特點：人力緊缺，畢竟能全心全意為愛發(fā)電的人并不多，多數(shù)時候，參與者是在本職工作(解決生存問題)之外，花費個人寶貴的休息時間參與開源(解決情懷問題)，因而能投入的有效時間非常有限。但同時，優(yōu)秀的開源項目通常有比較高的準(zhǔn)入門檻，且不說深入理解項目的實現(xiàn)原理、架構(gòu)設(shè)計，之后提交符合整體設(shè)計、代碼風(fēng)格的 PR，光是理解如何初始化環(huán)境并運行項目、如何提交有意義的 PR、如何按照提交高質(zhì)量 ISSUE，可能已經(jīng)需要耗費比較多的學(xué)習(xí)時間。

而站在項目管理者視角，當(dāng)參與開發(fā)的人數(shù)到達一定數(shù)量時，成員良莠不齊必然會衍生一系列過程質(zhì)量問題，例如提交一堆連單測都跑不通的 PR，又如未按各類規(guī)范準(zhǔn)則編寫代碼，再如提交的代碼存在明顯性能問題等等。原則上，問題越早發(fā)現(xiàn)修復(fù)成本越低，因此要求倉庫管理者們投入比較多的時間精力前置做好質(zhì)量把控，攔住這部分低質(zhì)量開發(fā)行為。

這兩類案例，究其根本都是時間、空間復(fù)雜度問題。在商業(yè)項目中，可以通過配置分工合理的團隊結(jié)構(gòu)，完善開發(fā)流程及規(guī)范，在有限空間復(fù)雜度內(nèi)通過增加人力與行為約束的方式緩解團隊協(xié)作引發(fā)的熵增。

但開源項目不可能采用這種方案，因為參與項目的群體可能比較龐大且地理位置分布廣泛，技術(shù)水平參差不齊，文化背景多種多樣，很難照搬商業(yè)公司的管理模式，將每一位成員按在特定的職責(zé)范圍上 —— 多數(shù)情況，反而是由個體按照其擅長的領(lǐng)域自發(fā)地解決某些特定問題(實際上這也正是開源的魅力所在)，但這種個體視角的解決方案在倉庫上下文環(huán)境中不一定是最優(yōu)的；其次，在開源環(huán)境中通常也很難通過規(guī)范文檔方式約束個體的開發(fā)行為，即使編撰了一堆完美的開發(fā)說明書，一是很少有人有耐心完整看完，并認可；二是文檔約束力非常薄弱，需要配置相應(yīng)監(jiān)督者持續(xù)關(guān)注研發(fā)細節(jié)，而這很不敏捷。

這些問題最終會導(dǎo)向一個相對可行的解決方案：工程化。注意，工程化并不僅僅是一堆工具的簡單堆疊，而是一個復(fù)雜、綜合的工程學(xué)問題，通常，開源環(huán)境對工程化、自動化的需求要遠高于商業(yè)項目，不僅需要配置好常見的 Bundle、Lint、UT、E2E 等基礎(chǔ)設(shè)施，還需要根據(jù)具體場景進一步搭建各類自動化工作流。

在發(fā)起開源項目時，非常值得投入一部分精力預(yù)先設(shè)計、搭建好適用的工程化環(huán)境，因為這些自動化流程能夠長期以極低的成本防止項目質(zhì)量劣化 —— 至少能規(guī)避許多來自四海八方的低級問題，減少管理者審核負擔(dān)；能在出錯時及時給出適當(dāng)反饋，降低項目的準(zhǔn)入門檻；也能規(guī)范化各類關(guān)鍵流程，避免人的隨機性帶來的隨機謬誤。

當(dāng)然，工程化也并不是銀彈，有許多邊界問題無法或很難被自動化解決，例如項目架構(gòu)設(shè)計是否足夠優(yōu)秀，或者用戶文檔是否足夠完備清晰，又或者整體項目規(guī)劃等，這類問題依然強依賴于人力介入。

自動化測試

這是需要著重強調(diào)的點：開源項目對自動化測試的要求比常規(guī)商業(yè)項目高出許多！商業(yè)團隊通常會設(shè)置專職測試者定期檢查產(chǎn)品的質(zhì)量情況，對最終質(zhì)量負責(zé) —— 或者至少起兜底作用吧。但如上所述，開源項目很難出現(xiàn)這類專職角色，因而開發(fā)者自身直接對產(chǎn)品質(zhì)量負責(zé)，需要親自完成各類測試動作，但為愛發(fā)電的開發(fā)者們很難投入時間反復(fù)做各類測試，也很難做的很細致。

因此，在開源項目中很自然地采用了另一種更敏捷，對人力需求更低的方案 —— 自動化測試，由代碼負責(zé)測試代碼的穩(wěn)定性。具體的測試技術(shù)有很多類型，單元測試、E2E 測試、性能測試、接口測試等等，視乎具體情況，許多優(yōu)質(zhì)開源項目會采用其中一種或多種自動測試方案，為功能代碼編寫若干測試用例，之后在合碼前、發(fā)布前等關(guān)鍵節(jié)點設(shè)置卡口，執(zhí)行測試代碼，當(dāng)所有用例都能運行通過，且測試覆蓋率達標(biāo)后才能繼續(xù)推進流程。

某種程度上，測試用例就是項目成員之間的一種非文檔性質(zhì)的強約束契約，任何人嘗試修改代碼時都必須遵循這份契約，必須保證存量用例都能運行通過 —— 或者，必要時更新這些契約以適應(yīng)功能代碼的迭代。雖然開發(fā)和維護用例代碼本身也是一件比較消耗時間的工作，但這份契約定義的越是詳細，覆蓋面越廣，越是不容易犯錯，即使是完全不了解項目上下文的新人，也能夠在缺乏第三者協(xié)助的情況下，單純依靠測試框架及其它質(zhì)檢工具，就可以寫出符合要求的代碼，而這很契合開源項目的人力分布特點。

理論上測試用例越是完整，項目整體質(zhì)量越是穩(wěn)定，但自動化測試也是有技術(shù)門檻與人力成本的，要達到上述的理想狀態(tài)并不是容易，需要體系化設(shè)計測試系統(tǒng)，常見的手段包括：

1. 借助單元測試（UT）技術(shù)實現(xiàn)白盒測試，覆蓋代碼模塊內(nèi)部的各邏輯分支。需要注意的是，單純追求覆蓋率其實意義不大，而應(yīng)該進一步思考并推導(dǎo)出各類邏輯上的邊界場景(雖然這很難) —— 特別是異步、并發(fā)等復(fù)雜時序場景。舉個例子，在測試一個按鈕組件時，不僅要驗證它的基本功能，還要設(shè)計用例來測試連續(xù)點擊是否會導(dǎo)致事件的連續(xù)觸發(fā)；
2. 借助 E2E 技術(shù)，對產(chǎn)品界面做黑盒測試，從最終用戶視角與產(chǎn)品交互，驗證過程與結(jié)果的正確性。相比于單測，這種測試方案更關(guān)注代碼模塊集成后的運行效果，更接近用戶體驗，適合作為 UT 的一種補充；
3. 其次，必要時還可以使用 Benchmark 等工具對產(chǎn)品的核心算法，或執(zhí)行頻率較高的代碼片段補充性能測試，保證性能下限。

等等。

依賴管理

依賴管理是一個較為復(fù)雜的工程問題(詳見：《NPM 依賴管理的復(fù)雜性》)，若處理不當(dāng)，容易引發(fā)性能、穩(wěn)定性等質(zhì)量問題，因此理論上，無論是商業(yè)項目還是開源項目，通常都需要設(shè)計一些精細的管理方法，控制三方依賴的使用情況，避免濫用。而對于 NPM Package 形態(tài)的產(chǎn)品而言，這類管控措施需要更加嚴(yán)格一些 —— 許多開源項目最終提供的使用方式也正恰恰是 NPM Package 形態(tài)。

在使用 npm/pnpm/yarn 等包管理器安裝 Package 時，工具會向下遞歸分析并安裝依賴下游的所有子孫依賴，因此對用戶而言，每增加一個 Package 就需要導(dǎo)入該依賴對應(yīng)的依賴關(guān)系圖，最終依賴結(jié)構(gòu)越復(fù)雜越是容易出問題，包括：

• 容易出現(xiàn)依賴安裝的性能問題；
• 底層依賴的問題會向上擴散，影響上層應(yīng)用穩(wěn)定性；
• 依賴關(guān)系圖不穩(wěn)定，實際安裝版本容易出現(xiàn)大范圍變動，最終影響項目穩(wěn)定性；
• 容易出現(xiàn)重復(fù)依賴，例如 NPM Package 聲明了 lodash@1.2.0 依賴，而用戶的 package.json 中也聲明了 lodash@1.3.0 依賴，那么最終會在用戶項目就需要安裝兩個 lodash 版本；

圖片

毫不夸張的說，NPM Package 的子依賴數(shù)量越多，性能與穩(wěn)定性越差，用戶的使用成本就越高，進而會給人一種強烈的“難用”的感覺。因此在這類場景中務(wù)必保持一定的克制，合理設(shè)計依賴結(jié)構(gòu)，盡可能降低依賴圖的復(fù)雜性，為此可以視情況有意識地采用一些緩解手段，例如：

• 可以將一些相對簡單的代碼片段(例如：escape-string-regexp)直接復(fù)制進倉庫中，不必為此額外增加子依賴項。雖然在軟件工程中，“復(fù)制”通常為人所不屑，但適當(dāng)?shù)娜哂啻_實能非常有效降低方案復(fù)雜性；
• 也可以將一些簡單依賴與項目代碼整體打包成一個 Bundle 文件，同時將子依賴聲明為 devDependencies 類型，避免在用戶側(cè)重復(fù)安裝。這種方式本質(zhì)上就是子依賴以快照方式與項目代碼捆綁發(fā)布，雖然也存在一定冗余，但不會受到子依賴版本變化的影響，穩(wěn)定性與性能相對更好一些；
• 對于復(fù)雜依賴，也可以考慮將其設(shè)置為 peerDependencies，由用戶自行管理三方依賴版本，雖然這可能會引發(fā)其它復(fù)雜問題，但能有效避免沖突。

歸根結(jié)底，依賴管理容易被忽視但又比較復(fù)雜，處理不當(dāng)會直接影響用戶口碑，推薦讀者擴展閱讀《NPM 依賴管理的復(fù)雜性》一文，更深入了解前因后果，以及關(guān)于依賴管理的各類最佳實踐。

溝通

商業(yè)開發(fā)團隊通常會采用一些 IM 軟件(飛書、企業(yè)微信、Bear Chat 等)作為主要溝通手段。但在開源項目中很少見到使用 IM 的情況，多數(shù)時候更偏向于使用 Github Issue、Disco、Reditt 等工具溝通各類項目細節(jié)，如 Bug 反饋、RFC、用法咨詢等。

雖然這類論壇形態(tài)的工具遠不如 IM 即時溝通帶來的高效率與便利性，但確實存在許多特質(zhì)使之成為開源項目的首選，包括：

1. 這類工具以 Timeline 形態(tài)組織信息流，圍繞特定話題展開討論，使得溝通主題非常聚焦，不容易發(fā)散走偏，信噪比會高出許多；
2. 足夠開放，甚至幾近透明，任何人都可以極低的門檻進入這類信息環(huán)境；同時，非常有利于搜索引擎檢索；
3. 歷史記錄更容易追溯，方便新人了解歷史上下文，使得這類 Issue 本身自然形成項目文檔的一部分；
4. 開源項目成員來自世界各地，時區(qū)對不上，實時溝通意義不大，天然更適合使用異步溝通工具。

因此，推薦在開源環(huán)境中優(yōu)先使用 Github Issue、Disco 等工具作為主流溝通手段，雖然這會部分喪失 IM 實時性帶來的溝通效率。

不過，可能很多同學(xué)沒有定期看郵箱或 Github Notice 的習(xí)慣，接觸開源項目的前期可能比較難適應(yīng)這一點，所幸這類工具都提供了非常便利的開放接口體系，可借此設(shè)計實現(xiàn)一些自動化工具提升信息流轉(zhuǎn)效率，例如在 Github Issue 中可以使用 Github Actions 實現(xiàn)：

1. 監(jiān)聽 Issue 變化，回調(diào) IM 接口(例如飛書：feishu-bot-webhook-action)將動態(tài)轉(zhuǎn)發(fā)到對應(yīng)群組，提升實時性；
2. 定期匯總活躍 Issue、PR 等，整理成報表發(fā)送到 IM 軟件，避免信息阻塞；
3. 定期關(guān)閉不活躍 Issue，避免信息泛濫；
4. 配合 LLM，在創(chuàng)建 Issue 后由 AI 分析內(nèi)容，自動給出初步反饋；
5. 等等，不一而足。

總之，開源環(huán)境不推薦使用 IM 作為主要溝通手段，建議切換為 Github Issue 等異步溝通工具，之后配合各類工程化手段提升信息流轉(zhuǎn)效率即可。

最后

文章內(nèi)容比較散，雖然聊了很多，但實際上開源與商業(yè)的差異遠不止如此，這里只是蜻蜓點水，求個拋磚引玉吧。但最核心的，我認為商業(yè)團隊在進軍開源領(lǐng)域之前，務(wù)必先停下來，想清楚預(yù)期與成本，以及兩者之間文化差異所帶來的解決問題的方式方法上的變化。