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

文章来源于，我在知乎相关话题上的回答。问题大意是：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 挂了的今天，影响了你吗？