作者:許凱平 / 臺灣大學計算機及資訊網路中心程式設計組程式設計師
本文以資訊系統建置個案回顧的方式,提供欲採用開源軟體發展資訊系統之委託或開發機構之一個實際案例的經驗分享。內容涵蓋組織是否採用開源軟體之討論與決策,尋找、評比可能適用之開源軟體,以及採用過程中的所遇到的問題。
背景
林一鵬教授擔任計資中心主任時,就相當鼓勵計資中心同仁將程式變成開源軟體,直接貢獻給社會,也算是對於傅斯年校長「貢獻這所大學于宇宙的精神」的實踐。首先我們要了解的是,要將一個程式變成開源軟體並不是將程式碼放到網路上就算完成。程式師要先面對自己的程式碼,將秘密與客戶資料移除、加上必要的註解。在這個過程中,為了讓後續的程式師可以維護,對於程式碼進行適當的重構(Refactoring)與Code Review也是必要的。然後,還得撰寫詳實的說明文件,否則,諮詢電話與郵件很快就會將熱情淹沒。另外,適當的品管過程及採用也是必要的,若是裝起來就一堆錯誤訊息的軟體,我想即使是開放源碼,也難以說服別人採用。
在有限的人力與緊迫的時程壓力下,我們明白許多程式都是趕出來的,只是可以執行,不具「他人」可維護性。在那個時代,客戶通常不會要程式碼,當然不會有人在意程式碼的排版與架構;程式師也就確保了他的「不可取代性」:只有我能維護。這些員工會是組織的支柱,同時也是危險的罩門。一個有用的程式會有很長的壽命,這時就會有不只一個版本,多個程式師在不同時空參與。許多程式師被要求對舊程式賦加新功能的時候(時程:三個月),通常會跟主管提案以重寫的方式進行(對工程師來說,這是最佳策略)。在這個時候,主管會被要求給一個完整的建構時程(一年)。基於版本增加上的癖好(我們常會誤以為會比v2比成v1.1好),有企圖心的主管通常會同意如此進行。有時候事情不是那麼美好,要到一年後,才會發現新版還比舊版差。
開源「許多隻眼睛」效應是兩面刃,一方面用眾人之力將臭蟲找出來,另一方面也可能給駭客可趁之機。以「付款查詢」這項服務來說,如果做開源的話,駭客可能會有機會研究程式碼可能的漏洞,而加以入侵取得別人的收入資料。這些漏洞有些甚至是做開源之前不為人知的作業系統漏洞所造成的,即使做了完整的程式碼複核也沒辦法避免。所以在挑選程式貢獻給宇宙之前,自保與免責條款還是要先準備好。
2004年應中華民國資訊學會之邀,由我和臺大資工系學弟鄭先廷將先前兩批學弟妹所撰寫之「NEWS 即時互動教學系統」整理後貢獻至Open Source社群。2006年我將我自己開發、無關安全的使用者介面元件整理到程式碼共享網站「藍色小舖」,也獲得一些迴響(文章分享長期排名第六)。2007年又替Google Map製作程式撰寫提示,並在Google Developer Day與以前的同事楊允言老師一起組隊參加現場的比賽,並獲得第三名(前兩名都是網站公司)。但在缺乏實質回饋(累積經驗點數又如何),又跟本身工作沒有多大關係下,我也漸漸淡出。
雖然臺大計資中心四個組中有三個組早已大量使用開源軟體建構服務,但在筆者服務的程式設計組,在考慮各種因素之後,仍以微軟平台建構校務資訊系統。開源軟體在程式組也不是從沒有機會。2007年初,隨著Web 2.0風潮,組內也開始討論新一代的校務資訊系統該何去何從?各種軟體/解決方案一個一個被大家提出來熱烈討論,主要還是以開源的軟體如Ruby on Rail、PHPCakeWeb、Extjs、Dojo及Yahoo UI為主,幻想著軟體開發者烏托邦的降臨。在Che Guevara式的激情之後,我們還是得做出抉擇:開源的PHP/MySql或微軟.NET/Mssql?最後管理階層考慮開發工具的便利性與前瞻性,資料庫與開發平台繼續沿用微軟,開源軟體Extjs在前端也佔了一席之地。在2008年,前端部分因Extjs開發較為不易,又再改成美觀、易於開發又跨平台的 Flex(非開源)。我不時想起美國詩人 Robert Frost的那首「THE ROAD NOT TAKEN」,那條我們沒有踏上的開源之路可能會是怎麼樣?
「國家公園虛擬標本館」之建置計畫案由
在台灣特殊的地理環境與氣候呵護下,許多生物在這個小島上跨越地質年代繁衍至今,並演化成各種珍貴特有的物種。內政部營建署迄今已成立7座國家公園,用以保護自然風景、野生物及史蹟,並供育樂及研究之用。有鑒於研究人員在國家公園進行採集後將標本保存於各學術研究單位之事實,以及滿足國家公園為進行保育所需之各項統計,實需建置資訊系統進行統合。因此,營建署國家公園組林義野組長特委託臺大植物標本館館長郭城孟教授與計資中心陳信希主任進行「國家公園虛擬標本館」之建置計畫,以下簡稱「NPVM」(National Park Virtual Museum)。
計畫第一年為先期規劃,用以了解各領域專家研究之需求以及國家公園管理上所需之功能。第二年以實作方式進行規劃系統可行性之驗證。在陳主任與郭館長、林組長洽談本案的時候,正好筆者手上的憑證推動工作也接近尾聲,所以便被指派進行本案之建置,也藉此機會繼續探討是否能以開源軟體進行客制化資訊系統之開發,為將來校園資訊系統走入開源時代的可能性做前驅測試,也算繼續我的未竟之夢。
系統建構
資訊系統之獲取,不外取得既有套裝軟體、自行建置或委外開發等方式。套裝軟體通常能滿足資訊工作者之共通需求:例如文書處理軟體、作業系統等等。符合各種行業之特有需求的軟體通常不存在,因此通常需以客制化、量身打造的方式進行。委託者難以具體形容一個目前沒有的系統,是客制化開發的常見的問題之一,開發者也因此很難抓到客戶的概念。另外,在價格上,套裝軟體的開發成本由大量的發行均分,客制化軟體的開發經費卻是要由業主個人完全吸收,業主常會誤認價格不合理。
在價格競逐之下,接案公司通常是小公司或者個人工作室,基於成本考量,通常不會採用微軟平台(一個案子才十萬,買足夠的微軟版權可能還不夠),而使用免費的開源軟體做二次開發。這些人在撰寫程式上都是很有天分的一群,也能很快寫完,卻常常要面對沒辦法通過驗收之風險。因為缺乏專業測試工程師,所以無法進行多種使用狀況之測試;因為沒有經驗,所以也不會運用負載平衡等技術將大量使用者加以分流;因為沒有長期營運的打算,常常會有忽略安全性急就章的程式碼,造成日後遭駭客入侵的漏洞。客制化專案的這些特性,常常會造成時程上的延遲,甚至於沒有辦法通過驗收,驗收後的營運也常常沒有辦法持續。
本計畫第一年經由生態所郭城孟實驗室團隊進行先期規劃後,業主了解並無現成之套裝軟體可用,是以必須以委託開發團隊進行高風險客制化軟體之開發。在受委託開發單位這邊,首先要做的就是降低客制化軟體之各項風險。因為開發單位可以投入的資源相當有限,從零開發勢必不可行,所以選擇開源軟體進行二次開發變成為我們的最佳策略。
開源軟體選擇
由於筆者本人一直在微軟平台上從事程式設計與資料庫管理的工作,本身並非開源軟體的專家,所以在無窮無盡的網路空間中找到適合的開源軟體幾乎是一件不可能的任務。所幸計資中心作業組張傑生副組長(Jason)、工程師黃植懋(James),以及教學組唐瑤瑤(Dana)程式設計師已經有多年的採用開源軟體的經驗,可以提供諮詢。中研院自由軟體鑄造場工作坊也整理了關於開源軟體的大量的資料,以及提供教育訓練的服務。參加開源人年會也是一個獲得開源軟體新知與認識同好的機會。
在了解這個專案的需求後,Jason建議內容管理系統(Content Management System, 以下簡稱CMS)是可行的方向。雖然接下來的工作也是不算輕鬆,但至少縮小到一定的範圍。在請教Google大神與維基百科之後,發現雖然我們已經限縮到開源軟體的一個類別,可選的的平台也是非常多。要從這些CMS挑出一個來使用,也是不容易的事。還好有人做了CMS Comparison Matrix,讓我們可以對照我們需要的功能挑出可能適合的候選平台。另外幾個會對每年的傑出開源軟體進行票選與獎勵的網站也是個相當好的參考資訊來源。James所建議的 Google Trends 也能提供相當好的相對趨勢參考。雖然全球的採用情形(網站數、使用人數)是我們決策的重要因素,基於以往使用開源軟體在中文環境中常會有一些中文特有的問題,這些是其他語系國家(其實主要是英語系以及英語通用的國家)所不會遇上的,所以台灣該CMS 的社群人數與活躍性也是個重要考量。基於團隊成員所熟悉的開發語言與資料庫做適當過濾也是個重要考量。開發團隊同意我們之中也沒有可以三天學會一種程式語言的天才(幸好團隊中也沒有自以為可以三天學會一種程式語言的天才),所以開發語言與資料庫必須是我們之中兩個人以上熟悉。綜合以上,Joomla與Drupal兩個CMS 成為我們實際建置測試的對象。
小結
由於篇幅所限,本文僅就個人開放源碼經驗、本計畫案由以及開源軟體選擇的過程加以敘述。接下來將敘述建置測試的結果、實際導入過程中所碰到的種種問題以及因應的措施,提供有興趣的讀者分享,並請不吝指教。
參考文獻與相關連結
[1] Drupal, http://drupal.org/
[2] Drupal Taiwan 正體中文支援站, http://drupaltaiwan.org/
[3] Joomla!, http://www.joomla.org/
[4] Joomla!台灣, http://www.joomla.org.tw/