自由軟體的自由

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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