[敲打鍵盤] 打造三太子

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

打造三太子

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

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

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

在本文開始之前,還有一件事:日前歐萊禮出版社的新書《The Art of Community》(社群的藝術)已採用創用CC「姓名標示—非商業性—相同方式分享」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: