[敲打鍵盤] 打造三太子

2009 年 9 月，我著手三太子之後，寫了一份三太子技術細節文件，說明各種製作三太子時的相關細節。除了這份技術細節文件外，我後來又以「社群」與「專案」的觀點，重新整理相關的資訊，加以簡化後寫成這一篇稿子，並於 2009/10/11 刊登於自由軟體鑄造場電子報第 136 期。這一篇稿子現在也收錄到三太子計畫網頁內了。

打造三太子

「三太子」是一個開放專案，目的是要將 Opera 桌面瀏覽器按照台灣使用者的習慣與偏好，修改成適合台灣人使用的樣子。本文將簡要描述這項專案如何進行，提供給任何企圖發起開放源碼專案的讀者參考。

最近一個月來，我著手進行了一項（目前為止仍然只有一個人維護的）軟體專案，這項專案命名為「三太子」，目的是要把 Opera 桌面瀏覽器按照台灣使用者的習慣與偏好，加以調整。Opera 本身雖然是一套私有軟體，但是其企業文化相當鼓勵使用者社群在不修改 Opera 本身程式碼的前提下加以修改、包裝客製版本；有些客製化版本甚至有機會獲得 Opera 公司的官方支援，並成為正式釋出的版本之一。中國的「朱雀」就是這樣的例子。

像這樣的一個第三方維護專案，也可以是開放源碼專案。事實上，開放源碼社群行之多年的各種技術、慣例、文化，即使拿來跟私有軟體合作，也能夠有很好的搭配；本著拋磚引玉的精神，我決定以本文來記錄這一個月來用於「三太子」專案的各種實務要點，回饋給開放源碼界的各位。

在本文開始之前，還有一件事：日前歐萊禮出版社的新書《The Art of Community》（社群的藝術）已採用創用ＣＣ「姓名標示—非商業性—相同方式分享」3.0 授權條款釋出，並可於其網站上下載英文全文 PDF 電子檔，讀者不妨也將此書納入開放源碼社群經營的重要參考。

命名

許多開放源碼專案往往始於「我想要做某某事」的想法，由極少數人（例如祇有一個人）開始動手進行；接下來隨著專案日趨成熟，參與的人也越來越多，專案也越來越龐大、複雜。不論專案成員有多少人，當專案成為專案的那一刻，就要有個名字，或者是個代號；「名稱」在任何語言當中都有神奇的魔力，可以把一個不存在的、虛幻的、抽象的概念，轉化成一個具體存在的實體，可以讓溝通能夠集中，讓彼此知道在談論的是什麼。

命名本身是一項大學問，甚至有專門以命名謀生的行業，在此便不多論述；不過命名時有個重點，是每個參與專案的人都該牢記在心的：不管命名的背後考慮了多少細節、用了多少暗示或明示，名字就只是個名字而已，世界上沒有十全十美的名字，一定會有人對這個名字有意見⸺但是請饒了自己吧，名字取好後沒事最好不要更動，精力應該著重在專案的發展上，而不是一直繞著名字打轉。

「三太子」這樣的名字，說實話多少受到了「朱雀」的影響。中國版 Opera 叫「朱雀」，如果跟著叫「玄武」、「青龍」、「白虎」之類的顯然太過沒有創意，而且就沒辦法跟 Opera 的主題色：紅色相稱了。那如果從另一個角度來想，Opera（歌劇）到了中國變京劇（Chinese Opera），到了台灣是不是應該叫「歌仔戲」（Taiwanese Opera）呢？總覺得哪裡怪怪的。後來在跟我一個朋友的閒聊之中，冒出了「哪吒三太子」這樣的想法；哪吒三太子在台灣的民間信仰當中，是很重要的神祇，手上有各種神兵利器，而且腳踏風火輪，行動迅速，似乎可以跟 Opera 的本質巧妙呼應！再說，風火輪就是圓形的，又是紅色的嘛！所以最後就決定這個專案要叫「三太子」了。

有了中文名字後，接著還得有個英文名字，除了可以保留日後「與國際接軌」的可能性外，英文名字也適合用於檔案命名。由於「哪吒」的出處是梵文佛經當中的「Nalakuvara」音譯之略，因此「三太子」的英文名稱就決定採用「Nalakuvara」了。

決定基準

許多軟體專案在發展之初並不會先訂好完整的里程碑，或者繪製完整的藍圖（實務上來說，確實不是所有的軟體專案都可能在一開始就做好這些事）；不過就算如此，也應該在一開始就先決定好取捨的準則，讓參與開發的偕同工作者，或者是專案的使用者，都能夠明確地判斷哪些事項比較有可能會囊括在專案內，哪些則不大可能。

這項工作可以為整個專案奠定起最高指導原則，日後若有功能衝突時，或者需要排定工作項目優先順序時，都該以此最高指導原則為基準。有些專案在初期僅憑著核心成員之間的默契來行事，隨著時間過去，或者是隨著成員變動，這些「默契」就很有可能發生變化或喪失，導致專案走向不明，甚至是無法持續下去，實在是相當可惜。

盡可能地把「默契」轉化成具體的文字，讓各種決策都有明白的依據，這是任何專案健全成長的必要根基之一。

「三太子」的基準相當簡單，跟五洲製藥的理念一樣，是「先講究不傷身體，再講究效果」。因為 Opera 本身的開發理念之一就是希望能兼具簡潔與功能強大，因此這也成為「三太子」的最高指導原則⸺讓 Opera 更適合台灣使用者的同時，也一定要讓 Opera 保持簡潔、乾淨。

在這樣的前提下，「三太子」必須要盡可能地遵循 Opera 本身的設計，按照 Opera 原本的目錄架構邏輯來放置檔案，致力於維持 Opera 一貫的美感。如果可能的話，盡可能地不要添加第三方應用程式、外掛、使用者 JavaScript，這樣纔是符合 Opera 精神的「三太子」。

這樣的決定還有一個好處：理論上各平台的 Opera 的邏輯是一致的，因此在盡可能不添加額外程式的前提下，所有對 Opera 的動作理論上也會是能夠跨平台的。也就是說，遵守這樣的指導原則，可以讓「三太子」更靈活、有彈性，也能更容易地移植到不同的平台上。我們稍後就會看到這樣的實證。

可惜現實世界當中並非事事順心，有些台灣使用者極為渴望的功能，不靠外力難以達成；這種情況下，「三太子」仍盡力保持 Opera 本身的純淨，想辦法把「破壞」減到最少，並且把各種額外添加的東西都做成選項⸺如果使用者不想要，那麼這些東西就不會進來。

版本管理

就算祇有一個人的專案，也應該要使用版本管理系統，而且盡可能不要拿本機當做版本管理系統的伺服器端。

使用版本管理系統的好處實在是不遑多論了：便於管理（從基本的版本比對到複雜的版本分支及合併）、便於偕同作業、作為備份，每一項都十足重要。就算是祇有一個人、沒有分支的專案，也有可能因為一時手殘（或者是任何意外）而毀掉手中的檔案，需要回溯到先前可正常運作的版本，任何開發者這時都會對著版本管理系統發出「哈里路亞！」的讚歎聲。

版本管理系統的選用會跟專案的本質、專案成員的偏好有關。以「三太子」來說，這個專案會將專案當中的某個目錄直接打包壓縮釋出，因此會產生一堆「.svn」目錄的 svn 在此就不是那麼合適；由於我原本就一直有在使用 Perforce（兩個使用者以內免費，用來開發開放源碼專案的話也可以去申請免費授權金鑰），這套版本管理軟體在各方面表現都不錯，也沒有「.svn」的問題，因此最後「三太子」就決定採用 Perforce 來管理修訂版。

不論使用哪一種版本管理系統，最重要的是要乖乖按照正確的取出、放入流程來使用，並且要養成仔細撰寫修訂版日誌的習慣。「三太子」半個月內就產生了數百次修訂版，如果沒有修訂版日誌，根本不可能在需要的時刻找到正確的版本。

源碼語言

每一種語言都有其擅長之處，也有其不擅長之處。軟體專案應該選用能夠滿足需求的語言⸺不過值得注意之處在於，一個專案不見得就祇能使用一種語言。

在「三太子」當中，基本上是按照不同作業系統版本的 Opera 安裝方式不同，來選擇所要搭配的腳本語言。

Windows 版本的 Opera 在安裝時有較多使用者互動，而 Windows 的使用者也比較習慣圖型化使用者介面，因此就要選擇能輕易處理 GUI、能處理 UTF-8 字串、能夠處理檔案及目錄、能夠讀寫登錄、能讀寫 INI 設定檔的腳本語言，最好還要能輕易編譯成執行檔，讓使用者毋須安裝執行環境就可以使用這樣的腳本。在這樣考量之下，最後雀屏中選的是 AutoHotKey。

到了 Linux 及 FreeBSD 上，則完全不一樣了。Linux 及 FreeBSD 版本的 Opera 在安裝時沒什麼需要使用者介入的地方，而且這些作業系統的使用者往往也比較熟悉文字使用者介面，所以選用了 Shell Script 來處理。

Mac OS X 又是另一種情況。由於 Mac OS X 內建了一套叫 Automator 的腳本語言，也支援 GUI，所以屆時「三太子」若要移植到 Mac OS X 上，就會選用 Automator 來實作。

不管選用了何種語言，如果能先撰寫虛擬碼及描述程式邏輯的文件，那麼日後要是不幸得改用不同的語言來實作時，就會比較輕鬆。不過請注意：許多軟體專案隨著時間成長，軟體本身的發展往往會超出虛擬碼及程式邏輯一開始的設定範圍，這時別忘了要跟著更新相關的文件及虛擬碼，以免產生了一堆過時而無法使用的文件，在關鍵的時候反而就幫不上忙了。

源碼註解與文件

有了版本管理之後，修訂版日誌可以協助了解每一批修改的用意為何；但是修訂版日誌無論如何也無法取代源碼註解。源碼註解可以幫助明天的你還能看懂今天所寫的東西，也能幫你釐清邏輯上的瑕疵與漏洞⸺換句話說，詳細的註解其實主要還是幫自己的忙，其次才是幫其他人看懂你都在寫些什麼。

除了源碼當中的註解外，還要另外維護使用者文件跟開發者文件。使用者文件用來讓專案的使用者知道這個專案做了些什麼事、有什麼功能可以使用、有哪些東西可以調整或開關、如果出錯了可能是誰造成的；開發者文件則是讓其他有興趣參與開發的人，可以更迅速地上手，掌握整個專案的結構與步調。

雖然維護這些註解與文件所費不貲（「三太子」專案花在文件上的時間大約是三分之一到一半左右），但是卻會是物超所值的行動，因為藉由這些文件，可以讓整個專案更容易地被檢視，有瑕疵時也能更迅速地補正，因此使用者及開發者之間的關係更透明而直接，信任關係也就越強烈。「信任」正是一切社群的核心，妥善而完整的文件則是開放源碼專案累積信任的重要基礎。

「三太子」對 Opera 所做的一切處理，皆盡可能詳實地公布在網頁上，這樣不但能讓台灣使用者社群更放心地使用三太子，也能讓台灣使用者社群藉此機會更瞭解 Opera，甚至是以此為基礎，打造屬於自己的個人 Opera。

訊息管道

任何一個開放源碼專案，有了名字、進行開發、有了文件之後，更重要的是得有個便於公眾取用的入口。在網頁時代，這個入口也就是一個網頁或網站。

但是光有網站還不夠，因為這年頭網站實在太多了，開放源碼專案也如過江之鯽，九成以上的使用者對任何網站都祇會看一次⸺這些使用者可能是看到某些資訊入口網站或媒體的報導而來，但是離開之後就不會再回來。

對於健康的開放源碼專案來說，祇有一次的高度關注是沒有用的，細水長流纔是生生不息的象徵。如何能夠掌握那唯一一次的使用者來訪呢？在網站上提供源料，或者是利用 twitter 或 plurk 這類可供訂閱／跟隨的媒介，都會是不錯的作法。藉由這類管道，使用者就能源源不絕地獲得最新的更新資訊，誘使他們再度回訪。

