這本書為什麼會拖這麼久，背後有個不多人知道的故事：原來的日文版《でかいプレゼン 高橋メソッドの本》的著作權是兩個人共同持有的：作者高橋征義，以及他的編輯；而台灣這邊的出版社與日本 SoftBank Creative 談翻譯授權的時候，著作權持有人之一（那位編輯）卻已經過世了，所以就要展開遺囑清查，看看是他的哪一位家人繼承了相關的權利，再去談授權。再加上日本人做事異常謹慎的風格，光是台灣的出版社競價談判就過了一個多月，到最後簽妥翻譯授權合約已經過了將近半年。

另外，日本人的各種權利是切得很細的，PCuSER 這本書祇有買了文字的翻譯權利，沒有買插圖的使用權利，所以這本中譯版就我所知（我現在還沒拿到書），插圖的部份是全部重新製作，書籍的開數（也就是尺寸啦）也與日文版不同，有興趣的讀者不妨注意一下。

Tenz 為這本中譯本寫了推薦序，以下我也提供我寫的譯者序。

譯者序

簡報是一項有趣的技藝，多年來隨著軟硬體技術進展，衍生出眾多門派；就跟武功流派一樣，不同門派的簡報術會使用不同的兵器、有各自的必殺技與罩門，專業的講者必須練熟各種門派套路，才能見招拆招，把訊息傳遞給聽眾。

Perl 開發者社群當中「最受歡迎的講者」陶敏修於 2004 年來台，講述他最膾炙人口的題目：「研討會簡報柔道」，強調「傳達」的重要性，說明時間掌握、節奏、重點分配等內外功精要心法；另一位風采十足的講者 Ingy，則是每年都在研發新的簡報系統。2005 年初，知名簡報專家 Garr Reynolds 開設了專門探討簡報技術的部落格《Presentation Zen》，提出四種他認為最具影響力、效果最卓越的簡報典範：前微軟總裁 Bill Gates 使用的「蓋茲流」，特色是大量的條列與圖表，這也是許多人對簡報的第一印象；蘋果執行長 Steve Jobs 使用的「賈伯斯流」注重個人魅力，使用簡潔的圖文，搭配預先準備好的操作演出；Creative Commons 創辦人 Lawrence Lessig 使用的「萊席格流」運用影音及再三重現的文字，以說書的形式傳遞概念；日本 Ruby 協會會長高橋征義使用的「高橋流」則是完全靠文字跟語感取勝，也是四種簡報風格當中最容易做準備的。

2006 年在一場研討會上，吾友 gugod 以高橋流做了一場簡報，這可能是台灣第一次實際採用高橋流的簡報，讓聽眾初次感受到高橋流帶來的震撼。高橋流開始風行起來，一方面是因為它真的很簡單、上手迅速，另一方面則是因為它的本質相當單純，很容易隨著不同講者的人格特質、場合環境、目標聽眾而加以調整、衍生。高橋先生曾在 2007 年及 2008 年來台參加研討會，親自展現高橋流簡報，更是把這股風氣帶上高峰。

筆者自九零年代就展開了簡報生涯，數種簡報風格均有長時間深入使用，2006 年起投向高橋流的懷抱──短至三分鐘的快閃談話，長至連續兩天（共 12 小時）的教育訓練，均成功地運用了高橋流；甚至在取得醫學相關學位的論文口試上，也用了高橋流，突破原本高橋先生所擔心高橋流未必適用較長簡報或正式學術場合的限制。

為了將高橋流融會貫通，筆者花了幾天的時間觀看《新世紀福音戰士》系列動畫，嘗試上百種字型與色彩搭配，改良簡報工具，並參加台灣知名網頁設計社群「快樂設計師」以高橋流為主題所舉辦的工作坊；在這個工作坊中，參與的設計師們分別以紙筆、小畫家、HyperCard、PowerPoint、Keynote、Firefox、Flash 等包羅萬象的工具，不到一小時內當場完成高橋流簡報，體現高橋流易學、易用、靈活、簡便、效果好等諸多特色。

但要說完整掌握高橋流精要，則是在拜讀《高橋流簡報》之後。這本「用高橋流簡報介紹高橋流簡報」的書，風格詼諧平易，鉅細靡遺地說明高橋流的由來、特色、實際作法與各種細節，同時也是高橋流簡報的完美示範。「這麼有趣的書，台灣讀者看不到實在太可惜了！」抱持這樣的想法，筆者便鼓勵太座 Pluto 著手翻譯，再由筆者校譯，確保所有的內容均符合高橋先生的原意；承蒙電腦人姚副主編的抬愛，處理著作權及後續編輯工作，這本書最後得以出現在各位面前。

那麼，接下來就請各位細細品嚐這本樸實而有趣的簡報書吧！

歷經了三個月，終於這四篇文章完成了編輯、校對的程序，刊登出來了：

• Opera Nalakuvara, a customized browser for the Taiwanese community — Part 1: planning
• Opera Nalakuvara, customized Taiwanese browser — Part 2: Tweaking Opera default settings
• Opera Nalakuvara, customized Taiwanese browser — Part 3: Third party components and menus
• Opera Nalakuvara, customized Taiwanese browser — Part 4: Deployment, documentation, testing

Opera 的網頁福音戰士 Zi Bin 並寫了一篇部落格介紹這一系列的文章：《Nalakuvara - a user customized Opera Desktop package》，有興趣的讀者也不妨參考。

至於這一系列文章未經編輯、裁切的原始版本，我之後也會放到三太子計畫網站上。

... A and/or B ...

許多譯者沒想太多，就照著翻譯成：

……甲及／或乙……

或者是稍微白話一點的，翻譯成：

……甲和／或乙……

也有展開成這樣的：

……甲和乙，或者甲或乙……

這種翻譯你拿出來念念看，有人這麼說話的嗎？認為必須要照這樣翻譯的人，多半是覺得這個英文原文的寫法看起來很謹慎而精確，覺得也必須要這麼精確的翻譯；既然要精確，讓我們來仔細看看這個原文到底是什麼意思。

英文的「... A and/or B ...」也是個有陷阱的用法，因為這裡的 and、or 並不全然是我們在數學課本講邏輯關係的時候，所學到的那個 AND、OR。讓我們畫圖來說明好了：

首先我們有個母集合：

在母集合當中，有個 A：

然後有個 B：

我們可以馬上得知「非 A」（數學課本上會寫成「~A」）：

以及「非 B」（數學課本上會寫成「~B」）：

現在讓我們來看看「... A and/or B ...」，把中間的 / 展開可以得到「... A and B / A or B ...」，也就是「... (A and B) or (A or B) ...」，稍微跟數學邏輯熟一點的人馬上會想：「A 跟 B 的交集，與 A 跟 B 的聯集取聯集，這不就是 A 跟 B 的聯集嗎？為什麼不直接寫『... A or B ...』就好了呢？」

有點混亂嗎？來看看圖。「A 跟 B 取交集」（數學課本上會寫成「A AND B」）：

「A 跟 B 取聯集」（數學課本上會寫成「A OR B」）：

原來是這樣的：書寫正常人閱讀的英文句子時，如果寫了「A or B」，語意上暗示著「如果是 A 就不會是 B，是 B 就不會是 A」，也就是說，其實是「『A 除去含有 B 的部份』or『B 除去含有 A 的部份』」的意思，即「『A 跟非 B 取交集』跟『B 跟非 A 取交集』取聯集」。

一樣來看看圖解：「A 跟非 B 取交集」（A AND ~B）：

「B 跟非 A 取交集」（B AND ~A）：

前述兩者取聯集：

因此，這樣的結果再跟「A 跟 B 取交集」取聯集後，纔會等於 A 跟 B 取聯集的結果。繞了一大圈，真正的原因是邏輯上的 OR 跟日常用語中的 or 不相等的緣故，所以為了表達 A 跟 B 的聯集，纔會寫出「... A and/or B ...」這樣的東西來。

精確理解這段原文要表達的意義後，終於可以來想想看要怎麼翻譯成中文比較好。在傳統的中文（也就是沒有被西化的中文）裡面，表達兩個東西的聯集用的字眼就是「和」，所以「... A and/or B ...」真正合適的譯法應該要是「甲和乙」。

中文程度較差的讀者會因為受到西化影響，又產生另一個疑問：「『和』不是『and』嗎？『and』不是『交集』嗎？為什麼會變成聯集呢？」

因為，翻譯從來就不是一個字對應一個字的固定函式，中文表達「聯集」的時候用「和」，表達「交集」的時候則是用「且」；至於把「and」翻譯為「和」的時機，則是跟前述的邏輯脈絡無關的列舉用法，像是把「master and apprentice」翻譯成「大師和學徒」（這時候沒有人會解讀成「大師跟學徒取交集」吧？）

不過就算是在這個「列舉」的用法之中，「和」仍然是個翻譯時常常誤用的字。主要的誤用情況是在這樣的英文原文中：

A, B, C, D, E, F, G, and H.

很多譯者非常喜歡把那個「and」翻譯出來：

甲、乙、丙、丁、戊、己、庚、和辛。

或者是譯成：

甲、乙、丙、丁、戊、己、庚和辛。

這也是個西化過了頭的結果，中文在這邊不會沒事多加個字；最簡單、明瞭的參考實例是以下這段順口溜：

一棵樹上七樣果：蘋果、桃兒、石榴、柿子、李子、栗子、梨。

試試看，把那個「和」加進去，這還溜得起來嗎？所以「A, B, C, and D」應當要翻譯成「甲、乙、丙、丁」。

基本上這大概就是一種行銷術語的操弄啦，印象中是日本先開始流行起這種用法，然後台灣因為哈日所以也就跟著用。至於操弄的是什麼，我認為有幾種可能。首先是來自「智力」、「體力」、「耐力」、「魅力」這種所謂「RPG 角色屬性」的命名方式，認為詞尾加上個「力」的後綴，就會讓某個東西成為「角色屬性」的一環，所以一開始骰子沒擲好的，就會被哄騙去花錢加點，好個無本生意！

不過你知道，如果跟你說「體力」會影響到能釣到多大的魚，這大家都能接受，可是如果跟你說「釣魚力」才會影響到你能釣到多大的魚呢？然後再跟你說「配餌力」會影響到釣到的魚的種類？顯然這些「力」纔不是屬性，而是技能啊！

說到技能的話，就有不同的故事了。

話說很多歐美人這些年來很崇尚「東方文化」，像是有人會在身上刺青刺一個「性交」的，還有刺「窮」字的（實在是很難理解）；又像是有本明明是講簡報技術的書，一開始就跟你分享日本新幹線的火車便當，還跟你說「和食」就是「Harmony + Food」……文化匯流之下，產生很多，嗯，匪夷所思的發展。不小心扯遠了，總之在這股崇尚東方文化的潮流之中，也有很多歐美人迷戀著「功夫」，音譯為「Kong-Fu」，接著就出現了「-Fu」這種後綴用法。舉例來說，你可能會聽過「Google-Fu」或「Perl-Fu」這樣的說法，通常是把任何一種工具的名稱，接上「-Fu」的後綴，意思是使用那種工具的厲害技能。

哦，所以我明白了。日本人說「○○力」，歐美人說「○○-Fu」，就是我們說的「○○神功」。

Creative Commons 已經邁入第八個年頭，在台灣的發展也進入第六年，筆者有幸參與其中，在台灣創用ＣＣ計畫擔任過幾年的技術首席，後來雖然因故離開，但是對於 Creative Commons 以及台灣創用ＣＣ計畫，仍然有不少想法及期許，再加上有些話語其實更適合離開之後纔說出口，所以在此一併與讀者們回顧一下創用ＣＣ計畫的過去，也提出些對未來的展望。

Creative Commons 的本意是要讓淪為財團剝削創作者與消費者的「著作權法」也能幫助人們使用各種創作，這個出發點放棄了「與著作權法為敵」的立場，試圖用容於現有體制的方式，尋找雙贏局勢的可能性。在這個前提下，Creative Commons 不論怎麼發展，都離不開著作權法的勢力範圍；對剛起步的 Creative Commons 來說，離不開的是美國的著作權法勢力範圍。當其他──所施行著作權法與美國並非完全相同的──司法轄區也和 Creative Commons 扯上關係，不論是想要有各自司法轄區版本的 Creative Commons 授權，或者是在其他司法轄區要使用採 Creative Commons 授權的作品，馬上就會因為著作權法條文的不同而發生問題。

這個困境，最早是以「最小更動、求其相容」的方式來處理，先後有二十幾個司法轄區間接參與了 Creative Commons，都是採用這樣的原則，把 Creative Commons 授權條文的內容翻譯成當地語言，接著按照各自司法轄區實際施行的著作權法及相關法律條文的用字，對這個翻譯過的授權條文做最小的更動。這個作法的用意是希望能讓每個司法轄區下的 Creative Commons 授權條文容於該司法轄區的法律條文，而在大略的意涵、精神上，盡可能保持各種版本的 Creative Commons 授權條文版本之間仍然一致。

即便做到了這樣，不同司法轄區對著作權法的解釋及執行還是有所不同，是無法改變的事實。為了讓 Creative Commons 授權條款能夠像 GPL 等授權方式一樣全球一致施行，最後的進展就是 3.0 版授權條款的推出：這個版本的授權條款條文列出了種種可能的司法轄區差異，說明在不同的法律背景中，授權條文應該要如何實行。雖然在實際的使用行為上，仍然會發生不同司法轄區中的不一致，但至少可以用一套條文遍行全球，而且各司法轄區中的使用者也能比較清楚地有所依循。

不過，這個進展僅限於 Creative Commons 的核心授權部分而已。Creative Commons 除了提供這些大家比較熟知的核心授權方式（姓名標示、姓名標示─非商業性、姓名標示─非商業性─相同方式分享、姓名標示─非商業性─禁止改作、姓名標示─相同方式分享、姓名標示─禁止改作等）外，還提供了其他的授權選擇，其中最容易發生相容性問題的，則是「公共領域」。由於著作權法的差異，不同司法轄區對公共領域的認定及處理也會有所不同，像是對著作權保護年限的差異，就可能導致某個司法轄區中已經進入公共領域的著作，在另一個司法轄區中仍受到著作權保護；另一方面，某些司法轄區允許著作權人拋棄著作權，把作品送進公共領域，但是另外一些司法轄區則不允許拋棄著作權，這也會造成各司法轄區間公共領域的不一致。筆者習慣把這種情況稱為「破碎的公共領域」或「不連續的公共領域」。

這種破碎／不連續的情況也波及到「創作公園」（由各種善意著作集合而成的虛擬場域，名稱正好也叫「Creative Commons」），因此 Creative Commons 機構與計畫持續進行中的另一個重要的企圖，是要增加各種授權方式間的可互通性，其中最顯著的成果是 GFDL（GNU Free Document License，GNU 自由文件授權）1.3 版已可與創用ＣＣ姓名標示─相同方式分享 3.0 授權條款互通，再加上原本 GFDL 的設計包含「版本升級條款」，即在 GFDL 採用者未指明特定 GFDL 版本或指明「或任何未來的版本」時，採用內容者就可以自由選擇按照最新的 GFDL 版本條文來解讀，這讓大量原本採用 GFDL 授權的內容，能夠方便地轉換到創用ＣＣ姓名標示─相同方式分享 3.0 授權。維基百科上數量驚人的著作，也是此舉的受益對象之一。但讀者諸君務必留意：GFDL 有這種版本升級條款的設計，創用ＣＣ授權則無；任何採舊版創用ＣＣ授權方式釋出的著作，都「不會」自動採用新版授權方式。

由於維基百科的知名度高，這兩種授權可互通性的實作知道的人也多，比較少人知道的幕後花絮則是：Creative Commons 佈這個局很久了！

多年以前，Creative Commons 實驗性地提出了許多不同的授權組合，包括：姓名標示、姓名標示─非商業性、姓名標示─非商業性─相同方式分享、姓名標示─非商業性─禁止改作、姓名標示─相同方式分享、姓名標示─禁止改作、非商業性、非商業性─相同方式分享、非商業性─禁止改作、相同方式分享、禁止改作等十一種核心授權，取樣、特別取樣、非商業性特別取樣等三種取樣授權，開發中國家等一種實驗性授權，CC-GNU GPL、CC-GNU LGPL、BSD、圍紀、音樂分享等四種掛牌授權，再加上基於美國著作權法的公共領域認證書，一度達到 21 種不同的授權方式。由於過多的授權方式會讓使用者感到困惑，所以 Creative Commons 讓未含有「姓名標示」授權要素的五種核心授權、使用率過低的取樣授權、與開放近用精神相左的開發中國家授權正式「退役」，另外則是讓掛牌授權淡出。

所謂掛牌授權，指的是把某個原本已經存在的授權方式賦予一個新的名稱。CC-GNU GPL 與 CC-GNU LGPL 其實就是 GNU GPL 與 GNU LGPL，BSD 也還是 BSD，只不過按照創用ＣＣ授權的模式製作了授權標章及詮釋資料，來輔佐原本的法律條文；圍紀授權和創用ＣＣ姓名標示─相同方式分享授權一模一樣，而音樂分享授權則與創用ＣＣ姓名標示─非商業性─禁止改作授權沒有不同。這兩種掛牌授權其實是為了鼓勵相關網頁服務／數位內容供應商便於選用；雖然「創用ＣＣ圍紀授權」淡出，但是與其相等的創用ＣＣ姓名標示─相同方式分享授權條款最後仍然成為適合各種圍紀──包括維基百科──選用的授權方式，一開始的目的也就達成了。

讀者諸君可能注意到了這種授權方式當中包含了「姓名標示」這項授權要素，對於集體創作的作品如維基百科，到底要如何實行？這是 Creative Commons 從創用ＣＣ授權條款 2.0 版推進至 2.5 版的主要原因；從 2.5 版起，著作權人能夠利用著作權聲明、使用條款或其他合理方式來指定贊助機構、出版者、期刊等第三人來做為姓名標示的對象。前述「創用ＣＣ圍紀」掛牌授權就是隨著創用ＣＣ姓名標示─相同方式分享 2.5 授權條款而推出。當時，有一件令人困惑的事情發生了：創用ＣＣ授權標章的文字也在差不多相同的時候進行了翻新，原本姓名標示要素的「您必須標示作者或授權人的姓名」變成「您必須按照作者或授權人所指定的方式，表彰其姓名」，讓許多人認為「按照作者或授權人所指定的方式」對應的正是前述法律條文的變動；然而這次變動也同樣地影響到最古早的 1.0 版（以及 2.0 版）授權標章內容，這表示創用ＣＣ授權的授權標章內容不見得可以充分且必要地表達同一授權的法律條文內容，而這個狀況至少會有兩個層次的影響：其一是「按照作者或授權人所指定的方式」可能會被過度解讀，超過法律條文中所描述的程度；其二是舊版的授權標章可能會暗示超出法律條文所規範的條件範圍。

第一個層次最簡單的例子是：授權人可能會希望規避背書關係，因此主張「不准彰顯我的姓名」──「不准彰顯」確實在字義上也是一種「指定的方式」，但是實務上創用ＣＣ授權卻無法讓授權人做出這樣的要求；在台灣，尤其因為著作權法規定著作人格權禁止拋棄及轉讓，更是對有這種需求的著作權人不利。創用ＣＣ授權 3.0 版加入了「禁止背書」條款來解決前述的問題，但是，再一次地，所有版本的創用ＣＣ授權標章上，也都出現了「但不得以任何方式暗示其為您或您使用本著作的方式背書」字樣。這也就是前述的第二個層次的影響。

這種授權標章與法律條文內容不一致的情況，在實務上還沒有引起爭議或重大糾紛，但是卻會是個隱憂；畢竟創用ＣＣ授權最大的方式就在於法律條文、授權標章、數位標籤的三位一體，倘若這三者互有出入，長遠來看必然會造成解讀分歧甚至產生兩造之間的誤會。除了授權標章與法律條文之間的不一致外，在筆者任職台灣創用ＣＣ計畫技術負責人時，與當時擔任法律負責人的同事討論之間，也發現了數位標籤與法律條文的不一致。這件事得從創用ＣＣ授權的 RDF 數位標籤說起。

每一種創用ＣＣ授權都可以用 RDF 格式的 XML 數位標籤來闡釋。以創用ＣＣ姓名標示─非商業性─相同方式分享 3.0 授權為例，其數位標籤如下：

<rdf:RDF xmlns="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <License rdf:about="http://creativecommons.org/licenses/by-nc-sa/3.0/tw/">
    <permits rdf:resource="http://creativecommons.org/ns#Reproduction"/>
    <permits rdf:resource="http://creativecommons.org/ns#Distribution"/>
    <requires rdf:resource="http://creativecommons.org/ns#Notice"/>
    <requires rdf:resource="http://creativecommons.org/ns#Attribution"/>
    <prohibits rdf:resource="http://creativecommons.org/ns#CommercialUse"/>
    <permits rdf:resource="http://creativecommons.org/ns#DerivativeWorks"/>
    <requires rdf:resource="http://creativecommons.org/ns#ShareAlike"/>
  </License>
</rdf:RDF>

這段數位標籤相當易懂，大致上就是在詮釋這種授權方式：

• 允許重製（permits reproduction）
• 允許散布（permits distribution）
• 允許衍生著作（permits derivative works）
• 要求保留完整的著作權及授權聲明（requires notice）
• 要求彰顯著作權人姓名（requires attribution）
• 要求衍生著作以相同方式分享（requires share alike）
• 禁止商業利用（prohibits commercial use）

http://creativecommons.org/ns 網頁上很明白地說明了創用ＣＣ的 RDF 數位標籤架構，任何人都可以明白看出各種授權要素按照允許（Permissions）、要求（Requirements）、禁止（Prohibitions）分成三類。資訊技術出身的使用者若透過數位標籤來理解創用ＣＣ授權，應該會得到「創用ＣＣ授權就是預先允許一些用途、要求一些事項、禁止一些利用的授權方式」的印象。然而，從法律的角度來看，創用ＣＣ授權並非如此。創用ＣＣ比較是「預先允許在某些條件下的一些用途」的授權方式，所以同樣的創用ＣＣ姓名標示─非商業性─相同方式分享 3.0 授權，從法律條文的角度來闡釋，簡化過的版本應該會像這樣：

• 在保留完整的著作權及授權聲明的條件下，且
• 在彰顯著作權人姓名的條件下，且
• 在以相同方式分享衍生著作的條件下，且
• 在非商業利用的條件下，則
• 允許重製，且
• 允許散布，且
• 允許衍生著作

讀者諸君應該可以從中明白發現那微小但關鍵的差異。前述授權標章與法律條文間的不一致，以及數位標籤與法律條文間的不一致，筆者都曾在全球參與的 Creative Commons 論壇中發起討論，可惜都仍懸而未決。有時候筆者會感到些許無奈：在這個已經推動多年的運動中，仍然可見「做法律的太過法律、做技術的太過技術（、做音樂的太過音樂）」的狀況，沒能時時顧及真正的重心在於普羅大眾。

以 Creative Commons 的現狀來說，法律部分的工作進度應該算是最領先的，3.0 版授權條款已經相當成熟，解決先前遇到的種種問題，若干司法轄區中也有用上創用ＣＣ授權的法院判例；技術部分的工作進度雖然還有待努力，但是過去幾年間確實也有不少進展，像是 Movable Type 及 WordPress 等部落格系統、各 BSP、Flickr 及 YouTube 等線上藝廊內建的創用ＣＣ授權支援、Google 及 Yahoo! 等搜尋引擎的創用ＣＣ授權選項支援、微軟 Office 及 OpenOffice.org 的創用ＣＣ授權支援、XMP 格式的創用ＣＣ授權後設資料，都是這方面努力的成果。另外在大型專案方面，也有 ccHost 這麼一個強調創用ＣＣ授權處理能力的多媒體藝廊暨內容與媒體管理系統，以及實際使用 ccHost 營運的網站如 ccMixter 等。此刻的 Creative Commons 實驗室也在嘗試著許多不同的資訊技術，包括 CC 0、Freedoms 授權選擇精靈、DHTML 授權選擇精靈、轉移終止（Termination of Transfer）精靈、詮釋資料實驗室等。

