[敲打鍵盤] 打造三太子

內容變更標示示例
從舊版刪除的內容
安插至新版的內容

-1,5 +1,5

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

打造三太子

打造三太子

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

-9,7 +9,7

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

命名

命名

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

-19,7 +19,7

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

決定基準

決定基準

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

-35,7 +35,7

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

版本管理

版本管理

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

-45,7 +45,7

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

源碼語言

源碼語言

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

-59,7 +59,7

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

源碼註解與文件

源碼註解與文件

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

-69,7 +69,7

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

訊息管道

訊息管道

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

-81,7 +81,7

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

多語

多語

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

-100,7 +100,7

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

跨平台

跨平台

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

-110,7 +110,7

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

檔案測試與釋出

檔案測試與釋出

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

-120,7 +120,7

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

外交

外交

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

-130,14 +130,14

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

結語

結語

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

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

相關連結

相關連結

jedi.org: