如何使你的開源項目成功

時間 2020-01-20

標籤如何開源項目成功欄目職業生涯简体版

原文原文鏈接

做者：Dmitri Pavlutin
翻譯：瘋狂的技術宅javascript

原文：https://dmitripavlutin.com/ho...前端

未經容許嚴禁轉載java

你已經爲一個有趣的問題工做了幾個月，如今決定啓動一個開源項目。你在 README.md 中編寫了一些說明，併發布了1.0版。react

幾周後，人們對這個項目仍然沒有什麼興趣。你作了大量的工做，付出了最大的努力，可是最後，仍然沒有誰對它感興趣。git

怎麼會這樣？更重要的是，怎樣才能使你的開源項目成功？程序員

我建立了一個開源庫 vocajs.com，通過努力，這個庫成爲了 GitHub 上最受歡迎的項目之一。在這個過程當中，我學到了一些重要原則，這些原則涉及如何製做高質量的開源項目。我想要與你們分享這些想法。github

1.沒人關心你的項目

首做爲做者，要轉變你對開源的見解。你可能會認爲，若是你對你感興趣的項目（庫、工具、框架等）投入了大量精力，那麼許多人也應該會感到興奮。web

不幸的是，事實並不是如此……面試

聽起來可能很苛刻，可是開發人員僅對解決他們的問題感興趣。所以，當有人訪問你的 github 存儲庫時，就是在尋找解決方案。chrome

2.解決實際問題

甚至在啓動開源項目以前，甚至在編寫第一行代碼以前，都要花大量時間去尋找要解決的實際問題。

總而言之，一個好的開源項目解決了開發人員正在積極尋求解決方案的問題。

根據個人經驗，我決定寫一個 JavaScript 字符串庫。個人主要理由是當時的解決方案質量低下。另外 JavaScript 自己沒有全面的標準字符串庫。

我對字符串並不特別熱衷，建立這樣的庫甚至可能很無聊……可是更重要的是，我發現了一個須要解決的問題。

尋找問題要用到的一些策略：

思考你遇到的問題。你能夠爲此建立解決方案嗎？
探索被普遍使用但性能中等的開源項目。能夠實施本身的更好的解決方案。
在 GitHub 的熱門項目、Stackoverflow 問題甚至 Twitter 問題中搜索想法。

關鍵點

🏛 成功的開源項目解決了一個已知的問題

3. 強調質量

大多數開發人員都在閉源項目中工做。除了你的隊友之外，極可能有一些開發人員會閱讀你的代碼。

可是，當你爲全部人開放代碼時，狀況就不一樣了。

事實是，不少開源代碼並非最好的質量。沒人會依賴於難以理解、不穩定且充滿錯誤的代碼去解決問題。

這方面是增長信任度並證實你的開源項目正在測試質量的好方法。你可能須要至少 80％的代碼覆蓋率。

你甚至能夠走得更遠，並在 README.md 上放一些標記，以證實代碼庫已通過全面測試。

源代碼的可讀性也是一個重要方面。若是你想在之後的階段吸引更多的貢獻者，則代碼必須易於閱讀且結構合理。

此外，開源工具將只從實現非功能性需求中受益：

有直觀、可配置和可擴展的 API
支持普遍的環境（跨平臺，跨瀏覽器等）
提供選擇功能的可能性
幾乎沒有依賴關係
體積小

關鍵

🏛 成功的開源項目具備 高質量代碼和 高代碼覆蓋率

4.優秀的 README.md 和文檔

好，你遵循了個人建議，發現了一個不錯的問題，並實施了一個相對不錯的解決方案。這就夠了嗎？

不幸的是，只完成了一半的工做……

README.md 文件是項目的入口點。並且，若是你不能簡潔明瞭地解釋項目的確切目的，人們將幾乎不瞭解它的任務。

若是 README.md 缺乏詳細信息，你可能會認爲開發人員慧深刻研究實現細節，並自行找到如何使用該工具的方法。一般，這種狀況不會發生，由於沒人喜歡解密代碼。

每一個人的指望是瞭解你的工具能夠解決什麼問題以及如何使用它。就這樣。

告訴你一個對我有效的真理：

花 50％的時間編寫引人注目的 README.md 和簡單明瞭的文檔。

是的，你沒有看錯。花一半時間解釋項目的用途以及如何使用它。

4.1 README.md

用戶在訪問項目存儲庫時最早看到的是 README.md 文件。你只有20-30秒的時間吸引注意力去兜售你的東西。

我建議 README.md 包含如下部分。

1. 任務

首先用簡短的句子解釋你的項目的任務：「它作什麼？」將其放在項目名稱的後面。

例如，對於個人開源庫 Vocajs，我用瞭如下單句進行解釋：

「Voca 是一個用於處理字符串的 JavaScript 庫」

這句話可以告訴你個人項目是作什麼的：一個處理字符串的 JavaScript 庫。

