如何看待 GitHub 上许多笔记、面经等获得过多的 star?

Phodal phodal 今天

文章来源于,我在知乎相关话题上的回答。问题大意是:SQLite 和 SQLAlchemy 项目的 Star 比许多学习笔记、面经还要少。


作为一个 GitHub 的忠实用户,我算是了解 GitHub 世界里的一些游戏规则和现象。


Rule 1:只有你接受开源社区的规则,开源社区才会接受你


GitHub 上有一个 SQLite 源码项目,仍而并不是官方的项目。隔壁的阿猫阿狗,把别人的代码 Clone 下来,同步到 GitHub 上,居然能赚到这么多 star。

我突然有赚 1000000000000000000 个 star 的 Idea 了。

我突然有赚 1000000000000000000 个 star 的 Idea 了。

我突然有赚 1000000000000000000 个 star 的 Idea 了。

如我在 《GitHub 漫游指南》 所说:开源,并不是把项目放到 GitHub 就完了。SQLAlchemy 这个项目居然不提供一个 Issues 渠道,star 少也是必然的:

隔壁的相同功能的 Peewee 都比它多:

这个时候,我遇到问题,我去找谁?如果我提了个 Issue,作者解决了我的 issue,star 多多的。要是没有找到合适的渠道,问题解决不了,我是不是要换个库了?

Rule 2: 遇到 bug 的时候,你才会想起这个项目还有作者

开源世界有一个通用的基本规则:遇到 bug 的时候,你才会想起这个项目还有作者。ElasticSearch 有 1476 个 issues,了解一下。相比之下,它有 35k 的 star。

基本上就是“大牛” 写一个软件放在上面,提供给其它人使用, 以此来接受反馈。如果我们在这个项目使用的时候,没有遇到 bug、问题,那么我们基本不会找到项目的出处。使用 SQLAlchemy 和 SQLite 这些库的时候,它们提供的并不是源码,而是二进制包。而作为使用方,大多数时候,我只是把这个依赖添加到项目里,然后查看文档。我才不可能去打开它的 GitHub 呢,更不用说去点个 star。

Rule 3: 开发人员访问的是文档

我们使用库的时候,基本只有那么一次——把这个库的名称 + 版本加入到我们的项目中使用。OK 了,自那以后我们需求的都是文档。而且,它个告诉我们如何在项目中使用的,也是它的文档而非代码库。

除非某个项目将其文档直接放在 GitHub 上,否则我们几乎不可能再回到 GitHub 页面上了。我们只会寻找合适的文档,对于国内的众多(参差不齐)开发人员来说,中文文档才是最欢迎的那个。

Rule 4:你所在领域并非全世界

GitHub 流行的时候,正好是前端崛起的时候。所以,现今 GitHub 最流行的语言是 JavaScript。哪怕是使用 JavaScript + Node.js 开发后端应用,选的也会是 MongoDB,而非 SQLite。

用 SQLite 和 Python 写后台服务的应用,本身并不多。

Rule 5:对用户有用的才是受欢迎

我在 GitHub 上有近 40000 的 star,其中有:22416 个 star (6248 + 3585 + 3115 + 1985 + 1778 + 1557 + 1470 + 771 + 644 + 548 + 434 + 326)是电子书相关的——主要来自我博客文章的合集 + 自己相关笔记的整理。

但是要知道我在 GitHub 上还有两百多个项目……。我最好的项目 Growth 也就只是 2263 个 star,前三都不上。要知道 Growth 的用户,可是近 10 万。

Rule 6: Git 是最好的版本管理工具,GitHub 是可能最好的 Git 服务器之一

如,在我的第二本《全栈应用开发:精益实践》里,其早期开源版 growth-ebook ,最初是作为开源应用 Growth 的一部分存在的。慢慢的,它独立出来,以开源的方式运行着,接受别人的 PR 和反馈。而随着阅读的人数变多,它的 star 也就慢慢的上去。

文档是代码的一部分。它需要不断的更新,而使用 Git 来管理,真的是再合适不过了。这些内容也可以放在博客上,但是它真的不如在 GitHub 上修改来得方便。


GitHub 挂了的今天,影响了你吗