你所掌握的開源，也許都是錯的！

「開源很像是公開演講，許多人不認為他們的東西有價值，這種想法完全錯了——每個人都有人類知識的一小部分，但沒有任何人有能力掌握所有知識。所以，必然有一些人需要你的東西。」開源的原始意義，簡而言之，不過如是。

如果你曾了解過 Slick Carousel、Webpack Dashboard、Spectacle、Cash 等開源庫，應該就對 Formidable 開源總監 Ken Wheeler 不陌生，他在本文中分享了自己在開源方面的經驗。

以下為譯文：

作者 | Ken Wheeler

譯者 | 彎月

責編 | 仲培藝

出品 | CSDN（ID：CSDNNews）

在正式介紹這些經驗之前，我想先說明一下為什麼要開源，以及在這一點上我的一點個人體會。

為什麼應該寫開源代碼

我有不計其數的理由可以說明開源對你個人和你的職業生涯都大有裨益：

• 開源對你的個人品牌非常有利。如果你有非常受歡迎的項目，那麼人們就會熟悉你和你的作品。
• 開源對你的公司品牌非常有利。提供並維護一些開源項目可以增加公司品牌的知名度。讓員工花一些時間在開源上並讓他們分享他們的點子，能讓你的公司成為最好的工作場所。
• 作為開發人員你可以得到成長！你個人項目的腳本不必在 /Users/Me/devshit 等目錄下蒙塵長蜘蛛網。別人會關注你的項目，所以你有動力去不斷改進它們。
• 你能夠回饋社區。就像 John-David Dalton 寫的 lodash 為你的項目節省了不少時間一樣，你也可以通過自己的代碼為他人提升效率。你可以成為社區的一部分，大家通力合作並分享，一起節省時間。
• 滿滿的成就感。雖然只是個人看法，但是每當別人感謝你的項目，或者告訴你你的項目節省了他的很多時間時，那種感覺非常美妙。
• 開源也許不會為你帶來一份工作，因為絕大多數公司並不會根據 GitHub 上的 Star 數招聘，但開源肯定會對你的面試有積極影響。

我的開源經驗

我可能是有史以來最差勁的開源維護者了——好吧，也許不是最差的，但每次我做得都不夠好。

有好幾次我都沒能很好地管理開源項目，我常常希望自己沒有搞過這麼多項目。

但是我能從每個項目的失敗中學到很多東西，從而促使自己以後做得更好。這一點我稍後再說。當然在這方面我已經越做越好了，不過我還是希望讀者能從我的失敗中得到教訓，避免走彎路。

下面我簡單介紹一下我的經驗，因為與正常的開源經驗相比，我的經驗相對「非主流」一些——我的整個職業生涯中給別人的項目做的貢獻大概不超過 20 次，我只不過是寫了一些代碼然後推送了上去。所以我覺得應該介紹一下每個項目的背景。

我的第一個開源項目大概是我最成功的項目。當時我在某個軟體公司工作，為紐約的一個大型時尚品牌做一個電商網站，作為團隊中的高級開發，我需要做不少難度很高的 JS 開發。想念那段使用 jQuery 的日子……

時尚品牌的電商到處都是跑馬燈式的圖片，他們還喜歡使用各種複雜又宏大的設計。我發現，現有的跑馬燈或幻燈片的庫都不夠靈活，無法支持他們給我的設計，所以我只好從頭開始用 CoffeeScript 編寫自己的「跑馬燈」。最後終於實現了，但是顯然同事們並沒有因此給我好評。

但是我看到了明確的需求。人們需要一個跑馬燈插件，它要足夠靈活，能支持任何設計，又易於使用、便於修改。所以我就自己寫了個插件。後來我覺得既然這個插件很有用，為什麼不貢獻出來節省所有人的時間呢？於是我就把它開源了……

結果發現，我的確節省了很多人的很多時間，人們都很喜歡它。發布後的最初幾個月里，該插件的受歡迎度一飛衝天。當時我剛剛接觸開源，看到有人使用我的代碼，自是激動萬分，經常通宵修改 bug、發布新版本，想盡辦法確保沒人能和我的代碼競爭。

簡而言之（畢竟這篇文章是忠告，不是我的個人簡史），最後的結果就是我不再關心那個項目。原因有幾個：首先，我換了份工作，所以不再需要跑馬燈，不再需要解決這類問題了。另一個原因是 React 出現後，我第一時間開始使用，所以對 jQuery 也興趣不再。

但最大的原因是我身心俱疲——我在那個項目上花費了太多精力，我仔細閱讀每一篇評論，人們似乎都很有主見，他們指責我不應該那樣使用跑馬燈（甚至我正常工作中的項目都未能倖免，而我只不過是依照別人的設計幹活），我還因此發福，連我老婆都因此很有意見。

在那以後，我在多個不同領域做了幾個流行的庫，每個都是為了解決不同的問題。我最害怕的一點是我無法再寫出任何流行的庫，我的輝煌時刻已然成為過去。時至今日我都很抗拒這件事，一直以來我都在做傻事，但我一直對我在那個跑馬燈項目上的管理不善而耿耿於懷。

所以，下面是我對於開源的一些忠告，希望你能利用好並建立成功的項目，不要在開源上做傻事。

萬事開頭難

開源很像是公開演講，許多人不認為他們的東西有價值。這種想法完全錯了。「冒名頂替症候群」這個詞說得太對了。每個人都有人類知識的一小部分，但沒有任何人有能力掌握所有知識。所以，必然有一些人需要你的東西。

我的優點有二，一是臉皮厚，二是迷之自信，所以我敢發布代碼，但我發現很多人覺得這一步很難。

對此，我的建議是：

放手去做！別讓夢想變成夢。

最壞還能怎樣？別人會議論？坦白說，就算是你寫出 GitHub 上最完美、最有用、最驚艷的代碼，那又怎樣？一些傻x還是會罵你。這是不可避免的。最壞也不過是你學到了新東西。如果他們說，「這玩意兒太慢了。」那麼你該怎麼辦？是說「我寫不了代碼，我放棄」，還是說「謝謝你的意見，我改好了，現在性能好多了」？顯然你應該選擇後者。

那麼，你該構建什麼呢？這個問題價值一百萬！

我這麼看：

• 你遇到了一個問題
• 你想到了該問題的解決方案
• 你把這個解決方案打包得很好，別人也想用你的方案解決他們的問題

所以，我們來說說怎麼才能打包好……

API 設計

好了，現在你有了想法——你遇到了一個問題，並解決了這個問題——但你想讓別人也用你的方案，對吧？要想實現這一點，我這裡有幾條建議。

首先，也是最重要的一點，去找找競爭者和現有的方案。如果別人的庫和你的功能一樣，那麼你就需要做一些有區分度的東西。比如，假設你想做另一個 lodash。首先祝你好運，但除此之外，如果你想從 lodash 那裡分一杯羹，那麼就得有自己的特長。你得更小，或者更快，或者提供更好的 API。看到問題所在了吧？

說起 API 設計，必須要考慮平衡性。你可以寫一個不用任何配置拿來就能用的庫，但別人就會抱怨他們想自己定製。你也可以寫出非常靈活的可以配置的庫，但那樣你就會像 Tobias Koppers 或者 Sean T. Larkin 那樣被人抱怨工具太難配置（不好意思 Sean，說的就是 v4）。

你要找到拿來就用和可配置之間的完美平衡。在此之上，還要保持代碼整潔、明確和可配置。命名要直觀，不要用那些自嗨的函數式編程，如果需要 hack 就一定要在注釋里寫明原因。

現如今，我在寫出理想的 API 的 mock 之前不會編寫一行代碼。雖然 mock 的 API 會在實現過程中會不斷變化，但它是代碼應該努力的目標。只有你喜歡用的 API 才是正確的 API。

做好發布的準備

現在你解決了問題，也包裝好了，到了該發布的時候了。但如果你希望別人使用你的代碼的話，在發布之前還有一些工作要做。

寫文檔

這不是開玩笑，你必須寫出最優秀的文檔。不要用那種優越感滿滿的「只需」、「很簡單就可以」等口氣。文檔開頭要有目錄鏈接，要有「快速入門」一節，極其詳細地為第一次使用的人解釋怎樣開始使用。API 中的每個細節都要寫到文檔中。

如果你有個方法，就要寫出方法應有的參數、類型和返回值。要寫明方法的功能，還要給一個使用的例子，讓別人很容易地使用你的庫。

你還應該寫明怎樣做貢獻。你應當在文檔里寫出怎樣運行所有的構建步驟。如果需要引用另一個庫或某個概念，就要給出鏈接。如果要引用任何可以鏈接的東西，也要給出鏈接。

完整的文檔會為你打開新世界的大門，給你完全不同的開局。

寫測試

在這點上一定要聽我的：你必須測試你的代碼，且測試覆蓋率要達到合理的百分比。原因如下：

• 測試能證明你的庫是健康的
• 測試能讓你安心地合併 PR
• 測試能讓你離開項目一段時間後自信地回來繼續為之工作