在這些技術成就之中，我們要非常自豪，因為台灣可能是除了美國的 Creative Commons 外，做出最多技術貢獻的創用ＣＣ相關計畫機構。在筆者就職台灣創用ＣＣ計畫任內，促成了包括 ccHost 等軟體採用 GNU gettext 架構來處理國際化與本地化（早期的 ccHost 源碼風格實在是相當地急就章，維護及本地化都是相當困難的工作），並從自由軟體鑄造場的「授權精靈」源碼改寫出「創用ＣＣ授權相容精靈」，讓普羅大眾混搭採用不同授權的著作內容時，能更得心應手；BobChao 隨後也將來自 Firefox 的技術實力發揮到創用ＣＣ上，製作了 ccZotero 及 JetCC 等 Firefox 套件，這些成就都讓台灣創用ＣＣ計畫接二連三地受到國際注目。

儘管如此，Creative Commons 在資訊技術上的實作還太少。截至目前為止，還沒有任何桌面源料閱讀軟體能夠處理嵌入源料中的創用ＣＣ授權詮釋資料，瀏覽器對於嵌入網頁的創用ＣＣ授權詮釋資料的支援也幾乎沒有──Creative Commons 先前實作的 MozCC 套件停留在 Firefox 2.x 時代，其他瀏覽器的支援則更是付之闕如。同時，Creative Commons 在近五年內也開始改變一開始把 RDF 詮釋資料以註解的方式嵌入 XHTML 網頁的作法，轉而嘗試採用微格（Microformats）及 RDFa；這些技術都還在發展之中，而且也都有各自的限制，坦白說，今年之內這方面恐怕不會有重大突破，因為真正的癥結在於，哪一種作法纔能夠讓夠多的人來使用。於是乎，技術的問題又回到了普羅大眾。

台灣的大環境是這樣的：官方求數據、民間求收益。筆者任職台灣創用ＣＣ計畫期間，常接到政府單位來電或來函洽詢類似「目前台灣在網路上有多少著作物」這樣的問題，這可真的是大哉問，自從著作權不再採登記制、而是「著作人於著作完成時享有著作權」後，就很難求出著作物數量。可行的估算方向或許是先假設網路上的數位內容必然有對應的資源識別符（例如：網址），再根據識別符的數量來推測。

但這裡的問題是，華人世界當中常見同樣的著作重複發表於多個不同網站，以及隨網誌興起的（全文）轉錄文化，都會導致同一份數位內容有著眾多資源識別符的情況。這個情況還會導致另一個令人困惱的問題：使用者越來越難判斷到底著作的真正著作權人是誰、哪一些授權聲明纔是真正有效的。由於創用ＣＣ授權的設計把求證的責任交給使用者，而不是授權者，使得 Creative Commons 原本預期「促進使用」的效果大打折扣；有些律師甚至會建議公司行號避開採創用ＣＣ授權的著作內容，擔心的也就是以為的授權人並非真正的著作權人。

有個可以嘗試發展的方向是：數位浮水印。如果能夠有一套系統，讓數位內容的創作者能夠在完成作品之時，輕易地加上數位浮水印，那麼日後就可以用浮水印來判斷或驗證著作權人資訊的可靠性。採用浮水印而不使用加總檢核或數位簽章的原因是：採創用ＣＣ授權的數位內容是允許使用者進行轉變的，而一旦有所改變，加總檢核或數位簽章也會失效，但浮水印則仍能保留。當然這還是個很粗淺的想法，是否所有的數位內容類型都能夠搭配浮水印系統使用，也還需要再評估一番。

民間會因為擔心受害而不敢使用採創用ＣＣ授權釋出的著作，也會因為覺得無利可圖而不採用。智慧財產局剛開始參與創用ＣＣ計畫時，誤將創用ＣＣ授權解讀成「免費授權機制」，這樣容易造成機關行號的誤解，以為一旦採創用ＣＣ授權，就會大幅減少收益。實際上並非如此，CC+（CC Plus）技術的出現就是最好的佐證。CC+ 是把創用ＣＣ授權與其他商業授權方式接軌的設計，BobChao 在他的部落格上撰寫過一篇《雜談 ccPlus 運作模式》，從各方面描述了相關的議題，筆者在此不再贅述，但要提出一些看法：

筆者認為以數位內容著作來說，「什麼都賣、什麼都不奇怪」的大賣場是難以存在的，因為數位著作內容實在是太多、太雜，而且不同媒體類型間的處理方式實在太不相同了。取而代之的會是重視社群互動、專注在特定媒體類型的專賣店，而且著作者主要會根據各自原本養成的網路生活習慣，來挑選「寄賣」的店家，甚至是自己擺攤。在這樣的前提下，過於寄望專賣店其實有點捨近求遠，因為現在自己擺攤的難度已經低很多了。以金流來說，如果想做跨國生意，讓使用者以信用卡付款，那麼 PayPal 一直都是不錯的選擇；如果想做國內生意，讓沒有信用卡的使用者也可以轉帳付款的話，玉山銀行已經推出相關的服務，可以把任何銀行的晶片金融卡製作成對應的專屬收款 WebATM，並且能夠在各種作業系統（Windows、Linux、Mac OS X）搭配各種瀏覽器（Opera、Firefox、Safari、IE）使用。數位內容著作者只差臨門一腳：如何搭配創用ＣＣ授權要素制價、如何在網頁上與金流服務結合。不論是撰寫教學示範，或者是提供相關的工具，其實都可望迅速滿足這樣的需求。這也是接下來可以做做看的。

最後再談到推廣──把 Creative Commons 帶給普羅大眾的重擔。

其實最近幾年的機會也比過去好上許多，有許多重要的實例：麻省理工學院開放式課程網站計畫協助教職員釐清著作的智慧財產權，並採用創用ＣＣ授權釋出，對於所有執行數位典藏計畫的單位來說都是重要的參考指標；維基媒體基金會所執行的 Wikipedia、Wiktionary、Wikinews、Wikiquote、Wikispecies、Wikisource、Wikiversity、Wikimedia Commons、Meta-Wiki 等計畫均採用創用ＣＣ授權，對於所有執行協同創作以及編目計畫的單位來說都是重要的參考指標；美國白宮網站自歐巴馬總統上任後也改採創用ＣＣ授權，對於所有的政府部門來說都是重要的參考指標。

上述這些例子，都是不容忽視的例證，各種配套措施以及軟硬體設置也都應該列為重要的參考；另外當然還有許許多多的實例，展現創用ＣＣ授權的可行。以台灣來說，有個值得努力的方向，是一直還沒有用力發揮的：有許多非營利／非政府組織，多年來累積了不少出版品，這些過期出版品對營收來說很有限，但是仍然承載著這些組織的信念，如果能夠廣為散布，對這些組織的使命有益無害──這就是個很適合採用創用ＣＣ授權的情況，只不過這些組織平時忙於各自的業務（講白一點，像是上街拉布條等），很難主動去掌握創用ＣＣ授權的知識與技術，實在很可惜，台灣創用ＣＣ計畫在此不妨考慮主動伸出援手，奠定雙贏局面。

筆者所能想到最困難的協助對象，其實是所謂既得利益的機關團體。舉例來說，也許有個公部門多年來利用國民稅捐營運，累積大量典藏品，然後開始靠著販賣典藏品的照片營利；一旦採用創用ＣＣ授權，意味著這些數位內容將易於取得，這些機關團體的主事者便擔心「銷售量會變差」，結果最後僅把「目錄清單」釋出，或者繼續保持不釋出。尤其當機關團體的主事者開始把「人民的」文化資產當成「自己的」，就更艱難了。機會仍然有，只是難見速效：一邊從民間努力，累積來自人民的聲音與力量；一邊想辦法從更高層努力，往下施壓；一邊則繼續與對等接口磨合，尋找可行的配套方案。不過，至少就筆者所知，台灣創用ＣＣ計畫這邊可從來沒放棄過。

台灣創用ＣＣ計畫邁入第六年，還有很多事可做，筆者在此期許各方面今年會更好，也盼望讀者諸君一起支持創用ＣＣ在台灣。

「當寫作成為閱讀的手段」，這並不是虛無的想像，而是此刻正在發生的現實；對於維基百科以及網路上成千上萬運用圍紀來製作百科、辭典、文件的計畫來說，最完整的閱讀體驗，少不了參與書寫的部份。並不是每個網路使用者都能體認到這一點，就連維基百科這麼知名的計畫，也不是每個使用者都會參與書寫──事實上參與貢獻的使用者比例並不高，許多使用者僅閱讀網頁上最膚淺的文字部分，沒有進一步地去發掘這些表象背後的實質內容。僅閱讀維基百科網頁表面的內容而不深究，往往距離真相最為遙遠。

維基百科以「編撰一部百科全書」作為出發點、作為概念上的目標，讓許多對資訊技術較不敏感的使用者也能迅速掌握整個計畫的輪廓，這部份固然是功不可沒，但是隨著數年過去，許多使用者很容易受限於傳統對「百科全書」的認知與想像，這就很不妙了。維基百科跟傳統百科全書之間有著許多差異，本質上可以說是完全不同的兩回事：

百科全書係經過寡頭權威式的編輯作業，編輯修改的過程並不公開，一旦面世後若非必要則甚少更動，若出現謬誤則出版社及編輯需負全責；維基百科採用鄉民參與式的編輯作業，儘管使用者的權限等級可以有所不同，但技術上任何使用者隨時都可以編輯、修改、刪除、還原，這些編輯過程會公開地保留下來，內容時時刻刻均有不同，甚至每一秒都可能與前一秒相異，一旦內容有謬誤，沒有別人會負責──誰發現錯誤，誰就有責任去改正。

由於這些本質上的差異，當需要在權威體系下（亦即現今多數的學術系統、政經體系中）正式引用資料或數據時，維基百科就會是最不適合的引用來源之一，因為維基百科的內容常常會處於未經同儕審閱且尚未編輯、校對的狀態，而且通常引用時的維基百科內容，與後來讀者查閱時必會有所出入，使得原本力求穩步徐行的研究方法，完全派不上用場。更甚而者，未經紮實編輯的維基百科內容，所發生的種種謬誤，諸如將愚人節笑話當成正經的消息來源，同一個人名在同一句話中出現兩種不同譯法，或者前一段所言與後一段南轅北轍，屢見不鮮；尤其在維基百科開始將若干語言合併為一後，語言及文化差異造成的編寫阻礙，更是嚴重。

雖然維基百科在編輯、校訂，以及學術價值的權威性上遠遠不及傳統的百科全書，但是另一方面，這也是維基百科的過人之處。任何使用者，不需要先經歷傳統學術權威體系的制約，就可以參與內容變動；這個特性使得維基百科有機會避免過於單一的詮釋角度，讓維基百科的內容不會輕易流於學究或布爾喬亞觀點。也因為參與門檻遠比傳統百科全書低得多，維基百科也能更有彈性地反映出最新近的流行文化，因此對於文化事件以及次文化領域的闡釋，維基百科總能更迅速地收錄有關內容。

儘管維基百科有一整套的守則與方針，也有企圖堅守的立場，現實上還是不可能讓所有參與的人都有共同的信念及認知；任何維基百科的內容，尤其是重要的內容，必然歷經頻繁反覆的編修競爭，這也是維基百科追尋聖杯的必經之途。這些演變的歷程，自成一部集體文化認知的發展史，正是所有其他的百科全書所缺乏的部份；這些演變的歷程才真正是維基百科的價值所在，每一次的內容變化，像是為什麼要如何更動、刪減了些什麼、添加了何種潤飾等，或多或少都有些「故事」可說。這些故事可不是八卦而已，而是見證內容存廢的重要註腳，使用者可以從這些故事體認維基百科的立場定位、運作模式，掌握寫作風格，並有效減少再三反覆的爭議或推敲。

當德國的出版社要將維基百科印刷出版成冊、或者當維基百科的「離線閱讀套件」逐一釋出，都只是在體現維基百科的「內容自由」而已；這些都是合理的發展沒錯，可是這些產物充其量是維基百科的驚鴻一瞥而已，如果過分重視或強調這類利用，反倒是在抹煞維基百科最珍貴的部份了。當然也有針對內容沿革進行研究的計畫，但這並不容易，可以說是維基百科發展至今難以有所突破的瓶頸之一：要如何輕易、明確地描述這些沿革呢？或者說，要如何才能讓維基百科的尋常使用者，也能便利地取用這些資訊呢？

維基百科每一則內容都有「修訂歷史」可查，但是這部份的操作介面十年來沒什麼成長，大致上就是按照時間順序列出由新到舊的修訂版、修訂的使用者、修訂摘要，並且讓使用者能夠任選兩個修訂版來比對內容差異。說實話，這樣的介面設計非常的技客導向，任何尋常的使用者幾乎都會略過這部份的功能不顧。如果維基百科想讓使用者能夠善用修訂沿革的資訊，接下來的發展方向應該是把這些資訊跟內容緊密結合在一起，亦即讓使用者在檢視模式下，就可以利用滑鼠選單或其他機制，即時操作動態的修訂歷史資訊，而且這些修訂歷史資訊也需要進一步地分類、整理，例如按照修改的模式、修改的幅度、修改的範圍等不同的條件，以程式化或人工的方式來處理，也可以試著用心智圖來呈現這些整理過的資訊。

用說的當然是很簡單，實際上困難重重：當一份內容有著上萬使用者參與、經歷數十萬次的修訂，是否還適合這樣子表達？再加上前段所描述的介面，也勢必得用上最新的網頁技術來重新開發，但這樣的工作遲早都必須進行，因為唯有幫助使用者融入內容脈絡，才能繼續降低參與貢獻的門檻，讓使用者能參與內容編修，並藉此探索維基百科真正的內容與價值。

到了那一天，我們才能說維基百科「一刀未剪」吧。

「三太子」是一個開放專案，目的是要將 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 的台灣辦公室、中國辦公室、挪威總部也都有相關的人員主動聯繫「三太子」專案，足見「三太子」專案至今的經營與發展方向，大致還算穩健、正確。

結語

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

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

相關連結

• 「三太子」計畫與文件集：http://Jedi.org/p4/Opera/pub/
• Opera：http://www.opera.com/
• 《The Art of Community》：http://www.artofcommunityonline.org/
• Perforce 版本管理系統：http://www.perforce.com/
• AutoHotKey 腳本語言：http://www.autohotkey.com/
• 鳥哥的 Linux 私房菜──學習 Shell Scripts：http://linux.vbird.org/linux_basic/0340bashshell-scripts.php
• Automator 腳本語言：http://www.macosxautomation.com/automator/
• GNU gettext：http://www.gnu.org/software/gettext/
• VMware Server：http://www.vmware.com/products/server/
• VMware Player：http://www.vmware.com/products/player/
• Sun VirtualBox：http://www.virtualbox.org/
• Microsoft Virtual PC：http://www.microsoft.com/windows/virtual-pc/

請注意：文中提到的各軟體版本，均是以撰文時為準，不一定能反映現狀。

本專欄在去年曾經提過 FreeMind、Cayra、XMind 等心智圖軟體，並針對當時這些軟體的不足提出建議。時至今日，這些開放源碼軟體專案不停地發展，我們是否有了更好的選擇呢？本期就讓我們重新思考：心智圖是什麼？你需要心智圖嗎？哪一套開放源碼心智圖軟體跟你最速配？

心智圖法是一套非常特殊的學習方式，歷史上有許多著名的天才，包括李奧納多‧達文西、伽利略、理查‧費曼、威廉‧布列克、艾伯特‧愛因斯坦等，都運用了類似的原則來學習及思考。一九六零年代左右，心理學家東尼‧博贊 (Tony Buzan) 提出了「心智圖法」這樣的說法，並在一九七零年代發展出一整套方法論。

心智圖法偏重在視覺表現上，主張以繪製的方式來表達繪製者心中對於某個特定概念的投影。在心智圖當中，與個人精神狀態有關的諸多面向，包括情緒、理智、放任、衝突、對立、延展、擴充、侷限、節奏、關聯等，會以布局、陳列、顏色、粗細、筆觸、比例、距離、扭曲、形變、符號、圖片、背景等視覺化的方式呈現。

簡單來說，心智圖法的原則是同時運用左右兩個半腦來學習或記憶，同時著重邏輯與情緒，以及多重感官的刺激，來洞悉事物的本質，並且促進創造性的思考。以此方法學習或記憶，能夠迅速掌握核心思維，並將各種細節做為互有聯繫的整體，所以能夠有效地回想及使用。

心智圖應該要是宏觀且微觀的呈現──不論是要將整張圖拉遠看做一個整體，或者是要拉近來看每一處細節，甚至是在遠近之間任意取一個區域，這些表達都會是有意義的。在繪製心智圖的過程中，可以將繪製者的心智具體呈現，協助繪製者補齊大大小小的片段，並且可以透過視覺回饋，增強繪製者對特定概念的感受與認知。

心智圖之所以能讓人們腦力激盪、加深記憶，是因為「繪製」的過程比「觀看」的過程要來得重要；繪製心智圖時，為什麼要把某個項目放在這邊、某個枝幹拉到那邊，在「看起來順眼」的直覺反應背後，總是可以挖掘出更深入的原因及動機。這些連自己都不見得會注意到的慣性，一旦落在紙上，就變得鮮明而醒目了。這也是學習心智圖繪製技巧的入門練習：探索自己繪製的心智圖。

隨著對自己的「本能」、「直覺」有了明確掌握後，接著就可以反客為主，開始練習操控這些因素。以相同的主題來繪製心智圖，但是嘗試用不同的手法來表現，從中實驗不同的思考方式，同時也能以更多面向來深入探索同一個主題。做過這樣的練習後，即使閉上眼睛，自己繪製過的心智圖也能了然於胸，鉅細靡遺；爾後從任何一個片段開始，也能觸發當初繪製心智圖時的心智歷程，把整張心智圖還原回來。

如何繪製心智圖固然是一門學問，如何賞析別人的心智圖更需要學習與練習；賞析一幅心智圖，就是在揣測一個人的思緒、意識、潛意識，因此真正能夠洞悉心智圖的第一人，往往也就是繪製者。學習心智圖最好從「畫」開始，等功力夠深、「有感覺」之後，再來體驗別人的心智圖。

「一開始要畫什麼好呢？」這樣的疑惑常見於初心者；可別小看了這樣的疑惑，因為不是所有的事情都適合利用心智圖來完成。心智圖是一種單一中心、注重整體性的工具，如果要處理的議題無法（或者刻意要避免）歸納出單一核心，就不適合以心智圖來處理（這時可以考慮使用概念圖）；表達的內容如果大量連貫且不容變更、刪改，例如文學領域中必須引用整章的小說，或者資訊領域中必須印出數百行以上的程式碼，也不是心智圖所擅長的。

在這些「不適用」的任務中，心智圖還是派得上用場。舉例來說，可以用心智圖來整理小說當中的人物、事件、恩怨糾葛等劇情推演，也可以用心智圖來整理程式碼註解，說明程式的外部規格及內部規格、呼叫的函式、運用的技巧等。藉由心智圖的輔助，繁雜而讓人難以理出頭緒的事，也能進一步抽象化，凝聚出更高層的焦點；不論是要規劃、構思、回顧，都可以有所幫助。

說了這麼多，到底要如何挑選心智圖軟體呢？誠如去年曾經提過，最能讓人自由發揮的解決方案，可能是一疊夠大張的紙，以及各種不同粗細、色彩的筆。截至目前為止，沒有任何電腦軟體能夠完美地實現東尼．博贊的心智圖法；包括商業軟體，甚至是東尼．博贊自己公司開發的 iMindMap 軟體也都還在努力之中。在開放源碼／自由軟體的世界中也是如此，沒有任何一套可以說是「最好」；每一個心智圖軟體專案都有各自著重的發展方向、近期及遠期目標，因而做出了具備不同特色的軟體。以下就讓我們來分別看看這些軟體：

FreeMind

FreeMind 是一套用 Java 撰寫而成的心智圖軟體，可能也是開放源碼界當中最知名的心智圖軟體之一。FreeMind 在開發及設計上相當注重（數值上的）效率以及檔案格式的開放性，因此 FreeMind 格式也成為各家心智圖軟體（不論商業與否）率先支援的對象；也拜 FreeMind 所賜，許多心智圖軟體纔有機會與其他工具搭配使用，並能將檔案內容轉換成不同的格式。

不過 FreeMind 的一大缺失則是過於缺乏視覺刺激，繪製出來的心智圖相當生硬，祇比大綱軟體稍具彈性一點而已。使用 FreeMind 將很難展現前述心智圖帶來的種種好處。如果你認真地想要探索自己的思考潛力，最好還是考慮別的解決方案。

FreeMind 目前最新的版本是 2009/05/22 釋出的 0.9.0 RC4，採 GPL 授權，專案網頁位於 http://freemind.sourceforge.net/，除了可下載源碼自行編譯外，亦提供了 Windows、Mac OSX、Linux（Debian、SuSE、Fedora、Mandriva 等）、OS/2（eComStation）等平台上預先編譯好的可執行檔。

Semantik

Semantik 是承襲 Kdissert 而來的心智圖軟體，運用了 KDE4 與 Python。嚴格來說，Semantik 並不是要成為一套「心智圖軟體」，而是「利用心智圖來撰寫文件」的軟體，因此在素材運用上比較偏重文字，輸出時也以文字型態的檔案格式為主。如果你需要撰寫文件（或者是論文或較長的文章）的靈感，想避免自己岔題岔太遠，不妨試試看 Semantik。

除了拿來寫文件之外，Semantik 在一般的心智圖運用上仍然不是多好的選擇，跟 FreeMind 一樣，所能表現的樣式並非很有彈性。再者，由於 Semantik 用了 KDE，使得這套軟體想要橫跨諸多作業環境也不是那麼容易，這些都可能是挑選心智圖軟體時必須注意的。

Semantik 目前最新的版本是 2009/04/25 釋出的 0.7.2，採 QPL (Q Public License) 授權，專案網頁位於 http://freehackers.org/~tnagy/semantik.html，僅提供源碼，需自行編譯。

VUE

VUE (Visual Understanding Environment) 是一套用 Java 撰寫而成的軟體，嚴格來說並非本賜所要探討的心智圖軟體，而是一套也可以繪製心智圖的概念圖軟體。與其他的軟體相較，VUE 更著重於數位多媒體內容的整理；VUE 能夠管理 FTP 伺服器等不同來源的數位媒體檔案，也能夠嵌入顯示／播放媒體內容，並建立起內容群組等。

一般在繪製心智圖時，是先有想法或感受，再尋求合宜的方式來表達；VUE 則是在你手上已經有一堆數位媒體檔案（圖片、音樂、文件、影片等）時，讓你加以整理、理解其關聯性用的。VUE 或許不擅長激盪你產生新的念頭，但是 VUE 特有的分析／合併模式，用來當做心智圖的後續發揮，也是個不錯的主意。

VUE 目前最新的版本是 2009/05/06 釋出的 2.3.1，採 ECL (Educational Community License) 2.0 授權，專案網頁位於 http://vue.tufts.edu/，註冊帳號後除了可下載源碼自行編譯外，也有 Windows、Mac OSX、Linux 等平台上預先編譯好的可執行檔。

VYM

VYM (View Your Mind) 是一套用 QT 及 C++ 撰寫而成的心智圖軟體。與 FreeMind 相較之下，VYM 更為敏捷，而且也比較貼近心智圖法的需求，可惜目前仍然祇能使用內建的少量圖示，也無法自行定義、添加其他素材。VYM 在處理數位媒體檔案的能力也比較弱勢，無法任意附加檔案，跨平台的能力也比 FreeMind 差。

VYM 目前最新的版本是 2009/07/15 釋出的 1.12.2，採 GPL 授權，專案網頁位於 http://www.insilmaril.de/vym/，除了可以下載源碼自行編譯外，亦提供了 SuSE 與 Mac OSX 平台上預先編譯好的可執行檔，另外也有一些人在維護其他 Linux 及 FreeBSD 平台上的移植套件。目前則還沒有能妥善運作的 Windows 版本。

XMind

XMind 是一套用 Java 撰寫而成的心智圖軟體，也是第一個直接邁入商業授權模式的開放源碼心智圖軟體。XMind 對系統資源的要求較高，執行速度上也還有改善的空間，但是在視覺表現上確實已達商業軟體的水準（視覺表現乃是心智圖法當中相當重要的一環）；XMind 除了心智圖外，也可以用來繪製概念圖、樹狀圖、魚骨圖、資料表格等，並讓使用者將同一份內容即時轉變成另一種圖型。施行心智圖法並不需要這樣的功能，但是前面也提過心智圖法不見得適用所有的情境，因此 XMind 這樣跳開心智圖法的設計，正好可以提供其他的選擇。

