写在 GitHub 的第 19999 个 star 时——开源的路还很长

605 阅读5分钟

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 已经有了过万的用户,每天活跃的用户数也接近 300 了。第一步看上去很成功,但是下一步怎么走呢?

下一个开源项目

后来我开始在思索一个问题,创建一个开源框架是必须的吗?


在编写 Growth 电子书的时候,我发现一个好的软件工程实践远远比一个易上手的框架重要多了。框架本身是易变的东西,过去你在用 Backbone,现在你在用 React.js;过去你在用 Angular.js,现在你在用 Vue。会不会使用某个框架,并不是区分你是不是一个有经验的开发者的标准。

一直将焦点关注于学习不同的框架的使用是有问题的,一个在校生可以轻松地比你了解某个框架的原理——你白天在工作,而他整天在学习。这时你很容易就失去竞争力了,你需要从框架之外了解更深层次的东西。一个好的框架并不能让你写出一段好的代码

如果中国人的思想不觉悟,即使治好了他们的病,也只是做毫无意义。

这算是我为自己在 GitHub 下的 Markdown 的自辩吧——谁让我一直有写作的冲动呢。


不过我仍然还有一些想法,只是还没有抽出足够的时间去思考这样的事。

GNU/Linux 的桌面。这是几年前的一个想法了,当时 GNU/Linux 的那些操作系统上都没有一个好玩的桌面,不过感觉这个坑太深了,就没有进行了。

家居智能中心。我仍然对于大学学的知识有点念念不忘,虽然已经写了一本书,但是硬件还是相当的刺激。唯一的问题是:连房子都没有,怎么做智能家居。

图形框架。这是我之前在做一个图形界面的时候,发生没有一个合适的框架可以满足我的要求。然后我就在想,还是自己做一个吧。

不过,最好的开源项目就是自己平时用的。于是,我开始将写各种工作来提自己使用——如现在在用的这篇微信编辑工具:mdpub

最后,我做了一个简单的 HTML 5 动画来记录这一时刻,作为这一个里程碑的记念:

phodal.github.io/20k/

下期更精彩~~


相关文章:

GitHub连击500天:让理想的编程成为习惯

我的GitHub PR故事,以及我向往的开源

如何用Github去管理你的Idea

点击“阅读原文”观看