选：如何选择一个开源项目？
聚焦是否满足业务？
聚焦是否成熟？
可以从以下几个方面考察是否成熟：
1）版本号：一般建议除非特殊情况，否则不要选0.X版本的，至少选1.X版本的，版本号越高越好。
2）使用的公司数量：一般开源项目都会把采用了自己项目的公司列在主页上，公司越大越好，数量越多越好
3）社区活跃度：看看社区是否活跃，发帖数、回复数、问题处理速度等
聚焦运维能力？
可以从以下几个方案去考察运维能力：
1）开源方案日志是否齐全：有的开源方案日志只有寥寥启动停止几行，出了问题根本无法排查
2）开源方案是否有命令行、管理控制台等维护工具，能够看到系统运行时的情况
3）开源方案是否有故障检测和恢复的能力，例如告警、倒换等
案例2：很多团队最初使用MySQL的时候，也没有怎么研究过，经常有业务部门抱怨MySQL太慢了，其实经过定位，发现最关键的几个参数（例如innodb_buffer_pool_size, sync_binlog，innodb_log_file_size等）都没有配置或者配置错误，性能当然会慢。
用：如何使用开源方案？
深入研究，仔细测试
可以从如下几方面进行研究和测试：
1）通读开源项目的设计文档或者白皮书，了解其设计原理
2）核对每个配置项的作用和影响，识别出关键配置项
3）进行多种场景的性能测试
4）进行压力测试，连续跑几天，观察cpu、内存、磁盘io等指标波动
5）进行故障测试：kill，断电、拔网线、重启100次以上、倒换等
小心应用，灰度发布
假如我们做了上面的“深入研究、仔细测试”，发现没什么问题，是否就可以放心大胆的应用到线上了呢？别高兴太早，即使你的研究再深入，测试再仔细，也还是要小心为妙，因为再怎么深入的研究，再怎么仔细的测试，都只能降低风险，但不可能完全覆盖所有线上场景。
但是，不管研究多深入、测试多仔细、自信心多爆棚，时刻对线上要有敬畏之心，小心驶的万年船。我们的经验就是先在非核心的业务上用，然后有经验后慢慢扩展。
做好应急，以防万一
虽然因为一次故障就完全反对尝试是有点反应过度了，但确实故障也给我们提了一个醒：对于重要的业务或者数据，使用开源项目时，最好有另外一个比较成熟的方案做备份，尤其是数据存储。例如：如果要用MongoDB或者Redis，可以用MySQL做备份存储。这样做虽然复杂度和成本高一些，但关键时刻能够救命！
改：如何基于开源项目做二次开发？
保持纯洁，加以包装
我们的建议是不要改动原系统，而是要开发辅助系统: 监控，报警，负载均衡，管理等。以Redis为例，如果我们想增加集群功能，不要去改动Redis本身的实现，而是增加一个proxy层来实现，Twitter的Twemproxy就是这样做的，而Redis到了3.0后本身提供了集群功能，原有的方案简单切换到Redis 3.0即可。详细可参考(http://www.cnblogs.com/gomysql/p/4413922.html )
如果实在想改到原有系统，怎么办呢？我们的建议是直接给开源项目提需求或者bug，但弊端就是响应比较缓慢，这个就要看业务紧急程度了，如果实在太急那就只能自己改了，不过不是太急，建议做好备份或者应急手段即可。
发明你要的轮子
如果你有钱有人有时间，投入人力去重复发明完美符合自己业务特点的轮子也是很好的选择！毕竟，土豪们（BAT、Facebook、Google......等）很多都是这样做的，否则我们也就没有那么多好用的开源项目了 ：）