目前為止我已經有五個專案登上 Github 的 Trending 頁，所以想分享我的一些經驗和方法。
如果你開源過程式碼，就會知道讓別人對你的感興趣是多麼困難。這很奇怪，不是嗎？ 我們花了至少數百小時在這上，把它免費提供給別人卻沒人感興趣！！經過幾次較為幸運經歷，我慢慢發現如何讓其他人對我的開源工作感興趣。如下圖展示的：

最終你希望得到那些使用你Repo（Github上開源的專案）的開發者的點贊加星。但第一步你需要先獲得一些加星，你就是這篇文章的目的。
首先，我介紹下我自己。我目前主要是一名iOS開發者，我在六個月前開始釋出自己的開源作品。目前為止，我應該算是能在Github的世界範圍頂級iOS開發者榜單上出現了。

事實上我沒有Github上顯示的那麼厲害（謝天謝地，不要鄙視我~）我覺得我能夠在開源社群有些影響力，是因為我同時能做些設計工作（你接下來會見識到），下面是我的流行專案：
- TinderSimpleSwipeCards (650+ 加星, 6 個月內)
- RKSwipeBetweenViewControllers (400+ 加星, 4個月內)
- RKDropdownAlert (500+ 加星, 4個月內)
- RKCardView (500+ 加星, 2個月內)
- RKNotificationHub (500+ 加星, 一星期內)
這上面的5個專案都上過Github流行的頁面，我把如何做到如此分為6個步驟。
六步驟（主要祕訣在第四到第六步）
為了行文簡短，一到三步驟會簡單論訴下，四到六步驟會詳細講解。
- 專案是最重要的
- 閱讀和調研
- 開搞專案倉庫
- 寫好 Readme
- 配上好圖
- 注重反饋迴路
專案是最重要的
Repo就是你作為開發者在構建的產品。
那既然是產品，它就要解決使用者的難題。你估計聽見過不少那些著名的產品都是創始人正好碰到一些難題需要解決而產生。同樣的思路，大部分開源出來的程式碼也是要解決開發者的一些難題。所以，你不一直的創造新東西你怎麼會遇到那些待解決的難題呢~
Twindr（Twitter+Tinder）就是我為了逗樂我朋友和自己這個簡單原因做的傻傻的業務專案。不過最後它帶來了 RKCardView（500+個加星）
所以做業務專案，參加程式設計馬拉松吧，週末和同事瞎搞搞。找到你在重複什麼樣的程式碼，從而你可以構建別人也會需要的模組化的東西~
閱讀和調研
大部分問題已經被解決過成百上千萬次了，並且它還會被繼續重新解決。
每次你想到某些可以開源做成Repo的，先看看是否其他人已經做過類似的了。如果真的已經存在，很多人已經在用了，說明它還不錯，那麼拿起來用別自己搞了。
如果它還沒有被解決，或者沒有被優雅的解決，那開始你的調研。看看現有的方案，找出不喜歡它們的原因。我喜歡瀏覽現有專案的Githu Issues來為如何構建自己類似方案找靈感。如果我有足夠時間，我會親自使用這些專案記錄下我遇到的一些問題（或文件上不好的地方），雖然我自己沒這麼做過，我只是聽說過這個方案而且覺得真的不錯。
最後，開始真正過下它們現有的程式碼。譬如我喜歡 SVProgressHUB 這個專案。特別的，我喜歡它僅僅通過一行程式碼就能呼叫而不需要建立和維護物件才能實現。最終我以類似的方式實現了 RKDropdwonAlert。
開搞專案倉庫
先快速說5次這句話：『簡單，直白，可用』！
我意識到我最近的專案比之前的老專案更快的獲得一些關注和加星。可能是因為越來越多人認識我了（我覺得自己非常有名哈哈哈），但我覺得是因為我越來越懶了。一開始我寫開源專案時，我會寫很多很多程式碼就為了些不那麼明顯優化，我因為那些很重要很吸引人。不過現在我會構建優雅好用的東西，卻花不少時間來清理介面/介面。

RKNotificationHub 漢堡選單按鈕的左上角。
我們拿RKNotificationHub（RKNH）來舉個例子。
一開始我設想RKNN是當我希望在我專案的選單按鈕上加上一些東西，因為我認為是非常好的懂事吸引使用者來檢查下新功能。這的確工作的很好，我持續在其他專案中也陸續使用。
一開始我設想這個Repo可以支援大量的後端的全能型通知系統。譬如連結到類似 set，array，dictionary，API hit，APN等上，每次值改變了就更新它。
不過最終，我就實現了簡單的UI邏輯，把具體業務邏輯交還給使用者自己去實施，使它們有更多精細控制。為什麼？因為我變懶了，但是我認為它也有它的優勢：足夠簡單，輕量和直白，非常易於使用。
一句話總結就是：如果沒人知道怎麼使用你的程式碼，那麼就沒有會使用它。
寫好 Readme
Readme（Github允許你建立該檔案，通過markdown等語法來在專案主頁顯示你專案相關內容）是你整個專案中最重要的內容。
如果你最後只能從該文章學到一樣的話，我覺得就應該是：
你在程式碼上花多長時間，那麼就花同樣的時間來寫你的 README 吧。
我是認真的！事實上，我認為我在Github上的成功很大部分來自於我認真設計我的 README 讓它更具美感（也證明了我就是一般程式設計師而已）。
下面是我是怎麼佈局我的 README 檔案的：

