COSCUP 2019：褪下志工服，穿上講者裝

這真的是我這次參加 COSCUP 2019 的寫照。  XDD

上次參加 COSCUP 是 2013 年，也就是擔任過多次總召的 BobChao （推特/噗浪/臉書）被我慫恿、終於狠下心衝國際會議中心 (TICC) 的那一年。剛好，那幾年 Open Data 很紅，我在那一年主持了「Open Data 面面觀」座談會，重量級的與談人張善政、莊庭瑞、翟本喬、高嘉良都是老朋友，算是官、學、產、社群都到齊了，相當難得！

To charge or not to charge, that is the question.

台灣開源界一年一度的大拜拜 COSCUP 從創立以來一向不收報名費，但也不斷有人認為應該要收。我在商業公司工作，我並不反商，使用者付費沒什麼不對。不過對於 COSCUP，我有不同的想法。

COSCUP 和一般學術或技術研討會一樣有專業的演講，但最大的不同是在現場才能感受到的無私分享、熱情和歡樂！

因為 COSCUP 很特別，「人家研討會都收費，為什麼 COSCUP 不能？」這句話未必能直接套用。

COSCUP 從 2006 年第一屆以來，一向是免費報名、報到名才能入場聽講，而活動所需費用都從贊助金支應，相對會給贊助單位一些權利，如大會演講、技術演講、攤位、手冊中的廣告、大會網站上的品牌露出等等。

從財務的角度來說，雖然 COSCUP 每年開辦時都不確定能找到多少錢，但感謝各界熱情贊助，每年量入為出之後都還能留一點未來的雨天基金。COSCUP 的財務報表並不需要有「報名費」這項才能收支平衡。

從經營的角度來說，Yahoo!、Pixnet、Google、Facebook 等等公司提供免費網站，Angry Bird、RoboDefense 等等手機 App 有免費版本，Freemium 也是廣為人知的名詞。營利的公司都能用免費產品或服務生存了，不以營利為目的的 COSCUP 如果要向與會者收費，需要充分的理由。

而且，收費研討會和免費研討會的差別不是帳簿上多一項少一項而已，而是本質上的不同。比方說，幾年前在邀請某國外講者時，曾被問到 COSCUP 是否收報名費，如果收的話，該講者的公司規定不能由公司支付旅費，就要由大會出。同時，即使會眾獲得的比付出的報名費多很多，也不免有會眾持出錢的是大爺的想法，破壞了大拜拜的歡樂氣氛。

我不想寫太長，只總結幾個點供大家參考：

• 收報名費不只是量變，而是質變。
• 收報名費後，某些會眾的心態可能不再是「參加大拜拜的朋友」，而是「消費者」，破壞了大拜拜的歡樂氣氛。
• 收報名費後，視訂價策略，可能會改變會眾組成。
• 收報名費後，視訂價策略，總人數可能會降低，隨之可能會影響某些公司的贊助意願或金額。
• 收報名費後，某些公司不再能幫講者出旅費。
• 收報名費後，報名網站應該不會擠爆了。但照說這是技術問題，有技術的解法。

補充一下會眾組成部分：收報名費可能會減少學生的參與。未來的新星是今天的學生，我認為讓一定比例的學生參加是必要的。另一方面，確保工作忙碌的長輩大神們有時間報名也是必要的。在一位難求的這幾年，大會用 VIP 票制讓大大們不用搶就有票，確保大拜拜的本質，也兼顧了學生參與的機會。

收來的報名費要如何使用也是個要考慮的問題：

• 如果用在人事費用，無酬志工和有酬雇員之間的關係和籌備團隊內的氣氛可能會有不小的化學變化。
• 如果用來分攤活動費用，如前所說，COSCUP 不需要報名費就能打平收支。
• 如果用在贊助台灣社群活動，如乃特所說，不是件容易做好的事。而且本來就可以在 COSCUP 大會期間募捐，報名費不是唯一募得社群活動經費的方法。

我不能預測未來，或許有一天經濟大環境或廠商生態改變了，造成 COSCUP 的贊助收入不足。但是只要大家對 COSCUP 有心，一定能找到出路，募捐、義賣 T-shirt、午餐自理、… 等等，有太多方法可以打平收支。（OS：我好想買 COSCUP T-shirt 啊！）

而我最不希望看到的，是因為收費或其他原因，讓 COSCUP 失去獨有的無私分享、熱情和歡樂。

那一年，我們一起辦的 COSCUP 2011

艦長日誌：COSCUP 星曆 6086.20，天氣晴。

