[[332871]]

 對企業而言，發布和維護開源項目都是需要耗費大量心力的。在為 React（一款由 Facebook 開發的知名開源 JS 庫）工作四年后我對此深有體會。我最開始只是一名外部貢獻者，加入 React 團隊后，又從工程師做起，最終升為團隊管理。和大多數的 Facebook 開源項目一樣，React 起初只是為內部使用而開發的，見識到它在簡化 UI 代碼的開發和維護上的作用后，我們決定將它與全世界分享。

事實證明，React 是 Facebook 的一次令人難以置信的成功，而這成功背后也隱藏了巨大的挑戰。舉例來說，盡管 React 非常受歡迎，但它仍處于一個競爭激烈的領域，這使得我們在開發新版本時需要小心再小心。

我們盡量不去做重大改動，原因很明顯，人們沒有時間或者不愿去適應一個變更太快的產品，甚至可能會一氣之下改用其他競品。但反過來想，如果我們固步自封，那么 React 將會落后于其他更新潮，更有創新性的產品。React 會像它的前輩們一樣，被后浪拍死在沙灘上。

龐大的用戶群體也讓我們在做出任何決定時都會收到反對的聲音。在你規模還很小的時候，你可以取悅任何人，一旦你規模做大，滿足所有人就變成了不可能 的任務。這一現象并不僅局限于 OSS（開源軟件）。這就意味著，在準備更新版本時，我們同樣需要仔細考慮我們的溝通策略。在 2018 年 10 月的 React 大會上公布 React Hooks 之前，我們特意避免公開發表任何 React Hooks 的消息。這是因為我們擔心在只有部分設計的情況下，可能會讓用戶錯誤理解我們的設計。于是我們在直到項目完善后才將它公布于世。一個項目越是受歡迎，就越難在不刺激到用戶的情況下實驗新想法。

當 React 還是個剛出生的小嬰兒時，大多數的用戶都是出于個人喜好選擇了它。而在它幾乎算是行業標準的現在，很多人用 React 是因為沒得選，可能是因為團隊中有人在用，也可能是授課教授選擇了它，而這類用戶往往都并不了解 React 的獨特優勢。因此，更多的新用戶都會帶著挑剔的眼光看待 React，期待著新的補丁出現。React 的用戶群之大，相關文章之多，讓新用戶（有時甚至會有老用戶）在找幫助時都摸不清楚哪些資源才是可信的。當然，所有資料的貢獻者都是好心的，但這并不能保證這些資源都是高質量的。

很多公司都指望通過發布一個任何人都可貢獻代碼的開源軟件來吃紅利，但就據我所知，這種做法實際幾乎從未成功過。回應問題，回答使用問題，仔細規劃新版本發布的時間線，這些都要花時間來做。哪怕是代碼貢獻，這個被譽為能讓企業開源的決策收獲可觀回報的大獎，也總是盛名難副。新的貢獻者既不像核心團隊一樣對現有代碼了如指掌，也不像他們那樣對項目的遠大愿景有著清晰的認知。外部貢獻者的代碼總要經過修改才能使用，即使是一些較為優秀的拉取請求也是要過幾輪審查的，對審查者而言，你永遠無法確定貢獻者會不會更新，以及何時才會更新。這種情況下，通常還是自己寫程序比較快。

此外，絕大多數的拉取請求都只是順手做的貢獻。某人在做某項目時，發現了他們正在使用的某開源工具的一個 bug 或者限制，于是他們提交一個小補丁，覆蓋了他們所遇到的獨特情況。通常這類的貢獻者是不會做回頭客的，而肯回來幫忙的都是好人。在幫忙的過程中，他們會逐漸了解你，了解你項目版本間的微妙差異，他們對項目的可靠性和長期的成功有了個人的投入。在 React 中，我們對新的貢獻者總是很友善，希望他們或許會回來繼續幫忙。但無論我們對他們有多么歡迎，鮮少有人會有精力或意愿繼續貢獻代碼，這可以理解，每個人都有他們各自的生活，而有意義的貢獻是需要花費時間的。

以上提及的困難點都是成功項目才會遇到的，但開源項目難免會失敗。原因有很多，可能是這個項目解決的問題太過小眾、不常見，或者是它針對的問題已經有了個更好的解決方案。開源項目的創建者也許無法證明自己項目的實用價值，或者是沒有提供足夠的文檔，尤其是沒有對新用戶的指引。項目可能需要復雜的設置或者前置基礎架構環境，也可能是用某種小眾的編程語言寫的，或者是由于其他技術原因導致了不兼容問題。即使某個項目一開始看起來前途無量，但如果 bug 不斷或者面對一些常見問題沒有好的答案，人們也會無情地拋棄它。同樣，隨著時間的推移，項目負責方做出了一些重大的負面改動，或者其他有害項目的決策，人們也會對這個項目失去信任。忽略 OSS 社區也會讓項目受到影響：這里說的不重視可以小到問題管理，大到項目的未來方向。

誠然，項目的成功會帶來高昂的維護成本，失敗的可能性也不容小覷，但處理得當的開源項目也會帶來巨大的價值。

1. 開始之前

文檔以及代碼質量

有些開源帶來的好處甚至在項目宣發之前就已經體現出來了。準備將某項目開源會迫使人們清理代碼、劃出清晰的 API 邊界、讓項目在現有環境和公司之外實際可用，這樣維護起來會更方便，日后如果需要重構也會容易很多。開源同樣是個讓人認真寫軟件運行文檔的好時機，哪怕這個項目只是在公司內部使用，好的文檔對新入職的員工而言也是個很好的資源。隨著使用項目的人增加，外部的人 也會開始幫忙寫入門指南。到后來，只要是軟件使用相關，只有你想不到，沒有你找不到的問題和其解決方式，就像 React 的社區做到的一樣。

2. 擴展之后

大多數開源軟件的好處會隨著項目的受歡迎程度擴大而增長。成功的開源項目往往擁有多功能的基礎架構，和可以重復利用的核心構件。項目越是不針對具體業務，他人越會覺得這個項目有用，項目作者也就越不用擔心會泄露公司機密。

工程品牌

無論是名不見經傳的小公司還是五百強科技公司，開源項目都可以提升工程部門的品牌聲譽。2013 年 Facebook 發布 React 時，很多人對此都不屑一顧，“Facebook 的工程建議？他們連自己在干什么都不知道！”。現在，隨著 React 和其他開源項目的出現，Facebook 作為前端工程領域的領軍者已經得到了廣泛的認可。這在招聘方面是一大助力：在我任職期間，面試過的許多工程師應試者都說過，他們想要加入 Facebook，是因為這里是 React 的發源地。無論公司規模大小，發布高質量項目不僅可以炫技，還能吸引到新人加入。

提升可靠性

他人在使用你的軟件時會遇到 bug，遇到你沒見過的邊緣情況。多數情況下，這些 bug 被發現都是遲早的事，而隨著使用人數的增多，你也就有更多的機會發現并修復這些 bug（免費的質量保證！）。即便 Facebook 擁有上千名使用 React Alpha 版的開發人員，并在每個新版本公開前發現了大多數的 bug，外部 bug 報告里仍然不斷有新的問題匯報進來。

投資于員工

發布開源軟件的最大內部擁躉之一，通常都是希望能回饋廣大編程社區的員工個人。他們借此得到了在日常工作中做公益的機會，也得以圍繞工作打出個人的招牌。開源項目也可以讓他們的工作更為充實，如果一個項目的受益人不僅是公司，那么人們就更容易發自內心地關注它。

另外，項目得到推廣后，關于它的知識也會變得更有價值。公司內使用開源項目的員工會收獲可轉移的技能，而不是針對專有系統的小眾技巧。擁有開源項目使用經歷的員工在轉職后上崗會更快。和行業大眾割裂的專有基礎架構只會變成負擔，而開源則可以幫你避免這種情況。其他項目的同行們會在軟件兼容性上向你看齊，日后使用這些軟件時，集成工作也會大大減少。

技術上的自知之明

最后，開源中最重要的好處之一：將你的基礎架構作為獨立項目發布，有助于你了解自己技術棧的真實水平。如果你的公司是以專有技術為基礎，那么對自己程序的盲目自信更像是一種冒險，直接用另一款現有的替代品可能效果會更好。讓項目在公司之外憑借其自身優點進行競爭，會幫助你看到更現實的情況（亞馬遜 大概是這種策略在大規模背景下應用的最著名的例子）。如果基礎架構的某部分能夠憑借自身獲得成功，那這就說明你前進的道路是正確的。

3. 值得嗎？

如果你所在公司搭建的某款軟件對業務有較強的針對性，那么將其開源的可能性就不會太高。事實上，如果潛在用戶看不到它的價值，那么這款軟件基本就是無用的。但如果開發的工具泛用性較高，即便它并不完美，開源也可以被列為認真考量的事項。明確的維護承諾也很重要，如果你能夠保證長期維護，用戶會感激不盡的。反之，如果只是一次性的代碼發布，雖然也會有幫助，但要記得提前告訴大家！

有了開放源碼，你就能得到你所投入的東西。它可以幫助推動行業發展，使你的公司受益，并激勵當前和未來的員工——雖然這需要時間和努力。如果條件合適，它是值得的。

開放源碼會讓你的付出有所回報，會幫助推動行業發展，使你的公司受益，激勵當前和未來的員工——盡管這些都需要付出時間和精力，但如果條件合適，你會發現這些付出都是值得的。