有些開放源碼專案總是在新版本釋出的時候纔跟著撰寫釋出聲明，這對於專案發展來說幫助是有限的；正確的作法其實是盡可能頻繁地更新訊息，不論是網頁上的文件有修正，或者是專案源碼有變更，就算還沒有達成階段里程碑而不會釋出新版，也還是可以先放出風聲，一方面可以讓社群感受到專案的活躍，另一方面也能鼓舞社群回應，並避免已修正的問題重複回報。

如果每一則訊息，以及網頁上的每一段資訊，也都能有個靜態鏈結，那麼社群成員就更能把相關的訊息散佈出去，使整個專案能見度更高。

多語

任何軟體專案，祇要是會有前端使用者介面的部份，就一定要顧及多語的使用情境。這部份可以分成幾個不同的層次，循序漸進：

  1. 在不同語言的環境之中，至少要能正確地顯示同一種語言的訊息
  2. 在不同語言的環境之中，至少要能正確地處理同一種語言的輸入內容
  3. 在不同語言的環境之中，至少要能正確地處理同一種語言、不同編碼（例如 Big5 跟 UTF-8）的輸入內容
  4. 在不同語言的環境之中，能夠正確地按照語言環境變數，用不同的語言來表達相關訊息內容
  5. 在不同語言的環境之中，能夠正確地處理不同語言、不同編碼的輸入內容
  6. 在不同語言的環境當中，能夠處理不同語言及編碼的檔案名稱與路徑名稱

處理輸入內容的時候，重點在於要判斷輸入內容的原始編碼，統一轉換成 UTF-8 等通用編碼格式，再繼續做處理（正好 Opera 的設定檔都必須以 UTF-8 編碼來撰寫）。

處理訊息時，會遇到的問題則是要同時維護多種語言的版本；為了讓程式／腳本本身盡可能單純、簡化，這些訊息字串最好抽出另外處理，而不要嵌入主程式／主腳本之中。開放源碼界的 GNU gettext 是個相當成熟的國際化框架，當專案成長到某個程度時就可以予以採用，如此也便於把不同語系檔交付給不同的社群成員來負責。（當然在專案還很小的時候就率先採用 gettext 也很好，並沒有什麼不妥）

從網頁服務乃至於商業化的獨立遊戲，處處都可見到 gettext 的蹤跡，足見其成熟度。

跨平台

軟體專案要如何跨平台呢？最簡單的辦法是使用本身就跨平台的開發框架，並且避開平台特定性的元件或語言模組。很不幸地「三太子」沒有辦法這樣做。因為 Opera 在不同平台上的安裝方式、檔案放置位置都有所不同，所以正如前述一般，「三太子」在不同平台上選用了不同的實作腳本語言。不過「三太子」一開始就決定了靈活與彈性的最高指導原則，盡可能避開平台限定的元件，因此很容易就可以移植到許多不同的平台上。

實務上，「三太子」的開發也是在不同的平台上平行（但是同步）進行，這時候就得說虛擬機器實在是開發者的好朋友了。

VMware 的 VMware Server、VMware Player 及 Sun 的 VirtualBox 都是開放源碼的虛擬化解決方案，另外微軟也有一套免費（但是沒有開放源碼）的 Virtual PC，都可以讓開發者在自己的電腦上準備好多種不同作業環境，用來開發及測試。

「三太子」最先完成的平台是 Windows，並且將多語訊息抽離出來另外處理，主要的腳本保持簡潔，又撰寫了詳細的註解，很快就整理出虛擬碼；在虛擬碼的協助之下，很快地就轉寫成 Shell Script 的版本，於是 Linux 及 FreeBSD 平台很快就處理完一半了，剩下來的部份就是將檔案的換列格式調整成 UNIX 格式，並且重新分配檔案路徑，調整檔案權限，然後就可以打包收工。

檔案測試與釋出