不知道為什麼 2011 年的工作人員名冊中我變成艦長了... 一定是從某位自稱船醫的喬巴（Chao Bob）開始的。

（咦？船醫被某人黑去做了？喂！船醫變成輪機長，這樣真的可以嗎？ XD ）

在新艦長啟航前，趁還有點記憶，側寫一下 2011 年的 COSCUP。

在 COSCUP 星曆 5103.11 我們組好了艦橋團隊，正式啟航。

• 投稿人的命運規劃局局長 Freedom（議程）
• 募款實力超強的特種精英 Ernest（銷售）
• 比魔球經理還熟悉數字的 Lloyd（會計）
• 團隊裡許多人的好姊妹小菲（行政）
• 讓大家知道 COSCUP 是個更好的世界的 Bob（行銷）
• COSCUP 的命運化妝師 Laetitia（公關）
• 做網站火力拳開到 Mozilla 的 Paul Rouget 讚不絕口的 Timdream（網站）
• 今年終於可以嘴砲的立夫（線路）。
• 讓大家在報名時大玩鐘點戰、晚來就極速秒殺、還要幫中國大陸朋友辦入境手續特別服務的 Choupi（會眾）
• 玩咖兼宅爸的 Jouston（輔導）
• 謀殺許多底片和記憶卡的殺手小朱盆栽 Yurenju（記錄）
• 要問清楚「先生你哪位？」的報到處、讓大家不必外出用餐的餐點組、讓門當證不對的人不得進入的門神組，他們共同的領隊當然就是在會場上上下下的翻滾吧！三秒（場務）

開放源碼軟體不准為惡？

今天有條新聞的標題很有意思：

• zdnet 中文新聞：授權條款加入「不為惡」 Google拒代管
• cnet 英文新聞：'Don't-be-evil' Google spurns no-evil software

Google 的源碼代管服務 "Google Code" 的服務對象是開放源碼的軟體，在 Philosophy 頁裡的任務說明寫得很清楚：

Mission Statement

To support the open source community by providing a scalable, reliable, and fast collaborative development environment for open source software, docs, and standards that promotes best practices in open source software engineering.

問題是：在開放源碼軟體授權條款中加上一條「不得用此軟體作惡」，這個軟體還是不是開放源碼軟體？

這個問題可能要由律師回答，但我個人的看法是：加上這一條軟體就不再是開放源碼的了，見 Open Source Definition 的第六條，摘錄出來：

6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

「授權條款不得限制任何人在特定領域使用該程式。」

作惡的領域也是個領域，依第六條的精神，開放源碼軟體不能要求使用者不可用它作邪惡的事。

如果採取 Open Source Definition 的定義，規定軟體不得用來作惡抵觸了這一條，因此軟體就不再算是開放源碼軟體。

代管非開放源碼軟體既然不是任務之一，Google 請加上不作惡條款的 JSMin-PHP 離開 Google Code，看來是合理的。

軟體創作者有權利為自己的軟體加上任何授權條款，別人沒什麼好干涉的。所以 JSMin-PHP 作者有天賦的權利，要求使用該軟體的人不得用它來作邪惡的事。不過話又說回來，如何界定什麼事是邪惡的？

1. 用 ssh 和偷聽到的密碼進入他人的系統算不算作惡？
2. ssh 進去後，偷系統裡的資料算不算作惡？
3. 如果以上兩個行為是資訊兵在兩國交戰時入侵對方的系統，對自己的同胞算是作惡還是英勇戰績？對敵人來說呢？

或許這是為什麼法律條文中不會有邪惡這個字的原因。

自己的條款違反了開放源碼的定義，還要炒新聞謿諷代管服務，實在有點失格了。

Chrome OS 源碼釋出！

Google 官方部落格今天貼出了一篇文章 "Releasing the Chromium Open Source Project"，也召開了一場有 webcast 的記者會，正式宣布 Chrome OS 的源碼開放了！

Chrome OS 的開放源碼專案叫做 Chromium OS，官方網站放在 chromium.org 上。

這應該連 Alpha 版都不能算吧？是 "Release early, release often" 原則下的結果。「及早釋出」這個原則對大型開放源碼專案很重要，尤其是 Chromium OS 這種要整合 kernel、xorg、clutter 等其他源碼的專案，更是如此。不然內部程式可能會越改離 kernel 或 clutter 這些上游（upstream）的最新源碼越遠，最後要和上游整合就會極為困難。

