GitHub 里程碑
写在 GitHub 的第 19999 个 Star 时
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 动画来记录这一时刻，作为这一个里程碑的记念：