| 設計：劉穎潔

開源社引言

開源歸根結底是一種人類的文化，而全球化背景下的互聯網，將全球的任何開發者鏈接起來，使得這種文化得以跨時空獲得發展，具備全球視野的 APISIX 項目就是這樣的典型的例子，從中國某個角落的幾個胸懷夢想的編程熱血青年，積極的擁抱Apache 基金會倡導的共同體勝於代碼，開發出頂級的項目，也積極的和雲計算廠商進行合作，為持續性發展奠定基礎。作為聯合創始人溫銘的故事怎麼可以錯過？

我是溫銘，深圳支流科技的聯合創始人，開源微服務 API 網關 Apache APISIX 的 PPMC，OpenResty 軟件基金會創始人和第一任主席，360 開源委員會發起人，極客時間《OpenResty 從入門到實戰》專欄作者。

為什麼寫這篇文章？

還不是今年春節假期，在家不能外出憋壞了嘛。閒著也是閒著，不如把最近 3 年在基礎軟件領域創業的經驗和教訓總結下。

關於中國的開源項目、社區和創業，很多的分享都是講自己的成功經驗，其實背後還有更多尚未成功者的身影，他們的經驗也能提供另外一個維度的視角。

我希望能通過這篇文章，讓大家能夠更深層次的理解下面這些和開源相關的常見疑問：

• 如何運營開源社區？
• 如何選擇和評價開源項目？
• 國內外開源文化為什麼會有差異？
• 技術創業的坑有哪些？
• 開源項目在國內如何商業化？

在讀文章之前，我來花點兒篇幅介紹下自己的背景，這有利於你來更好的理解本文。

與開源結緣

我是一個服務端工程師，創業之前在互聯網安全公司工作了 10 年，主要從事服務端的開發和架構，負責過木馬雲查殺、反釣魚欺詐和企業安全產品。

我剛開始工作的時候，就有幸和當時國內 Python 社區的幾位大牛共事：Zoom Quiet、March Liu 和 Albert Lee，除了技術上的提升之外，更多的是在開源文化上的啟蒙和薰陶：選擇開源軟件而不是自己造輪子；對於郵件列表的認同；對參與開源項目的文檔和翻譯工作的尊重；對軟件版權的重視；信息的公開和透明等。簡單的說，就是樹立了一個正確的三觀，但還沒有太多具體的實踐。

後面在新項目的選型中開始接觸 OpenResty，但苦於當時找不到學習的書籍和資料，只能摸著石頭過河，磕磕絆絆的把系統搭建起來。隨著團隊中新同學的加入，OpenResty 相關知識的沉澱和昇華，成為一個迫在眉睫的問題。於是，我開始通過 GitHub 開源項目的方式，來編寫《OpenResty 最佳實踐》這本電子書。隨著貢獻者和關注者的增加，需要一個更加實時的渠道來增加溝通，於是 QQ群、微信群也開始建立起來，並通過幾年的自然沉澱，有了一個近萬人的開發者社區。

認識的網友多了，自然就有了線下見面的打算，於是每年的 OpenResty 大會、定期的 meetup 也就應運而生了。至此，一個野生的社區，被一本電子書無心插柳的灌溉而且成長起來了。

隨著社區的快速成長，很快，我就意識到軟件基金會的重要性，和大部分的技術社區一樣，我的腦海中也浮現出一樣的疑問：為什麼中國沒有類似 Apache 這樣的軟件基金會？

當時我並沒有想明白這個問題，而是轉向了另外一個更讓我興奮的挑戰：

既然沒有，為什麼不去做第一個吃螃蟹的人，來創立中國第一家合法的軟件基金會，幫助國內眾多的開源項目走向世界呢？

經過一番研究和比較後，我在 2015 年 10 月份向香港稅務局遞交了OpenResty 軟件基金會有限公司的成立申請。沒錯，軟件基金會本質上也是有限公司，只是沒有股份的概念。

令人驚喜的是，錘子科技 2015 年底發佈會的收入也想捐贈給國內的開源項目，這和 OpenResty 基金會創辦的初衷一拍即合。後面的故事大家都知道了，經過兩年多的曲折，OpenResty 軟件基金會終於獲得了接收捐款的資質，順利收到近 100 萬人民幣的捐款。

2017 年初，我從 360 離職，以合夥人身份加入到某開源創業公司工作了 2 年。

2019 年 4 月創辦了深圳支流科技，從零開始構建微服務 API 網關：

包括騰訊雲、奇虎 360、貝殼找房、美國航空航天局、歐盟 eFactory 等知名公司或機構正在使用 Apache APISIX：

上面這些從無到有的構建開源社區、開源基金會、開源委員會、開源項目、開源創業公司的經歷，讓我對開源有了更多的認識和思考。從某種意義上來講，我算得上是中國開源界縱切面上一個很好的樣本。下面的內容就是我這個樣本的一些思考了。

忘掉 star 數，活躍度才是衡量開源項目的唯一指標

我們在選擇和評價一個開源項目的時候，GitHub 上的 star 數是最直觀的一個指標，但也是嚴重失真的指標。

star 數受到很多因素的影響：項目成立時間的長短、是否有商業公司的強力 PR、是否有作弊刷量等。很多情況下，一個高 star 值的項目可能已經完成了當初的 KPI，疏於維護了。

那麼，我們應該選擇哪一個指標呢？GitHub 其實已經給出了標準的答案：pulse，也就是活躍度，這是 GitHub 內置的一個功能，每個人都有權限來查看此數據。下圖是 Apache APISIX 的一個示例（一個月的活躍度統計數據）：

從上圖中可以看到，在一個月的區間內，Apache APISIX 有 17 個貢獻者參與，合併了 58 個 Pull Request，解決了 36 個 issue，新建了 21 個 issue，可見這是一個健康、活躍的開源項目。

我找了另外一個很高 star 數的項目，同樣也是一個月的區間，沒有 Pull Request 的合併，只解決了一個 issue，基本是休眠狀態了。

如果選擇了休眠的項目，那麼在遇到問題的時候，你只有靠自己來解決，無法從社區得到有效的支持，這顯然不是我們想要的。

除了項目的活躍度，還有另外兩個維度來輔助考量：

• 貢獻者的多樣性。貢獻者大都來自同一家公司，還是分佈在多家公司？Pull Request 完全是由頭部的一兩個貢獻者完成的，還是相對均勻的分佈？
• Pull Request 和 issue 的質量。除了顯而易見的數量，質量也是非常重要的：Pull Request 主要解決的是文檔、註釋、typo 這些問題，還是核心代碼和功能點？issue 是否能夠準確的描述和重現 bug？這些體現了整個社區參與者的質量，以及社區領袖的領導力。

首選軟件基金會的項目

再來聊下另外一個大家經常問到的問題：為什麼中國的開源項目成為國際化知名項目的並不多？是工程師都被 996 壓榨的沒有時間？還是我們不夠聰明？

其實都不是，由中國工程師發起的開源項目絕對數量並不少，但其中不少都是 KPI 項目和獨裁項目，很難形成社區和上下游生態，也無法形成開源文化的傳承。

這兩類項目它們都可能很活躍，按照剛才提到的活躍度的維度，是無法篩選出來的。這時候我們需要從社區的角度來觀察：

• 是否有 committer 和 PMC 的選舉流程？
• 是否有人有凌駕於 committer 和 PMC 之外的特權？比如只有一個人可以合併 PR 和發佈版本。
• 是否有明確的商標歸屬權？

上面這幾點不僅適用於評估成熟的開源項目，也適用剛起步的開源項目。

以 Apache APISIX 為例，有 Apache 基金會完善的 committer 和 PMC 選舉機制，以及版本發佈管理機制；所有 PMC 都是平權的，沒有獨裁者的存在，話語權需要用你的貢獻來放大；代碼和商標由 Apache 基金會持有，Apache 2.0 協議對於商業化非常友好。

“社區大於代碼”，是 Apache 基金會的理念，也是被無數次證明過的正確理念。多年前我並沒有那麼認同，而經過現實的洗禮，現在我是這個理念的堅決擁護者。這也是我們堅持把 APISIX 捐贈給 Apache 基金會的原因，沒有社區，就不會成長為國際頂級的開源項目。

對於普通開發者而言，沒有必要去做這麼多的功課，直接選擇 Apache 基金會、CNCF、Linux 基金會的項目去深度參與和貢獻就好。

這個話題可以進一步延伸：中國是否需要自己的軟件基金會？我在 2019 年開源年會上做過類似的分享，我自己的答案是：先參與國外成熟的基金會，多孵化出來一些高質量的開源項目，影響出一大批三觀正的開源貢獻者，才能解決最根本的問題，建立中國自己的軟件基金會並不是一個捷徑。

技術人創業要邁過的第一關：不要自嗨

現在越來越多的工程師開始創業，技術上的優勢很明顯，但自身能否快速的成長，補上技術之外其他方面的短板，就至關重要了。這對於不少喜歡寫代碼的創業者來說，是一種跳出舒適圈的艱難挑戰。所以，很多意識到這一點的技術大牛，一般都是擔任 CTO 或者首席科學家的角色，比如 Nginx 和 Redis 的作者。

與銷售、產品背景的創業者不同，技術人創業首先要避免的就是自嗨，這可能會有很多種不同的表現：喜歡優先解決技術難題，重複造輪子，追求完美等。

