英文：Vincent Voyer，翻譯：Linux愛好者 - nEoYe
【導讀】：作者 Vincent Voyer 用親身經歷鼓勵大家從事開源活動：他在 Nodejs 源碼里改了兩個字符，解決了內存泄漏，信心大增；沒找到合適的圖片 lazy load 的庫，自己動手做，竟被印度電商巨頭的網站用上了，信心倍增。
今年我做了一次演講，內容是如何讓我們的開源項目獲得其他人的貢獻，比如提問、寫文檔或者更新代碼，從而打造一個成功的開源項目。在這次演講結束后，我得到了這樣的反饋：“你展示了如何開發一個成功的開源項目，但是我應該怎樣開始一個開源項目呢？”。本文便是來回答這個問題的。文章闡述了如何開始貢獻開源代碼以及如何創建自己的開源項目。
本文分享的知識是基于我們的工作經驗：在 Algolia 工作時，我們發布和維護了許多成功的開源項目，它們都經過了長時間的檢驗。同時，我也花了很多時間來練習和創建自己的開源項目。
我職業生涯的關鍵時刻是六年前我在 Fasterize（一家做網站應用加速的公司）工作的時候。在 Node.js 工作進程中，我們遇到了一個很嚴重的內存泄漏問題。除了 Node.js 源碼庫，我們找遍了所有可能引發這個問題的地方，結果一無所獲。我們的臨時解決辦法是每天重啟這些工作進程（這會使內存使用量歸零），但是我們知道這不是一個優雅的解決辦法，所以我想從整體考慮問題。
當我的聯合創始人 Stéphane 建議我檢查一下 Node.js 的源碼時，我幾乎笑了出來。我想：“如果有 bug，很可能來自我們自己的代碼，而不是來自于創造革命性服務器端框架的開發人員代碼。但是，我還是會看一下的”。兩天之后，我提交的 2 個字符的改動被合并到了 Node.js 的源碼中，修復了 http 層的 bug，解決了內存泄漏問題。
這次的舉動給予了我足夠大的信心。http.js 文件的其他 30 個代碼貢獻者都是我崇拜的人，比如 isaacs（npm 的創造者）—— 這使我明白了不管是誰寫的代碼，都可能會有瑕疵。
在使用開源項目的時候，你是否遇到了 bug？嘗試查閱源碼，不要停留在本地的代碼上。你的答案會使其他人收益，引導著你去給更多的開源項目做貢獻。閱讀其他人的代碼，也許不能馬上解決你的問題，而且需要花費很長時間才能理解源碼，但是你會學到新的模塊，新的語法以及編碼的不同技巧，這些都會促使你成為一名出色的開發者。
Node.js 源碼倉庫的第一個貢獻標簽
“我沒有好想法”，這是那些想為開源做貢獻，但又自認為沒有好的點子或項目來分享的開發者通常會抱怨的一點。那么，我會說：沒關系。為開源做貢獻的機會有很多。許多項目已經開始通過分類或標簽列出那些優秀的首次貢獻者。
你可以通過瀏覽這些網站獲得一些開源靈感：Open Source Friday，First Timers Only，Your First PR， CodeTriage，24 Pull Requests，Up For Grabs， Contributor-ninja 和 First Contributions。
創建工具是幫助他人的一種很好的方式，而且不用考慮太多復雜的問題或 API 設計。你可以開發一個你最喜歡的框架或平臺的模板。你可以將從許多博客上學到的知識和工具集中到一個項目中進行很好的詮釋，并做好隨時更新和發布新特性的準備。create-react-app 是這種開源工具的一個優秀案例.
在 GitHub 上有 5 萬 8 千多個開源模板倉庫，開發一個這樣的項目比較容易而且受歡迎。
今天，你也可以開發 Atom 和 Visual Studio Code 的純 JavaScript 插件，比如我們開發了 Atom 自動補全模塊導入的插件。那些 Atom 或 Sublime Text 中的優秀插件是不是還沒有出現在你喜歡的編輯器中？趕快去開發一個吧。
最后，你也可以為 webpack 或 babel 開發插件，用于解決 JavaScript 技術棧的特殊用例。
好消息是，很多平臺都會告訴你如何去創建和發布插件，所以你不用花費太多的時間去思考怎么下手。
當你在 GitHub 上瀏覽項目時，你也許會發現和使用那些創建者不再維護的項目。雖然它們有價值，但還有很多創建者沒有回答的 issues 和 pull requests 。這時你會怎么做？
fork 一份并用一個新名字發布
成為新的維護者
我建議你兩者都做。前者有助于推進你自己的項目，而后者對你自己和社區都有好處。
你會問，那么如何成為一個新的維護者呢？向創建者發一封郵件或推特，說：“你好，我想繼續維護這個項目，你覺得可以嗎？”這種方式通常效果不錯。這是開始你自己的開源項目的好辦法，因為這個項目已有很多人知曉和受益。
成為新維護者的推特消息示例
創建自己的開源項目最好的方式是尋找那些至今還沒有很好的解決方案的問題。如果你發現你在網上沒有找到能解決你問題的特定的庫，那么這正是去開發一個開源庫的好時機。
下面是我職業生涯中另一個關鍵點。在 Fasterize 工作時，我們的網站性能加速器需要一個快速、輕量級的圖片延遲加載庫 —— 不是一個 jQuery 插件，而是一個單獨的項目，它必須能嵌入所有瀏覽器的所有網站并正常工作。我花了數個小時在網上搜索已經存在的優秀的開源庫，可是最終沒有找到合適的。所以我說道：“完蛋了。我不能找到一個完美的開源庫，我們的工作沒法開展了。”
對于這種情況，Stéphane 回復說：“那么，我們自己來創造一個吧”。嗯..好吧！我將 StackOverflow 上的一段答案復制粘貼到了我的 JS 文件中，就這樣開始了我自己的開源項目之旅。最終，我創建了一個圖片延遲加載的庫，它被像 Flipkart.com（每月大約 2 億的訪問量，在印度排名第 9）這樣的網站使用著。有了這次成功經歷之后，我便無時不刻關注著開源項目。我突然意識到，開源項目可以成為我程序員職業生涯的另一部分，而不是僅有傳奇人物和能力超群的程序員才能做開源項目。
一個沒有好的解決方案的問題：可以嘗試以重用的方式解決它！
時間點很重要。如果你不打算創造一個可重用的庫，而是在自己的項目中寫一些只適用于你系統的代碼，那么你便錯失了一次機會。在某個時刻，其他人會開發出你之前可能有機會做出的項目。所以與其被他人搶先一步，你應該盡快從你的項目中抽離和發布可重用的模塊。
為了確保任何想使用你的模塊的開發者能確切地找到你的開源項目，你需要做到以下幾點：
你的 README 文檔上需要有徽章和虛榮指標
開發一個有著漂亮的設計和在線演示的網站來專門介紹說明你的項目。需要一些靈感么？看一下 Prettier 吧。
在 StackOverflow 和 GitHub 上回答一些相關的問題，并在答案中寫上你的開源項目
將你的項目發布到 HackerNews、reddit、ProductHunt、Hashnode 和任何其他技術社區網站
將你的新項目推薦到相關技術平臺的新聞媒體
和別人交流你的項目，或做一次演講
不要害怕向網站投稿；只要你真的相信自己的項目是有價值的，那些網站從來不嫌文章太多。通常，技術社區都是十分歡迎大家投稿分享的！
在“虛榮指標”（stars 數和下載數量）方面，有些項目在第一天會迅速飆升，但是很快會停止增長。而其他人，在他們準備好登上 Hacker News 首頁之前，也許需要等上一年。你要相信，你的項目在某一時刻會被他人所注意到，如果沒有，那么你也學到了一件事情：這個項目可能只對你有價值 —— 這為你下一個項目的成功做了鋪墊。
我有許多 0 個 stars 的項目（比如 mocha-browse），但是我從來不沮喪，因為我沒有很高的期待。在開始做一個項目時，我總是這么想：我發現了一個問題，我用我自認為最好的方式解決了它，也許有的人會使用我的方法，也許沒有。這不是什么大不了的事情。
這是我做開源項目最喜歡的部分之一。2015 年，在 Algolia 工作時，我們嘗試尋找單元測試的解決方案，暫停了為 React UI 庫 InstantSearch.js 編寫 React 組件時用 JSX 輸出 html 。
由于 JSX 會被轉換成函數調用，當時我們的解決方案是寫成這樣expect(
為了解決這個問題，我們創造了 algolia/expect-jsx，它可以在單元測試中輸出對比 JSX 字符串，而不是輸出無法閱讀的對象。輸入輸出的測試會使用相同的語義。我們并沒有就此停止。我們從代碼中又提煉開發出了另一個庫，并最終發布了兩個開源庫，而不是一個：
algolia/react-element-to-jsx-string 將 JSX 的函數調用轉換成 JSX 字符串的庫
algolia/expect-jsx 將斷言庫 mjackson/expect 和上方的 react-element-to-jsx-string 庫結合了起來
通過發布兩個模塊來共同解決一個問題，社區的開發者可以將你的低級方案在不同的項目中重用。甚至，他們會以一種你從未想到過的方式來使用你的模塊庫。
比如，react-element-to-jsx-string 已經被使用到了許多其他的測試斷言框架中，同時也被用到了像 storybooks/addon-jsx 這樣的文檔插件中。現在，一般都使用 Jest and snapshots testing 來測試你的 React 組件的輸出，在這些場景下已經用不上 expect-jsx 了。
圖中有許多 issues。其實這只是為了好看而使用的假數字??
一旦你開始收到反饋和貢獻代碼，你要以一種開放和樂觀的心態去面對它們。你會得到熱情的反饋，但也會有負面的評論。記住，與用戶的任何互動都是可以看作一種對于項目的貢獻，即使有些看起來像是在抱怨。
首先，用文字來表達意圖和語氣不是那么的容易。“這很奇怪…”也許會被你解讀成：這很棒/這實在是很糟糕/我不理解/我很開心/我很沮喪。詢問更多的細節，嘗試重新解讀這個問題，來更好地理解問題的根源。
避免抱怨的一些建議：
為了更好地引導用戶提出反饋，可以提供一個問題反饋模板，讓他們在提問時可以參考。
盡量對新貢獻者的嚴苛程度降到最低。請記住，他們可能還沒有測試，并很樂意向你學習。不要由于少個分號而對于新的貢獻者的 Pull Requests 置之不理。讓他們感受到溫暖。你可以禮貌地要求他們把分號加上。如果，這樣不行，你也可以就這樣將 Pull Request 合并，然后自己完成測試和文檔工作。
提供一個良好的開發環境，包括自動化測試、錯誤檢查和代碼格式化或自動刷新示例。
感謝閱讀，我希望你們能夠喜歡這篇文章，并幫助你們創建開源項目。貢獻開源代碼是拓展技能的好辦法，并不是每個開發者都需要有這種經歷，但是這是一個讓你快速進步的好機會。
我很期待你的第一個或下一個開源項目。記得在推特上 @vvoyer，我會很樂意給你的項目提出建議。
如果你喜歡開源項目，同時想在工作中去貢獻開源代碼而不是在你的空閑時間，Algolia 有相應的 JavaScript 開源項目研發的職位。
你可能會喜歡的其他資源：
（資源無法添加外鏈）
opensource.guide，學習如何創建和提升你的項目。
Octobox，將 GitHub 的通知以郵件的形式發送給你。一個很棒的方式讓你避免由于 issues 太多，而忽視了其中重要的問題。
Probot，一個GitHub 的 App，幫助提升你的工作流程，使其更自動化，比如關閉時間久遠的 issues。
Refined GitHub 為 GitHub 界面在許多層面提供了更好的體驗和特性。
OctoLinker 給你更好的體驗來查看他人的 GitHub 代碼。
感謝 Ivana，Tiphaine，Adrien，Josh，Peter 和 Raymond 對于這篇文章的幫助、建議和貢獻。
