个人想法：
（一）不应当做的事
1. 不应当把开源代码直接包装成产品。
2. 不应当把开源代码做些修改后包装成产品。
因为这样做的话，团队成员可能难以消化开源代码，从而导致遇到故障时摸不着头脑。
为什么难以消化，因为不是自己写的代码。
另外，开源代码的演进不受自己控制，可能一个版本一个大变样。
假设设备商在2.0版本的某个函数f1中加了点代码，等3.0版本出来时，发现3.0版本代码变化巨大，代码中根本没有f1这个函数了。
f1的功能，被拆散到若干个其他函数中去了。这样的话，商备商的版本跟踪维护人员将面临巨大痛苦。
开发团队又要重新花精力，去重新熟悉新版本的代码。
痛苦的是，每次开源社区推出新版本，设备商的人可能都要面临一次痛苦。
（二）应当做的事
可以参考开源软件的某个版本（例如，1.0版本），代码搞明白了，组织人力从零开始编码，完全自己实现。按照自己团队的传统风格，写代码。
不要怕麻烦，不要怕代码多。其实代码并不多。一般开源软件，可能也就几百个文件。而开发团队如果有20个人，一年下来，一人写10个源文件，几百个文件也就出来了。
等到自己编码的第一个版本做完了，接下来好戏就来了。对于开源代码的后续版本，团队可以不用再看他的代码了，看看他的release notes就行了。主要是看看release notes中描述的他这个新版本，实现了哪些需求。把这些需求理解一下，搞清楚搞明白，然后自己编码实现就可以了。
这样一来，团队自己才算掌控了代码，面对故障不会心里没有底了。调试函数，统计，日志，都用得得心应手。面对客户提出的需求，心里也很有底气了。
（三）可以做的事
自己实现过程中，可以参考开源软件的某些代码。例如，领域规范性质的数据结构定义。就像TCP头、IP头等结构体的定义一样。可以拷过来直接用。
另外，某些纯粹功能计算性的函数，也可以拷过来直接使用。个别不太有把握的地方，也可以研读一下开源代码，参考一下开源的实现。
但这些做法，都不碍事。因为不用再为开源代码的变化而烦恼了，他的变化不再是团队的负担。
原文地址：http://blog.csdn.net/crazycoder8848/article/details/43679179
