Android：最成功的Linux發行版正面臨兩敗俱傷的結果
關于Android項目和內核主分支開發社區的關系，已經談論得夠多了。在LinuxCon大會日本站，詹姆斯·博頓利（譯者注：James Bottomley，Linux SCSI子系統的維護者）又深入探討了這個問題。他說，從Android和內核主分支分道揚鑣這件事上，我們可以吸取一些有趣的教訓。如果內核開發社區能關注到Android在干什么，那么我們以后處理這些問題可能會更得心應手。
詹姆斯首先給Android下了個定義，很簡單，它是有史以來最成功的Linux發行版。它的市場占有率是其他桌面和服務器發行版所望塵莫及的。Android的成功很驚人，但總結起來歸結于：
- 自立門戶，和官方內核走不同的路
- 重寫了工具鏈和C庫
- 開發了一套自己的Java應用框架，并且
- 極度不喜歡GPL
詹姆斯說，換句話說，Android為“如何跟開源社區對著干”樹立了榜樣 。我們讓他們別做的事情，他們都做了，并且做得很好。我們一直想讓Android開發人員回到正道上來時，但他們的成功似乎證明了，需要改變的，不只是他們。也許內核開發社區也應該重新評估，我們在代碼質量和市場成功兩者之間到底如何權衡取舍。他問道，我們是否需要一套更面向商業的制度？
這場討論的一個重大假設是，自立門戶是一件壞事。Android一開始就自己單搞了一套內核，然后另起爐灶開發了自己的用戶空間代碼。內核社區適時地譴責了這種做法。但我們還是有必要去理解當時Android開發人員想干什么。他們一開始先要找到想采用Android的人，然后才會真正動手去實現這個系統。這個時候，時間壓力就會很大。他們需要盡快搞定。對于內核社區走查和接受補丁代碼的流程，有很多話可以說，但這個流程確實還有可以改進的地方。谷歌顯然等不到他們的補丁被接受，因他們要發布Android，所以除了單干以外別無選擇。
自立門戶有錯嗎？詹姆斯說，從某種意義上來說，沒錯：畢竟GPL保障了這種權利。因為自己搞自己的，有時候還是有必要的，所以這種權利必須被保證。沒有實踐機會的權利是毫無意義的。在這個事情上，如果Android跟著官方內核走，那他們很難在短時間內達到商用目標（指的是電源管理和其他一些東西）。如果那樣，結果將會是Android延遲發布，它獲得市場成功的可能性就小了，甚至完全錯過市場的檔期，成為一個失敗的產品。所以，自立門戶有時候是好事，能使開發團隊更快地做出產品，而你要走內核社區的審核流程，就慢了。
自立門戶就意味著分裂嗎？他問道。這是一個很重要的問題。分裂扼殺了90年代的UNIX市場。詹姆斯聲稱，如果自立門戶失敗了，它就消亡了，不會導致分裂。自立門戶后，又把開發出來的代碼合并回原來的項目，那也不會產生分裂，他們會帶著他們的代碼和開發人員回歸到最初的項目中。只有這樣的自立門戶是有害的：他們取得了一些成功，部分的社區力量轉而成為他們的擁躉，這些人再也不會回到原來的項目中。此時，開發社區要幫助這些自立門戶的人把他們的代碼合并回原來的項目，這顯得非常重要。
Android開發人員，不止是自立門戶，而且抱這樣一種態度：GPL對商用是有害無益的。Android起初的計劃是完全不使用GPL授權的代碼，他們準備寫一個新的內核。但后來很多原因迫使他們采用了Linux內核，還有其他一些GPL授權的組件。詹姆斯說，所以我們應該感謝安迪·魯賓（譯者注：Android之父）——對GPL的憎恨就來自他——他向世人展示了采用GPL授權代碼的手機也能獲得市場的成功。看起來下游廠商根本不關心他們設備里面運行的代碼的授權許可證是什么，只要這個許可證清晰并能遵守就行了。
Anroid特殊的應用框架如何？詹姆斯說，基于Java的應用框架是Android最創新的部分之一。它抽象了平臺的細節，使應用層盡量遠離內核。這個框架限制了應用程序能使用的API，對應用進行了更多的控制。鑒于這個系統的結構，重寫C庫似乎是完全沒必要的。框架層之上的應用不可能直接使用它。
所以，Android不是什么都錯，但確實有一些錯誤。從詹姆斯的觀點來看，最大的錯誤就是它的日歷程序不支持SyncML（譯者注：一種平臺無關的信息同步標準協議集，可以在不同手機間同步數據）。這使得Android手機對于商務用戶來說沒什么用。黑莓（Blackberry）成功的關鍵之一就是它的日歷做得非常好。摩托羅拉（Motorola）就意識到了這個問題，并且為他們的Droid手機自主開發了支持SyncML的應用。但這使事情變得更糟，因為這會使用戶誤以為Android手機都支持SyncML。當他們拿到一臺非Droid的手機時，他們會很失望，并且最終去買一部iPhone。Android直到2.1才支持SyncML，是完全從頭去實現的。這個錯誤的代價就是一年內沒什么公司愿意用Android。
當然，Android的另一個問題是開發門檻。Android看起來是個開源項目，但是谷歌完全掌握著基線版本的控制權。沒人能看到代碼，直到谷歌把代碼放出來為止。沒有任何合作伙伴貢獻的修改，所以根本沒什么開發社區，沒什么共享制度可言。舉個例子，如果Android愿意接受外部幫助的話，它原本可以更快地解決它的日歷問題。谷歌對Android的完全控制是為了更好地專注于市場。如果想統治市場，這是必要的先決條件，但對于內核開發社區來說，這不是好事，這也使谷歌被迫去做“重復發明輪子”的事情。
還有一個錯誤，正在被甲骨文（Oracle）起訴。這個案子的起因是Android重寫了Java，并且接下來和GPL唱反調。如果Android是建立在甲骨文的GPL授權的Java之上的話，就不會有這樁訴訟了，而谷歌也會受到GPL的默示專利許可（implied patent license）的保護。如果甲骨文贏了，那么為繞開許可證而重寫Java將是一次非常昂貴的嘗試。更可悲的是，許可證其實是無關緊要的，因為Java運行環境把上層應用隔開了，上層應用無需遵守GPL。
教訓
從中我們可以學到什么教訓？詹姆斯重申了自立門戶可以變成一件好事，只要開發成果能夠回歸。盡管做了很多努力，Android內核的開發成果沒有回歸到官方內核。而且我們也不清楚內核社區提出的方案時，Android開發人員有沒有參與其中。他說，也許我們應該使合并代碼變得更簡單。內核社區應該找到更好的辦法來處理這個流程。目前的流程很容易卡在代碼走查這個環節，尤其是當代碼量很大的時候。
自立門戶的項目也需要思考他們的流程。自立門戶容易產生“非我發明”的心態（譯者注：not-invented-here，指拒絕使用非自己創造的技術），導致他們不愿意公示自己的開發成果。因為發布代碼去找罵，誰也不愿意。自立門戶時間越長，情況就越糟，因為改正基本的設計錯誤（內核社區的觀點：wakelocks機制就是一個錯誤）會更難。為防止這種錯誤發生，需要這些項目變得更包容，經常發布他們的代碼，并向內核社區咨詢意見——即使他們不打算采納。打破壁壘，使思想能夠相互交流，這很重要。
詹姆斯又談了一點關于“許可證恐懼”，他指出GPL就是我們的懼、惑、疑（譯者注：即FUD，Fear，Uncertainty，Doubt，這是一個專用名詞，指向客戶灌輸其他競爭公司產品的負面觀念）。內核社區對許可證的討論，看起來很嚇人。他們對這個問題也需要降降溫。對GPL的恐懼往往是受外部利益驅使，但我們也在盡可能使他們能受益。內核社區應該主動出擊，幫助大家消除這種恐懼。比如，可以幫助Android看看能不能換用GPL授權的代碼。Linux基金會曾經做過一些工作，但詹姆斯認為內核社區應該提供幫助。他說，其實相較于大多數商業許可證協議，遵守GPL更容易。這一點我們必須要澄清。
在遵守GPL的問題上，我們必須澄清一些界線。比如，用戶空間的代碼，不算是起源于內核（譯者注：這樣就不需要遵守GPL）。明白了這些界線，可以幫助大家消除對GPL的恐懼。
內核社區應該更好地培養和擁抱多樣化，鼓勵別人單干（這可能帶來重大的進步）并幫助他們回歸。詹姆斯說，在這個問題上，內核社區只能說是勉強及格，還有很大改進空間。我們接受的代碼，只來自于和我們有一樣價值觀的人。這造成的結果就是，把Android內核合并回來的難度越來越大。
公司如果想掌握項目的控制權，應該以贊成或反對的方式，而不是獨自占有項目的所有權。李納斯·托瓦茲（譯者注：Linus Torvalds，Linux創始人）是一個很好的例子，他有很大的控制權，但這只是因為內核社區相信他能做出正確的判斷。也就是說，社區如果信任你，那么他們很高興交出大量控制權。這就是為什么“善良的獨裁者”模式能大行其道。另一方面，如果公司通過拒人門外的手段來昭示它的控制權，或者逼貢獻代碼者交出版權，這必然會與開源社區交惡。
詹姆斯說，總之，對于所有牽涉其中的人來說，Android是一個兩敗俱傷的結果。我們所有人都必須好好想想，如何才能做得更好。我們需要找到更好的辦法來鼓勵和管理自立門戶的項目，并消除對許可證的恐懼。自立門戶的項目也應該想著要合并回去。這樣，項目（比如Android）既能取得商業成功，也能在社區中取得成功。
原文地址：http://select.yeeyan.org/view/234039/204194
【編輯推薦】