要解決自嗨的問題，關鍵是思維上的轉變：

• 重視產品和商業邏輯

這是一個多大的商業機會？已有競爭對手有哪些？你的產品會帶來什麼改變？用戶會因此買單嗎？

在商業公司中，不管你的技術有多牛，都需要理順這些基本問題。很大概率上，你並不是下一個“喬布斯”，你也不會開創一個新的萬億美元的市場。重視商業邏輯，是技術創業者的第一課。

• 把公司當做產品

如何把技術的優勢，轉換為有效的銷售線索和付費訂單？每個員工各自的優勢是什麼，如何最大化？團隊的劣勢有哪些，如何去補齊？

技術型的創業公司，需要 CEO 跳出技術的視野，把公司本身當做產品來看待。

遠程工作中，充分的溝通是關鍵

開源項目天生就是分佈式協作的，這是一種鬆散的結構。以 Apache APISIX 為例，現在有 60 名貢獻者，雖然社區每個月都有一次線下的 meetup，但我見過面的也就 6、7 個人而已。

但對於開源商業公司而言，並不能簡單的使用這種遠程工作模式。在商業公司中，協作會更加的密切，而且對時效性的要求更高，當面溝通更能保證信息傳遞的完整性，這是遠程工作難以替代的。當然，遠程工作也有自己的優勢，那就是吸引全球的人才。

所以，開源商業公司採用遠程協作並沒有問題，但一定要保證溝通的足夠充分，拉平信息：

• 要視頻溝通，文字只作為最終的記錄。視頻是溝通過程中信息丟失比較少的方式，是遠程工作交流的首選方式。千萬不要用文字來討論非技術問題，這會帶來巨大的信息差和誤解。
• 保證溝通的尊重和善意。在開源項目中，大家因為沒有僱傭關係，都是無償做貢獻，所以在異步溝通時特別強調尊重和善意；而在商業公司的遠程辦公時，因為缺少同事之間的溝通、吐槽和心理按摩，就更要注意溝通的尊重。
• 定期線下見面，增加相互之間的瞭解和信任。

另外一點，長期的遠程協作，對於參與的工程師來說，除了需要很高的自律和自我管理的要求外，也要注意工作和生活的隔離，保持正常的社交活動和運動健身，否則很容易與社會脫節。

聚焦和快速發佈

開源項目和創業公司一樣，都是一直處於各種資源不足的狀態。這時候，找準主線任務，並進行快速的發佈和迭代，就顯得至關重要了。

以 Apache APISIX 為例，使用者會提出五花八門的需求和意見，如何來評估是否要做以及優先級呢？其實很簡單：

誰提出來的誰做，Apache APISIX 的 PPMC 保證會 review 你的 PR，達到要求就合併到主線。

聽起來很簡單，但其實很多開源項目是做不到及時 review 和合並 PR 的。這裡面有精力不夠的原因，但更多的是某些開源項目的核心開發者，想做另外一個層面的聚焦：保持代碼的乾淨，不合並自己用不到的功能。這種做聚焦的方法當然是錯誤的，真正的聚焦是保持底層的穩定和靈活，以便用戶可以添加更多自己的功能。

快速發佈，頻繁發佈，也是 Apache APISIX 的一個特色。Apache APISIX 從 2019 年 4 月份開始編寫代碼，到 2019 年 6 月 6 號就發佈第一個版本，如此快的速度，除了團隊本身技術硬實力之外，也是因為這第一個版本“中看不中用”，它只有一個框架，並不能直接使用。但 Apache APISIX 之後每個月的 6 號都會發佈一個新的版本，在春節前已經發布到了 1.0 版本。這種快速和頻繁的發佈，會逐漸現成社區的一種文化，帶著項目向前發展。

對於開源創業公司也是一樣，制定好長期的目標，圍繞著目標來進行開發；篩選出用戶的真實需求，樹立行業的標杆。在這個過程中，你可能需要拒絕各種合作、定製開發等外部的誘惑，在做決策的時候需要提醒自己，這個是否符合公司的長遠目標？要把有限的資源用來和時間賽跑。

最後

中國的開源社區和項目正在快速的成長，企業也接受了為基於開源的商業軟件付費的概念，同時也湧現出了越來越多的商業開源軟件公司。

和其他類似的 ToB 不同的是，開源軟件天生是沒有國界的，在中國這種大流量、複雜業務場景下起步的商業開源軟件公司，一樣可以去歐美市場做全球化的競爭。

期待看到更多的中國開源項目走向世界，也希望 Apache APISIX 和支流科技能在其中貢獻自己的一份力量。

閱讀更多 開源社 的文章

關鍵字: 奇虎360 雙11致富故事 設計