除了擅長編寫 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 之前，我們可能需要一些額外的安裝工作，如：

1. npm install koa

如 Koa 的示例：

1. constKoa=require('koa');

2. const app =newKoa();

3. // response

4. app.use(ctx =>{

5.  ctx.body ='Hello Koa';

6. });

7. app.listen(3000);

作為一個程式設計師，你應該懂得它的重要性。

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

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

技術文件

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

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

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

WTF！

技術文件

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

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

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

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

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

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

更多的示例程式

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

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

Redux

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

編寫技術文章、書籍

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

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

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

鼓勵、吸引貢獻者

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

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

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

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

已合入《GitHub 漫遊指南》