XMind 目前最新的版本是 2009/04/29 釋出的 3.0.3，採 EPL (Eclipse Public License) 1 與 LGPL 3 雙授權，專案網頁位於 http://www.xmind.net，除了提供源碼外，使用 OpenID 登入後還可以下載 Windows、Mac OSX、Debian、Ubuntu 等不同平台上預先編譯好的可執行檔。XMind 另有可作為 Eclipse 外掛的版本，以及免安裝的跨平台可攜帶版。

篩選

本次所介紹的五種開放源碼心智圖軟體當中，排除跨平台支援不夠理想的 Semantik 與 VYM 後還剩三種；接著再以視覺表現來篩選，就會排除 FreeMind，剩下 VUE 跟 XMind 兩種。VUE 適合用於數位媒體內容較多的情況，可以用來探索這些內容間的關聯性；XMind 則較為泛用。有趣的是，VUE 與 XMind 除了心智圖外也都還可以繪製其他類型的圖，或許這種不預先設限的作法，纔讓這兩個軟體成為開放源碼心智圖軟體當中的佼佼者。

規則

隨著選用的軟體不同，以及每個人的特質差異，心智圖法的實務進行也得要跟著加以調整，纔能發揮最大的功效，不過不論是哪一種心智圖的做法，大致上仍然有一些共通的原則，是不會改變的。這些原則，與其說是規則，其實更像是心智圖法的前提與假設，初學者獨自摸索時候容易錯過，因而無法領略心智圖的威力，這是很可惜的。

所以，接著就讓我們來介紹這些基本的規則。

1.核心構念

心智圖從一個核心構念開頭，再向四面八方伸展蔓延，所有圖中的其他內容，都是用來描述、闡釋那個核心構念的。核心構念是最核心、最重要的構念，也是能從你的記憶中提綱挈領把整張心智圖取出的關鍵。

核心構念是心智圖的核心，因此也會放在正中央，讓所有延伸出去的內容，也都有充足的空間可以繼續發揮。

2.枝幹與分支

從核心構念發展出來的，是心智圖的若干枝幹，表達的是與核心構念相關的數個領域或元素，每個枝幹再有分支，表達的是這些領域或元素的細部組成。枝幹不宜過多，否則心智圖將難以烙印在你的心中，回想起來必有疏漏，而且會使得每一個枝幹都不夠深入；另一方面，枝幹的數量也不宜過少，因為這樣會稀釋資訊的濃度，讓核心構念周圍過於空曠。一般來說，理想的枝幹數量約在四到六個之間，最多不宜超出七個，因為七個項目已經是人類平均短暫記憶的長度了。

3.枝幹順序

核心構念周遭的枝幹並不是隨意擺置的。一般來說，通常人們習慣以看時鐘的方式來看東西，亦即從一點鐘的方位循順時針方向看一圈，所以這可能就是一個適當的枝幹擺放策略：從核心構念的右上角開始，接下來是右下、左下，最後在左上收尾。

不過由於受到數位文件及網路文件的影響，有越來越多的人會從左上方開始，再依順時針方向前進，因此不妨也可以考慮從左上開始，接下來右上、右下，最後在左下收尾。

這些順時針方向的閱讀習慣，暗示著偏重左腦的思考方式，另外當然也有人比較習慣按照反時鐘方向──偏重右腦──來理解畫面的，那麼就可以改以反時鐘方向的順序來分配這些枝幹。在心智圖中，重點在於枝幹要有個一致的順序，這個順序會反映出每個人的思維模式，也因此會因人而異。

4.視覺暗示

一般人記筆記的習慣，就是將要點項目逐條寫下而已，這是完全偏重於左腦的記憶模式。心智圖法則是要同時使用左腦及右腦，因此除了一項一項地將要點記下外，還需要有許多能喚起情感或情緒的視覺暗示，例如不同顏色、粗細的線條，圖片或圖示、框線、關聯線等。

當今的心理學研究均指出，在這種模式下，整張圖片將能夠在大腦中同時激發更多神經叢衝動，而形成更鮮明的記憶；除此之外，由於心智圖法運用了刺激右腦的視覺暗示，所以將比傳統的筆記方法，更能讓人們發現潛藏的關聯、弦外之音，並且創造出新的想法等。

5.畫，而不是看

心智圖是每個人自己心智模式的投影，是一種非常個人化的思考工具，因此心智圖的正確用法是要去「畫」出自己的心智圖，而不是去「看」別人畫好的心智圖。

看別人畫好的心智圖，比較像是要去欣賞別人的心智，或許能夠因此獲得額外的靈感，是原先自己所想不到的，但是真正要學習、記憶，還是得親自繪製自己的心智圖。因為在繪製心智圖的過程當中，可以逐步把自己的感受及想法記錄下來，填補本來沒特別注意的缺漏之處，讓你可以「想清楚」；更重要的，是繪製心智圖的這個過程本身，也會成為你的體驗──當日後你再次面對圖中的核心構念時，繪製心智圖的整個歷程，亦是提取記憶的關鍵之一。

6.有機

心智圖的枝幹生長，大可不必規規矩矩、如同傳統筆記一樣地排列對齊，而應該像樹木的枝幹生長一樣，自由地彎曲，同時又讓所有的枝葉都能受到陽光照耀。這種生長方式就是所謂的「有機」，線條的長短、粗細、蜿蜒等，都是負有生命的，反映出人的內心情感與思維。

徒手繪製心智圖的時候，這種有機的特性比較容易發揮出來，然而在使用電腦軟體繪製時，受限於目前的軟體技術，這一點往往會受到犧牲。東尼‧博贊近年來自己開設公司所研發的心智圖軟體 iMindMap，以及另一套在 Mac 上也享盛名的 NovaMind，大概是少數特別強調這種「有機」特性的軟體；本專欄在去年的專文當中，也指出開放源碼的心智圖軟體也得朝這方面努力。

繪製

繪製心智圖之前，首先要決定心智圖的核心構念。心智圖可以用於多數的情況，包括課堂筆記、準備演說、舉辦聯誼等，都可以利用心智圖來協助思考。實際繪製心智圖的程序，又可以簡化分成三個層次：

1. 開始動手

準備一大張白紙（至少 A4，A3 為佳）以及各種顏色的筆；將紙橫擺，因為我們的視野也是橫向較寬的。為你所決定的核心構念選擇一個足以代表的圖像，然後把那個圖像畫在白紙的正中央，接著在圖像上（或者是旁邊、底下）標上核心構念的名稱。核心構念務必要從紙張中央開始，因為這樣四面八方纔有充足的空間，讓你表達自由的思想。

2. 延展思緒

接下來要從中心的構念圖像，往四面八方畫出不同顏色的粗枝幹，這些枝幹會代表你的主要思緒；枝幹的數量沒有一定，但是別忘了我們前面提過的原則：不宜太少、不宜太多（超過七個），最好介於四到六個之間。在每一個枝幹上，同樣地使用不同的色彩，用較大、較粗的字體，將你的思緒轉為單一的關鍵詞。試著運用想像力，來把複雜的想法歸納成簡短的幾個字。

選用對你的大腦能帶來衝擊的色彩，因為他們能讓你的心智圖有更多能量，並幫助你進行創造性思考。

心智圖的效率來自於影像與關聯。自然的大腦思考歷程往往是充滿影像的，因此把影像納入思考歷程將能事半功倍；俗話說「一圖勝千文」，在心智圖中使用圖片，不但能節省時間，更能幫助你回想所有的細節，而且圖片也會提振你的興趣，讓你更能專注在此刻的思考上。

3. 念頭、思緒與關聯

心智圖法的最後一步，就是在你的心智圖中建立關聯，讓心智圖的概念更為擴展。仔細看看前一步的各個枝幹關鍵詞，它們應該會激起更多的念頭；從枝幹的一端再畫出較細的分支，把這些念頭與你的主要思緒關聯起來，當然它們的數量也是沒有限制的。這些細分支的念頭還有可能誘發出更多想法，你可以反覆進行這個步驟，直到所有的念頭通通紀錄到心智圖上為止。

最後把你的心智圖存檔起來，因為之後你還可以再把它拿出來，加上更多的念頭，做為學習的工具。

經過這簡單的三個步驟，你應該就能成功地畫出一張心智圖，結構分明、充滿創意地，有效綠地表達你的思緒。接下來就是持之以恆地練習，隨著繪製過的心智圖越多，你將越能掌握到心智圖法的巧妙之處，也將對你選用的軟體有更精確的掌握，並逐步發展出最適合你自己步調的心智圖法。屆時，你也將發掘出心智圖對你日常生活的種種助益。

在眾多瀏覽器當中，Firefox 以其擴充性著稱；雖然 Firefox 本身功能少，但包羅萬象的擴充套件讓 Firefox 可以彌補各方面的不擅長，甚至能把 Firefox 包裝成不同功能目的的應用程式。這種設計並非全無缺失。最常見的情況是，使用者必須安裝數十個不同的擴充套件，結果補強功能的同時，也把整體效能拖累了；另一種常見的情況，則是擴充套件之間的相容性問題，不但讓網頁顯示結果變得奇怪、瀏覽器效能低落，而且還讓人難以判斷到底是誰（哪一個擴充套件）惹的禍。

最近才爆出一起 Adblock Plus 與 NoScript 這兩個擴充套件的糾紛事件。這兩個擴充套件應該都是 Firefox 愛用者耳熟能詳的；前者的功能是用來阻擋各種網站上的廣告，後者則是標榜預設禁用所有的 JavaScript，讓使用者能一一批准放行，以抵禦未知的不良網站攻擊。這兩個擴充套件看似井水不犯河水，但不少使用者發現瀏覽某些網站時，同時裝有這兩個擴充套件的 Firefox 會有異常的情況；也有不少使用者發現，啟用 NoScript 的情況下，瀏覽器整體速度變慢。這究竟是怎麼一回事呢？

Adblock Plus 的作者 Wladimir Palant 於五月一日在部落格上發表了一篇文章（http://adblockplus.org/blog/attention-noscript-users），指責 NoScript 的作者為了謀取廣告收入而不擇手段。該文大意如下：

「NoScript 為了營利，在更新說明網頁放置了大量廣告，並且頻繁改版，再強迫所有的使用者於每次更新後，都連到充斥廣告的更新說明網頁；雖然 NoScript FAQ 當中宣稱只有重大版本更新時才會連到該網頁，但實際上卻是每次更新都會連過去。」

「原本 NoScript 應該是預設阻擋所有的 JavaScript，但是為了要顯示 NoScript 更新說明網頁上的廣告，NoScript 內建了一組預設白名單，讓 NoScript 網頁的網域，及其他用來顯示 NoScript 網頁廣告的網域，一開始就能執行。這個設置讓有心人士能夠從 NoScript 更新說明網頁執行 XSS 攻擊，使用者在剛安裝或更新 NoScript 後就會第一時間中招。」

「此外，為了阻擋 NoScript 更新說明網頁上的廣告，Adblock Plus 的 EasyList 於兩週前開始加入了一些規則，用來擋掉這些廣告。接下來 NoScript 與 Adblock Plus 展開了一連串的戰役；NoScript 開始在其更新說明網頁上運用各種手段來避開 EasyList，EasyList 也不斷地修改其規則，繼續阻擋 NoScript 更新說明網頁上的廣告。一週前，新版的 NoScript 擴充套件加入了一些針對 Adblock Plus 的惡意程式碼，用來干擾及停用 Adblock Plus 的部份功能。因此，在 NoScript 網頁及許多其他網域當中，若使用者同時安裝了這兩個擴充套件，網頁顯示就會不正常。」

