使用开源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網站原創，未經授權禁止轉載。