標籤：

如何運營一個開源項目並取得較大影響力？

01-01

本人碼農+黑客。喜歡為開源社區作貢獻。沒事的時候很喜歡做一些框架啊，工具包啊…當然都是開源的。

我為我心愛的框架寫了文檔，寫了readme，做好了官網，做好了論壇，配置了CI和測試，還放進了包管理…

說實話我感覺我寫的很多庫和框架還是很實用，很優秀的，解決了很多常見的問題和需求…

可是至今參與貢獻的人數都是個位數…在包管理上下載量也是區區幾百…

如何在開源軟體社區取得影響力呢？

除了擅長編寫 md 電子書來攢 star，我還寫了一系列的開源軟體，也掌握了一些項目運營的技巧。

開源並不是你把軟體、README 寫好就行了，還有詳細的文檔、示常式序等等。

開源也不是你的項目好了，就會有一堆人參與進來。

開源還要你幫助別人解決 Bug，……。

人們做事都是有原因的，即動機。再舉例一下，如果你的項目不夠火，別人都沒聽過，那麼寫到簡歷上可能沒啥用。

Marketing First

開源需要一些營銷的技巧，這些技巧可以幫你吸引關注。舉個簡單的例子，司徒正美的 avalon 框架出身得很早，也 MV* 方面也做得很不錯，但是在 marketing 上就……。以至於國內的很多前端，都不了解這個框架，要不今天在國內可能就是 AVRR 四大框架了。

Vue 不是因為好用，而一下子火了。這一點我印象特別深，當時在 GitHub Trending 上看到了這個項目，發現它還不能很好地 work。

而如文章 《FIRST WEEK OF LAUNCHING VUE.JS》所說，項目剛開始的時候作者做了一系列的營銷計劃：

  • HackerNews
  • Reddit /r/javascript
  • EchoJS
  • The DailyJS blog
  • JavaScript Weekly
  • Maintain a project Twitter account（維護項目的 Vue 賬戶）

除此，文中還提到了一篇文章《How to Spread The Word About Your Code》 。

這一點相當的有意思，如果你的想法好的話，那麼大家都會肯定，點下鏈接，為你來個 star。那麼，你就獲得更好的動力去做這件事。項目也在開頭的時候，獲得了相當多的關注。而如果大家覺得你的項目沒有新意的話，那麼你懂的~。

除此，還有一種可能是，你的 ID 不夠 fancy，即你在社區的影響上比較少。此時，就需要一點點慢慢積累人氣了。當你積累了一些人氣，你就能和松本行弘一樣，在創建 mRuby 的時候就有 1000+ 的 star。並且，在社區上還有一些相關的文章介紹，各個頭條也由他的粉絲髮了上去。如，一年多以前，我創建了 mole 項目。

當時，是為了給自己做一個基於 GitHub 雲筆記的工具，在完成度到一定程度的時候。我在我的微信公從號上發了相關的介紹，第二天就有 100+ 的 star 了，還接收至最一些鼓舞的話語。對應於國內則有：

  • 極客頭條
  • 掘金
  • 開發者頭條
  • v2ex
  • 知乎
  • 不成器的微博

所以，你覺得呢？

編寫一個好的 README

在一個開源項目里，README 是最重要的內容。它快速地介紹了這個項目，並決定了它能不能吸引用戶：

  • 這個項目做什麼？
  • 它解決了什麼問題
  • 它有什麼特性 — hello, world 示例

這個項目做什麼——一句話文案

GitHub 的 Description 是我們在 Hacking News、GitHub Trneding 等等，第一時間看到的介紹。也是我們能快速介紹給別人的東西，如下圖所示：

這一句話，必須簡單明了也介紹，它是幹什麼的。

如 Angular 的一句話方案是：One framework. Mobile desktop.

而 React 是：A declarative, efficient, and flexible JavaScript library for building user interfaces.

Vue 則是：A progressive, incrementally-adoptable JavaScript framework for building UI on the web.

它解決了什麼問題

上面的一句話描述，它不能很好地說明，它能解決什麼問題。

如下是今天在 GitHub Trending 上榜的 RPC 項目的簡介：

Most machines on internet communicate with each other via TCP/IP. However TCP/IP only guarantees reliable data transmissions, we need to abstract more to build services:

以上便是這個項目能解決的問題，不過這個項目能解決的問題倒是比較長，哈哈哈。

它有什麼特性

當我們有 A、B、C 幾個不同的框架的時候，作為一個開發人員，就需要對比他們的特性，。如下是 Go 語言實現的 MQTT 示例：

這個項目只支持的 Qos 級別為 0。如果我們需要的級別是 1，那麼就不能用這個項目了。

又比如 lodash 項目：

Lodash makes JavaScript easier by taking the hassle out of working with arrays, numbers, objects, strings, etc. Lodash』s modular methods are great for:

  • Iterating arrays, objects, strings
  • Manipulating testing values
  • Creating composite functions

你會怎麼寫？臉皮夠厚的話，可以直接寫一下，與其它項目的對比，blabla：

當然了，這種事不能太過，要不是會招來一堆黑。

安裝及hello, world 示例

在我們看完了上面的介紹之後，緊接著接一個 hello, world 的示例。在運行 hello, world 之前，我們可能需要一些額外的安裝工作，如：

npm install koa

如 Koa 的示例：

const Koa = require("koa");
const app = new Koa();

// response
app.use(ctx =&> {
ctx.body = "Hello Koa";
});

app.listen(3000);

