本文寫在 markvis 釋出後的一週，總結了在推廣個人專案方面的一些經驗。閱讀時長 10 分鐘。
每個程式設計師都幻想過自己的程式碼執行在千家萬戶的電腦上，但如何讓你的專案獲得更多的關注卻少有人去思考。我們把注意力放在對程式碼的鑽研、對技術的提升，卻少有人關注如何吸引別人參與你的專案。一個人的力量總是有限的，尤其是在開源社群，越多的人蔘與就意味著你的專案有越多的可能性。
我的業餘小專案 markvis(markvis.js.org) 釋出一天之後，在 GitHub 收穫了 200 stars，爬上了 Trending 榜前十，現在一週過去已經近 1000 stars。雖然這不算什麼大的成就，但讓我不得不重新思考推廣的意義。
對推廣的偏見
一般人對推廣都有或多或少的偏見，從我的個人經驗來說大概來自兩個方面：
一是受「酒香不怕巷子深」的影響，總認為只要是金子就會發光的。其實不然，道理很簡單，你覺得你程式碼水平不錯，但跟你同水平的程式設計師肯定不止你一個，如何讓別人更加青睞於你，你需要的是曝光率，你需要把你自己的真實水平展現出來，你需要告訴別人你的實力，而不是等別人去挖掘。這個社會競爭太激烈了，尤其是在我們可愛的程式設計師界。
二是總把推廣和低階的營銷混為一談，甚至把推廣當成一個貶義詞。我之前對推廣的偏見主要來自於此，我總覺得推廣和那些無腦發小廣告的沒什麼兩樣。然而，真正的推廣應該是在散播價值，讓別人知道這個東西的存在，給別人提供瞭解的渠道。當然這得站在你專案是有價值的基礎上，而不是空中樓閣就到處招搖撞騙。
如何推廣
一個吸引眼球的開源專案，我認為需要具備以下幾個要素：
- 一個還不錯的 Logo 或優雅的主頁
- 簡短有力的 slogan
- 能線上試用
- 完善的文件
前兩點一般都會被人忽略，但其實非常重要。第一點很好理解，畢竟是看臉的時代。第二點，為什麼很多企業花很大代價去設計朗朗上口的標語？因為希望在最短的時間內給別人留下最深的印象。第三點正所謂百聞不如一見，向別人傳遞自己的想法總是困難的，不如讓他們自己使用一下，用過才能理解你到底做了什麼偉大的事情。如果你的專案沒辦法線上試用，最好有一個 gif 或短視訊來演示一遍。如果說前三點是包裝，那最後一點則是必須做到的重中之重，接下來我們重點說一說。
README 毋庸置疑是你專案最重要的頁面，如何讓別人迅速瞭解你的專案，你需要用最簡短的話說清楚三件事：
- 你的專案是什麼
- 為什麼要創造它
- 如何使用它
尤其是為什麼，一定要說清楚。它解決了什麼問題，使用它的必要性是什麼，它做出了什麼貢獻等等。
我們可以從使用者的角度去想問題：每當我們考慮是否要用這個庫的時候，都是先去看他的 README，瞭解清楚它到底做了什麼，以及它的優勢。接著再看看它有沒有測試，issues 多不多，解決 issues 和程式碼更新的頻率是多少，大概有多少人使用等等。這就引出了另一些決定你專案成敗的小細節。
- 良好的程式碼風格
- 必要的註釋
- 測試
- 開源協議是否規範
這些事情說大不大，說小也不小。我在釋出 markvis 之前把這些都檢查了幾遍。在 README 裡可以用 coverall 的 badge 來展示測試覆蓋率，用 fossa 來檢測你的協議是否規範。
專案打造
不是任何專案經過推廣都能成功，推廣的重要性可能只要 10%，剩下的 90% 都取決於專案本身。一個有價值的專案我認為要滿足下面幾個要求：
- 解決了一部分需求
- 專案完成度高
- 長期維護
首先你要有明確的目的，你要解決的是一個什麼問題。這個問題通常不是空想出來的，而是有真正需要的，大多數情況來自於我們自己的需求。我在做 markvis 之前，已經在思考如何讓寫作時的視覺化更簡單。正好當時讀了一篇論文《Vega-Lite: A Grammar of Interactive Graphics》，我發現只要用簡單的 JSON 就可以生成一個互動豐富的圖表，這給我做 markvis 提供了極大的靈感。儘管接下來在專案開發的時候遇到一些空難不得不暫時放棄用 vega-lite 的方案，但閱讀相關論文讓我有了做 markvis 的底氣。
其次你需要完成你的專案。開坑不填坑是我們技術人的常態，往往是腦子一熱開始寫一個專案，寫了不到一半遇到點困難或中間停頓了幾天，就放棄了。開發 markvis 的時候我也是這樣，看 commits 記錄就知道我其實不到一年前就開始開發了，但是強大的拖延症生生的把我拖到現在。沒有完成，功能殘缺，bug 一堆，誰還敢用。
開源專案最難的是維護。知名專案 issues 多的處理不過來，不知名專案完全無人問津。最痛苦的是那種用的人不多，還又沒人蔘與的專案，這就完全靠自己了。你要面對的可能是無理的需求或質疑，但收到感謝信的時候還是非常開心的。
如何釋出
萬事俱備只欠東風，釋出也是關鍵。我們沒必要開個釋出會，但至少要抱著搞個大新聞的心態。一般情況下，如果你不想讓人提前知道你在做的東西，你最好不要在完成之前 push 到 GitHub 上，你可以悄悄的在本地緊鑼密鼓的開發。直到完成的那一天，你需要準備下面兩樣東西：
- 釋出（帖子）的標題
- 釋出（帖子）的內容
我們不要做標題黨，但是也要在帖子標題上稍微下點功夫，最好能說清楚你要幹嘛還又能讓別人有點選的慾望。帖子的內容很重要，可以把你 README 上的話再精簡一點，口語化一點。然後開始有策略的向各大網站發帖：
- Hacker News
- reddit/r/javascript
- ProductHunt
- V2EX
當時我對 markvis 沒抱太大期望，也沒有考慮國外的作息時間，一大早起來就只在前兩個網站上提交了自己的帖子。Hacker News 的流量太大，帖子直接秒沉了，reddit 上遲遲不見反饋。當時可能美國的程式設計師兄弟剛下班，都去浪了，所以一直沒啥動靜，star 好像只有十幾個。雖然我有點失望，但是沒有放棄，因為周圍的小夥伴說我做的東西還不錯。於是我在午飯之前又去 ProductHunt 上厚顏無恥地提交了自己的專案。沒想到當天就上榜了。於是 star 數開始不停的長，第二天上了 GitHub Trending 之後就漲得更快了，完全超出了預期。
除了上面的這些網站，如果你英語不錯的話，可以直接向 DailyJS 提交自己的文章，也可以讓 JavaScript Weekly 推薦，總之渠道多多，就看你的專案如何了。下面是我釋出一週後的主頁 Google Analytics，可以看出上週一共有 4.5k 的人來訪，週四即我釋出的第二天是人來的最多的一天，而且程式設計師果然都喜歡凌晨學習，哈哈。
寫在最後
有一些事我們不去做是因為我們對它有偏見，比如推廣。有一些事我們做不好是因為我們沒有認真思考該怎麼做，比如推廣。禁錮我們的不是技術手段，而是思維。這是我這次釋出 markvis 得到的一些人生經驗，共勉。歡迎新朋友來和我交流，我的部落格是 geekplux.com ，會一點前端，懂一點資料視覺化。