有一次我發布一個庫時沒有寫測試，Paul Irish 就評論說，「要是有一些測試就好了。」我很自然地回答：「竟然是你。」然後乖乖地去寫了測試。結果寫測試的過程中就發現了大約 15 個bug！多虧了 Paul！

不論做任何事情，都要寫測試。而且要寫好。它可以為我節省很多時間，避免很多噩夢。

使用類型

測試抓不住的 bug 就要靠類型。現在，如果你的 JS 不使用類型，就相當於開車不系安全帶。而且，隨著越來越多的人使用 TS 或 Flow，人們都開始期待代碼里自帶類型。要麼編寫庫時自帶類型，導出並提供類型。要麼就等別人用第三方的形式給你寫類型，這種類型一般都是過時的，很可能還是錯的。自己選擇吧。

代碼庫的基本要求

• README.md
• CONTRIBUTING.md
• LICENSE.txt
• 正確的 package.json

關於 README 就不必多說了。永遠別忘了加上 LICENSE.txt，否則別人就不會使用你的代碼，用 MIT 就好。不要為了假裝可愛就寫一些亂七八糟的授權，只要用 MIT 就好，不要問我為什麼。

CONTRIBUTING.md 里不僅可以寫出怎樣參與項目，還可以添加或鏈接行為準則（code of conduct）。一定要加行為準則，不管你是否同意裡面的理念。相信我。有了行為準則，一些人才會願意貢獻並參與，而且如果以後遇到麻煩，可以指著行為準則來對付那些討厭的人。

其他加分項

現在你寫了完美的文檔、優美的 API，所有必須的東西都完成了，一切都準備就緒就只差發布了，不過我還有一些建議：

添加一些徽標。沒什麼能比徽標更能表現你代碼的正確性了。徽標太多看上去會招人厭，但一些有用的徽標是正確性的標誌，它表明你在乎這個項目。

徽標你可以選用 npm 版本、測試狀態、覆蓋率等等。

而且，Markdown 支持純 HTML，所以可以讓代碼庫的門面變得更漂亮。居中、加一些引用，裝點一下門面吧。

如果真想做到最好，可以加一個貢獻者列表，就像這個一樣：https://github.com/kentcdodds/all-contributors

感恩每個為項目做出貢獻的人這一點很重要。在這裡感謝 Kent C. Dodds！

發布和宣傳

現在一切都搞定了，該發布了。怎樣才能讓別人下載並使用你的代碼呢？

我的建議非常具體。一定要在美東時間周一中午 12 點發布。這個時間在歐洲是工作日的結束，在紐約是午飯時間，在舊金山是大清早人們還沒開始工作之前，你的大部分受眾都在玩手機上網呢。（編者註：時間這一點依據具體受眾群體而定，不拘泥，供參考）

至於怎樣發布，我覺得你應該首先在社交平台（包括 Twitter） 上進行——打出最漂亮的廣告詞。

「厭倦了用鍵盤寫 CSS 嗎？你現在可以用 XBox 手柄寫了！」

「棧跟蹤給你 dump 了？要是能用 VR 來瀏覽棧跟蹤有多好！」

諸如此類，還要加上圖片，最好是視頻。讓人們一眼就能看明白你的代碼是幹什麼的，為什麼要用，還要加上鏈接。人們閱讀的大概過程如下：

• 瀏覽社交平台
• 看到了你發布的內容
• 我去，這個能幹啥？
• 點鏈接
• 看到代碼庫：哇哦真酷，看著不錯咧
• 翻到入門指南
• 複製粘貼到命令行，開始使用
• 點擊 Star 按鈕

具體情況根據賬號粉絲數量以及他們對於技術的態度，可能每個人都有所不同，但一般來說這種方式都有很好的效果。除此之外，其他宣傳渠道還有 HackerNews 和 Reddit 等。

此外，如果你的想法很好，那麼可以在發布的同時寫一篇博客，特別是要以公司的名義發布，這樣就可以通過更多的細節來對其加以介紹。

勇敢、自信，不要怕別人的批評。

維護

我很怕討論這一部分，因為這是我最不擅長的。但我還是很願意介紹一下我經歷過的所有能想像到的失敗，希望你能了解其中的大致情況。

你的庫發布之後，一般會有兩種結果：

1. 無人問津

這無所謂，對於我來說這種情況太常見了，回去繼續干就好了。有時候一個東西不火，並不意味著你的想法不好，只是時機不對。重要的是你做了，而且做對了。那麼下次再做時，你就可以做得更好，更容易成功。安慰一下自己，至少你已經發布了！

2. 火了