想嚐鮮的人，可以下載源碼，再用 image_to_usb.sh 裝到 USB 隨身碟，不用洗掉電腦裡的資料或作業系統就可以玩 Chromium OS 了；另外也可以把 image 裝到 VMWare 或 VirtualBox 裡玩。

記者會的展示機 Chromium OS 7 秒就開完機了，但是在我兩歲大的 EeePC 8G 上就要 23 秒，其中 11 秒在等 BIOS。

開完機就是登入畫面，可以用 gmail 帳號登入（不用打 @gmail.com，只要按 TAB 鍵 Chromium OS 就會補完順便把游標移到密碼欄）。

這個時候你需要網路連線，Chromium OS 才能知道你打的密碼對不對。如果 Chromium OS 還不支援你筆電的 WiFi 晶片，可以先插上有線網路登入一次，之後 Chromium OS 會在硬碟（或是隨身碟）裡存一份快取，再登入就不需要網路連線了。

登入後就會看到全螢幕的 Chrome 瀏覽器，我自己較常做的幾件事是：

1. ctrl-t 開新分頁，在 Omnibox 打入網址或搜尋關鍵字，連去要看的網頁。
2. 點螢幕左上角的圓形 icon 進入應用程式清單的畫面，再選個 icon 點下去，還是連去要看的網頁。
   
   
   
3. ctrl-w 關分頁。
4. ctrl-alt-t 打開熟悉的文字模式 command line terminal（打 exit 指令離開）。

像 Calculator 和 To-do list 這種小應用程式和一般網頁不太一樣，它們比較像 Gmail 裡的 chat window，只佔畫面的一小部分，從下方浮上來。但不一樣的是，不論你切換到哪個分頁，它會一直留在畫面上，方便你隨時使用。

Chromium OS 的授權條款是 BSD license，使用和 Chromium 一樣的 depot_tools 工具和 git 源碼管理系統，有興趣自己 build image 或開發 Chromium OS 程式的人可以照 Getting and Building a Chromium-Based OS 網頁上的說明做做看。

目前 Chromium OS 已經可以正常顯示中文網頁和 flash，在 EeePC 8G 上看 YouTube 相當順暢，可惜尚未支援中文輸入。Chromium OS 有一份文字輸入的設計文件，我摘錄幾個點出來：

1. 使用的 input method framework 將會是 ibus。
2. 正體中文的輸入法將會有倉頡、注音、酷音。
3. 選字窗、設定介面、文字切換選單都會重做，以符合 Chromium OS 的使用者體驗。
4. 設定會同步到雲端去，所以換一台 Chromium OS 登入也會有相同的輸入法設定。

會同步到雲端的當然不會只有輸入法的設定，基本上除了螢幕和鍵盤的實體參數可能因不同機器有所不同之外，大部分的設定都會在雲裡。

好了，記者會結束了，關機睡覺吧...

你如果已經裝好了 Chromium OS，你可能會發現：咦？沒有關機選單，要怎麼關機？

這提醒了我 14 年前看到的 SGI 工作站... 電源開關按鈕會啟動 shutdown 程序，所以可以直接按開關，為了這個還被老工程師罵過一次：「你怎麼連 sync; sync; shutdown -h now 都不知道？」這... |||

所以，我按下我的 EeePC 右上角的電源開關，Chromium OS 就關機了，對嘛！消費者用的電器就該這樣直覺。按開關打開，再按一次就會關掉。什麼叫做「要先選〔開始〕選單上的〔關機〕才可以關電」？太不人性化了。

關好機，睡覺去。

｛更正：修正下載源碼的連結，原文中打錯 URL 真不好意思！｝

Google Code 正體中文版上線了

〔宣告：作者寫這篇時任職於 Google，下筆時不可避免有 Google 的角度，但所寫文字不代表 Google 官方的觀點。〕

如果你今天連上 Google Code，在網頁最下方，應該會看到這行文字：

Google Code offered in: English - Español - 日本語 - Português - Pусский - 中文(简体) - 中文(繁體)

比以前多了一個「中文(繁體)」選項，選下去！

吔！Google Code 有正體中文版了！

中文版包括哪些開發者工具呢？點選網頁下方的「網站目錄」連結看看吧！

有 Android、Chromium（Google Chrome 的開放原始碼專案）、Google 應用服務引擎、 Gears、Protocol Buffers、Google Web 工具組這些開放原始碼專案的文件，和 Google Data API、Gmail Atom 資訊提供（"feed"）、Google 帳戶驗證 API、Google AdSense API、Google AJAX API、Google Analytics、Google 圖表 API、Google Finance API、Google 地球 API、YouTube 資料 API 等等應用程式介面的文件，我眼花了！一共有 66 個給開發者用的產品，每項的介紹頁都已經中文化了。

