Open Source、Drupal、苦勞2.0

21號下午，DrupalTaiwan安排了即將入伍的Jimmy開了一堂Drupal的課程。超出預估地，來三十多個人，把跟Charles跟樂多商借的會議室擠得滿滿的， 每一個人來的人的需求都不大一樣，有人因為工作上的需求、有人則是個人的興趣，也有一些技術人員，來尋找不一樣的CMS的替代方案。

感覺得出Jimmy在思考這個課程時的針對性，雖然說，Drupal加上CCK、Views兩大模組，創造出極具彈性的架構，為其重要的長處，但是正如Jimmy所不斷強調的，Open Source的模組再多，如何針對客制的需求，去進行調整，仍是一個重要的問題，目前，Drupal社群所缺乏的，也正是可以進行這些工作的開發者。對於選用了這一個CMS的架站者如我們而言，對這個問題的急迫性，感觸也非常深，自從苦勞網2.0確定採用Drupal改版以來，Jimmy當兵日子的迫近，一直是我的焦慮（沒錯，我焦慮的東西還真多），到目前為止，舊資料還沒有匯入、新版沒有完成的東西，以及想要做的東西，還有很多，更不用提，以目前系統不穩的狀況，怎麼維繫網站的運作正常？Jimmy不在了，誰可以來作這些事？就算有人，他又能不能承接別人的工作？

以Open Source的社群運作方式，缺乏資源和有組織的運作，去計劃性地培養各個階段的人才，各自歧異的學習動機，也很難保證可以把開發的成果，回饋到社群，把「開放分享」的好處極大化（好比說，為營利性的公司所作的開發，在沒有得到公司許可的條件下，可以把開發的成果拿出來共享嗎？個人性的開發，如何兼顧開發流程與源碼釋出的標準程序？）。當然，Open Source的想法，是非常好的，但是，一旦遭遇到現實問題，運作的遊戲規則還沒能玩出來之前，真的只能走一步算一步。

休息的時候，打開苦勞網2.0的後台，引起一些好奇的眼光，新版苦勞的一個重要任務，是承接舊苦勞所完成不了的分類系統，一方面，它是用自訂標籤（tags）架構起來的彈性分類方式；另一方面，又需要兼顧共同資料整理時，分類的一致性，我們請Jimmy開發出一個全新的模組，可以由編輯台提供一系列「建議標籤」，以及最新有人輸入的「事件分類標籤」，同時大家又可以在這些標籤的欄位，任意輸入自己想要訂定的關鍵字，以期符合部份個人資料整理的目的，這種既集中又分散的後台維護方式，構成苦勞2.0前台各區塊的內容：

苦勞2.0的後台。

有人對這樣的設計感到好奇，也希望知道，這是怎麼做出來的；除此之外，現場詢問度最高的，就是「不同介面存取同一資料庫」的問題，在苦勞2.0，也已經實現了，請參考這個和這個頁面，它們的內容是完全一樣的，使用這種方式，我們可以制定出完全不同的樣板和各樣版自訂的區塊，共用資料庫裡的資料；最早的這個構想，是多年以前，我在構思全國產業總工會網站時希望架構的東西，一方面，它可以滿足全產總下各工會架構自己網站的需求，另一方面，這些資料的集合，又可以以自訂呈現區塊的方式，表現在平台性質網站（如全產總或苦勞網）的介面上，舉個例子來說，稍具規模的大型工會，會自己製作發行會刊，如果我們可以提供各工會輸入會刊的介面，並將這些會刊的版型與他們的網站結合，那麼他們就可以以維護自己的網站的方式，來共同架構「工會會刊」的平台；在舊的苦勞網，我曾經寫過這樣的東西：苦勞網的全聯會會訊和銀行員全聯會網站的全聯會會訊（目前看到的資料不一樣，是後來因為效能問題，而將兩個資料表拆開了）。

面對「無以為繼」與「找不到支援」的焦慮，我的回應是，我們應該把更多的過程，不僅僅是只有技術人員看得懂的source code，也包括需求的想像、溝通的過程、如何從想法，變成專案的過程，以及最後解決的方式，作一個有效的呈現，只有讓它更開放、有更多的人知道，這個系統才更安全、更穩定，也就是說，應該被開放的，不僅僅是技術，也包括了技術需求背後的社會性與組織因素。

這相較於技術集中的大型商業化軟體和BSP來說，是一種反向的思考，但我覺得，這也剛剛好是Open Source跟商業性軟體邏輯最大的不同之處。

當然，苦勞2.0現在還不能說問題已經解決了，「怎麼辦」的問題，焦慮狀態未曾解決，不過，作為一個NGO與開發者共同完成的case，我們該扮演的角色、該做的事情，也是應該開始去好好想想的時候了。