使用开源IP的具体工程方法
Girish Managoli MindTree高级技术经理
摘要： 在嵌入式产品开发领域，随着产品上市时间不断缩短，质量要求不断提高，开发人员面临更大挑战。开源方法被视为能够同时满足更快开发周期和更高质量这两个目标的最佳解决方案，许多OEM和产品设计公司采用开源方案。
关键词：
软件
Abstract：
Key words :
在嵌入式产品开发领域，随着产品上市时间不断缩短，质量要求不断提高，开发人员面临更大挑战。开源方法被视为能够同时满足更快开发周期和更高质量这两个目标的最佳解决方案，许多OEM和产品设计公司采用开源方案。
事实上，还有许多公司发现很难克服FUD(即恐惧、不确定性和疑虑)心理，这导致他们无法果断决策采用开源方案开发产品。
在产品开发过程中，一边是工程设计人员，即开发工程师、架构师和工程设计经理，他们了解开源及其优势，但是没有决策的权力；另一边是管理层和法律部门，他们可以作出决策，但却可能没有足够的背景信息。我们如何弥合这一差距呢？工程设计团队怎样才能说服管理层大胆使用开源方案呢？本文将阐述在产品工程设计阶段使用开源方案时需要考虑的一些关键因素和指导方针。
1. 选择正确的开源组件。
可供下载和使用的开源组件非常多，如何确定适合自己的产品？
除纯技术因素(编程语言、接口、内存和负载要求、组件在你的特定平台/操作系统上的可移植性/可用性)之外，还有一些其它因素要考虑：
A.成熟度。需要回答的问题包括：1)组件若用于商业产品中是否足够成熟？2)是否有其它知名的产品使用此组件？如果此组件被广泛使用，那么其开发者和维护者可能会通过链接包装网站上的推荐和成功案例。(我们可以用这些问题作为忠告，但是需要自行验证！)
留意旧版本、发行时间表、更改日志、已确定的流程(每日构建、文档补丁提交流程等)和支持机制是了解组件历史和成熟度的较好途径。
B．许可授权。以下是两个重要的考虑因素：1)组件许可证是否提供明确的记录——特别是在组件的网站上；2)你需要怎样对许可证进行分析(我们将在本文的后面详细说明如何进行此操作)。
C.支持。这里需要注意以下三点：1)是否提供文档 (可以是wikis、doxygen生成的文档格式)，如提供文档，则会简化开发人员/集成人员的工作；2)非官方文档。即使不提供官方文档，也可能有其他的热心用户提供几个非官方版本。在网上搜索可以找到这些隐藏的珍贵资源；3)活跃的社区、论坛和邮件发送清单，这些都将对集成支持和检测到的错误的修复大有帮助。
2. 分析许可证。
一旦我们决定要使用某个组件，下一步工作就是分析此组件的许可证，以确定此组件是否适合我们的方案。组件的网站一般会提到适用于此组件的许可证。
此外，强烈建议下载最新版本的组件，并检查嵌入的LICENSE/README文件。这两个文件有时可能有不同之处，对此最好得到组件开发人员和维护人员的说明。
完整的许可证条款和条件通常采用法律措辞。从工程设计的角度来看，我们只需要了解：
1) 许可证的名称或类型
2) 此组件是否能以我想要的方式(构建在一起、链接、服务或者实用程序)与其它组件(开源或闭源)配合使用？
3) 我们是否应该在任何地方都声明我们正在使用这种开源软件？
4) 源代码重新分配有哪些规则？
3.建立专家社区。
正确独立地评估一个组件的功能，以及许可证影响可能比较困难，此时社区就能派上用场。几个志同道合的工程师和架构师可以在组织内部自发成立一个非正式的社区。此社区可以共同评估质量、分析许可证、解答询问和解决问题。此外，在说服决策者方面，社区往往比个人更有说服力。社区还可以做以下事情：
1) 成为与开源相关的任何问题的关键人物；
2) 建立一个讨论开源问题、传播开源意识和鼓励资深工程师有效地使用开源的平台；
3) 建立关于常见许可授权问题的FAQ；
4) 推进创建常用开源组件的随时可用的软件包，以供组件内部使用。
随着时间的推移，专家社区被确认为组织管理和决策主体的机会就会越来越大。
4. 配合管理层和法律部门工作以达到正式使用的目的。
现在到了最后一步——说服管理层接受我们的选择。我们利用到目前为止收集的所有数据、事实和图表进行充分证明。每一个开源组件都必须提供以下内容：
1) 应用程序许可证
2) 影响/作用
3) 在其它产品中的已知应用
4) “专家社区”的推荐
5) 已下载和使用的组件的实际版本的链接
如果有任何分歧、缺少的信息或不明确的条款，请突出显示出来。我们在实际操作时，可将所有的信息放在一个易于理解的演示文档或者电子表格中。
法律部分则有更多的工作要做：应有的审慎性评阅、核实开源组件是否名副其实、检查是否有任何“不利因素”、检查版权所有权和与版权所有人可能的业务冲突以及所有的法律文书工作(若产品开发工作被分散/外包的话)。
市场上使用开源的产品很多。基于Linux的无线路由器就是一个商业上可行的开源产品的很好例子。缺少认识、对未知的某种恐惧和“不值得冒险”的态度让产品公司对开源避而远之。技术人员逐步而坚定地将开源引进传统产品开发过程，还有很多工作可以做。开源不仅适合产品开发模式，而且能让整个流程更顺畅更快捷。当然，它带来的经济效应也不错。
此内容为AET网站原创，未经授权禁止转载。