文章來源於，我在知乎相關話題上的回答。問題大意是：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 掛了的今天，影響了你嗎？