Google 的服務一向是先推 beta 版，再依使用者的回報來修改，Google Code 文件服務也不例外。

• 有些中文翻譯可能有 bug，歡迎回報。
• 網頁右上角有一行小字：「英文版或許有比此中譯版新的內容」，是的，中文版還沒跟上英文版的進度，所以有些較深入的文件還沒有中文版。

不過以 Google 的 API 和開放原始碼專案的更新速度，文件的翻譯版，不論是日文、俄文、西班牙文、還是中文，要追英文版恐怕不容易，所以先求有、再求好，先走廣、再走深，希望讓開發者對各種工具有個概略的認識，在開發網路應用時，知道有哪些工具可以用來加速開發的時程、或提高自己的應用在使用者心中的價值。

正體中文只有台灣、香港、澳門在使用，人口加起來約三千萬人，佔全球 0.5%。對 Google 來說，願意花資源提供正體中文的 Google Code 網站，可見 Google 對使用這個文字的開發者的重視程度。對 Google 來說，有流量才會繼續投入、提供更多 Google API 和開放原始碼的中文文件。希望大家多多愛用這個服務囉！

摻鉻的葡萄酒

今天看到 CodeWeavers 花了十一天把 2008/9/3 公開的 Google Chrome 瀏覽器的開放原始碼專案 Chromium 移植到 Intel Mac 和 Linux 上了。

不用太興奮，這不是 Google 說的 Chrome Mac 版或 Linux 版，而是摻鉻的葡萄酒（WINE）。

這個叫做 CrossOver Chromium 的東東，可以從這裡下載得到，但是沒有原始碼！

下載了 52 MiB 的 dmg 檔到手邊的 Intel MacBook，安裝起來約 139 MiB。可以跑，速度還可以接受，Omnibox 的 suggest 功能也正常，移動 Tab 順序時背後應該透明的地方變黑色了，把 Tab 拉出來變成獨立視窗沒問題，可惜拉的時候 Tab 內容就一片空白。這些都是小問題，但無法輸入中文是個大問題，每個字根都變成方塊。



CodeWeavers 自己也說，編出個 CrossOver Chromium 不是要給大家在日常生活中用，而是火力展示，引用 Jeremy White 的話：

In just 11 days, we were able to bring a modern Windows application across to Mac and Linux. Imagine what we can do for you.

換句話說，就像 CodeWeavers 的公司宗旨寫的，這是要證明 CodeWeavers 利用 WINE 把 Window 應用程式移植到 Mac 和 Linux 上的實力；照 Jeremy White 的說法，他們為了移植 chromium 還寫了新的 winhttp DLL 給 https 用。

這個摻鉻的葡萄酒，喝起來有點苦味。

Plurk source code 蛛絲馬跡：Python & MySQL

昨天開始玩 Plurk，先不說 Plurk 和 Twitter 或 Jaiku 的差異性在哪裡，網路早就有文章在討論了。有趣的是，今天在噗一個浪的時候，竟然看到了這個畫面：



顯然 Plurk：

• 是用 Python 寫的 :-)
• 用了符合 WSGI 架構的 amiweb，原始碼在 Skelotonz 專案裡，但今天下載到的和 Plurk 裡的行數不太一樣，也許 Plurk 用的是稍舊的版本，或是自己改過。
• 也用了 werkzeug 的 utils.py，本來想放個 link 指到 werkzeug 的 mercurial repository 的，無奈 werkzeug 的伺服器沒裝好，今天放在 mercurial 最新版的原始碼目錄是看得到的，但要看 utils.py 檔案內容就「Internal Server Error」了。
• 還用了 paste 的 translogger.py。
• 最後死在 MySQLdb 要連 MySQL 資料庫的時候，找不到 plurk_group006 這個資料庫。

是有人在「整理」資料庫時「不小心」弄爛了嗎？ XD

三評軟自協之二：評神經中樞

2007/11/25

自從去年 9 月寫了第一評《三評軟自協之一：怎麼會這樣？》之後，就準備寫第二評和第三評，大綱都擬好了，但是辦 11 月的 COSCUP 2006 研討會把我工作之餘的時間吃得精光，就擱下了。研討會結束後為了再給 SLAT 一次機會，要和 SLAT 辦 ICOS 2007 和 COSCUP 2007 的聯合研討會，總不好在與人合作的同時又公開批評，又按了下來。事隔一年，如今 COSCUP 2007 結束了，在一些社群朋友的敦促之下，今天就把這第二評發表出來。

