從「下町火箭」談開放原始碼／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 在商業策略上的利基包括：
版權還是在原作者或發起公司手上；
程式碼是開放了，但專利不是你的；
專案主導掌控權不在你手上，只有參與合作的企業有機會參與決策；
企業共利，降低獨立開發成本。
策略聯盟外的企業欲使用或修改該開源專案，可能就得支付權利金給專利擁有者，或得符合該授權中定義的「遊戲規則」，如 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 那樣一炮成名的人，還是億中選一。
務實，可能還是我們小人物的上上之策。