一些關鍵點是：
- 它是大部分人會停留還是會離開的關鍵。把它做好些從而開發者更會在走之前給它加星。越多人加星，就說明越多人認可/相信你的專案。
- 圖片，圖片，圖片！使用類似於 LICEcap 來建立gif圖如果它們是些動畫效果，把建立好的圖片統一放在 imgur 帳號中。
- 展示，而不是囉嗦講訴。 不要用文字說它怎麼怎麼優雅解決什麼什麼問題了，用一張 GIF 來展示，它比囉囉嗦嗦的廢話好用多了。給他們展示程式碼示例。
- 你必須有個 HOW-TO 的部分。用的人不會通讀你的程式碼，所以你必須替他寫好示例。
- 用圖片輔助你的程式碼示例來更好展示效果
- 如果有人提issue了，儘快解決它。如果有人提出同樣的問題多次了，那麼考慮是否要把這個寫到 README 上了。
配上好圖
圖片效果是好於文字的。
Repo 中確實需要好程式碼。不過我敢打賭如果我畫一些好看的圖片不放程式碼依然能獲得現在60%的加星。有了好的科技，然後好的設計就隨之而來 （wherever tech goes, design eventually follow）。消費硬體，應用，網站，著陸頁等都說明了這個趨勢。技術我們定位的是Github的瀏覽使用者，而僅僅是開發者。
下面有些當你在做圖需要考慮的一些關鍵點。我還是使用 RKNK 中圖作為例子。
思考怎麼把你的Repo的目的傳達出來。
你想要他們能理解為什麼這個Repo能有用。RKNK 就是建立出簡單的通知圖示，所以我決定使用 Facebook 的通知中心作為中心圖片。
留意空間

在頂部的title部分有個特定的短連結，在結尾有我的Twitter。然後把中間部分且為兩塊。
左邊的圖來展示如何使用RKNH的使用。它被居中排放（有不少的留白），人們大多都是從左讀到右的，所以左面承載了更主要的概念。
右邊的圖通用被居中並且留有空白。如果說左邊是為了說明這是個什麼產品，那右邊就是來說明你為什麼需要使用它。動畫很具有吸引力，所以我想用它來展示。
最終效果：

這個圖不僅僅是開始一份不錯 README 的簡單有效的方式，也同樣是適合分享。
快速說下目前的工具。我絕大部分的設計工作通過 Sketch3 來完成（它是個非常簡單的圖片設計軟體），GIFs 通過 LICEcap 錄製，並且在 GIMP 中被編輯。它們有些不太好用，不過也是我目前能發現最好的免費方案了
關注反饋迴路
迭代！開動！可執行的指標！
現在我們有了圖片和不錯被加了文件的程式碼。我要向你展示如何玩轉整個洗通過你。我首先介紹下 Github 的 Trending 流行頁的機制。

這就是你要努力登上的頁面。

資料是 Github 提供的，時間視窗不明確，我覺得應該是一週。
這就是原因。大於90%的頁面流量和跳轉來自於 Github 本身，很可能是來自於 trending 流行榜單頁。
成千上萬的開發者到 Github 的流行頁面來看看開發社群中又有哪些流行的東西。更棒的是這些人都有Github帳號並且都登入著。如果你喜歡獲得Github加星，這些人就是最好的來源。
流行頁的演算法也很簡單：就是看在特定時間內被加星的次數。當天和一週都是這樣。
反饋迴路（feedback loop）是我用來讓更多觀眾參與進來的方法（對他們的建議儘快的回覆和迭代）。這是從 the lean startup 中獲得的啟發和也是我第一次獲得30個加星的方法。
反饋迴路看起來像：
- 貼出帶有圖片的連結（比單單的Github有效多了）
- 幾分鐘內獲得反饋
- 及時回覆這些反饋
- 重複兩到三次，直到完成初次的傳播
因為之前的不愉快的事，我現在不太喜歡也很警惕在我個人的社交網路中王婆賣瓜似推廣自己的東西。所以除了這篇文章，你很少能在Facebook上看我的狀態。對我來說， Reddit 就是個不錯的地方，我能夠獲得匿名的反饋（因為那些人也喜歡學習和接受新東西）。它確實是一個積極和提升自信的好環境。
當然你不一定就要選Reddit作為主要平臺。我只是覺得它適合我。你可以更傾向於 Product Hunt，Twitter，Facebook，同事間，本地的電腦科學的使用者組類似於程式設計馬拉松的群組等。確保記住一下的原則：
- 如果你的作品是垃圾，那反饋很可能也是
- 如果你的文件是垃圾，那反饋也不會是什麼好貨
- 如果你還要和那些花時間給你他們建議的人爭吵，那你幾乎就會失去他們的後續關注
我們再看看上面的來源網站的截圖，可以發現Reddit給我帶來了58個人，那我需要從這個58人中取得最初的30個加星。這就是顯示出之前我們的工作（如專案文件README和配圖）的作用了，所以要加倍努力去取得這最初的加星。
如果我遇到一些舉棋不定的時刻，我總會求助於我的部分開發者朋友。他們都會幫我解決難題，所以密切關注他們。
結論
感謝那些讀到現在的朋友，我希望你們馬上就能夠獲得你想要的效果，但是要記住這不是一個一撮而就的魔法。你還是需要做你該做的工作，也許需要花上上百個小時。我並沒有誇大（當我說編碼和寫文件的時間應該1：1的對應），越是複雜的大型專案越需要越清晰易懂的文件。
你也許會從你寫的小東西上獲得好幾百的加星，但是如果你真的搞出影響力，你需要做出大型專案。我個人在接下來幾個月會繼續花時間來維護現有的開源專案，試著理解開發者上什麼使用我的Repo的。構建創造是快樂的，不過修復問題也是同樣重要的。