在第一評中，我指出了讓傳承付諸流水、辦活動交差了事、與社群漸行漸遠這三個從「2006 自由軟體傑出應用推廣選拔大賽」暴露出來的問題。在這篇第二評中，我要指出四個 SLAT 的神經中樞病症：大方針付之闕如、理事會頻頻流會、理事們理念分歧、理事長被動消極。這裡我評論的基本上是第一屆到第三屆的理事會，其實也講到我自己，因為我就在這三屆理事會中，所以這也算是我對自己的反省和批判吧...

四、大方針付之闕如

一個組織，不論是營利的公司、還是非營利的協會／基金會／工會／公會等等，都需要一個願景（vision），如『做出人人可用體積最小的個人 GPS』、『消除對任何族群的岐視』、『讓本公司勞工的權益獲得保障』等等，再依願景、自身的能力、大環境等等因素決定組織的定位，然後訂出階段性的目標（goal），據以執行。有清楚的願景、定位和目標的組織，比較不會在日復一日的工作中迷失了方向，而在突發事件出現時，也較能找到最適合組織的應變方式。

對於新創的公司來說，願景和定位是創辦人在創立時或創立前就要決定的，再交由經理人來把公司帶到正確的方向。雖然願景和定位在不斷變遷的世界中未必是絕對不可變的，但在任何一個時刻公司都該有個「大方針」，引領大家向前走。

SLAT 的大方針是什麼？

是首頁上大大打出來的這二句嗎？（不好意思，那還是我當年寫的...）

• 以宣揚軟體自由的理念為職志,
  
• 以推廣自由軟體與開放源碼的使用和開發為己任。

還是在章程裡明列的宗旨？

為基於軟體自由及開放精神，推動相關軟體及其源碼於各方面之應用，並落實資訊分享之理念﹔藉由教育推廣與國際交流等活動，以促進軟體自由社群之發展，進而提昇軟體品質與技術水準，促成軟體發展的健全環境。

（不錯耶！至少現在 SLAT 有網站可以查宗旨這些資料了。）

還是其他？我現在不是 SLAT 的會員，看不到任何內部文件，只能假設大方針會是這兩者之一。

那 SLAT 是否在做任何決策時，會把大方針拿出來，至少參考一下？

這兩年我沒參加 SLAT 的決策過程，也許和以前不同了；我能說的是，之前的幾年在理事會裡討論事情時，極少從大方針或策略面來討論某件事該不該做或該怎麼做，而是任由各個理事依手邊的人脈或出現的機會來提案，理事們再討論。在一個大家都不拿錢做事的組織裡，這樣的情形是難免的，但是一定要時時把大方針拿出來校正所作的決策，不然會逐漸逐漸地變成一個反應式的組織（Reactive organization），碰到事情才來手忙腳亂地反應。主動式組織（Proactive organization）會預先決定好方向、再依出現的狀況微調。

SLAT 基本上是個反應式的組織。反應速度呢？我會在第三評裡講到。

SLAT 如果有大方針的話，應該是上面列出的兩者之一。SLAT 做的事是否符合這些項目？讀者可以自行判斷。

與其說 SLAT 沒有依方針行事，我倒認為 SLAT 根本沒有實際拿來參考用的方針。

五、理事會頻頻流會

SLAT 第一屆和第二屆的理事會是 15 人，所以每次開會要最少要有 7 個人出席才算是有效的理事會。「7 個人不多嘛！」你說。是啊！7 個人不算很多，但有時還是開不成。會是在台北開的，有的理事住新竹或更遠來不了，有的理事工作忙不能來，總之偶爾會湊不齊法定人數，只好聊聊天。聊天其實是很好的，應該多聊聊，因為在第二屆理事會之後越來越多的理事彼此不認識，先不論這樣的理事會能不能有「革命情感」來共同無償地推動一些事情，和不認識的人共同開會作決策就已經非常怪異了...

如果只是偶爾流會也就罷了，在 2005 年某常務理事提案希望擴大成 21 人並廣邀各界人士進入理事會，好像是想增加 SLAT 的影響力之類的。我個人反對，但理事會還是通過了。之後在會員大會也通過了更改章程，正式生效，也當場選出了21 位理事。2005 年底我因為別的事件辭掉了理事，聽其他理事說之後開理事會就幾乎沒有成功過，常常湊不足法定人數。

