【譯】「開源」其實很容易

• 原文地址：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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。