這才是真正可怕的時刻——人們喜歡你的東西，Twitter 上到處都在說，你不斷改 bug、回答問題、回擊反對者。這裡我有幾個建議：

首先，如果有人表示願意為你的庫貢獻代碼，可以讓他們做維護者。再重複一遍：

如果有人表示願意為你的庫貢獻代碼，可以讓他們做維護者！

原因是：隨著時間流逝，會出現新的技術，問題也在變化。而你也會變化。但你但代碼永遠在那裡。如果你不放權，你的日子會很難過。你會為了維護而精疲力竭，你開始怨恨你的項目，最終它會變成一個垃圾堆。相信我，一定要放權。

接下來，我要說說如何應對別人。

這是開源最重要的一部分，很多時候甚至比寫代碼還要重要。總會有人噴你，總會有一些自以為是的人，總會有人對你說三道四。

不要聽那些人胡扯。

我也曾花了很多時間與人罵戰，真希望當時的我能夠把這些時間花在別的地方上。相信我，不要理他們。

但是，在判斷他人是否有惡意時一定要謹慎。有時候似乎有惡意，但實際上並不是。想想吧，你的代碼發布到了全世界。假如你是美國人，項目是用英語寫的，那麼千萬不要忘記並不是每個人都說英語。

假設你想給一個俄語的項目寫代碼。但你不懂俄語。所以你用 Google 翻譯說：「嗨，你有計劃什麼時候實現嗎？」但 Google 翻譯成的俄語是「這個什麼時候能搞定？！」第一眼看上去你可能會想，「這人是不是腦子有問題？」稍後你就會發現這只不過是翻譯沒有表達清楚本意而已。

一定要注意這一點，有些人並沒有惡意，只是他們不會說你的語言。

除此之外，我能給出的最好建議就是：為 PR 建立牢固的 CI 流程，並為 issue 和 PR 準備模版。你的代碼庫會收穫超大量的 issue 和 PR，如果你想管理好，就要設置一些規則。我的建議：

• 要求寫出復現步驟或失敗的測試用例
• 要求寫出 bug 出現的條件

你沒有時間處理那些很難出現的 bug。讓別人給你證明 bug 確實存在，並幫你找出 bug，這樣你才能迅速地改正它。

此外，或許還應該在 CONTRIBUTING.md 或其他地方寫明，人們在寫 PR 之前應當先通過 issue 與你溝通想法。世界上最悲傷的事情莫過於非常努力地編寫 PR 卻不被接受了。

說起接受 PR，我想說的最後一條就是，你沒有必要做人們要求你做的一切。我就在這方面浪費過很多時間。

許多時候，有些人只需要一個小功能去解決一個孤立的問題，但這個功能對於社區沒有任何價值。所以修改 API 時一定要謹慎，因為事事都需要處理的極端情況會讓你發瘋。全心全意做好你的核心庫，不要為那些冷眼旁觀者服務。

其實還有點：使用語義化版本，且一定要正確使用。

否則，別人就會不知所措了。還有別忘了推送標籤。還要寫發布說明——詳盡的發布說明。隨著庫的改進，任何參與的人都有必要知道庫發生了哪些變化。

此外還要保持透明、清晰、信息豐富。在棄用某些功能前一定要有寬限期。如果有人投資了你的代碼庫，而你做出的改變破壞了他們的應用程序，那麼他們會惱怒。在更新你的代碼庫的時候，一定要顧及別人。

總結

到此為止，你可能已經意識到我不僅沒有做好開源，而且也不擅長寫文章。但因為有人問起，我才勉為其難寫了本文。我希望這篇粗文能夠幫助那些想發布自己的開源代碼的人，幫助他們節約一些時間，減少他們的煩惱。

開源之路崎嶇坎坷，希望你在閱讀了本文後，前途更加順利，並取得成功。

儘管如此，我還有最後一條建議。如果沒有堅定的決心，不要輕易踏上開源之路，不要將其視作你應做的事情。即使不做開源，你也同樣可以找到工作。即使沒有開源，你也可以成為一名優秀的開發。雖然開源讓我獲益匪淺，而且我也很享受做開源的經歷，但是我永遠也無法挽回花費在那些代碼庫上的時光，我寧願與家人一起共度，或追求一些興趣愛好，或者其他可以帶來被動收入的事情。興之所至，心之所安。如果你對自己構建的東西沒有熱情，那麼就無法取得成功。

原文：https://medium.com/codezillas/a-bitter-guide-to-open-source-a8e3b6a3c1c4

作者：Ken Wheeler，Formidable 公司開源總監。

本文為 CSDN 翻譯，如需轉載，請註明來源出處。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！