作為一個程序員，你應該懂得它的重要性。

好在這裡的安裝工作只有兩步，而不是：

對於那些需要複雜的安裝過程的軟體，應該簡化安裝過程，如提供 Docker 鏡像，或者直接提供一個可運行的 Demo 環境。以免用戶在看完 README 之後，直接放棄了使用該庫。

技術文檔

好了，依一個開發人員的角度，如果上面的步驟一切順利的話，接下來，便是使用這個開源項目來完成我們的功能。這個時候，我們開始轉移注意力到文檔上了。

由於，之前在某一個項目，經歷過一個第三方 API 文檔的大坑——文檔中只羅列了 API 的用法。如下 Intellij Idea 生成的結構圖：

文檔中上，羅列了每個函數，以及每個函數需要的參數。我使用 Intellij Idea 直接反編譯 jar 包，看到的信息都比文檔多多了。文檔上，沒有任務示例，甚至連怎麼初始化這個庫的代碼都沒有。

WTF！

技術文檔

對於一個複雜的開源項目來說，文檔上要寫明安裝、編譯、配置等等的過程。如下圖所示：

並且在我們發布包的時候，就要不斷地去重複這個過程——如果你使用了自動化測試，那麼這個過程便自動完成了。

如果我們的項目使用起來相當的簡單，那麼我們就可以只寫一些示例代碼即可。

並且，我們可以將文檔直接入到代碼里。它可以有效地減少文檔不同步，帶來的一些問題。

上圖是使用了 jsdoc 的 Lodash 示例。

除了上面的示例，我們還可以錄製一些視頻，寫一些文章說明項目的思考、架構等等。

更多的示常式序

示例代碼本身也是文檔的一部分，不要問我為什麼~~。

反正，除了一個 hello, world，你還要有各種場景下的示例：

沒有這麼多示例，敢說自己是好用的開源項目？

編寫技術文章、書籍

到目前為止，我們做了一系列 markdown 相關的工作，卻也還沒有結束。要知道只有真正寫過一系列開源項目的人，才能體會到什麼是 markdown 程序員~~。

官方文檔，一般要以比較正式的口吻來描述過程，這種寫法相當的壓抑。如果要用輕鬆詼諧的口氣，那麼就可以寫一系列的技術文章。假如這是一個前端框架，那麼我們可以介紹它如何與某個後端框架配合使用；又或者是，它與某個框架的對比等等。

好了，一切順利了，那麼下一步就是吸引更多的人參與到項目上來了。

鼓勵、吸引貢獻者

要吸引其它開發人員來到你的項目，不是一件容易的事。

你需要不斷地鼓勵他/她們，並適時地幫他/她們解決問題，以避免他/她們在提 pull request 的過程中放棄了。這一點特別的有意思，當有一個開發人員發現了項目中的 bug，那麼他/她會嘗試去解決這個問題。與此同時，他/她還會為你的項目帶來 pull request，但是在這個過程中，因為測試等等的問題，可能會阻礙他的 PR。這個時候，就需要我們主要去提示/教他們怎麼做，又或者是幫他/她們解決完剩下的問題。那麼，下次他/她提一個 PR 的時候，他/她就能解決問題了。

這一點可以在 README，以及介紹上體現：

哪怕只是一個錯誤字的 PR，那麼你也可以 merge，啊哈哈~。然後，就有人幫你宣傳了，『我給 xxx 項目一個 PR 了』。剛畢業的時候，我也是從這種類型的 PR 做起的~~。

轉載保留原文鏈接：如何運營一個開源項目並取得較大影響力？

謝邀。

首先，我覺得搞開源軟體首先是要開心，真心做這事，有沒有影響力那就聽天由命吧，不用追求多大影響力。

其次，有影響力的開源軟體都是有獨到之處，或者是解決了一個大問題，或者是用一種全新的方法來解決問題，並不是說有了文檔、代碼風格、論壇、CI/CD這些東西就有影響力，因為這些東西只是輔助工具，而和項目帶來的價值無關。

有個位數的貢獻者很好了啊。

好多項目只有作者一個人寫代碼，

一大波圍觀群眾點star或者發issue

最近在學習閱讀開源代碼，剛看到這樣一句話，應該對問題有所幫助

開源項目離不開大家的廣泛參與和支持，要讓一個開源項目取得成功，有多個方面的因素。

-產品本身的創新功能

-在實際項目中的應用和推廣，業界大佬企業的積极參与

-教育培訓市場的積極跟進，也是一個開源項目最終能夠長久生存下來的必備因素

——許鵬

哈哈 同感，偶爾寫點技術文章，發版的時候發發新聞，自然發展就好，大部分時間我還是獨自敲敲代碼，很享受這個過程，至少自己就是項目的受益者，那它就是有價值的，有多少用戶和影響就無所謂了，有人發issues和pr，如果有時間我也會盡量去支持和維護

多發發廣告軟文，貌似好多人都這麼乾的

自己每天註冊幾個賬號刷star，刷到一百以上後自然被關注的機會會更大，之後就完全看你項目了

推薦閱讀：

※C/C++ 編程有哪些值得推薦的工具？
※你有用了Gentoo就不想用Arch的感覺嗎？
※如果代碼都開源甚至所有技術都開源，那麼人類社會是否能迎來一次質的飛躍？
※閱讀開源項目代碼的意義有哪些？
※有哪些有意思的，很cool的開源項目 ？

TAG:開源軟體 | 開源 | GitHub | 開源社區 |