本周末，阿里集团会在中南大学做校招。我作为校友，被邀请面向应届毕业生做一次技术分享。我想谈谈开源的问题。
由于技术分享的时间很短，我想在现场不太可能展开谈。所以在 blog 上先写一篇相关的子话题：在选择使用开源项目时，我的依据是什么？
我们在开发软件的过程中，总有一些模块的需求是普遍的，除了自己开发，使用一个具备合适的 License 的开源项目也是个不错的选择。
在一个程序员的职业生涯中，总会有那么一个阶段，不太愿意使用别人开发的代码。如果不是受项目进度压力所迫，宁愿自己实现。这并非是因为相信自己总能做得更好，而是希望少受牵制，能够自由发挥。而且，写代码往往比理解代码更简单。整合多块不同团队开发的代码也更难保证项目各个部分的一致性。
如果渡过了这个阶段，不那么执着于自己造轮子，选哪一个轮子必然会接受自己挑剔的眼光。毕竟，按捺了自己实现的冲动，要选也要选个合适的。
从我的角度，首先，我会选择的开源项目首先要是一个活跃的项目，有完整的更新历史。
软件代码，它们不是由一行行代码行构成的，而是在时间轴上，由一次次增删修改构成的。一个时间点上的快照无法帮助我理解软件，更不要谈融入到自己的系统中；任何一个问题，只要有人在关注，它就必然会随着时间演化。真正的用户是软件项目最宝贵的财富。一个几年不再更新的项目，就成了一个死项目（失去了所有的用户）。我们不应该把死项目融入到正在开发中的活项目中。
如果一个项目曾经很活跃，现在已经死了，那说明它的前一任用户已经离开。如果还是想继续用的话，要确认自己有没有精力让它活过来。即使是一个活的项目，你也很可能是除了原作者团队意外同时期唯一的外部用户。新的用户意味着新的需求和新的 bug 。自己必须有能力解决新产生的问题。
其次，要看项目的主导者是否善于沟通。
大部分开源项目都有一个灵魂人物，通常是项目的发起人。他可以脾气不太好，但要能做到讲道理，可以沟通；这个读一下项目的 issues 和 pull request 就能感受的到。如果是一个比较新的项目，还没有很多用户，那么也可以看看同一个人名下的其它项目。试用一段时间，发现 bug ，提几个单，会有更直观的感受。
任何一个基础功能，只要用户够多，需求肯定是千变万化。项目的这个灵魂人物起着分析和调解这些需求的作用。是他的沟通能力，而不是编码能力，决定了项目的演进方向。
最后，再来看一个开源项目专门程度。我个人倾向于解决单一问题的项目，能少做一点事情就少一点。不太希望使用包罗万象的大东西。这会方便我们组装，做取舍。而且一旦用过一段时间后发现不合适，也能回退回去，选择别的方案。
至于项目质量和代码质量，我觉得是个见仁见智的东西，没有什么固定的标准。我可以忍受没有注释、命名不规范、缩进不统一，没有测试案例的代码。接口不断的修改，bug 层出不穷通常也不是什么大问题。因为当选择了和一个开源项目共进退，就意味着不断的跟进，参与进去，一起把它改进的更好。大不了以后再换成另一个类似的模块，或者自己重写。
选择开源项目其实就是选择了和维护项目的人们合作。人才是最重要的因素：应选择 勤奋、开明、专注 的合作伙伴。
ps. 吐槽一下一些国内的所谓开源项目。做了一些声势浩大的宣传之后，扔出了某一个版本的代码快照，然后几年也不更新。最后几次提交，以及合并的 pr ，都是一些无关紧要的 typo 。开源还真不是这样玩的。