1. 开源核心
一年以前，因为一个项目引进了一个比较出名的开源软件，然后我们基于自己的业务对此开源软件进行审核，看是否符合我们的需求。在了解其开源架构后和简单的使用后，改造方案也确定下来：依然采用此开源软件的核心（也是业界很出名的），只是要对界面和业务进行改造。
在风风火火的一个季度里，我们基于自己的需求终于完成了产品改造。但是投入测试后却发现了致命的问题，（这个产品核心实现是依赖于硬件的）对于不同的硬件平台稳定性很差，甚至正确率都偏低。起初我们认为应该是我们引入的代码和逻辑影响了原有程序的稳定性，但是在进行仔细的代码审查和验证后排除了自身的问题，于是对原有核心进行相同条件的测试，症结找到了，是开源核心本身的问题。
这种情况下，我们的项目组遭受了严重的失败和问责，我们也总结了自身犯下的最大错误”引入开源不利，考察开源不全面“。我们几个比较推崇大胆引入开源软件的人也遭受到了反开源派的”攻击“。
2.windows自身组件---商业软件核心
此后我由于别的项目离开了此项目组，项目依然由他人进行着二次开发，去年中后期，产品成功发布，但是此后常常听见客服和市场反馈来的坏消息”不稳定“。终于在年底前一个月，公司决定对此产品下大力气整改，于是我又接手了，这时的程序核心已经换成了windows提供的组件，只是按要求调用windows的api就行，我接受的任务是审查代码和组件调用的正确性，我在阅读了大量的文档和审查代码后，实在没发现大的问题，于是只是完善了此组件的一些额外调用，增加了部分错误处理和日志输出后就很自信的转向了一个商业软件核心的api调用实现，在代码完成后。在实验室进行大规模测试后发现此核心对部分版本支持性很好，但是对部分版本支持性不好。而且又由于使用此核心需要安装此商业软件，在这种并不好的情况下公司为了规避授权问题最后放弃了此商业核心的使用。
3.再次转向windows自身组件
对于很多人来说，宁可怀疑身边的人也不会怀疑windows吧。于是公司又决定投入人力进行windows组件使用的仔细研究和对之前代码进行仔细审查。这次投入的是公司的另一个攻坚高手，我作为辅助人员进行支持。这位同事在接手项目后第一件事就是对代码进行重构（联系我前面的文章：怎样平衡c++项目的设计），然后又扩展了几处windows api的调用。然后也很自信的让产品投入测试，但是测试情况仍然不理想，于是一直修改代码，扩展调用，直到今天，我用windows自身实现的组件调用进行测试，才发现了问题”是windows自身组件支持不好“。
4.下一步，我们想走自己的路，但是还有时间吗？
看看我们走过的路
(1)在缺少大量测试和验证的情况下引入开源核心（稳定性和兼容性差），因为我们相信开源核心,你呢？
(2)在缺少大量测试和验证的情况下引入windows组件（稳定性和兼容性差），因为我们相信windows组件，你呢？
(3)在缺少大量测试和验证的情况下引入商业核心（有版本依赖），因为我们相信商业核心提供的api是天上的馅饼，你呢？