從「下町火箭」談開放原始碼/c9s

最近工作忙碌之餘,最大的樂趣就是看最近上映由阿部寬主演的日劇「下町火箭」,感覺得到日本人對於推動國產技術有極大野心及信心,甚至希望國產技術能與國際並駕齊驅;對於國外僅有的技術,也希望能夠在自己的國家做到,不受外國技術牽制,甚至是希望能夠做到世界第一。

這部日劇中的許多主題,都放在極小卻極為重要的零件上頭,譬如火箭引擎的閥門、人工心臟瓣膜等。

大家都知道日本在機器人領域、地震研究、醫學、太空科技及電子產業都是世界知名的國家。日本之所以強壯,是因為他們絕不眼高手低、不好高騖遠,且能夠專注在單一領域集中研發多年,才造就了他們今天工藝之國的稱號。

這種什麼都希望自己國家能夠做到的心態(できる),該說是閉門造車呢?還是野心?我想絕大部分是後者。

「不要重複造輪」的再思考

其實每次劇後,在我腦中不斷迴盪的是,台灣軟體界(可能更偏向 Web 界)的大環境似乎是在一種「不要重複造輪」的錯誤觀念下,譬如說「為何要寫編譯器?LLVM、GCC 不是很純熟了嗎?直接用就好了」、「為何要開發作業系統?Linux 都開放原始碼了」、「為何要自己開發網頁框架?為何不直接用 Laravel 就好?」等等。

乍看之下,或許是許多人熱烈討論新技術,有各類文章在各個平台上發佈、分享心得,但實質上並沒有新的技術發展或創新,以至於國內使用技術都是跟風國際;長期下來,可能只會使得國內軟體技術發展更為弱化。

更何況,你眼中所謂無聊的輪子,在未來,很可能會以你想不到的形式出現──在 LLVM 出現之前,恐怕很多人都是覺得 GCC 很足夠使用了吧?GIT 出現之前,恐怕很多也覺得 SVN 夠用了吧?

來自 Perl 開發經驗的啟發

筆者過去有五年左右的 Perl 開發經驗,曾三次參與在日本東京辦的「YAPC::ASIA」研討會,認識不少日本的 Perl 開發者。

在亞洲,日本是最大的 Perl 開發者國家。他們長年以來不斷嘗試各種技術上的創新與實驗,譬如:當年有一套由 Stevan Little、Dave Rolsky 等人開發的後現代物件導向系統模組(Moose),這套模組系統一出來之後,立刻受到所有開發者熱烈討論。

只可惜 Moose 運作實在太慢,於是在 YAPC::ASIA 會後的黑客松,這群日本黑客就嘗試做另外一套更快的模組系統 Mouse 來取代原版。依稀記得當晚 Tokuhiro 喝醉了,一直反覆的和我與 gugod(Kang-min Liu)說「Moose is tooooo slow」(笑)。

又譬如當年 Python 和 Ruby 等社群基於不同網頁框架,必須共用 HTTP 伺服器環境,因此各自開發了 Rack、WSGI 等規格及相容的伺服器。Miyagawa 便帶領了日本社群融合 Rack 及 WSGI 等優點開發了 PSGI ,以及該規格的實作「Plack」。

台灣的開源社群也並未落後,2008 年,Perl 5 社群已經討論 Perl 6 實作多年,但可惜開發一直沒有明朗化。來自台灣的開發者唐鳳(Audrey Tang)帶領台灣的 Perl 社群、以及各國讀箇中好手開發 Perl 6 編譯器「Pugs」;該編譯器實作後來成為 Perl 6 實作 Rakudo 編譯器的基石(詳情請見 Perl 6 十周年慶系列文章)。

複製別人的成功不是創新

可以想見,創新並不是要做很多個 Facebook、或是做很多個 Google、Dropbox 之類的「me too」商品。

創新,也不是喊喊口號。華碩喊著創新,卻做出一堆看起來像 iMac、Macbook 的商品,他們真的創新了嗎?

創新,重點在於打破既有框架、既有想像,讓事物以新的樣貌重生。 不管是多小多小的創新,都是在改變世界。

回到「下町火箭」。劇中主角因為七年前火箭發射失敗,所以為扛下失敗責任而毅然決然辭職,並開始埋頭研究「引擎閥門」這樣一個在火箭中如螞蟻般小的元件,並做到品質在業界中數一數二,最後被帝國重工找上,並且成為合作對象。

試想,如果日本的研發人員都抱著「小零件已經有人做」的觀念,為貪圖小利而放棄自行開發、甚至更進一步創新,那麼這個不是自己擁有的基礎零件專利,反而會擋住整個產業發展的未來;所有未來的研發跟創新,都會被這個基礎零件專利牽制,甚至在國際上遭到打壓。

現實生活中,有如 Oracle 身為收購昇陽 Java 的公司,對於 Google 發佈 Android 感到眼紅,於是利用該 Java byte code 專利,和 Google 打了整整兩年的專利訴訟

現實的案例

很多人想到 Open Source,就是想到免費、原始碼開放、站在巨人的肩膀上,這都沒有錯;但其實有許多 Open Source 專案是由商業利益在背後支撐,或甚至是由商業利益所驅,才有了今日的成就。譬如 Google Chrome、Apple LLVM、Qt、WebKit、Android 等知名專案均屬此類。

Open Source 在商業策略上的利基包括:

  1. 版權還是在原作者或發起公司手上;

  2. 程式碼是開放了,但專利不是你的;

  3. 專案主導掌控權不在你手上,只有參與合作的企業有機會參與決策;

  4. 企業共利,降低獨立開發成本。

