开源项目吐槽大会：那些让开发者又爱又恨的"开源瑰宝"
开场
开源世界是个奇妙的江湖。有人在这里封神，有人在这里头秃。我们每天白嫖别人的代码，嘴上说着"开源改变世界"，心里骂着"这什么鬼东西"。
今天，吐槽大会正式开始。
第一轮：README，薛定谔的文档
你发现了一个看起来很完美的开源项目。Star数破万，简介写得天花乱坠。你满怀期待地点开README，看到了一行字：
“文档正在完善中…”
四个字，杀伤力拉满。
更离谱的是另一种：README写了五千字，从项目愿景讲到拯救人类，但你翻遍全文都找不到安装命令。最后在某个issue的角落里，某个用户回复了五个字母：npm i。
还有一种README，它确实有安装教程，但写的是：
gitclone xxxcdxxx# 然后你应该知道怎么做不，我不知道。我如果知道，就不会来看你的README了。
好的文档像好老师，你甚至感觉不到它的存在。差的文档像前任，你永远猜不到它想表达什么。
第二轮：依赖地狱，套娃的艺术
你只是想用一个日期格式化的库，装上之后发现它依赖了47个包。其中一个包的作用是"判断当前环境是不是浏览器"，代码只有一行：
typeofwindow!=='undefined'但这一行代码，自己又是一个独立的npm包，还拥有自己的GitHub仓库、README、测试文件和CHANGELOG。
开源精神，体现在每一行代码都要有自己的独立包。
更经典的是left-pad事件。一个11行代码的包，被作者从npm删除后，半个互联网的构建瞬间全挂。那一刻我们才意识到，现代软件工程的根基，建立在别人的11行代码上。
你引以为豪的微服务架构，底层可能就靠一个周末写着玩的脚本撑着。
第三轮：版本号，语义化版本的终极背叛
语义化版本（SemVer）的承诺很美好：major版本才破坏兼容，minor是新增功能，patch是bug修复。
现实呢？
你在package.json里写的是^1.2.3，某天构建突然挂了。你查了半天，发现作者在1.2.4版本里"修复了一个bug"，修复方式是把函数的参数顺序换了。
在他的理解里，这是bug修复。在你的理解里，这是生产事故。
最可怕的是那种版本号直接从0.4.2跳到1.0.0的项目。你以为1.0意味着稳定成熟，点进去一看，作者只是觉得0.4这个数字不好看。
还有那些永远停留在0.x版本的项目。几年了，Star好几万，版本号还是0.3.7。作者的意思很明确：这东西我自己都没信心，你们用就用了，出事别找我。
第四轮：Issue，修了等于没修
你花了两小时写了一个详细的bug report。复现步骤、环境信息、错误日志、最小可复现示例，一应俱全。
三天后，维护者回复了：
“Could you provide a minimal reproduction?”
你看着自己issue里那个醒目的CodeSandbox链接，陷入了沉思。
还有一种经典回复：
“Works on my machine.”
这句话在开源世界的地位，约等于"臣妾做不到啊"。
更有趣的是那些被关闭的issue。维护者关issue的速度比闪电还快，理由是"invalid"或"wontfix"。你打开closed列表一看，关闭的比open的还多。这个项目不是在解决问题，是在消灭提出问题的人。
第五轮：Star通货膨胀
GitHub的Star正在经历严重的通货膨胀。
一个项目只要有好看的README封面图、一个动图demo、再加一个"为什么选择XXX"的对比表格，就能收获几千Star。代码质量如何？谁在乎呢，README好看就行了。
更离谱的是那些"awesome-xxx"仓库。一个README文件，里面全是链接，Star数比它收录的那些真正的开源项目还多。
开源世界里最风光的往往不是写代码的人，是写清单的人。
第六轮：License，法外狂徒的快乐
每个项目都有LICENSE文件，但90%的开发者从没认真读过。
你用了MIT协议的代码，没问题，宽松到几乎可以为所欲为。你用了GPL协议的代码，如果你的项目是闭源的，恭喜你，你已经在法律边缘疯狂试探了。
最搞笑的是那种没有License的项目。严格来说，没有License意味着作者保留所有权利，你不能复制、修改、分发。但大家默认"放出来就是让用的"。
开源世界的法律意识，全靠默契。
第七轮：贡献者，一个标点符号的战争
你发现了一个项目，文档里有个明显的错别字。你热心地提交了一个PR，改了一个字符。
维护者三天后review了你的PR，留了一条评论：
“Can you also fix the same typo in the Chinese translation file?”
你打开那个文件，发现中文版里根本没有这个单词。
一个月后，你的PR被合并了。你的GitHub头像旁边多了一个数字。这就是你作为开源贡献者的全部荣誉。
但你不知道的是，有些人的开源贡献就是专门提"fix typo"的PR。他们不看代码，只看README里的错别字。靠这个，他们的贡献图谱绿得发亮。
第八轮：维护者，用爱发电的圣人
说了这么多吐槽，最后得说句公道话。
开源项目的维护者，是这个行业里最被低估的人。他们用自己的业余时间，维护着全世界开发者的基础设施，收到的回报通常是：
- 几个Star
- 无数个"这个bug什么时候修"的issue
- 偶尔一个赞助，可能是5美元/月
- 无尽的PR review
有个维护者维护了一个被几百万个项目依赖的库，每月收到的赞助加起来不够付网费。他发了一篇博客说"我不想干了"，评论区全在骂他不负责任。
免费的东西用久了，就会觉得理所应当。这才是开源世界最大的问题。
第九轮：重新发明轮子
开源世界有个永恒的定律：每隔三个月，就有人觉得自己能写出更好的框架。
于是我们有了：
- 100个状态管理库
- 200个HTTP请求库
- 300个日期处理库
- 无数个"比XX快10倍"的轮子
每个新轮子的README都写着"比XXX更轻量、更快速、更简单"。三个月后，这个轮子自己也变成了一个需要被替代的"XXX"。
技术选型就像在超市选牙膏，摆了50种，功能都差不多，你最后选了包装最好看的那个。
结语
吐槽归吐槽，开源依然是软件行业最美好的东西之一。
我们骂的每一个问题，都是因为我们离不开它。那些文档不全的项目、依赖爆炸的库、突然断更的仓库，恰恰证明了开源生态的繁荣和不可替代。
没有开源，就没有今天的软件行业。这句话不需要加"但是"。
但下次如果再看到一个README写着"文档正在完善中"的项目，我还是会骂一句。
然后乖乖地去提一个PR。
本文纯属吐槽，如有雷同，说明你也被害过。
计算与可视化：从原理到实战)
