對企業而言，發佈和維護開源項目都是需要耗費大量心力的。在爲React工作四年後我對此深有體會。我最開始只是一名外部貢獻者，加入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社區也會讓項目受到影響：這裏說的不重視可以小到問題管理，大到項目的未來方向。
誠然，項目的成功會帶來高昂的維護成本，失敗的可能性也不容小覷，但處理得當的開源項目也會帶來巨大的價值。
開始之前
文檔以及代碼質量
有些開源帶來的好處甚至在項目宣發之前就已經體現出來了。準備將某項目開源會迫使人們清理代碼、劃出清晰的API邊界、讓項目在現有環境和公司之外實際可用，這樣維護起來會更方便，日後如果需要重構也會容易很多。開源同樣是個讓人認真寫軟件運行文檔的好時機，哪怕這個項目只是在公司內部使用，好的文檔對新入職的員工而言也是個很好的資源。隨着使用項目的人增加，外部的人也會開始幫忙寫入門指南。到後來，只要是軟件使用相關，只有你想不到，沒有你找不到的問題和其解決方式，就像React的社區做到的一樣。
擴展之後
大多數開源軟件的好處會隨着項目的受歡迎程度擴大而增長。成功的開源項目往往擁有多功能的基礎架構，和可以重複利用的核心構件。項目越是不針對具體業務，他人越會覺得這個項目有用，項目作者也就越不用擔心會泄露公司機密。
工程品牌
無論是名不見經傳的小公司還是五百強科技公司，開源項目都可以提升工程部門的品牌聲譽。2013年Facebook發佈React時，很多人對此都不屑一顧，“Facebook的工程建議？他們連自己在幹什麼都不知道！”。現在，隨着React和其他開源項目的出現，Facebook作爲前端工程領域的領軍者已經得到了廣泛的認可。這在招聘方面是一大助力：在我任職期間，面試過的許多工程師應試者都說過，他們想要加入Facebook，是因爲這裏是React的發源地。無論公司規模大小，發佈高質量項目不僅可以炫技，還能吸引到新人加入。
提升可靠性
他人在使用你的軟件時會遇到bug，遇到你沒見過的邊緣情況。多數情況下，這些bug被發現都是遲早的事，而隨着使用人數的增多，你也就有更多的機會發現並修復這些bug（免費的質量保證！）。即便Facebook擁有上千名使用React Alpha版的開發人員，並在每個新版本公開前發現了大多數的bug，外部bug報告裏仍然不斷有新的問題彙報進來。
投資於員工
發佈開源軟件的最大內部擁躉之一，通常都是希望能回饋廣大編程社區的員工個人。他們藉此得到了在日常工作中做公益的機會，也得以圍繞工作打出個人的招牌。開源項目也可以讓他們的工作更爲充實，如果一個項目的受益人不僅是公司，那麼人們就更容易發自內心地關注它。
另外，項目得到推廣後，關於它的知識也會變得更有價值。公司內使用開源項目的員工會收穫可轉移的技能，而不是針對專有系統的小衆技巧。擁有開源項目使用經歷的員工在轉職後上崗會更快。和行業大衆割裂的專有基礎架構只會變成負擔，而開源則可以幫你避免這種情況。其他項目的同行們會在軟件兼容性上向你看齊，日後使用這些軟件時，集成工作也會大大減少。
技術上的自知之明
最後，開源中最重要的好處之一：將你的基礎架構作爲獨立項目發佈，有助於你瞭解自己技術棧的真實水平。如果你的公司是以專有技術爲基礎，那麼對自己程序的盲目自信更像是一種冒險，直接用另一款現有的替代品可能效果會更好。讓項目在公司之外憑藉其自身優點進行競爭，會幫助你看到更現實的情況（亞馬遜大概是這種策略在大規模背景下應用的最著名的例子）。如果基礎架構的某部分能夠憑藉自身獲得成功，那這就說明你前進的道路是正確的。
值得嗎？
如果你所在公司搭建的某款軟件對業務有較強的針對性，那麼將其開源的可能性就不會太高。事實上，如果潛在用戶看不到它的價值，那麼這款軟件基本就是無用的。但如果開發的工具泛用性較高，即便它並不完美，開源也可以被列爲認真考量的事項。明確的維護承諾也很重要，如果你能夠保證長期維護，用戶會感激不盡的。反之，如果只是一次性的代碼發佈，雖然也會有幫助，但要記得提前告訴大家！
有了開放源碼，你就能得到你所投入的東西。它可以幫助推動行業發展，使你的公司受益，並激勵當前和未來的員工——雖然這需要時間和努力。如果條件合適，它是值得的。
開放源碼會讓你的付出有所回報，會幫助推動行業發展，使你的公司受益，激勵當前和未來的員工——儘管這些都需要付出時間和精力，但如果條件合適，你會發現這些付出都是值得的。