策略聯盟外的企業欲使用或修改該開源專案,可能就得支付權利金給專利擁有者,或得符合該授權中定義的「遊戲規則」,如 Jim Huang(jserv)在臉書上提到的:

開放原始碼的授權議題有多重要呢?我們可以思考 Java 執行引擎的佈署議題。官方的 (有註冊商標) Java 執行引擎是由 Oracle 公司提供,其 JDK 產品的發布依據 Oracle Binary Code Distribution License 規範,事實上,並不是能夠免費下載,就能夠「免費散佈」(redistribution),請看這個案例……。

該原文《Running java on Docker, You’re breaking the law》指出:

雖然 Oracle JDK 可以免費下載、也可以自由作為商業使用,但它的使用協議在「免費散佈」方面造成了一些爭議;如果仔細閱讀 JDK 讀我檔案,會發現其中註明你只能散佈未經修改過的 JRE 與 JDK 版本,而且必須依照指示保留那些必要的檔案。

至於散戶(或貢獻者),則可能會被強迫簽訂 Contributor Agreement License 協議來放棄該貢獻之著作權,進而維護策略聯盟之利益,以及消除未來專利訴訟的威脅。

也就是說,由於更多的商業公司加入開放原始碼的行列,當初 RMS 推廣的 Free Software 自由軟體概念,如今已進一步演化成一種商業競爭策略──透過開放原始碼廣納貢獻、策略結盟、企業利益共享、並使用專利來保護自己的智慧財產權,以防策略聯盟以外的企業利用 Project forking 的方式直接競爭。

且因為門檻極高(有哪家公司能有足夠資本重新開發一整套 Android 相容的 OS?),又有來自世界上所有公司願意協助新增功能、修補程式碼,加上專案裡各種專利保護,進而形成一種以技術門檻為基礎的市場壟斷。

至於 Android 下游手機廠商,只能選擇以聯盟合作的方式來銷售 Android 手機。除了不得任意修改 Android 架構,一切修改都得由 Google 決定是否合併原碼;Android 的下游廠商如 hTC ,其實也不缺優秀工程師,但礙於架構及專利限制,產品也沒辦法做太多變化(請參閱「htc如何和amazon合作又不違反OHA協議」):

由 Google 領頭的 OHA,即 Open Handset Alliance,開放手持裝置聯盟, 其中對於成員有一個規定:不能參與製作或販售不相容於由 Google 以 Google Play 為中心所塑造的 Android 生態圈。

為了確保這個生態圈是向上發展而不是向下沈淪,所以 Google 要求 OHA 成員不能參與開發販售使用 Android 衍生版本而且不相容於這個生態圈的中心:Google Play 手持裝置。

最後,這些下游廠商販售 Android 手機的盈利,恐怕還要被 Google 抽成(未證實):

市面上那些使用已經開源的 Android 程式碼項目開發作業系統,預裝在手機裡的智慧手機公司,以及智慧手機行業的供應鏈企業等,和 Google 還有一種聯盟合作。聯盟的名字叫 OHA(Open Handset Alliance)。目前尚無資料證明這種合作是否會為 Google 帶來任何金錢利益。

擔心現有開放原始碼被競爭者知道開發方向?這些企業當然不是傻瓜,通常都會私下維運一個程式庫(Repository) ,接近正式發佈時才會推到 GitHub 上更新。由於內部修改快速、有時因運作不夠透明,大規模修改使大量計畫程式庫(PR)無法直接被合併,這也可以解釋為何多數來自社群的貢獻多會被延宕。

拿 Apple 當初使用 KHTML 瀏覽器引擎開發 Safari 的案例來說:Apple 雖表面上符合開放原始碼精神,但其實也是有心機的;他們當時不定期大量送上幾千幾百個提交項目(commit)回上游程式庫(upstream),讓上游難以進行程式碼審閱(code review)和合併(merge)。

所以,Zack Rusin 就在郵件電子報中寫道:

你知道要合併兩個完全不同的樹狀分支有多難嗎?而且其中一個還沒有任何歷史紀錄?

這就是目前 KDE 遭遇的狀況。我們為蘋果建立了一個 khtml-cvs 列表,他們有 KDE CVS 的 CVS 帳號,但我們有什麼?我們收到的是他們以發佈 WebCore 為名,間歇丟來的程式碼炸彈。

我們許多人都願意跟蘋果簽下保密協議,只是為了至少可以看到他們內部 vcs 的歷史紀錄、並且可以漸次合併融入那些變動的部份;這是現在可以做的方式,但完全沒有得到任何成果,因為他們只做 LGPL 要求的最低、最低限度。

簡言之,Apple 為了保護自己的商業利益,刻意選擇符合最少最少的 LGPL 要求,進而危害到原 KHTML 的開發。如今 KHTML 當初打下的地基,被整碗捧去變成 WebKit ,如果當初 KHTML 團隊有申請專利,那麼說不定還可以從 Apple 身上要到一筆不小的賠償金呢。

技術實權最重要

也因此,不管是在太空科技研發或是在 Open Source 領域,擁有技術實權和專利保護,恐怕比什麼都重要。

而下町火箭教我的一件事,就是創新──很多時候都是從小細節,從那些平常被看不起的輪子、閥門,一步一步改善並做到最好,而不是急著做出酷炫可炫耀的玩具。

畢竟,能像 Jobs 或 Mark 那樣一炮成名的人,還是億中選一。

務實,可能還是我們小人物的上上之策。