不論做的變更有多小，檔案都應該要實際測試過再釋出，因為疏忽跟意外總是在料想不到的地方發生。前述虛擬化的做法還有一個優點，就是可以幫準備好的環境建立快照，日後就可以利用這些快照，迅速還原到用來測試的環境。包括全新的乾淨安裝，以及移除舊版後的再安裝、直接覆蓋的安裝、使用非預設路徑及設定的安裝等，通通都要測試過一遍。

在「三太子」的發展過程當中，最常出現的瑕疵是因為 Big5 衝碼導致腳本執行失敗，以及忘記更改版號，好在多半都有在測試階段發現，及時更正。

隨著專案規模擴大，要測試的流程與變數也會越來越多，如果可能的話，最好分配給社群成員來進行。不過為了要確認測試方式的一致性，應該要準備好測試說明文件，並且準備好檢核清單，方便社群成員回報。

釋出檔案時，除了應有釋出註記、版本沿革文件外，最好在檔名對不同的版本做區分，以免使用者同時下載多種不同版本產生檔名衝突。另外若是自行尋找空間放置檔案，則應該要盡可能尋找多個不同的下載空間，讓使用者能夠選擇對他們來說更為便利、迅速的下載來源。提供檔案的 MD5／SHA1 加總檢核碼是確保檔案下載完整的好方法，但是並非所有的使用者都瞭解如何運用加總檢核碼，所以釋出的檔案本身若能檢查自己的完整性，對於使用者來說將會更為便利。

外交

檔案釋出了，對於一個軟體專案來說，纔是真正的開始。當你的軟體投入廣大的使用者社群後，會面臨到許多你原本所沒有設想到的情境，也可能會激盪出更多不同的需求與想法，其中有些真的是非常珍貴的回應，但是也有一些會導致專案往奇怪的方向發展。專案一開始設立的基準此時就會是護身符了，理性、禮貌、平和地拿出專案基準，與使用者社群互動，就可以釐清八成的回應是否應該納入開發流程、應該納入哪個里程碑。

但是使用者社群並不是開放源碼專案唯一該接觸的對象。現今的軟體產業很少從上到尾靠自己就能搞定，尤其像「三太子」這樣的專案，除了接觸瀏覽器的使用者外，還有網頁及網頁服務的提供者，以及瀏覽器製造者（也就是 Opera 公司），也會與「三太子」的發展攸關。因此這些「上下游產業」也是「三太子」專案在發展過程當中，不斷聯繫的對象。

說實話，「三太子」專案的最終目標，是讓「三太子」專案可以不需要繼續下去⸺一旦 Opera 能夠針對台灣的使用者社群提供更好的預設值及功能，而網頁服務提供商也能更完善地支援 Opera，那麼「三太子」就可以下台鞠躬了。促成此事需要仰賴社群的力量，而一個目標明確、透明誠實的專案，則是凝聚社群力量的良好管道。

「三太子」專案首次釋出檔案後半個月內就有超過五千人次的下載數，並且在台灣及中國都掀起了一陣討論；目前已經有台灣的網頁服務提供商表達願意配合「三太子」專案修改產品的意願，而 Opera 的台灣辦公室、中國辦公室、挪威總部也都有相關的人員主動聯繫「三太子」專案，足見「三太子」專案至今的經營與發展方向，大致還算穩健、正確。

結語

經營一個開放專案，跟經營一個開放社群，兩者都是相當不容易的工作，更需要相當的熱誠與精力，纔有辦法保持日久彌新、穩健成長。「三太子」在這個領域當中，實在是非常年輕的一個專案；它到底會如何發展，沒有人能說得準。

身為計畫的維護者，我能確定的事情祇有一樣：秉持著開放的心胸、開放的想法，保持開放的文件與開放的源碼，讓整個專案的內容便於整個社群開放取用，那麼整個社群在此專案上所投注的每一分每一秒，就都能累積下來，成為重要的資產。即便未來這個專案因故告一段落，這些資產也還是會陪伴著整個社群，讓整個社群能以此為基礎，繼續繁衍出其他的計畫。

相關連結

jedi.org: