Star 雖好，可不要貪杯哦。
兩年前在做 Annual Review 訂下一年的目標時，想著寫一個開源框架。去年訂下今年的目標時，仍然繼續著這樣的想法。今年又要制定下一年的目標，2333~~。
不久前，在 GitHub Ranking 上看到自己的 star 數（star 不是設計用于做“點贊”的，而是用來收藏的）時，發現已經快 20000 了。然后把自己的項目過了一遍，發現沒有一個比較好的代表性框架，要么是應用，要么是電子書。
前 8 個項目里，除了 Growth 應用以外，其他的都是電子書內容——六本電子書加起來的 star 數有 10619，果然是騙 star 的。我只能盡力地去想想：為什么事情會變成這樣了？
從創建開源框架說起
創建開源框架和創建創建開源項目是不一樣的，前者你服務于開發者，后者你服務于用戶。
兩年前在做 Annual Review 的時候，想著未來的一年里可以做一個開源框架試試。那時剛畢業不久，對開源世界的各種游戲規則不是很了解：開源并不是將代碼提交上去，然后就會一下子火起來。雖然我們可以在短期內賺上一些眼球，但是真正要將它采用到項目上的人不多。
當時，我遇到的最主要的問題是：想參與到項目的人并沒有遇到足夠的能力。你還需要花費大量的時間去教他們，鼓勵 GitHub 新手并不是一件容易的事。有時我需要在接受他的 PR 后，再修改他的代碼。并且人們提交 PR 可能是出于不同的原因。
然后，知道了開源世界還有一個游戲規則是：誰的影響力大，誰就能產生更廣泛的影響。如 Virtual Dom 并不是 Facebook 首創的，但是卻因為 FB 火的； 松本行弘在寫下 mruby 的 README 時（印象中是這個項目），star 數就已經過 1k 了。這種例子數不勝數，要么是在推廣上花了力氣，要么個人、公司有著更大的影響力。
一年前，稍微改變了下策略：暫時以培養人為主，同時想著做一個合適的開源框架——只是在今年看來，前端領域已經沒有合適的地方可以造輪子了。
在 GitHub 上有一個很常見的問題是，大多部分項目的維護者就是發起人——如果這個發起人發生意外了，那么這個項目怎么辦。如果這是一個很火的項目，它就存在著巨大的風險；同時這可能也說明了，缺乏一套合理的機制。
你的開源項目不僅僅需要一個使用文檔，還需要一個相關設計思想的文檔、路線圖、未來計劃等等。
去年年底寫總結的時候，想到可以 RePractise 文章為基礎來培養人，于是就有了 Growth 的三個項目：
- 應用：Growth
- 電子書：《Growth：全棧增長工程師指南》
- 電子書：《Growth：全棧增長工程師實戰》
如今 Growth 已經有了過萬的用戶，每天活躍的用戶數也接近 300 了。第一步看上去很成功，但是下一步怎么走呢？
下一個開源項目
后來我開始在思索一個問題，創建一個開源框架是必須的嗎？
在編寫 Growth 電子書的時候，我發現一個好的軟件工程實踐遠遠比一個易上手的框架重要多了。框架本身是易變的東西，過去你在用 Backbone，現在你在用 React.js；過去你在用 Angular.js，現在你在用 Vue。會不會使用某個框架，并不是區分你是不是一個有經驗的開發者的標準。
一直將焦點關注于學習不同的框架的使用是有問題的，一個在校生可以輕松地比你了解某個框架的原理——你白天在工作，而他整天在學習。這時你很容易就失去競爭力了，你需要從框架之外了解更深層次的東西。一個好的框架并不能讓你寫出一段好的代碼。
如果中國人的思想不覺悟，即使治好了他們的病，也只是做毫無意義。
這算是我為自己在 GitHub 下的 Markdown 的自辯吧——誰讓我一直有寫作的沖動呢。
不過我仍然還有一些想法，只是還沒有抽出足夠的時間去思考這樣的事。
GNU/Linux 的桌面。這是幾年前的一個想法了，當時 GNU/Linux 的那些操作系統上都沒有一個好玩的桌面，不過感覺這個坑太深了，就沒有進行了。
家居智能中心。我仍然對于大學學的知識有點念念不忘，雖然已經寫了一本書，但是硬件還是相當的刺激。唯一的問題是：連房子都沒有，怎么做智能家居。
圖形框架。這是我之前在做一個圖形界面的時候，發生沒有一個合適的框架可以滿足我的要求。然后我就在想，還是自己做一個吧。
不過，最好的開源項目就是自己平時用的。于是，我開始將寫各種工作來提自己使用——如現在在用的這篇微信編輯工具：mdpub。
最后，我做了一個簡單的 HTML 5 動畫來記錄這一時刻，作為這一個里程碑的記念：20k/。但愿明年的工資能趕上 star 數~