「由於 NoScript 此舉已經侵犯了 Mozilla 的附加元件政策，因此 NoScript 的作者同意移除該版本 NoScript 擴充套件當中針對 Adblock Plus 擴充套件所加入的惡意程式碼；但是在四月底所釋出的新版 NoScript 擴充套件中，運用了 Adblock Plus 的應用程式介面，在未經使用者同意的情況下，逕自加入一份 Adblock Plus 過濾規則清單，此清單也會把 NoScript 網頁及其他用來顯示 NoScript 網頁廣告的網域，列入白名單。NoScript 的網頁上並宣稱『因為 EasyList 意圖攻擊 (NoScript) 開發者的網站，使得許多功能爛掉，所以才加入這份白名單』；實際上 EasyList 完全沒有攻擊可言，而是單純地阻擋網頁廣告而已。NoScript 網頁意圖規避 Adblock Plus 及 EasyList 才是造成所謂『不相容』的主因。這份 NoScript 擴充套件所加入的 Adblock Plus 過濾規則清單不但在加入時不會先取得使用者同意，而且也只能停用而無法移除──使用者若嘗試移除這份過濾清單，它仍會在下次啟動 Firefox 時自動加回去；即便是在移除整個 NoScript 擴充套件後，這份清單仍然存在。」

針對這樣的指責，NoScript 的作者 Giorgio Maone 五月四日在其部落格上發表了一篇更長的文章（http://hackademix.net/2009/05/04/dear-adblock-plus-and-noscript-users-dear-mozilla-community/），除了再三道歉、承認自己愧對了整個 Mozilla 社群的信任，是個天大的錯誤，永遠會對此感到懊悔。他並承認自己濫用了多年來整個社群對 NoScript 的信任，在未經使用者同意之下，讓 Adblock Plus 無法阻擋四個網域（noscript.net、flashgot.net、informaction.com、hackademix.net）中的內容。

Giorgio Maone 並宣稱其所逕自加入的 Adblock Plus 過濾規則清單無法移除乃是程式瑕疵，非其本意，緊接著釋出的 NoScript 擴充套件 1.9.2.6 版當中，亦會自動移除前述的 Adblock Plus 過濾規則清單（也不會先詢問使用者）。另外還有不少技術細節，一方面 Giorgio Maone 持續地承認自己犯的過錯沒得找藉口，另一方面也在試著表達自己並不如 Wladimir Palant 所說的那般邪惡；兩人之間對於「廣告」與「阻擋廣告」的認知略有出入，並且在互動之中或多或少都混雜著個人情感。

這並非 Firefox 擴充套件間的第一場紛爭，也不會是最後一場。或者說，在某個層面上，Firefox 這種仰賴擴充套件的作法，正是促成了種種競爭的原因之一。

在這個案例上，顯現了幾個不同的議題。首先是關於安全性的考量，開放源碼與否很難說誰比較安全──開放源碼軟體如 Firefox 的各種擴充套件並不見得因為「源碼大家都看得到」就不會含有惡意程式碼，有心人反而可能利用競爭對手的源碼，針對特定對象撰寫惡意程式碼；不過開放源碼的結果，是這些不安好心的勾當，也確實比較有機會被及時挖掘出來。受到夠多人的關注時，這些惡意程式碼就能迅速移除。

佈署開放源碼解決方案時，有個容易忽略的成本──必須要有夠多眼睛來監督這些源碼，才能保持程式品質與可靠。除了直接掌握程式源碼所需的人力外，還有每個元件的更新、佈署、確認元件間相容性等；使用者社群在這當中扮演著重要的角色，但是社群的努力並不能當做某種國際標準規範，而且要獲得社群協助前，也得要參與社群運作。這並不是開放源碼解決方案的「缺失」，而是一種「特色」。任何開放源碼專案都必須要有充分的社群參與，才能清新、健康地發展；當考慮要採用開放源碼解決方案時，跟著參與相關的社群（使用者社群以及開發者社群），纔是開放源碼解決方案的正確「用法」。

另一個議題則是 Firefox 這種「核心功能單純，開放肆意擴充」的策略，究竟帶給使用者更多方便還是困擾，也很難定論。從好的角度來看，這種設計確實可以顧到比較多樣需求的使用者社群，不管有多奇怪的需求、想把瀏覽器改裝成怎樣的怪獸，都有辦法達成；當然從不好的角度來看，就是為了達成這些目的──即使是多數使用者期待的日常使用功能──都需要使用者主動了解諸多擴充套件，並且從各式各樣的擴充套件中選擇搭配。如果使用者沒有這方面的知識，就無法讓瀏覽器成為順手的利器。

而在這種不斷安裝擴充套件的過程中，也可能讓整個瀏覽器變得肥大，或者是遇到前述的相容性（甚至是互相打架）的情況；由於許多這類的軟體專案都是由少數幾個人獨挑大梁，相較之下程式開發比較容易受到一時的想法或情緒左右，導致如前述 NoScript 事件這樣的結果。如果擴充套件的作者因故停止維護擴充套件，在瀏覽器主程式推出新版本時，相關的功能就可能因此擱置，不見得有人能有意願／時間／精力接手經營。Firefox 歷經 1.0、1.5、2.0、3.0 等多次重大改版，已經有許多難以取代的擴充套件就這麼消失了。

這並不是「開放源碼」的錯──任何封閉軟體也可能發生一樣的狀況，隨著公司倒閉、程式設計師跑路、硬碟損毀等事故，都可能造成乏人維護的程式。但實情是，開放源碼軟體依舊會斷頭（停止開發），使用者依舊會陷於其中，不知所措。以 Firefox 的情況來說，不少使用者面臨著某些靠著擴充套件功能，陸陸續續地消失或壞掉，而且求助無門；對一般使用者來說，不同版本的 Firefox 更像是不同的瀏覽器，有不同的設計、不同的功能、不同的瑕疵、需要搭配不同的擴充套件。說真的，掌握這些細節並不是件輕鬆的事。

開放源碼提供一條生路，讓人們可以自由檢閱、修改、使用、延續這些程式碼，但並不保證這些事項一定會發生；開放源碼也提供了多元選擇的機會，讓完成事情的辦法可以不只有一種，但不保證這些選擇當中存在最佳解。整個開放源碼史，也是眾多開發者與使用者的磨合、互動歷程。

在開放源碼軟體的世界中，「人」纔是真正的核心價值所在。不論是程式開發者或是使用者，都是構成社群的重要角色；積極地參與社群，與其他人理智地交流互動，最終才能在源碼當中累積眾人的智慧，讓源碼生生不息。

先前本專欄即曾經提過，自由軟體基金會為自由軟體訂定了四種屬於軟體使用者的自由：

• 第零自由（Freedom 0）：為任何目的執行軟體的自由。
• 第一自由（Freedom 1）：學習程式如何運作，並將其原理納入自己作品的自由。此自由建立在能取用源碼的前提上。
• 第二自由（Freedom 2）：重新散布副本的自由。
• 第三自由（Freedom 3）：改善程式、並將此改進釋出予公眾，使社群獲益的自由。此自由建立在能取用源碼的前提上。

這四種自由雖說是「屬於軟體使用者」，也的確都是在明確地定義軟體可以如何「使用」，包括執行、學習如何運作、將原理納為己用、重新散布、改善、釋出等，實際上背後的精神卻是在強調「軟體源碼」的自由──軟體源碼如何不受人們禁錮、如何成長（被使用者改善）、如何不受限制地出現在各處等的自由。

然而有在自己寫點程式的朋友總會有類似的體驗：寫程式最有樂趣的部分，在於寫出自己需要的功能；如果行有餘力，可以弄點介面，讓其他親朋好友（尤其是女孩子們）也願意拿去用，可能是接下來願意著手的事項。再來呢？有些人會願意多花好些力氣，讓隨便的路人甲也能一眼弄懂這個程式在做什麼、該怎麼用；至於把最後的程式碼再整理成簡潔易懂、適合其他人進一步修改取用或接手維護，並撰寫詳實註解，則根本是佛心來著的。

任何由興趣或信念而展開的程式撰寫，大抵來說都是如此。為數眾多的開放源碼程式也涵蓋其中。沒錯，即使是開放源碼軟體或自由軟體，任何使用者都可以輕易取得軟體源碼，也不能保證這些軟體源碼好讀易懂、人人有辦法輕易改動。

在前述兩種因素的交織之下，再加上使用介面的設計又是另一個有別於程式撰寫的專業領域，使得許多自由軟體給人的印象總是「使用介面不佳」。自由軟體開發社群多年來所重視的，一直是程式的核心效能，著眼於程式與程式、程式與硬體間的互動，而不是程式與人之間的互動。久而久之，自由軟體與開放源碼軟體社群的交流，總離不開「源碼」；幾年下來有了「UTSL（Use The Source，Luke）」這種夾槓縮寫，也有 NetHack 這種「攻略就在源碼中」的遊戲。

這本來不是壞事，但是當我們想要把此類自由的風氣帶給其他與程式源碼不熟的人群中，就會變成無形的屏障。例如 Firefox 有些「隱藏設定」無法透過標準的選項設定畫面直接核選，也沒有寫在任何官方的正式文件之中，唯有閱讀過其源碼的使用者纔會發現──或者是經由這些使用者輾轉告知；當有人去函詢問開發團隊為什麼要把這些設定項目「藏」起來，獲得的回應又是「這本來就不是一般人該知道的事」，其實蘊含著一種歧視，對「無法／未閱讀源碼」的使用者的歧視。

有人會覺得這些祇是小事而已：部落客間不乏撰寫這類「秘辛」、「小撇步」的，早晚會將這些事情解釋清楚、傳達出去，不會構成太大的問題；但是這麼一來，不就成了知識經濟「懂得多的騙懂得少的」手法的兇手嗎？一邊說著「學習程式如何運作」的自由，一邊又把這種自由侷限在「學習源碼如何運作」上，排除了「學習程式的執行操作邏輯」這種「如何運作」，真的是好事嗎？

使用軟體如此，修改軟體也一樣。在這個領域當中，有許多「慣例」是開發社群熟悉到不行、因而鮮少特別著墨的；也有許多元件，是一而再、再而三地被拿來使用的。對於還不熟悉的使用者來說，如果開發者過於熟悉而忽略文件與教學的重要性，也很容易造成新門檻。舉例來說，自由軟體／開放源碼軟體常常用 gettext 來處理軟體的國際化與本地化，這其實很方便而且功能強大；但是如果沒有特別說明，許多使用者很難知道要從何下手，既不知道那些 .mo、.po、.pot 檔案與此的關聯性，更不知道要如何編輯與編譯，更不要說是懂得利用 poEdit 這類工具了。有時候，使用者就祇是想稍微修改一下軟體用語，好拿給小朋友、老人家用，不是真的要去改程式什麼的，卻會有這種不得其門而入的困擾，十分可惜。

對於已經熟悉自由軟體社群的使用者，情況不見得就有好到哪裡去。別忘了，許多軟體都處於「恰好能用」的開發模式中，包括本地化在內，想要修改什麼或者擴充、安插功能進去，都不是簡單的事。還有很多軟體則在開發初期就有濃厚的領域特性，例如專門用於音樂社群的社群平台軟體（像是 ccMixer 背後的 ccHost），並非輕易就可以轉變成影像處理社群所樂於採用的樣子。重頭東修西補，有時候就像是要削足適履般不倫不類，有時則會讓人萌生整個砍掉重練的念頭。

自由軟體明明保障了這麼多基本且關鍵的自由，自由卻難以施展開來。

專案管理、介面設計、文件撰寫，每一個環節都是大學問，對於施展前述的「自由」也是同樣地重要。專案管理用來確保軟體開發的方向專一、架構合宜，介面設計用來讓每一項程式功能都有對應的合理操作邏輯與步驟，文件則讓不同背景、需求、程度的使用者也能逐步掌握軟體源碼。這些事或許離「撰寫程式」有點距離，但對於自由軟體的生態健全來說，實在有其必要。

當然我們不可能要求所有的自由軟體開發者，背負著這些程式撰寫以外的責任；在稍微大一點的專案中，這些事情其實各自都需要有單獨的人力全心負責。實務上也不可能期待有朝一日，所有的自由軟體專案在這些方面都無比健全。但若程式設計師願意多接觸這些方面的理論及實務，將能從中獲得許多寶貴的知識與經驗。

程式設計師稱做「設計師」而不是「工匠」的原因，就在於「設計」這兩個字上；任何設計，最重要的就是與使用者之間的溝通及互動。因此好的程式設計師，必然會在乎他的使用者，會想要有良好的介面，讓軟體對使用者更具親和力；會想要有良好的文件，協助使用者理解程式、鼓勵使用者參與程式發展；會想要有良好的專案管理，跟使用者（其中也包括了其他開發者！）維持良性互動。

