OpenVanilla 發展所遇到的挑戰，及一些可能的解決方向

作者: lukhnos

有好一陣子沒在 #osxchat blog 上寫東西了。先前寫 blog ，泰半是撰寫關於 OpenVanilla 的版本發佈、少許是一些 Mac 的使用心得。算起來這些都屬於「務實」的 blog 。今天我要講的是比較「務虛」的東西：關於 OpenVanilla 的未來發展。不是技術面的發展，是社會面的。

簡單地說，OpenVanilla 目前在使用及發展上，有以下幾個層面的挑戰：

• 使用上的疑難，包括 OpenVanilla 的安裝、解除安裝、移難排除等等
• 自訂輸入法（Generic輸入法）模組的使用
• 如何修改或更新現有的輸入法（資料表或演算法）
• 在 OS X 上某些軟體的不相容問題
• 如何撰寫新的輸入法
• 文件的撰寫、更新與維護
• 如何在其他平台上使用 OpenVanilla 框架（亦即如何移植 OpenVanilla）

上述的列表有層次上的分別。前兩項是使用上的，後面五項則是開發上的。這幾個挑戰有相扣的環節。

OpenVanilla 會發展到今日的規模，說實在話，有那麼點意外（大概幾個成員間也這麼覺得）。我蠻希望強調 OpenVanilla 應該簡稱 OV 而儘量避免用「開放香草輸入法」這樣的譯名，因為 OV 是為了這幾個目的而設計的：

• 將 OS X 的輸入法處理模組（text service component）分離，讓每個輸入法開發者不需要重頭研究 OS X 的 Text Service Manager
• 讓開發輸入法的人能專心於輸入法的演算法及邏輯程序
• 透過動態載入的方式，讓輸入法框架能同時載入多種輸入法，並即時切換

而自從 OV 0.7.0rc3 正式加入了「文字輸出處理模組」（output filter）這一層架構後，上述的設計目的又增加了「提供一套加掛文字輸出模組的方式，讓輸入法打出的文字，能夠透過不同的轉換模組（filters）進行變換」這一項。

然而，正因為 OV 的設計目的和設計方針是如此，以致於 OV 面臨相當獨特的挑戰。例如說，OV 並不是「一套」輸入法，而是「很多套輸入法的組合」，或者說 OV 其實是「一套可以載入各種符合 OV 規格的模組的框架」──因此與其說「OS X 內建的倉頡不好用，裝開放香草輸入法吧」，不如說「裝 OpenVanilla，用它裡面附的倉頡輸入法吧」。我們有「OV 倉頡」、「OV 大易」、「OV 酷音」、「OV 傳統注音」甚至是「OV 漁村」等輸入法，但是「OV」只是一套框架，一個殼子，一套載具而已。

因此，要回答 OV 使用上的疑難問題，恐怕還是得先問「用哪一套 OV 的輸入法」。好比說，OV 倉頡在使用上和 OV 大易所會碰到的問題，就未必相同。如果 OV 倉頡使用者遇到問題，能有同樣使用 OV 倉頡的人來回答，其實是最適合的。

我想，這就是目前 OV 團隊遇到的一個瓶頸：OV 的每一個開發者所熟悉的輸入法數量都有限。例如我一直只熟悉傳統注音輸入法，因此對於 OV 酷音，我只負責模組的編譯（build）、佈建（deployment）及包裝。又好比最早完成的通用輸入法模組（這個模組藉由資料表，生出了倉頡、大易、漁村等輸入法），後來也是因為有熟悉倉頡的 b6s 出手，才更臻完善。再譬如說 OV 的行列，最早是由我從通用輸入法模組撰寫，經過 ijliao、xeonchen、gontera 等朋友的耐心協助測試，開始稍具雛型，但是一直要等到 vgod 加入 OV 開發，以他身為行列使用者的親身體驗，才終於讓 OV 有了完全符合行列規格的輸入法模組。OV 的 POJ （台語白話字）模組也是因為有 pcchen 的「壓力測試」才能有今日的表現。

也就是說：OV 提供了框架，然而要解決某一輸入法的問題，最終還是要由熟悉該輸入法的人來解決，最為妥當。

就目前這個階段，我們能做的，就是盡可能提供完整的文件說明──儘管 OV 的文件，也已經長大成為了龐大的計劃。OV 的文件一直是由 zonble 和 mjhsieh 帶頭編輯的。0.7.0 版的說明文件（尚未正式發表），竟然已經是 54 個 A4 頁面的大傢伙，絕對可以印一本中等厚度的使用手冊。

然而，總一定會有手冊不能完善解決的，或是新產生的問題。這種時候，如果有使用者社群，情況就會改觀不少。

除了使用者社群，另一個我心裡面期望的，是能有 OV 的開發社群。這裡的「開發社群」，我心裡預想的倒不只是「撰寫、維護或修改輸入法模組／輸入法資料」的人群──儘管連這一點的規模都還不大──反倒是，如何讓更多人能從原始碼層次，直接編譯、佈建、安裝，甚至包裝 OV 。我的想法是，如果能有更多人瞭解 OV 是怎麼從原始碼編譯、安裝的，相信對於任何想要修改、建立新輸入法的人來說，都會有幫助。

換個方式說，目前要瞭解這些東西，必須憑藉少量的文件，或者直接與 OV 開發團隊聯繫上（主要還是靠 IRC）。然而不可否認，即使在網路上，人際距離還是存在的。更多人瞭解 OV 的組建，我的想法是，應該能縮短這樣的距離。好比說，如果能有更多使用簡體中文的朋友，能對 OV 的組成有更多瞭解，那麼例如在修改五筆輸入法資料，或是在建立新 OV 輸入法模組時，就能省去很多力氣。

在這一點上，有幾個困難點要克服，因為 OpenVanilla 在原始碼層次上，主要運用了以下三個工具：

• gcc 及 gcc 相關工具（make）
• Xcode
• svn 及版本管理工具

其中，gcc 或許對許多有 UNIX 經驗的朋友不是難事，但是對許多未曾在終端機工作過的朋友，會形成一定的挑戰（我們倒是成功地讓一位頻道上的朋友，因為想要取得 OV 最新版本的關係，而開始用命令列編譯建立安裝 OV ！）。而 Xcode 則往往是對任何人都很新鮮的。至於 svn ，在國外的自由軟體／開放源碼軟體界，已經漸漸開始風行起來，但是版本管理的觀念和工具一定程度上還是有進入障礙的。

要推廣 OV 從原始層次碼來安裝、維護、修改或演進，就一定會碰到上述這三個層次：OV 使用很多 UNIX 工具、OV 需要使用 Apple 的 Xcode （至少在 OV 的 OS X 版本是如此）、OV 是一個使用 svn 當版本管理工具的 open source project。反過來說，如果 OV 開發社群的成長過程，同時也是這三種工具的推廣過程，應該也會是很有意思的事。

至於，OV 在其他平台上的發展，似乎也必須仰賴有更多人能擔當 OV 的「種子推廣者」，協助更多人取得 OV 源碼、在不同平台上建立 OV 、解答 OV 使用上（尤其是安裝，及個別輸入法的使用、維護、修改）的問題，才有可能繼續進行下去。

簡言之，面對我一開始所列的 OV 諸多挑戰，用 gugod 的說法，叫 SIGMOREHACKERNEEDED （這個詞是仿 UNIX signal 的組合字：需要更多人來 hack）。而「形成各別輸入法的使用者社群」和「（藉由 OV 源碼層次組建方法的流傳）形成 OV 的開發者社群」這兩點，則是我目前認為更具體化的方向。