最近工作忙碌之餘，最大的樂趣就是看最近上映由阿部寬主演的日劇 “下町火箭”，感覺得到日本人對於推動國產技術有極大野心及信心，甚至希望國產技術能與國際並駕齊驅，對於國外僅有的技術，也希望能夠在自己的國家做到，不受外國技術牽制，甚至是希望能夠做到世界第一。
這部日劇中許多主題，都放在極小卻極為重要的零件上頭，譬如火箭引擎的閥門、人工心臟瓣膜等。
大家都知道日本在機器人領域、地震研究、醫學、太空科技及電子產業都是世界知名的國家。日本之所以強壯，是因為他們絕不眼高手低、不好高騖遠，且能夠專注在單一領域集中研發多年，才造就了他們今天工藝之國的稱號。
這種什麼都希望自己國家能夠做到的心態 (できる)，該說是閉門造車呢？還是野心？我想絕大部分是後者。
其實每次劇後，在我腦中不斷迴盪的是，台灣軟體界 (可能更偏向 Web 界) 的大環境，在一種 “不要重複造輪” 的錯誤觀念下，譬如說：「為何要寫編譯器？ LLVM, GCC 不是很純熟了嗎？直接用就好了」「為何要開發作業系統？Linux 都開放原始碼了」「為何要自己開發網頁框架？為何不直接用 Laravel, Rails, Symfony 就好？」等等。
乍看之下，或許是許多人熱烈討論新技術，有各類文章在各個平台上發佈、分享心得，但實質上其實無新的技術發展或創新，以至於國內使用技術都是跟風國際，長期下來，可能只會使得國內軟體技術發展更為弱化。
更何況，你眼中所謂無聊的輪子，在未來，很可能會以你想不到的形式出現 — 在 LLVM 出現之前，恐怕很多人都是覺得 GCC 很足夠使用了吧？GIT 出現之前，恐怕很多也覺得 SVN 夠用了吧？
日本 Perl 社群的新創精神
筆者過去曾有六年左右的 Perl 開發經驗，曾參與三次在日本東京辦的 YAPC::ASIA 研討會，認識不少日本的 Perl 開發者。
在亞洲，日本是最大的 Perl 開發者國家。 他們長年以來，不斷嘗試在技術上做各種創新與實驗，譬如：
當年有一套 Stevan Little, Dave Rolsky 等人開發的後現代物件導向系統模組 (Moose) ，這套模組系統一出來之後，立刻受到所有開發者熱烈討論。
只可惜 Moose 運作實在太慢，於是在 YAPC::ASIA 會後的黑客松，這群日本黑客就嘗試做另外一套更快的模組系統 Mouse，來取代 Moose。依稀記得 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 社群以及各國箇中好手開發 Perl6 編譯器 Pugs ，該編譯器實作後來成為 Perl 6 實作 Rakudo 編譯器的基石。 (詳情請見 Perl 6 十周年慶系列文章)
在 GIT 分散式版本控制系統被廣泛使用之前，國內知名的 Perl 開發者高嘉良 clkao (也就是現在帶領 g0v.tw 的大家長)，也使用 Perl 程式語言，基於 SVN 製作了一整套相容於 SVN 的分散式版本控制系統 — SVK，在當年可是國內外知名的版本控制系統，後來被 Best Practical Solutions 公司收購。
可以想見，創新，不是要做很多個 Facebook ，或做很多個 Google, Dropbox 之類的 me too 商品。
創新，也不是喊喊口號。華碩喊著創新，卻做出一堆看起來像 iMac, Macbook 的商品，他們真的創新了嗎？
創新，重點在於打破既有框架、既有想像，讓事物以新的樣貌重生。 不管是多小多小的創新，都是在改變世界。
技術力，從小做起
劇中主角，因七年前火箭發射失敗，為扛下失敗之責，毅然決然辭職，並開始埋頭研究引擎閥門這樣一個在火箭中如螞蟻般小的元件，並做到品質在業界中數一數二，最後被帝國重工找上，並一同合作。
試想，如果日本的研發人員，都抱著 “小零件已經有人做” 為貪圖小利而放棄自行開發甚至更進一步創新，那麼這個不是被自己擁有的基礎零件的專利，反而是會擋著整個產業發展的未來，所有未來的研發跟創新，都會被這個基礎零件專利牽制，甚至在國際上被打壓。
現實生活中，有如 Oracle 身為收購昇陽 Java 的公司，眼見 Google 發佈 Android 眼紅，於是利用該 Java byte code 專利，和 Google 打了整整兩年的專利訴訟。
開源專案的商業策略聯盟
很多人想到 Open Source ，就是想到免費、原始碼開放、站在巨人的肩膀上，這都沒有錯。 但其實有許多 Open Source Project 是由商業利益在背後支撐，或甚至是由商業利益所驅，才有今日成就。 譬如說 Google Chrome, Apple LLVM, Qt, WebKit, Android 等知名專案。
Open Source 在商業策略上的利基在於:
- 版權還是在原作者或發起公司手上
- 程式碼是開放了，但專利不是你的
- 專案主導掌控權不在你手上，只有參與合作的企業有機會參與決策
- 企業共利，降低獨立開發成本
策略聯盟外的企業欲使用或修改該開源專案，可能就得支付權利金給專利擁有者，或得符合該授權中定義的 “遊戲規則”，如 Jim Huang (jserv) 在臉書上提到的:
開放原始碼的授權議題有多重要呢？我們可以思考 Java 執行引擎的佈署議題。官方的 (有註冊商標) Java 執行引擎是由 Oracle 公司提供，其 JDK 產品的發布依據 Oracle Binary Code Distribution License 規範，事實上，並不是能夠免費下載，就能夠「免費散佈」(redistribution)，請看這個案例:
http://www.oschina.net/news/71417/running-java-on-docker-youre-breaking-the-law
該原文 Running java on Docker, You’re breaking the law 指出:
While Oracle JDK is free to download and free for commercial use, the agreement raises a question when it comes to redistribution. A deeper dive into the JDK readme file indicates that you can only distribute unmodified versions of the JRE and JDK, as long as you follow the instructions of keeping the required files.
也就是，雖然 Oracle JDK 是免費下載給商業使用，但 JDK 的讀我檔案指出，你只可以散佈尚未修改過的 JDK 及 JRE。
至於散戶 (或貢獻者) ，可能會被強迫簽訂 Contributor Agreement License 放棄該貢獻之著作權，進而維護策略聯盟之利益，以及消除未來專利訴訟的威脅。
也就是說，由於更多的商業公司加入開放原始碼的行列，當初 RMS 推廣的 Free Software 自由軟體概念，如今已進一步演化成一種商業競爭策略 — 通過開放原始碼廣納貢獻、策略結盟、企業利益共享並使用專利來保護自己的智慧財產權，以防策略聯盟以外的企業利用 Project forking 的方式直接競爭。
(註: Free Software 提倡的 GPL, LGPL 等授權條款，對延伸性軟體限制較多，因而較不商業友善。 GPL-3.0 甚至增設了專利條款，限制延伸性軟體禁止向後手聲明專利侵權。這邊指的「演化後」並不是指 Free Software 本身，而是為了開源而衍伸出更商業友善的 “Open Source” ，兩者並不全然相同，”Open Source” license 如 MIT License, BSD License, Apache License 等是更為商業友善，限制相對也較少，也因此有更多人選擇以這樣的授權開源，而非採用 GPL 或 LGPL，相對的，自然不是以前那樣 “自由” 的世界了。)
且因為門檻極高 (有哪家公司能有足夠資本重新開發一整套 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 雖表面上符合開放原始碼精神，但其實也是有心機的，他們當時不定期 squash 幾千幾百個 commit 送回 upstream，讓上游難以 code review, merge ，如 Zack Rusin 就在 mailing list 中寫道:
Do you have any idea how hard it is to be merging between two totally different trees when one of them doesn’t have any history?
That’s the situation KDE is in. We created the khtml-cvs list for Apple, they got CVS accounts for KDE CVS. What did we get? We get periodical code bombs in the form of them releasing WebCore.
Many of us wanted to even sign NDA’s with Apple to at least get access to the history of their internal vcs and be able to be merging the changes incrementally, the way they can right now. Nothing came out of it. They do the very, very minimum required by LGPL.
簡而言之，Apple 為了保護自己的商業利益，刻意選擇符合最少最少的 LGPL 要求，進而危害到原 KHTML 的開發，如今 KHTML 當初打下的地基，被整碗捧去變成 WebKit ，如果當初 KHTML 團隊有申請專利，那麼說不定還可以從 Apple 身上要到一筆不小的賠償金呢。
也因此，不管是在太空科技研發或是在 Open Source 領域，擁有技術實權和專利保護，恐怕比什麼都重要。
結語
下町火箭教我的一件事，是創新 — 很多時候都是從小細節，從那些平常被看不起的輪子、閥門，一步一步改善並做到最好，而不是急著做出酷炫拿來炫耀的玩具。
畢竟，能像 Jobs 或 Mark 那樣一炮成名的人，還是億中選一。
務實，可能還是我們小人物的上上之策。