若是有的話，在任務結束後當即插入指向詳細文檔的連接。

2. 說明

任務結束後，將進行簡短說明：「我爲何要用它？」它應該稍微詳細說明任務。

例如這就是我用來描述的內容：

「Voca 庫提供了有用的功能，使字符串操做變得溫馨：更改大小寫，修飾，填充，段化，拉丁化，sprintfy，截斷，轉義等。「模塊化設計」容許加載整個庫或單個函數以最小化應用程序構建。該庫通過了「充分測試」，「有據可查」和「受到長期支持」。」

說明中不要添加太多技術細節。只突出好的部分。

3. 特色

以後，你能夠經過列出功能來更深刻地解釋技術細節：「它提供哪些功能？」。

爲了便於閱讀請使用列表。

4. 安裝和使用

最後描述「如何安裝和配置？」

若是有的話，你能夠在此處再次插入指向詳細文檔的連接。

能夠把 https://github.com/panzerdp/v... 做爲例子。

4.2 文檔

若是項目很大，README.md 可能不適合描述詳細的 API。須要建立一個僅描述 API 的附加頁面。

詳細文檔示例：lodash，ant.design。

文檔簡明扼要地說明了全部的使用方面。例如：列舉函數的參數，說明可接受的數據類型，並給出適當的示例。

這是我爲庫中 v.kebabCase() 函數記錄文檔的方式：

你能夠輕鬆地瞭解如何使用 kebabCase() 函數：它的做用、接受的參數以及返回的值。還提供了一些示例。你甚至能夠找到到源代碼和單元測試的連接。

關鍵

🏛 成功的開源項目應該具備 引人注目的 README.md 和 出色的文檔

5. 展現 demo 和截圖

人類是視覺生物。這就是你構建可視工具（圖表、UI小部件、移動/桌面應用等）的緣由，我強烈建議你包括 demo 和截圖。

一個好的 demo 賽過千言萬語。

例如我實現了一個小型的開源 Chrome 擴展程序 Cliboardy。它能將代碼從 stackoverflow.com、github.com 和 npmjs.com 複製到剪貼板。

在 README.md 的開頭，我沒有文字說明，而是提供了一個演示 gif：

觀看這個演示，你甚至無需閱讀說明。

6. 嘗試創建社區

與人打交道是管理開源項目的一個重要的部分：與用戶溝通、實現新功能、修復錯誤。

雖然乍一看彷佛不是很重要的，但溝通是一項複雜的任務。響應問題和審查代碼pull請求可能比預期要花費更多時間。

有時您會遇到沮喪的用戶，不管如何，找到了與你們禮貌地交流的意願。

準備對某些請求說「No」或拒絕 pull 請求。始終試着禮貌地解釋你的決定，並感謝貢獻者所花費的時間。

目標是吸引新的人蔘與項目。有人說，流行的開源項目基於強大的貢獻者社區。

關鍵

🏛 成功的開源項目創建在 有效的溝通和 活躍的社區上

7. 讓全世界都知道

一切都準備就緒。你的項目的版本爲 1.0，有出色的 README.md 和文檔。

如今該推廣你的開源項目了：讓全世界都知道它。

把你的項目共享到 reddit.com（一個或多個相應的 subreddits）、news.ycombinator.com，echojs，Twitter 等。幸運的是，你的項目可能會在普及方面有一個良好的開端。

可是要注意兩個微不足道的問題。

首先，抵制發佈還沒有完成的項目的衝動。先搞定一切。 你永遠不會有第二次機會去留下良好的第一印象。

其次，在 Reddit 等網站上分享可能會引來一些鍵盤俠對你的工做發表嚴厲評論。不要受到這些評論的影響而使你沮喪。

批評很容易，可是創造卻很難。請記住，創造的人是當今的英雄。

接受建設性的批評，忽略垃圾評論。

8.結論

一個成功的開源項目須要付出大量的時間和精力。

首先，項目必須可以解決一個問題，並將其解決好。開發人員正在爲他們的問題尋找更好的解決方案。

你必須花費大約 50％的時間來建立高質量的 README.md 和詳細的文檔。對於用戶而言，工具的使用應該儘量省力。

擁有良好的代碼覆蓋能夠創建對代碼質量的信任。也不要忘記對非功能性需求進行投資，例如支持許多環境且幾乎沒有依賴性。

嘗試與項目的用戶進行交流。他們將常常報告問題並提出改進建議。要禮貌和建設性的溝通：你的目標是吸引貢獻者。

若是你想了解更多信息，我建議你閱讀「Producing Open Source Software」這本免費書籍。

你知道哪些使開源項目成功的其餘策略？請在下面的評論中告訴我。

本文首發微信公衆號：前端先鋒

歡迎掃描二維碼關注公衆號，天天都給你推送新鮮的前端技術文章

歡迎繼續閱讀本專欄其它高贊文章：

更多文章...

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。