Open AlexiaChen opened 4 years ago
相似开源方案比较多，新项目总是对外宣称技术更先进更优秀。如果面对这样的情况，请首先关注该开源项目是否满足当前业务，不要过于关注开源项目是否优秀。
显然，无论多牛逼的程序员写出来的项目都会有bug，千万不要以为作者厉害就没有bug，不成熟的开源项目用到生产环境，风险极大。成熟的开源项目一般都是有数年的积淀的。个人经验，要成熟，至少3年起步。
版本号：不要选择0.x的版本号，至少选1.x版本，理论上来说，版本号越高越好，但是也不一定是，版本号高，会有新添加的功能，可能也会同时引入新bug。现在都推崇版本语义化，建议了解下，进行选择。相同功能不变的情况下，建议选择，fix以后的最新版本。
开源项目的用户数量：一般开源项目都会把采用了自己项目的公司写在主页上，公司越大越好，数量越多越好
社区活跃度： github上的star数量，issue数量以及回复处理速度，PR数量，commit数量以及频率等都是活跃度的度量指标
大部分小公司的“架构师”在选择开源项目时，基本都是关注技术指标，以及上面提到的两个维度，很少几乎不会关注运维方面的能力，可能小公司没有专门的运维团队吧，程序员自己就是开发+运维。然而，用户量也不大，反正昆明这边很少。
这里说下用户量稍大点的公司的情况，如果将技术选型方案应用到线上环境，则运维能力是必不可少的一环，否则一旦出问题，运维，开发，测试全部都傻了，根本无从下手。
开源项目日志是否齐全： 有的开源项目日志不详细，寥寥数行，出了问题根本没法查。
开源项目周边生态如何？是否有配套或者第三方的命令行，Web控制台等监控维护工具，能够看到系统运行时？尽量选择周边生态繁荣的开源项目。
开源项目是否好使？门槛和学习成本高不高？配置项是否复杂？
是否有故障检测和恢复能力？
不能完全“拿来主义”，看了几个Demo，或者编写了几个Demo就把开源项目拿到自己的项目中部署上线是不可行的。要仔细研究和测试。
对线上环境要抱有敬畏，这是无数IT行业的人的血与泪的教训。无关前期的调研测试多么完美，都不可能覆盖线上所有情况。经验就是，把开源项目先用在非核心业务上，有经验后慢慢扩展，农村包围城市。
一个业务量庞大的公司，如果采用开源项目，根据墨菲定律，很可能一下子就大概率碰上一个之前全世界使用者从来没遇到的致命bug，如果是核心业务就是致命打击，阿里这么大的体量，很可能里面每天都有人会遇到少见的难题或bug。所以要考虑清楚，如果这个项目真出问题了，用什么办法应急，这个是必须考虑的。
这个公司发展到一定体量都会基于开源项目做二次开发，或者魔改核心源码的，因为开源项目不一定满足公司需求，我知道的阿里数据库组就对InnoDB做了不少魔改。要达到魔改阶段，首先要从使用上用好开源项目，对开源项目有足够的熟悉和了解之后，才开始魔改，这时候一般团队的水平都需要高一点了，当然，意味着达到这个阶段，公司想必还是有钱上规模了。
魔改也是有方法论的，你不能上来就改核心源码。
尽量不改核心本身，而是开发周边辅助系统，比如开发一个中间件。MySQL的大量开源中间件就是这么来的，改数据库不太现实。
有句话其实是这么说的：是不鼓励重复发明轮子，而不是不鼓励重复造轮子。有能力造轮子的公司当然是好的，前提是你找不到现有并且合适你的轮子，这个就没办法了，只能自己造。
国内你能看到大部分的国产开源项目，这些公司一般都到达了魔改，或者造轮子阶段，当然这些轮子你去看源码，其实也不是完全从0开始，也参考或者间接使用依赖了不少开源项目。比如，国内有几个小尺寸文件系统貌似参考了FaceBook的Haystack。这方面可能需要你查不少高质量的资料和论文，因为没有现有成熟轮子。
如何选择一个开源项目
选型阶段
关注是否满足业务
相似开源方案比较多，新项目总是对外宣称技术更先进更优秀。如果面对这样的情况，请首先关注该开源项目是否满足当前业务，不要过于关注开源项目是否优秀。
关注是否成熟
显然，无论多牛逼的程序员写出来的项目都会有bug，千万不要以为作者厉害就没有bug，不成熟的开源项目用到生产环境，风险极大。成熟的开源项目一般都是有数年的积淀的。个人经验，要成熟，至少3年起步。
版本号：不要选择0.x的版本号，至少选1.x版本，理论上来说，版本号越高越好，但是也不一定是，版本号高，会有新添加的功能，可能也会同时引入新bug。现在都推崇版本语义化，建议了解下，进行选择。相同功能不变的情况下，建议选择，fix以后的最新版本。
开源项目的用户数量：一般开源项目都会把采用了自己项目的公司写在主页上，公司越大越好，数量越多越好
社区活跃度： github上的star数量，issue数量以及回复处理速度，PR数量，commit数量以及频率等都是活跃度的度量指标
关注运维能力
大部分小公司的“架构师”在选择开源项目时，基本都是关注技术指标，以及上面提到的两个维度，很少几乎不会关注运维方面的能力，可能小公司没有专门的运维团队吧，程序员自己就是开发+运维。然而，用户量也不大，反正昆明这边很少。
这里说下用户量稍大点的公司的情况，如果将技术选型方案应用到线上环境，则运维能力是必不可少的一环，否则一旦出问题，运维，开发，测试全部都傻了，根本无从下手。
开源项目日志是否齐全： 有的开源项目日志不详细，寥寥数行，出了问题根本没法查。
开源项目周边生态如何？是否有配套或者第三方的命令行，Web控制台等监控维护工具，能够看到系统运行时？尽量选择周边生态繁荣的开源项目。
开源项目是否好使？门槛和学习成本高不高？配置项是否复杂？
是否有故障检测和恢复能力？
使用阶段
深入调研和测试
不能完全“拿来主义”，看了几个Demo，或者编写了几个Demo就把开源项目拿到自己的项目中部署上线是不可行的。要仔细研究和测试。
还是要小心点
对线上环境要抱有敬畏，这是无数IT行业的人的血与泪的教训。无关前期的调研测试多么完美，都不可能覆盖线上所有情况。经验就是，把开源项目先用在非核心业务上，有经验后慢慢扩展，农村包围城市。
最终还是要有应急方案
一个业务量庞大的公司，如果采用开源项目，根据墨菲定律，很可能一下子就大概率碰上一个之前全世界使用者从来没遇到的致命bug，如果是核心业务就是致命打击，阿里这么大的体量，很可能里面每天都有人会遇到少见的难题或bug。所以要考虑清楚，如果这个项目真出问题了，用什么办法应急，这个是必须考虑的。
魔改造轮子阶段
这个公司发展到一定体量都会基于开源项目做二次开发，或者魔改核心源码的，因为开源项目不一定满足公司需求，我知道的阿里数据库组就对InnoDB做了不少魔改。要达到魔改阶段，首先要从使用上用好开源项目，对开源项目有足够的熟悉和了解之后，才开始魔改，这时候一般团队的水平都需要高一点了，当然，意味着达到这个阶段，公司想必还是有钱上规模了。
魔改也是有方法论的，你不能上来就改核心源码。
尽量不改核心本身，而是开发周边辅助系统，比如开发一个中间件。MySQL的大量开源中间件就是这么来的，改数据库不太现实。
有句话其实是这么说的：是不鼓励重复发明轮子，而不是不鼓励重复造轮子。有能力造轮子的公司当然是好的，前提是你找不到现有并且合适你的轮子，这个就没办法了，只能自己造。
国内你能看到大部分的国产开源项目，这些公司一般都到达了魔改，或者造轮子阶段，当然这些轮子你去看源码，其实也不是完全从0开始，也参考或者间接使用依赖了不少开源项目。比如，国内有几个小尺寸文件系统貌似参考了FaceBook的Haystack。这方面可能需要你查不少高质量的资料和论文，因为没有现有成熟轮子。