當一名程式設計師開始注重這些環節，那麼在實際行動中所學到的，就跟研讀、撰寫程式源碼所學到的知識一樣重要，也會對其專業工作上有所助益。更重要的，就如同自由軟體社群素來藉著自由軟體專案提升整個社群的程式碼品質一樣，這些受益也會在自由軟體社群中，產生不斷進步的正向循環，把原有的四種自由往前再推進一步：

• 第零自由（Freedom 0），2.0：對任何軟體，發揮其完整能力（及延伸能力）的自由。
• 第一自由（Freedom 1），2.0：學習程式如何運作，並讓自己的作品參與其中的自由。
• 第二自由（Freedom 2），2.0：隨時換用不同軟體而不會打斷原先工作的自由。
• 第三自由（Freedom 3），2.0：改善軟體專案社群互動、並將此良性互動帶入軟體開發，使軟體改進的自由。

與原本自由軟體基金會所訂定的四種自由相較，此處所謂「2.0」版的自由，更著重於「人」的自由；包括開發者、推廣者、終端使用者等，都需要這樣的自由，來實踐軟體的自由。

筆者以往常常說，「流通、使用中的資訊纔是有意義的資訊」，軟體何嘗又不是如此呢？能真正讓人們享受自由、便於參與、樂於使用的軟體，本身纔會是自由的呀！

這個夢想很大很遠，但並非無法實現的海市蜃樓；願本文做為一個起點，鼓勵更多自由軟體社群成員，暫時擺脫「寫程式最大」的念頭，用不同的視角來回顧手上的專案，把自由軟體的「自由」真諦發揚光大。

各位電子報的讀者新春快樂！在這次的專欄當中，筆者要從 GnuPG 的基礎切入 Web 2.0 的世界，點出發展網頁服務的可行方向。GnuPG 與 Web 2.0 乍聽之下實在是沒什麼關係，究竟是怎麼一回事呢？且聽筆者慢慢道來……

在自由軟體／開放源碼軟體的世界中，說到隱私與保密，一定會提到 GnuPG。GnuPG 的技術背景是非對稱性的公開金鑰加密法，因此許多相關的文件、文章，都大量著墨於這些加密法；公鑰、私鑰、簽章、憑證、指紋等專有名詞，也是這些文章當中所少不了的關鍵字。

然而，對於終端使用者來說，GnuPG 到底如何利用階段金鑰、如何使用質數來運算，一點兒也不是重點；真正重要的事情是要如何來管理 GnuPG 金鑰與鑰匙圈。如果我們不在意一份加簽文件的簽署者是不是真的如簽章所宣稱的人，那麼再嚴密的演算法也可以輕易偽造簽章；如果不在意收件者的公鑰是否真的屬於該收件者，加密法再嚴苛也守不住秘密。

GnuPG 這套方法，首先要求使用者確定特定的金鑰是否屬於某個實際的使用者，使用的手段包括人與人實際見面、檢視彼此的有效證件、以白紙黑字的方式查核金鑰 ID 與指紋等。接著 GnuPG 再以金鑰加簽的方式，讓金鑰之間能夠互相「背書」；在理想的 GnuPG 實務當中，簽署一把金鑰，代表使用者對另一個使用者的金鑰經謹慎驗證，並且公開地將驗證結果表達出來，讓其他使用者可以用於參考。

最後，GnuPG 讓使用者可以設定「主觀信任」──使用者可以決定自己對「另一個使用者驗證他人金鑰的過程」有多信任，這種信任資料不會公開出來，但是卻能幫助使用者判斷未知的金鑰。舉例來說，如果你完全信任葉大雄，認為葉大雄對他人金鑰的簽署必經嚴格縝密的考核，那麼葉大雄所簽署過的金鑰，對你來說也會是有效可用的金鑰；如果你對葉大雄的驗證能力祇有半信半疑的程度，對於源宜靜的驗證能力也祇有半信半疑的程度，可是葉大雄跟源宜靜都簽署了武技安的金鑰，則武技安的這把金鑰對你來說或許就是有效可用的了。當然，如果你完全不信任葉大雄，那麼他簽署過的金鑰通通當做沒簽署過，也是天經地義。

GnuPG 這種由主觀信任搭配金鑰簽章，推測未知金鑰的有效性的程度，也稱作「客觀信任」；這整個機制在 GnuPG 當中稱作「信任網」，由信任關係延續交織成的虛擬網絡，默默地成為 GnuPG 世界中的重要根基，讓公鑰網絡成為資訊時代最穩固、有效的人際網絡之一。

信任網的運作，能帶給我們什麼啟發？

近年來隨著網頁科技的發展，社交網站把網路使用的人口帶往新高峰；各種社交網站及人際網絡網站不外乎提供每個使用者代表自己的網頁，然後讓使用者能夠與其他使用者建立連結。這些網站都能讓使用者設定「朋友」，有的網站則有提供「朋友」、「同事」、「家人」等多種人際關係；多數的社交網站當中，這些人際關係都是單向的，亦即你是我的朋友，我卻不見得要是你的朋友，不過也有一些網站，要求人際關係的更動是雙向、且需兩造都同意纔能成立。

幾乎所有這類的社交網站，都會把這種人際關係公開揭露出來，讓所有的使用者都能夠看到你有哪些朋友、認識那些人；人脈成為一種能力的展示，也成為這類網站使用者的經營重點。有些網站讓使用者可以互相撰寫評價「背書」，這跟 GnuPG 信任網中金鑰互相簽署很像，都是公開表達使用者之間，不祇是單純知道對方而已。然而現有的社交網站當中，能夠對映到 GnuPG 信任網的功能僅止於此，所以會有一些難以處理的狀況：

第一個情況是「損友」：你總會認識一些人，有些事務往來，但是如果可以的話，會希望盡可能避而遠之；當你到了下班時間後，最不希望的就是被這些人打擾，與這些人的私下交往對你來說完全是浪費時間。或者反過來，你也會有一些酒肉朋友，平常一起喫喝玩樂，但是你真的知道，這些朋友在行事上完全靠不住，事業上招來的麻煩比助益還多；這些人，以及經由這些人而找上門來的其他人，都不會是你想要的合作、聯繫對象。以 GnuPG 信任網的術語來說，這些都是你主觀「完全不信任」的部分。

雖然你不信任這些人，但不代表你會想跟他們交惡；與人交際，少一個敵人總比多一個好。所以站在人性的角度來看，我們需要一個網站，除了表面上的和氣，還能讓使用者對自己的人際關係品頭論足一番，而且這些資訊祇有該使用者自己能夠取得，沒有任何其他方，能以任何方式探知箇中秘密。

另一方面，基於隱私之必要，你也會有一些好朋友，但是你們的友誼並不適合任意公諸於世；這可能是為了利益迴避，例如分別扮演著黑白手套的死黨，或者是你們之間有不倫的關係而不可告人。不論原因是什麼，這些朋友都是你的人脈，祇不過都不是其他人能藉你動用的人脈。在 GnuPG 的信任網模型當中，這種關係可以由主觀信任搭配（金鑰）本地簽章來表達：你信任某個人，但是這種信任關係及背書並不公開。

換句話說，你跟那些人有交集、你的人際網絡如何伸展，應該是由你決定要如何披露。真正有價值的人際關係，是個人隱私的一環，不應該跟八卦網絡搞混；參與八卦流通固然吸引人，但是不該為此犧牲交友的隱私。

現在的社交網站缺乏這些功能。或許你可以選擇公開所有的人際關係，或者不公開所有的人際關係，但是沒辦法選擇祇公開某些人際關係，也沒辦法對人際網路中的某一部分標記為不信任，因此許多社交網站就算造就了大量有著眾多親朋好友的使用者，充其量也就是某種遊樂園，難有「家」一般的長久歸屬感。

當每個社交網站都是如此時，也難怪有人說「Web 2.0 就是到每個網站建立帳號，然後一次又一次地（把同樣的一群人）加入好友」了。每個網站都是如此相似，唯一不同的是每個網站各有其核心小圈圈；對於不在核心小圈圈的普羅使用者，則祇能隨波逐流，四處飄蕩。長久下來，除了產生大量無活動的使用者帳號，消磨了許多人寶貴時間外，不見得有什麼建樹，實在很可惜。

人際交往必有親疏之別，建構社交網絡時自然不可天真地一視同仁；GnuPG 多年來用信任網的模式打下了穩固基礎，正是時下 Web 2.0 社交網站還須學習的：讓使用者能夠放心且便利地掌控信任關係，使社交網絡中的每個「人」更為鮮明，纔是把抽象網絡轉換為實質功能的入場券。

過去幾年間，軟體業從手工製造業轉型為服務業的趨勢越來越明顯：願意掏錢出來的使用者各有不同的奇怪需求，鮮少有什麼軟體可不經調整就滿足所有的使用者。在經濟不景氣的現在，仍然有人願意花四十萬客製一台腳踏車，而對軟體業來說也是如此：客製化能力纔是真正的收入來源。

隨著這種服務業的概念日益篤定，軟體業出現了「訂購服務」的消費方式，也就是消費者（使用者）花錢購買的並非一項軟體資產，而是一段時間內的使用權利及軟體業者提供的維護支援、軟體更新等。這就好像捷運一日券，你在合約時限（一天）內可以隨意地搭乘捷運往來各站，使用捷運站內的洗手間，請求捷運服務人員協助等，但是無論如何也不可能把捷運列車開回自己家，因為你沒有買到捷運，祇有買到時限內使用捷運的權利。

這種訂購軟體服務（也有人稱作「軟體租用」）的商業模式已經不是一天、兩天的事而已，但是並非各地的使用者都能馬上接受；畢竟在傳統產業的年代，經濟活動都是圍繞著具體的「產品」產生，有人生產物品，有人購買物品，有人收藏物品，許多人也習慣把軟體當做「物品」來看待，期待花了錢就可以在接下去的一百年間擁有它。

事實證明，當使用者發現事情跟自己的認知不同時，最是憤怒。

Six Apart 公司以部落格系統 Movable Type 聞名，這套系統的源碼從一開始就是攤在使用者面前的──取得軟體的同時，使用者就能夠看到每一行程式源碼，甚至能夠自行修改以滿足各自的獨特需求。然而當時的 Movable Type 卻不是一套開放源碼的軟體，使用者雖然能夠看到所有的程式源碼、能夠修改所有的源碼，但是卻沒有公開散播修改後的版本的權力；這種模式可以稱作公開源碼或分享源碼，但源碼從來不自由、從來不是真正的開放。

問題是許多使用者習慣了開放源碼軟體，誤以為 Movable Type 也是如此開放，於是當 Movable Type 3 上市時，Six Apart 公司刻意強調了 Movable Type 並不自由，並且激進地採行了嚴苛昂貴的授權方案，讓許多人非常憤怒。那一年，Movable Type 流失了大量的使用者。（這個事件導致成熟度低很多、但開放源碼的部落格系統 WordPress 使用族群大增，不過那是另一個故事了。）

多年之後，Six Apart 重新找到了安撫使用者的方法。Movable Type 4 除了依舊有昂貴的商業版本外，同時也提供了開放源碼的版本，叫 MTOS，Movable Type Open Source，按 GPL v2 授權，包含 Movable Type 一切核心主要功能，同時不提供任何額外服務或支援。

開放源碼不祇讓 Movable Type 重新獲得使用者重視，同時也有助於軟體的開發與維護，因為開發社群在開放源碼的前提下，比較有意願對軟體做出貢獻。同時，Six Apart 繼續提供針對企業用戶所做的客製化功能如 LDAP 整合、Oracle 及 SQL Server 支援、其他技術協助與支援等，給願意負擔高昂費用的使用者。現在你可以自己看著源碼，投入自己的時間力氣來搞定各種難纏的技術細節，或者花錢讓 Six Apart 幫你安裝、升級。

當核心程式碼的資產價值降低後，使用者就能夠接受「免費資源、付費支援」的模式，巧妙體現了資本主義世界中「花錢省時間、花錢換人脈」的現實。

這種以「支援服務」、「特製功能」作為營運模式，以「開放源碼」打入市場的公司，也越來越多，最近紅起來的 XMind 就是一例。

