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

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

前言

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

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

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

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

商業(yè)項(xiàng)目 vs 開(kāi)源項(xiàng)目

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

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

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

圖片

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

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

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

工程化

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

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

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

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

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

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

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

自動(dòng)化測(cè)試

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

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

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

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

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

等等。

依賴管理

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

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

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

圖片

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

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

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

溝通

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

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

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

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

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

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

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

最后

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