理事會基本上是社團法人的中樞單位，法人所做的事，最好都由理事會事先同意或事後追認，免得有爭議。理事會頻頻流會，基本上就是說有事情的時候都要靠理事長一人的判斷行事，而且還沒辦法事後請理事會追認，不用想也知道這樣的組織問題很嚴重。

SLAT 章程裡明訂理監事任期是兩年，但是 2005 年選出的第三屆 21 位理事在 2006 年的 ICOS 就改選了，而且又變回 15 人的理事會，見第四屆名單。

第四屆的理事長加常務理事共有 3 位在台北，15 位理事中也有 7 位在台北，只要在台北的人能全數出席，常務理事會和理事會都可以到達法定人數，祝第四屆理事會能成功開會囉！

六、理事們理念分歧

SLAT 的問題不是到第三屆理事會才開始的，從第一屆理事會開始，理事之間就存在著矛盾。矛盾有的大、有的小，個人認為最大的問題是「路線」：有的理事希望 SLAT 要多做事，包括辦活動、研討會（就是 ICOS），以實際的行動推廣自由軟體，讓更多人受益，為了能做事，不惜下海爭取政府的補助；有的理事希望 SLAT 不要拿政府的錢，以保持清高和批評政府的立場。

這兩種不同的做法沒有對或錯，可惜的是，理事之間一直沒有就路線好好地辯論一次，做出結論，然後全力往討論出來的路線上走。結果呢，每件新事情的出現都可能引起內部的激辯，想做事的理事不時會被別的理事套上「想把 SLAT 變成白手套」的大帽子。白手套？那是不是代表有隻黑手伸進去操縱？黑手是誰？

這種事情發生幾次之後，基本上就沒有人想提案做事了，犯不著做義工還被扣帽子吧？也因此 SLAT 逐漸變成「不作為」的組織。不少社群朋友公開問過：「SLAT 做了什麼？」理事們理念分歧是造成 SLAT 無法做什麼的主要原因之一，另外一個原因是執行力，等我的第三評吧！

七、理事長被動消極

SLAT 四屆的二位理事長都是我的好朋友，第一位理事長還是我的老師，所以寫這段文字的心情非常沉重，但還是不得不寫，希望兩位理事長如果看到這一段，能諒解我是對事不對人。

理事長在 SLAT 內部基本上是個被動而消極的角色：不太會主動表達自己想做的事，而是等理事提案出來，如果理事之間有爭議，再出面協調；更不會積極推動事情，而是等理事或工作人員在業務上有困難時，再想辦法解決。

理事長之所以變成這樣的角色，一方面也許是因為正職工作太忙，更重要的應該是因為理事們經常不合，理事長要保持中立和超然的地位。但不可諱言的，這樣的領導風格比較適合一切上軌道的組織，而不是正在披荆斬棘開疆闢土的組織。理應帶著大家向前衝的班長，變成支持班兵向前衝的後勤，班兵之間偶爾還要爭執一下要往哪裡衝，這個班能衝出什麼成績可想而知。

雖然如此，我還是要表達對兩位理事長的敬意。沒有這兩位理事長，SLAT 可能連最基本的行政秘書人力都生不出來；在舉辦前幾屆的 ICOS 時，兩位理事長也不遺餘力找出必要的資源來，社群朋友都該要謝謝這兩位理事長。

結語

理事長與理事會是 SLAT 的神經中樞，但一直到第三屆都有著相當嚴重的問題。第四屆我沒有參與，也沒有什麼二手的消息，不過從 ICOS 2007 和 COSCUP 2007 聯合研討會爆發出來的問題來看，恐怕也是問題重重。

第三評我會從執行面來看 SLAT。

三評軟自協之一：怎麼會這樣？

〔註：這篇文章是我在 2006/9/16 寫在我的個人 wiki 上的，因為主機當掉了，就把內容轉貼在這裡。 - 2007/11/25〕

文／Ping

2006/9/16

這次的「2006 自由軟體傑出應用推廣選拔大賽」原是一件美事，竟然被眾人批評得體無完膚，怎麼會這樣？

之所以會有這麼多瑕疵，原因很多，但最根本原因是兩個：

• 之前辦過相同活動，但沒把相關程式和經驗傳承下來。
• 必需另起爐灶，可是沒投入足夠的人力，為了趕時間而急就章。

從這兩個問題分析，我認為主辦單位 SLAT 犯了三個錯誤：讓傳承付諸流水、辦活動交差了事、與社群漸行漸遠，以下一一說明。