XMind 是一個心智圖的 Eclipse 軟體，標榜能夠即時把心智圖轉換成資料表格、魚骨圖等多種圖表的能力，雖然開發初期就受到重視，但是一開始祇有付費購買方案的 XMind 卻面臨著高不成、低不就的窘境，論功能比不上 MindManager，論自由度比不上 iMindMap，論售價比不上自由軟體 freemind 優勢，論速度也沒有比前述任何一套好，因此許多心智圖的愛用者始終處於「觀望」的態度，把錢留在口袋裏。

上個月 XMind 推出了 3.0 版，同時改變了銷售商業模式。XMind 3.0 版同時按 EPL（Eclipse Public License） v1.0 及 LGPL v3 兩種開放源碼授權釋出，這對於開放源碼界或心智圖界來說，都是不容忽略的事；因為 freemind 除了是開放源碼軟體，在售價（零）及檔案格式上具備優勢，而獲得如 XWiki 等系統支援，並成為各大心智圖軟體與線上服務都必然要支援的格式外，平心而論，並不是個適合用來繪製心智圖的軟體。freemind 太硬了，相當嚴重地限制了心智圖法中對於心智、情緒投影的表達能力。而 XMind 的源碼一旦開放，就表示 freemind 馬上受到正面挑戰，不再是開放源碼界的唯一選擇。事實上，由於 XMind 開放源碼化，台灣也迅速出現了 XMind 使用者社群，以及參與 XMind 開發的社群。

XMind 把所有稍微進階的功能都放在要付費使用的 Pro 版本上，包括了簡報、聲音註記、甘特圖、匯出成 Word／PowerPoint／PDF／MindManager 等格式、透過網頁（但不公開地）分享、製作局部畫面快照（MapShot）、待辦事項、圖庫、樣式管理等。但是不像 Movable Type 訂價一下子從 0 跳到 395.95 美元（大約合 13,300 台幣），XMind 用了前述的訂購服務模式來降低入門門檻：交出六美元，就能在一個月內使用上述種種加值功能。

這是個很巧妙的策略，一方面用開放源碼來吸引社群關注及參與，另一方面則用訂購服務模式變相地把早先的試用期轉型成加值，再把線上服務（XMind Share）的部份也併入付費加值方案，提供更多使用彈性，讓使用者接受自己的錢買到的不是物品，而是服務。當然 XMind 究竟能擴展多少市場，還是得回到程式本身到底成不成熟、功能是否滿足使用者所需；以目前的情況來看，XMind 還有非常大的改善空間。

不過再回頭看看心智圖界的龍頭老大 MindManager，其實也用類似的方式操作：使用者花錢購買 MindManager 主程式，然後花更多錢多買一套 JCVGantt 甘特圖暨計畫管理模組，有需要的話再付費訂購以月計算的 Mindjet Connect 線上服務，以及網頁版的 MindManager Web……線上付費機制（尤其是小額付費機制）的便利，加上網頁科技的進步，讓這種商業模式變得越來越可行。

對於開發公司來說，雖然一開始使用者負擔的支出並不多，但隨著重度使用者逐漸培養出來，以及需要用到進階功能的企業用戶出現，訂購服務模式也意味著持續的收入，讓開發商的線上服務收益也有機會跟上主機成本的成長幅度。

蠶食總比鯨吞容易，現在早就不是有辦法靠一個產品上市造就億萬富翁的年代了，讓開發者願意參與，讓一般使用者願意掏出小錢，讓大企業願意掏出大錢，纔是開放源碼專案走上商業之路的生存之道。

推特（twitter）跟噗浪（plurk）打著「微型部落格」的旗幟，最近越來越紅，佔據了多少人掛網時光，儼然成為當代殺手級網頁服務。然而在推與噗之後，又留下了什麼呢？

舉例來說，使用者並不會堅持祇能在 Twitter 寫「我正在做什麼」，對於 Plurk 的 karma 的認知也不見得是原先設計者所想的「報應」──但這並不重要，重要的是人們從中持續發掘出不同的樂趣與用法，也提供更多社交的材料。Twitter 也好，Plurk 也好，對於這些意料之外並不多做限制，讓使用者樂在惡搞，也成就了 Web 2.0。

這些「微型部落格」在最近幾年格外引起注意的原因之一，在於他們迅速地產生了大量網頁，這些網頁就跟部落格一樣各自有其靜態鏈結，也常常連到其他網頁；而且由於內容很短，讓使用者寫起來如囈語般隨興，所以產出頁面的速度很快就超過了「傳統」的部落格。數量多、更新頻繁、互相連結、靜態網址等，正好切中搜尋引擎的索引偏好，使得他們成為網頁世界中令人無法忽略的存在。

然而認真地重新加以回顧，卻會發現這股浪潮並不如表面上那般堅挺。首先，以網頁服務來說，Twitter 與 Plurk 都是狀況頻仍的網站，維修、資料庫斷線、網站連不上等情事，隔沒多久就會發生個一次。近期所傳出的 Twitter 入侵事件，也證明了這些網站可能充滿著安全瑕疵，無法提供安全無虞的服務。

微型部落格並且喜歡使用「縮短網址」的服務，喜歡到了會強迫執行的地步：不論使用者輸入的內容多短，有網址必縮；網址縮短的同時，讓人不能一眼看出自己會連到哪裡去，也造成一些安全疑慮──事實上，的確已經有藉此散播的微型部落格病毒在四處流竄。

若以網路分散性的角度來看，這些微型部落格都是中心化的社群網站，使用者就算能透過 API 而使用多種不同的軟體、平台，終究要在同一個網站上做各種事；一旦這個網站連不上，所有的人就一起再見；一旦這個網站出了意外，所有人的貢獻就一併遭殃；每個使用者就算可以決定自己帳號下的頁面外觀等，終究還是受到整個網站的固有限制。

在從內容來看，微型部落格的氛圍跟傳統部落格並不相同，後者多少會讓人想要有頭有尾地完成什麼，前者則比較不受拘束，簡短的幾個字詞、語句，也能站在網頁舞台上。這兩種運用文字的的方式各有其優劣，但是輕薄短小的文字大量生產出來之後，卻會引起原本未受重視的情況。

第一個情況是，網頁產生的速度又膨脹了數倍，打破了原本搜尋引擎用以評斷網頁重要性的前提假設；因此我們會觀察到這些微型部落格的 Google Rank（或其他搜尋引擎的重要性評比）迅速提高，而後隨著搜尋引擎修正，又降了回來。這是技術遇到人的問題：當人們運用文字的習慣、目的、方式都跟以往不同，相關的程式就得要順應這種變化，做出修正。

第二個情況是，當文字零星片段地呈現時，在法律上的地位就會有所不同。著作權法雖然保障任何著作在完成的那一刻，著作權人即擁有一切法定權利，但是實務上對於「著作」的認定卻不會遍及所有發表在網頁上的內容。舉例來說，任何人都可以在推特上寫下一句「今天好無聊喔」，並由推特的系統，產生出這麼一個祇寫了句「今天好無聊喔」的網頁；然而在正式的法律訴訟當中，要這麼主張這句話的著作權，並不容易。換句話說，法律上不見得會認定這樣的網頁作品，是一份「著作」。

這並不見得是說微型部落格難以受到法律保障，而應該視為現今科技應用對法律的挑戰：法律要如何看待這種著作方式、如何權衡取捨眾人權利，更動遊戲規則以順應時代？在此之前，微型部落格上的內容也會因此受到兩方勢力牽扯，一則是著作內容更容易被挪用、侵犯，另一則是某些意見與精神也將更不受限地，由這種耳語似的管道往四方蔓延。整個問題又邁向另一個層次：法律在此應該扮演核種角色？應該要試圖把這些使用方式納入規範，或者乾脆當做化外之地置之不理，任其自身演變出私有國度的律法？

面對重重難題，不論是科技、法律、人，三個環節都激起了無限漣漪，其中最有趣的，卻又是人們對這些問題的當下反應──「那又怎麼樣？」推者仍推，噗者益噗；這裡當掉了就去那裡抱怨，那裡連不上就回這裡咒罵，喃喃自語接連傾倒，「我聽朋友說，朋友的朋友如何如何」式的八卦吸引了更多耳目，是不是真有其事反而就不重要了。

原來，他們從來就不是殺手，而是現代人打發時間的新模式，一如有線電視上百個頻道，電視機前的寂寞靈魂卻是徹夜拿著遙控器，不停地轉台。這裡既沒有救贖，也不是人生旅途的終點；發生了很多事，也跟什麼都沒發生一樣。「過程比結果更重要」的哲學，或許就這樣在本世紀初，以前人所未曾設想過的這種媒介，得到了絕佳應證。

剛好去年底（其實就是前兩天而已）在廚房發現到有可以搭配的材料，就隨手亂做了蘋果紅茶，還蠻受家人歡迎的，而且成功率極高，作法簡單又迅速，於是在這邊就很不要臉地寫出來給大家參考一下。

1. 用煮沸的開水沖泡紅茶包到八～九分滿，差不多就是離你想要喝的量略少一點就可以了
   
2. 靜置一分鐘，茶湯顏色比你平常喝紅茶時的略深一些沒關係，稍微會澀也不要緊，不要太誇張就好
   
   然後就可以把茶包拿去丟掉了
3. 用湯匙挖出滿滿的一匙蜂蜜生蘋果醬，喜歡清淡一點的話可以挖少一點
   
4. 把整湯匙的蜂蜜生蘋果醬放進茶杯，攪拌均勻就可以喝了！因為蜂蜜生蘋果醬平常要保存在冰箱中，所以得攪拌久一點纔會溶開，要有耐心喔！
   
   蜂蜜生蘋果醬裡面會有蘋果果粒，湯匙可以留在杯子內，飲用時更方便！

如何，很簡單吧！冬天喝這個很幸福喔，悄悄泡一杯給另一半，更是有意想不到的妙處（以下略）！

cd /usr/ports/www/awstats/

sudo make clean deinstall reinstall

如果是全新安裝的話則是用：

sudo make clean install

接著要來把原本是 Big5 編碼的繁體中文語系檔改為 UTF-8 編碼：

cd /usr/local/www/awstats/cgi-bin/lang/

sudo cat awstats-tw.txt | sed -e 's/big5/utf-8/' | iconv -f big5 -t utf-8 > awstats-tw-utf8.txt

sudo mv awstats-tw-utf8.txt awstats-tw.txt

別忘了還有工具提示的語系檔：

cd /usr/local/www/awstats/cgi-bin/lang/tooltips_w/

sudo cat awstats-tt-tw.txt | iconv -f big5 -t utf-8 > awstats-tt-tw-utf8.txt

sudo mv awstats-tt-tw-utf8.txt awstats-tt-tw.txt

接著是設定（有需要的話），可以參考 /usr/local/www/awstats/cgi-bin/awstats.model.conf 來做，並不難。修改好的設定檔存成 awstats.FOO.conf，其中 FOO 就是這個設定檔的「名字」，等一下會用到。

最後是最重要的一點：用靜態網頁模式來使用 AWStats，這樣可以保證絕對的安全，也就是不會讓歹人有機會利用 AWStatas 可能的安全漏洞入侵你的機器（多年前我還很菜的時候吃過這種虧）。我現在用的是這個 Makefile：

Makefile:

YYYY    !=      date -v -1d +%Y

MM      !=      date -v -1d +%m


AWROOT  = /path/to/html/output/

DIR     = $(AWROOT)/$(YYYY)/$(MM)

update:

        /usr/local/www/awstats/cgi-bin/awstats.pl -update -config=FOO

output:

        mkdir -p $(DIR)

        cd $(AWROOT) && find 2*/* -type d | sort -r | sed -e 's#\(.*\)#<a href="\1/">\1</a><br>#g' > index.html

        /usr/local/www/awstats/tools/awstats_buildstaticpages.pl -config=FOO -dir=$(DIR) -awstatsprog=/usr/local/www/awstats/cgi-bin/awstats.pl -year=$(YYYY) -month=$(MM)

        cd $(DIR) && ln -f awstats.FOO.html index.html

這樣以後要更新資料（把 log 處理成 AWStats 資料檔）就用：

gmake update

然後要做出統計網頁（把 AWStats 資料檔做成靜態網頁）的時候就用：

gmake output YYYY=四位數的年份 MM=兩位數的月份

如果你發現不會動的話，別忘了調整一下各目錄及檔案的讀寫權限。