Neng-Yu 'Tony' Tu
前幾個禮拜, 參加了資策會 OSS (經濟部工業局自由軟體產業應用推動計畫) http://www.oss.org.tw/ 主辦的 FreedomHEC2009 (http://www.oss.org.tw/dokuwiki/doku.php?id=freedomhec2009) . 今年在 Android 與 Moblin 的市場光環加持下, 加上工作人員也很努力的拉國外 key developer 來演講, 現場人數大概比去年多了一倍 (完全感覺不出來產業不景氣...哈哈).
Greg Kroah-Hartman 跟其他主要幾位主講人, 其實講授的內容都很實在, 對 kernel developer 來說, 有很多有用的 tips, 例如這篇 kernel report:
http://www.oss.org.tw/dokuwiki/lib/exe/fetch.php?media=kreport.pdf
提到以最近的 release 30 來說, 每天 kernel 平均增加 6500 行 131 個 changes, 這個數字看起來對一班人來說只是數字而已, 但是對很多公司的開發人員來說, 一直 trace 最新的 kernel 其實是有負擔的. 就台灣開發硬體產品的 cycle 來說, 大約開發一個全新的產品平均需要 6-8 個月, 以新 linux kernel release 週期為 15 週來看, 這一段時間 kernel 起碼已經跳了 1 到 2 個版本.
換句話說, 即使產品一開始如果就使用最新 vanilla kernel, 到出貨時, 先為了符合 GPL 而開放原始碼, 然後更有心一點再作相關 driver/patch upstream 的工作, 但為了適應新的 kernel 變更, developer 也還是需要額外的工作時間去適應新版本. 如果有公司想要像 beagle board (http://elinux.org/BeagleBoard) 一樣, 能夠讓產品直接 make omap3_beagle_defconfig 就可以透過 toolchain 編出 kernel 其實是需要時間了解 upstream 的模式. 主要包含:
* porting 前先註冊硬體資訊 (mach id..etc)
* 加入討論區, 適應 Linux community 的 coding/討論習慣
* 你要送 code 到哪邊 upstream (這顆 AP (Samsung/TI/Freescale) 的 maintainer 是誰, review 流程大概是怎麼樣)
這些都要實際 "加入" community (社群), 才能了解更多的細節. 這邊又卡到兩點 1. 開發人員本身的意願及英文能力 2. 製作產品的 RD 資源投入的時間是否應該在產品出貨後結束.
我在網路上找到一篇還不錯介紹 arm linux porting white paper 的放在這裡, 有興趣的可以參考一下. http://www.t0ny.net/foss/doc/porting/PortingLinuxKernel.pdf
因為 OEM/ODM 特性做習慣的關係, 不需要面對終端客戶, 在台灣典型的都把產品出貨當成是產品投入 RD 資源週期的結束. 但這一點, 對 community 來說, 產品到手 (hacking) 才是軟體應用可能性階段的開始, 是不太一樣的. Community base 公司的產品 (buglabs/beagleboard or LEGO like!!!), 等於把第一個產品當成是產品線的頭, 再慢慢展開看 community 需要哪些產品, 再逐漸充實產品的內容, 軟體可能增加支援的 platform (Android/Linux/Windows CE...) or 硬體 (更多的模組). 雖然這類的應用模式, 早就存在於常需要客製化的工業電腦產業中, 但是包括 Openmoko 在內, 蠻多的 (or 一部分) 趨勢都是朝著將原先客製化的模式, 帶到標準消費性產品中. 當然, 以目前這幾年的景氣 (2009-), 跟這些公司目前的狀況來看, 整個 biz model 都還在試水溫的階段, 但是最起碼提供一個產品開發的有趣方向.
一般只是拿 linux 當成是免費的 OS + 一堆好用的 utility 的一般硬體廠商而言, 是完全 or 至少一部分誤解了開放硬體的精神. 大部分廠商都停留在擔心自己的產品有違反 了 GPL 規定. 而不是利用 community 來開拓可能的市場, 及需要開放硬體專案的合作機會.
另一個矛盾就是, linux kernel "community" 只會一直 maintain 最新 2-3 個 kernel 版本, 與個例子來說, kernel.org 是不會一直幫 2.6.18 上 patch, 而是只會 maintain 目前 (2009.06) 最新的 2.6.28-30, 然後以極快的速度 (跟 MS 系統比較) 繼續往新的 release 前進. 這也是與業界的一般方式, fork 一份 2.6.24/26 的 kernel 下來, 然後自己 maintain 自己的 tree 的一般開發 (非 community) 方式有很大不同. 一般完全 fork 然後 maintain 自己藏起來的 tree 方式最大的問題就是公司最後只有少數 RD 能 maintain/patch 整個 tree, 所以公司的產品能力跟擴充方向, 也會直接或間接會受到這些 keyman 的限制. Maintain 一個 distribution 其實就是一件 "事", 如果又有其他的工作 overlap, 自己 maintain distribution 只好挖東牆補西牆, result 跟 quality 都不會太好.
當然在兩天的研討會過程中, 也反映出許多業界使用 Linux 開發, 跟融入 Linux 社群中的矛盾點, 主要的就是 release 原始碼 (源代碼) 的問題. 又想要 community 幫忙解決, 或是快速接受自己的硬體, 另一方面又不想或非常被動的 release source code. 當然 release source 有許多的問題, OM 都遇過. 包括產品中有相關 chipset 廠商的 NDA 問題. 不過這並不是無解, 或者說, 在產品開發選料前就要跟廠商談好, 不是產品要出了才進行 community friendly 工作.
在 OM 專案中, 最好的例子就是 wi-fi driver source code, 因為 FOSS community 不喜歡 binary 的 driver, Atheros 當時又是以非常 community friendly 的方式 release wi-fi 的驅動程式原始碼 (align with mainline source), 所以就溝通協調專案內容後 (我們使用的 AR6k fw 版本是 2.x), 就請 Atheros 新 release 一份對應的 GPL driver 給 OM. 當然除了 GPL 版本外, Atheros 還有另一份只能 release binary 版的 driver, 這也是 chipset vendor 經營開放軟體 community 常見的手法.
總而言之, 如果希望 Open Source Community 支援你想要接近 community 的產品, 我個人的建議是:
* 提交硬體 community 開發時, 底線是開放 kernel 部分的 source code, 最簡單的 release 方式打成 tar ball, 或文明一點放在公開 git/svn 上.
* 想辦法幫 community 或是對你的硬體有興趣的人, 解決他們的問題 (提供 documentation/跟 vendor 談 release 文件)
* 了解跟 community 成員的溝通方式
* 讓 key community member 盡早拿到硬體 (每間公司的策酪及考量不一樣, 但這的確是目前國際大廠 (you name it!!!) 為了接近 FOSS community 都在做的事), 但是不能期望這些 community key member 能提供有用的 feedback.
當然, 以上純就有興趣建立品牌或是接觸社群開發的專案. 若只是 OEM/ODM, 只要 spec 跟 term 清楚, 問題很單純, 大部分的公司, 都不缺乏這類的經驗.
很高興能在這類大拜拜場合 :) 遇到像是 matt_hsu 及 jserv, 以及目前在 0xlab 的 前 OM 優秀 developer (FOSS or not FOSS...haha). Real FOSS will be a life long way ;)
Greg Kroah-Hartman 跟其他主要幾位主講人, 其實講授的內容都很實在, 對 kernel developer 來說, 有很多有用的 tips, 例如這篇 kernel report:
http://www.oss.org.tw/dokuwiki/lib/exe/fetch.php?media=kreport.pdf
提到以最近的 release 30 來說, 每天 kernel 平均增加 6500 行 131 個 changes, 這個數字看起來對一班人來說只是數字而已, 但是對很多公司的開發人員來說, 一直 trace 最新的 kernel 其實是有負擔的. 就台灣開發硬體產品的 cycle 來說, 大約開發一個全新的產品平均需要 6-8 個月, 以新 linux kernel release 週期為 15 週來看, 這一段時間 kernel 起碼已經跳了 1 到 2 個版本.
換句話說, 即使產品一開始如果就使用最新 vanilla kernel, 到出貨時, 先為了符合 GPL 而開放原始碼, 然後更有心一點再作相關 driver/patch upstream 的工作, 但為了適應新的 kernel 變更, developer 也還是需要額外的工作時間去適應新版本. 如果有公司想要像 beagle board (http://elinux.org/BeagleBoard) 一樣, 能夠讓產品直接 make omap3_beagle_defconfig 就可以透過 toolchain 編出 kernel 其實是需要時間了解 upstream 的模式. 主要包含:
* porting 前先註冊硬體資訊 (mach id..etc)
* 加入討論區, 適應 Linux community 的 coding/討論習慣
* 你要送 code 到哪邊 upstream (這顆 AP (Samsung/TI/Freescale) 的 maintainer 是誰, review 流程大概是怎麼樣)
這些都要實際 "加入" community (社群), 才能了解更多的細節. 這邊又卡到兩點 1. 開發人員本身的意願及英文能力 2. 製作產品的 RD 資源投入的時間是否應該在產品出貨後結束.
我在網路上找到一篇還不錯介紹 arm linux porting white paper 的放在這裡, 有興趣的可以參考一下. http://www.t0ny.net/foss/doc/porting/PortingLinuxKernel.pdf
因為 OEM/ODM 特性做習慣的關係, 不需要面對終端客戶, 在台灣典型的都把產品出貨當成是產品投入 RD 資源週期的結束. 但這一點, 對 community 來說, 產品到手 (hacking) 才是軟體應用可能性階段的開始, 是不太一樣的. Community base 公司的產品 (buglabs/beagleboard or LEGO like!!!), 等於把第一個產品當成是產品線的頭, 再慢慢展開看 community 需要哪些產品, 再逐漸充實產品的內容, 軟體可能增加支援的 platform (Android/Linux/Windows CE...) or 硬體 (更多的模組). 雖然這類的應用模式, 早就存在於常需要客製化的工業電腦產業中, 但是包括 Openmoko 在內, 蠻多的 (or 一部分) 趨勢都是朝著將原先客製化的模式, 帶到標準消費性產品中. 當然, 以目前這幾年的景氣 (2009-), 跟這些公司目前的狀況來看, 整個 biz model 都還在試水溫的階段, 但是最起碼提供一個產品開發的有趣方向.
一般只是拿 linux 當成是免費的 OS + 一堆好用的 utility 的一般硬體廠商而言, 是完全 or 至少一部分誤解了開放硬體的精神. 大部分廠商都停留在擔心自己的產品有違反 了 GPL 規定. 而不是利用 community 來開拓可能的市場, 及需要開放硬體專案的合作機會.
另一個矛盾就是, linux kernel "community" 只會一直 maintain 最新 2-3 個 kernel 版本, 與個例子來說, kernel.org 是不會一直幫 2.6.18 上 patch, 而是只會 maintain 目前 (2009.06) 最新的 2.6.28-30, 然後以極快的速度 (跟 MS 系統比較) 繼續往新的 release 前進. 這也是與業界的一般方式, fork 一份 2.6.24/26 的 kernel 下來, 然後自己 maintain 自己的 tree 的一般開發 (非 community) 方式有很大不同. 一般完全 fork 然後 maintain 自己藏起來的 tree 方式最大的問題就是公司最後只有少數 RD 能 maintain/patch 整個 tree, 所以公司的產品能力跟擴充方向, 也會直接或間接會受到這些 keyman 的限制. Maintain 一個 distribution 其實就是一件 "事", 如果又有其他的工作 overlap, 自己 maintain distribution 只好挖東牆補西牆, result 跟 quality 都不會太好.
當然在兩天的研討會過程中, 也反映出許多業界使用 Linux 開發, 跟融入 Linux 社群中的矛盾點, 主要的就是 release 原始碼 (源代碼) 的問題. 又想要 community 幫忙解決, 或是快速接受自己的硬體, 另一方面又不想或非常被動的 release source code. 當然 release source 有許多的問題, OM 都遇過. 包括產品中有相關 chipset 廠商的 NDA 問題. 不過這並不是無解, 或者說, 在產品開發選料前就要跟廠商談好, 不是產品要出了才進行 community friendly 工作.
在 OM 專案中, 最好的例子就是 wi-fi driver source code, 因為 FOSS community 不喜歡 binary 的 driver, Atheros 當時又是以非常 community friendly 的方式 release wi-fi 的驅動程式原始碼 (align with mainline source), 所以就溝通協調專案內容後 (我們使用的 AR6k fw 版本是 2.x), 就請 Atheros 新 release 一份對應的 GPL driver 給 OM. 當然除了 GPL 版本外, Atheros 還有另一份只能 release binary 版的 driver, 這也是 chipset vendor 經營開放軟體 community 常見的手法.
總而言之, 如果希望 Open Source Community 支援你想要接近 community 的產品, 我個人的建議是:
* 提交硬體 community 開發時, 底線是開放 kernel 部分的 source code, 最簡單的 release 方式打成 tar ball, 或文明一點放在公開 git/svn 上.
* 想辦法幫 community 或是對你的硬體有興趣的人, 解決他們的問題 (提供 documentation/跟 vendor 談 release 文件)
* 了解跟 community 成員的溝通方式
* 讓 key community member 盡早拿到硬體 (每間公司的策酪及考量不一樣, 但這的確是目前國際大廠 (you name it!!!) 為了接近 FOSS community 都在做的事), 但是不能期望這些 community key member 能提供有用的 feedback.
當然, 以上純就有興趣建立品牌或是接觸社群開發的專案. 若只是 OEM/ODM, 只要 spec 跟 term 清楚, 問題很單純, 大部分的公司, 都不缺乏這類的經驗.
很高興能在這類大拜拜場合 :) 遇到像是 matt_hsu 及 jserv, 以及目前在 0xlab 的 前 OM 優秀 developer (FOSS or not FOSS...haha). Real FOSS will be a life long way ;)
View Neng-Yu 'Tony' Tu's profile
發表文章
沒有留言:
張貼留言