如何看待 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 挂了的今天,影响了你吗?

原文发布于微信公众号 - phodal(phodal-weixin)

原文发表时间:2018-10-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

MySQL分布式管理初步设计

中间件方案对于业务的使用相对是透明的,而且扩展性相对较好,这里说较好,是基于良好的架构设计,对于弹性伸缩的支持还是有限的。

982
来自专栏软件测试经验与教训

张老师聊面试

1、现在有个程序,发现在Windows上运行得很慢,怎么判别是程序存在问题还是软硬件系统存在问题?

973
来自专栏熊二哥

架构设计深入学习02-概念架构与细化架构

胜兵先胜而后求战,败兵先战而后求胜—《孙子兵法》。 这部分有些内容比较陈旧,但原理和思路还是一致的。 ? 通常来说,概念架构满足"架构=组件+交互"且只关注高...

2318
来自专栏SDNLAB

如何确保uCPE零接触部署

服务提供商正在努力用在通用客户端设备(uCPE)的标准平台上运行的软件来替换客户端设备(CPE)。他们还希望尽量减少在供应链和客户现场建立uCPE所需的步骤。在...

972
来自专栏廖念波的专栏

谈谈 KV 存储集群的设计要点

不同于无数据的逻辑层框架,KV 存储系统的架构设计会更复杂、运维工作更繁琐、运营过程中可能出现的状况更多、bug 收敛时间会更长。一句话:团队自己做一个 KV ...

2.2K0
来自专栏编程

程序员提高编程能力万无一失的办法

那就是去读别人写的代码。读那些你常用的库、编程框架的源代码,读那些你景仰的大牛的源代码,读代码里的测试(测试本身就是一种有效的文档);读代码、改代码、运行代码。...

2809
来自专栏along的开发之旅

互联网后台的奥秘 - 腾讯一大牛的分享

作者举了一个异步的例子, 是关于获取时间的. 获取时间涉及到内核调用, 内核调用涉及到用户态和内核态的上下文切换, 会比较耗时. 但是在程序中很多地方都需要获得...

1282
来自专栏魏琼东

基于DotNet构件技术的企业级敏捷软件开发平台 AgileEAS.NET - 系统架构

      本文是继AgileEAS.NET应用开发平台介绍及AgileEAS.NET之敏捷并行开发方法所做的架构补充,用于阐释AgileEAS.NET平台的架...

2025
来自专栏AI研习社

微软刚开源的这种开发语言,竟然是个 P

编者按:微软近日发布了一篇研究报告,介绍了一种为异步性、容错性和不确定性而设计的 P 语言,实现安全的异步事件驱动编程。该语言基于事件进行通信,能够很好的解决并...

3757
来自专栏个人分享

大数据理论体系总结--数据仓库管理与全链路数据体系

  就这样,大数据领域蓬勃发展了好几年,有很多伙伴执迷于技术,成为了分布式计算与存储的领域专家。也有很多伙伴执迷于数据,成为了行业的数据研发专家。当然还有很多小...

3904

扫码关注云+社区

领取腾讯云代金券