一、讓傳承付諸流水

自由軟體傑出應用推廣選拔大賽的第一次是在 2003 年舉辦的，後來於 2004 年再度舉辦，之後決定選拔大賽（FSSOC Awards）和技術性的自由軟體競賽（FS Contest）輪流隔年舉行，所以第三屆是在 2006 年舉辦。選拔大賽的規則基本上除了評審的組成之外，幾年來都沒有改變，因此只要把之前接受提名、e-mail 確認、徵詢被提名人意願、請評審審查資格、投票等等的程式拿來再用一次，就可以放心整個選拔大賽的程序基本上會以符合規則的方式進行。

2003 和 2004 年使用的程式是唐宗漢（唐鳳）用 mod_perl 寫的，在 OpenFoundry 上留了一個 FSSOC Awards 專案，原始碼可以從 svn repository 下載，2004 年給評審用的 mailing list 也在專案網頁上有歸檔，換句話說，該有的檔案差多不都找得到，剩下的只是弄清楚如何去用這些程式和文檔，這是 documentation 的問題。

在 2004 年辦第二屆時，就已經知道這是個要去爭取經費或募款來持續常態性辦理的活動。然而因為 SLAT 理事的任期是兩年（2005 年選出的理事不知為何是一年），下一屆選拔大賽舉辦時的理事已經是新一期理事會的人了，在下一屆接辦的人不知會是誰的情況下，怎能不趕快寫出一份「如何使用 FSSOC Awards 軟體和相關檔案」的文件，commit 進去 svn repository，供後人詳讀呢？

沒有寫下文件留傳，等於埋下了一顆地雷。這是對歷史不經心、對後人不負責的行為。若是辦一般社群活動的志工這樣子也就算了，有法律地位的社團法人這樣子不做為，造成日後活動的失敗，就是辜負了社群的期望。

歷史和傳承是一點一滴累積的，不花苦工累積，就會一點一滴失去。我認為沒寫文件這件事，只是 SLAT 眾多失去歷史、失去傳承的事情之一；另外一個很明顯的例子，就是 slat-talk 通信論壇資料的損毀。slat-talk 是 SLAT 成立後立刻建立的通信論壇，在上面討論的議題很多，許多人發表了很有深度的談論，也因為是 mailing list，發表人的 e-mail address 每個人都看得到，不太算有匿名性，所以惡意的人身攻擊並不多。現在的歸檔網頁，是從 2006 年 1 月才開始歸檔的，也就是說，2001 - 2005 這五年珍貴的歷史資料，很可惜的，已經遺失了。同樣可惜的是，訂閱者名單也一起失去了。

這樣子維護歷史資料的 SLAT，前幾屆選拔大賽的官方網站 http://fssoc.slat.org/ 會消失也就不意外了吧！

二、辦活動交差了事

這個活動原訂 7 月 8 日開始投票，但拖到 8 月 3 日才公告投票開始，猜測是因為另起爐灶而有所延誤。如果真的要表揚得獎人、讓得獎人有榮譽，在舉辦這樣的選拔時顯然要很仔細，每一個環節都要務求嚴謹，不能讓得獎人被他人懷疑得獎的正當性和公平性。

SLAT 做到了嗎？當然沒有！

誠然，拿到的舊程式是三不一可能的程式：『這個可能是完整的版本，不過不維護、不回答、不技術支援』，因此要讓它運作起來有一定的難度。但是，出現這個狀況不該讓警鈴響起嗎？沒有程式，選拔大賽程序如何進行？大賽程序無法進行，這個狀況難道不是嚴重的 show-stopper？

那 SLAT 有做什麼事去消除 show-stopper 嗎？看來也沒有！執行者的決定是自己重新練一個程式出來，但從零開始寫出一個完全符合規則的程式，除非是對規則了然於胸的 web 程式高手，不然一定要花上很長的時間。code reuse 是自由軟體的精神和重要原則之一，砍掉重練是萬不得已的手段。個人認為，當事人沒有想清楚，沒有採取消除 show-stopper 最有效的方法。

如果在辦活動時，連 show-stopper 都不儘力處理，那也只能說執行人和主辦單位根本不重視這個活動，並沒有想把它辦得盡善盡美。

這不就是交差了事？

三、與社群漸行漸遠

先講清楚，這裡所謂的「社群」是什麼。我自己對「自由軟體社群」的定義是：對自由軟體有貢獻自己的時間的人，而貢獻的方式可以是寫軟體、譯介面、寫文件、解決他人使用自由軟體的問題、辦推廣活動等等，廣義地說，凡是花時間讓自由軟體更好用或更多人用的人，都算是社群的一份子。

