- 原文地址：Start your open-source career
- 原文作者：Vincent Voyer
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：zwwill 木羽
- 校對者：劉文哲、SeanW20
開啟你的開源生涯
今年我做了一次關於如何讓開源專案獲得成功的演講，討論如何通過做好各方面的準備，來確保讓我們的開源專案吸引各種各樣的貢獻，包括提問、撰寫文件或更新程式碼。之後我獲得一個反饋資訊，「你展示瞭如何讓開源專案成功，這很棒，但我的開源之路究竟該從何入手呢」”。這篇文章就是對這個問題的回答，它解釋瞭如何以及從何開始為開源專案做出貢獻，以及如何開源自己的專案。
這裡所分享的知識都是有經驗可尋的：在 Algolia 中我們已經發布並維護了多個開源專案，時間證明這些專案都是成功的，我也花費了大量的時間來參與和創立新的開源專案。
千里之行始於足下
六年前在 Fasterize （一個網站效能加速器供應商），我職業生涯的關鍵時刻。我們在 Node.js workers 上遇到了嚴重的 記憶體洩露問題。在檢查完除 Node.js 原始碼外的所有程式碼後，我們並沒有發現任何可造成此問題的線索。我們的變通策略是每天重啟這些 workers 以釋放記憶體，僅此而已，但我們知道這並不是一個優雅的解決方案，因此我想整體地去了解這個問題。
當我的聯合創始人 Stéphane 建議我去看看 Node.js 的原始碼時，我幾乎要笑出來。心想：「如果這裡有 bug，最大的可能是我們的，而不是那些創造了革命性服務端框架的工程師們造成的。那好吧，我去看看」。兩天後，我的兩個針對 Node.js http 層的修復請求被通過合併，同時解決了我們自己的記憶體洩露問題。
這樣做讓我信心大增。在我敬重的其他 30 個對 http.js 檔案作出貢獻的人中，不乏 isaacs （npm 的創造者）這樣優秀的開發者，這讓我明白，程式碼就是程式碼，不管是誰寫的。
你是否正在經歷開源專案的 bug？深入挖掘，不要停留在你的臨時解決方案。你的解決方案會讓更多人受益並且獲得更多開源貢獻。讀別人的程式碼。你可能不會馬上修復你的問題，它可能需要一些時間來理解，但是您將學習新的模組、新的語法和不同的編碼形式，這都將促使你成為一個開源專案的開發者。
車到山前必有路
Node.js 倉庫上的首次貢獻的標籤
「我毫無頭緒」是那些想為開源社群做貢獻但又認為自己沒有好的靈感或專案可以分享的開發者們共同的槽點。好吧，對此我想說：that’s OK。是有機會做開源貢獻的。許多專案已經開始通過標註或標籤為初學者列出優秀的貢獻。
你可以通過這些網站找到貢獻的靈感：Open Source Friday, First Timers Only, Your First PR, CodeTriage, 24 Pull Requests, Up For Grabs 和 Contributor-ninja (列表出自 opensource.guide).
構建一些工具
工具化是一種很好的方式來發布一些有用的東西，而不必過多的考慮一些複雜的問題和 API 設計。您可以為您喜歡的框架或平臺釋出一個模板，將一些部落格文章中的知識和工具使用姿勢彙集到這個專案中進行詮釋，並準備好實時更新和釋出新特性。create-react-app 就是一個很好的例子?。
在 GitHub 上有大約 五萬九千個模板 庫，釋出一個並不是難事反而對你有益
現在，你仍然可以像我們給 Atom 構建模版自動化匯入外掛那樣對 Atom 和 Visual Studio Code 進行構建純 JavaScript 外掛。那些在 Atom 或者 Sublime Text 中已經存在了的優秀外掛是否還沒有出現在你最愛的編輯器中？那就去做一個吧。
你甚至可以為 webpack 或 babel 貢獻外掛來解決 JavaScript 技術棧的一些特殊用例。
好的一面是，大多數的平臺都會說明如何建立和釋出外掛，所以你不必太過考慮怎麼做到這些。
成為新維護者
當你在 GitHub 上瀏覽專案時，你可能時常會發現或者使用一些被建立者遺棄的專案。他們仍然具有價值，但是很多問題和 PRs 被堆放在倉庫中一直沒有得到維護者的反饋。此刻你該怎麼辦？
- 釋出一個新命名的分支
- 成為新的維護者
我建議你同時做掉這兩點。前者將幫助推進你的專案，而後者將使你和社群受益。
你可能會問，怎樣成為新的維護者？發郵件或者在 Twitter 上 @ 現有維護者，並且對他說「你好，我幫你維護這個專案怎麼樣？」。通常都是行之有效的，並且這是一個很好的方法能讓你在一個知名且有價值的專案上開啟自己的開源生涯。
示例：去復興一個遺棄的專案
建立自己的專案
發掘自己專案的最好方法就是關注一些如今還沒有很好解決的問題。如果你發現，當你需要一個特定的庫來解決你的一個問題而未果時，此刻便是你建立一個開源庫的最佳時機。
在我職業生涯中還有另外一個關鍵時刻。在 Fasterize，我們需要一個快速且輕量級的圖片懶載入器來做我們網站效能加速器，它並不是一個 jQuery 外掛，而是一個可在其他網站載入並生效的獨立專案。我找了很久也沒在整個網路上找到現成的庫。於是我說「完了，我沒找到一個好的專案，我們沒法立項了」。
對此，斯蒂芬迴應說「好吧，那我們就創造一個」。嗯～～好吧，我開始複製貼上一個 StackOverflow 上的解決方案 到 JavaScript 資料夾中，建立了一個圖片懶載入器 並最終用到了像 Flipkart.com （每月有 2 億多訪問量，印度網站排行第九） 這樣的網站上。經過這次成功的實踐後，我的思維就被聯結到了開源。我突然明白，開源可能是我開發者生涯的另外一部分，而不是一個只有傳說和神話的 10x 程式設計師才勝任的領域。
一個沒有很好解決的問題: 以可重用的方式解決它!
時間尤為重要。如果你決定不構建可重用的庫，而是在自己的應用程式中內聯一些程式碼，那就錯失良機了。可能在某個時候，別人將建立這個本該由你建立的專案。不如即刻從你的應用程式中提取併發布這些可複用模組。
釋出，推廣，分享
為了確保每個有需要的人都樂意來找到你的模組，你必須：
- 撰寫一個良好的 README，並配有版本徽章和知名度指標
- 為專案建立一個專屬且精心設計的線上展示網站。可以在 Prettier 中找一些靈感
- 在 StackOverflow 和 GitHub 中找到與你已解決問題的相關提問，並將貼出你的專案作為答案
- 將你的專案投放在 HackerNews, reddit，ProductHunt， Hashnode 或者其他彙集開源專案的社群中
- 在你的新專案中投遞關於你的平臺的關聯資訊
- 參加一些討論會或者做演講來介紹你的專案
向全世界展示你的新專案
不要害怕在太多網站釋出資訊，只要你深信自己創造出來的東西是有價值的，那麼再多的資訊也不為過。總的來說，開源社群是很歡迎分享的。
保持耐心持續迭代
在「知名度指標」（star 數和下載數）上，有些專案會在第一天就飛漲，之後便早早地停止上漲了。另外一些專案會在沉澱一年後成為頭條最熱專案。相信你的專案會在不久後被別人發掘，如果沒有，你也將學會一些東西：可能對於其他人來說它是無用的，但對於你的下一個專案來說它將是你的又一筆財富。
我有很多 star 近似為 0 的專案，比如 mocha-browse，但我從不失望，因為我並沒有很高的期望。在專案開始是我就這麼想：我發現一個好問題，我盡我所能地去解決它，可能有些人會需要它，也可能沒有，那又有什麼大不了的。
一個解決方案的兩個專案
這是我在做開源中最喜歡的部分。2015年在 Algolia，我們在尋找一種解決方案可以單元測試和凍結我們使用 JSX 輸出的 html，以便我們為寫 React 元件生成我們的 React UI 庫 InstantSearch.js。
由於 JSX 被編譯成 function 呼叫的，因此我們當時的解決方案是編寫方法 expect(<Component />).toDeepEqual(<div><span/></div>)，也只是比較兩個 function 的呼叫輸出，但是這些呼叫輸出都是複雜的物件樹，在執行時可能會輸出Expected {-type: ‘span’, …}。輸入和輸出比較是不可行的，而且開發者在測試時也會抓狂。
為了解決這個問題，我們建立了 algolia/expect-jsx，他讓我們可以在單元測試中使用 JSX 字串做比較，而不是那些不可讀的物件樹。測試的輸入和輸出將使用相同的語義。我們並沒有到此為止，我們並不是僅僅釋出一個庫，而是兩個庫，其中一個是在第一個的基礎上提煉出來的。
- algolia/react-element-to-jsx-string 將JSX函式返回轉換為 JSX 字串
- algolia/expect-jsx 用於關聯 react-element-to-jsx-string 和斷言庫 mjackson/expect
通過釋出兩個共同解決一個問題的模組，你可以使社群受益於你的底層解決方案，這些方案可以應用在許多不同的專案中，還有一些你甚至想不到的應用方式。
比如，react-element-to-jsx-string 在許多其他的期望測試框架中使用，也有使用在像 storybooks/addon-jsx 這類的文件外掛上。現在，如果想測試 React 元件的輸出結果，使用 Jest 並進行快照測試，在這種情況下就不在需要 expect-jsx 了。
反饋和貢獻
這裡有很多問題，當然，這是我為了好看而偽造的?
一旦你開始了開源的反饋和貢獻就要做好開放和樂觀的準備。你會得到讚許也會有否定。記住，任何和使用者的交流都是一種貢獻，儘管這看起來只是抱怨。
首先，要在書面上傳達意圖或語氣並不容易。你可以使用「這很棒、這確實很差勁、我不明白、我很高興、我很難過」來解釋「奇怪了。。」，詢問更多的細節並試著重現這個問題，以便更好地理解它是怎麼產生的。
一些避免真正抱怨的建議：
- 為了更好地引導使用者給予反饋，需要為他們提供一個 ISSUE_TEMPLATE，可以在建立一個新問題時預填模版。
- 儘量減少對新晉貢獻者的阻力。要知道，他們可能還沒進入角色狀態並很樂意向你學習。不要因為缺少分號
;就拒絕他們的合併請求，要讓他們有安全感。你可以溫和的請求他們將其補上，如果這招沒用，你可以就直接合並程式碼，然後自己編寫測試和文件。
最後
感謝你的閱讀，我希望你會喜歡這篇文章，並能幫你找到你想要幫助或者建立的專案。對開源社群做貢獻是擴充套件你的技能的好方法，對每個開發者來說並不是強制性的體驗，而是一個走出你的舒適區的好機會。
我現在很期待你的第一個或下一個開放原始碼專案，可以在 Twitter 上 @ 我 @vvoyer，我很樂意給你一些建議。
如果你喜歡開源，並且想在公司實踐而不是空閒時間，Algolia 已經為 開源 JavaScript 開發者 提供崗位了。
其他你可以會喜歡的資源：
- opensource.guide，學習如何啟動和發展你的專案
- Octobox， 將你的 GitHub 通知轉成郵件的形式，這是避免因堆積「太多問題」以至於影響關注重要問題的很好的方法
- Probot，GitHub App 可以自動化和改善你的工作流程，比如關閉一些非常陳舊的問題
- Refined GitHub 在很多層面上為 Github UI 提供了令人欽佩的維護經驗
- OctoLinker 為在 Github 上瀏覽別人的程式碼提供一種很好的體驗
感謝 Ivana、Tiphaine、Adrien、Josh、Peter、Raymond、zwwill 木羽、劉文哲、SeanW20 為這篇文章作出的幫助、審查和貢獻。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。