回到問題面來。臨危受命的執行人，碰到不會用但對活動具關鍵地位的軟體，該怎麼辦？

別忘了，這是自由軟體的活動，自由軟體社群和其他技術導向的社群的一個很大的不同，是它的開放性格。所以，不用害羞、不用覺得丢臉，直接向自由軟體社群求救吧！連 linux 裝不起來都能在 freesf.tnc.edu.tw、fedora.tw、BBS 的 linux 連線版等網路空間找到救兵了，apache 的 mod_perl 模組或用 mod_perl 寫的程式裝不起來，當然要搬救兵啊！自由軟體社群中不乏 perl 高手，看到這個活動需要急救，真的會置之不理嗎？或者換句話說，如果求救後，自由軟體社群寧願坐看這艘船沉到海裡去也不出手，不正可以解釋成社群不關心這個活動？真是如此的話... 也許不辦也罷，那至少也比後來的發展好些。

SLAT 有及時向自由軟體社群求救嗎？可沒聽說！

近幾年來 SLAT 因為 slat-talk 的消失和其他原因，平常並不太和社群交流。這也就算了，但是出這種緊急事件也不求諸社群，SLAT 和社群實在是漸行漸遠了。一個遠離社群的組織，不論是營利的公司或是非營利的協會，出面舉辦鼓勵有貢獻的社群朋友的選拔大賽，不很諷刺嗎？

在 SLAT 成立後第一次舉辦的研討會 ICOS 2001 中（喂！研討會的官方網站 http://twopensource.org/icos2001 也連不上了），我給了一場專題演講『社群近況報告 - 軟體自由協會』，向與會的社群朋友宣布了軟體自由協會的成立、以及個人對軟體自由協會的期許，我提出 SLAT 應該是 of the community, by the community, for the community（由社群擁有、由社群組成、為社群服務）的主張。這當然是從林肯大大那兒抄來的，私以為很貼切。雖然必未每個人都同意這個定位，但至少當初 SLAT 和社群是很貼近的。時至今日，不但 SLAT 的理監事會成員和自由軟體社群交集日漸縮小，連行事風格都離社群越來越遠，一嘆！

結語

這是《三評軟自協》的第一評，焦點放在和「2006 自由軟體傑出應用推廣選拔大賽」比較直接相關的三個問題：讓傳承付諸流水、辦活動交差了事、與社群漸行漸遠。對 SLAT 更一般性的問題的診斷，將會出現在第二評和第三評中。

COSCUP 2007 總算結束了

經過將近一年的風風雨雨，COSCUP 2007 總算辦成了，也結束了。

今年的 COSCUP 和去年第一次辦有些不同，但也保持了不少特色，就隨手寫幾條來... :)

• 乃特大的憤怒： 2006 年因憤怒 SLAT 而辦 COSCUP，2007 年因辦 COSCUP 而憤怒 SLAT。
  
  
• 議程平衡：兩年都有 coder/user/promoter 議程，但 2007 年較明顯偏重 coder 部分。
  
  
• 國際：2006 年沒有國際講者，今年有兩位國外講者，分別是 OLPC 的 Mike Fletcher 和 Google 的 Christophe Bisciglia。
  
  
• 對比議程：去年有 Web-oriented architecture 讓各個 web framework 同台較勁，今年有兩個對比議程：Linux-based laptop 與社群有華碩的剛上市沒兩週的 EeePC 與 laptop.org 的 OLPC，大規模運算則有學界（中研院）的 Grid Computing 與業界（Google）的 Cloud Computing。
  
  
• 傳統：中文資訊處理的議程算是從 OSW/ICOS/COSCUP 一路下來的傳統，今年不例外。除了輸入法持續有進展外，今年多了搜尋和動態組字這兩個新題材，非常有意思。
  
  
• 新加：今年多了嵌入式系統的議程，不過由於聯繫上的未盡完美，有的演講內容可能不如聽眾預期，明年要加強。
  
  
• 社群組織：今年的一大新趨勢是法人！moztw、study-area、tossug 都要成立法人，再加上已經成立的 Wikimedia Taiwan，open source / open content 界看來會有一些不一樣的狀況。這些組織（或是將成立的組織）都來 COSCUP 介紹自己，可算是歷史性的一刻啊！
  
  
• 最後... iPhone 可以倉頡輸入耶！