為什麼 open source 總是感覺粗鄙？

這題目譯自Why Free Software has poor usability, and how to improve it。一直都在使用開源碼，也因此會反省自己是不是犯了底下這些錯誤？

開源碼軟體的開發者大部份都是志願者，這本身雖然是好事情卻也造成兩個明顯的問題：

一、沒動機去改善使用性。這其實是相對的，商用軟體本來就是要賣給使用者，若是你操作感太差怎麼可能賣得掉？可是開源碼軟體不一樣，通常撰寫者自己用居多，另一方面用於學習的功能也佔不少比例，加上用戶數也少，得到的回饋相對上少(但絕非主因)，最重要的，作者通常懶得去強調。

解決方案：應該由政府鼓勵或舉辦設計大賽，不見得要新創軟體，還要鼓勵優良軟體的改善。廠商愈來愈多使用開源碼，也應該回饋到開源社群或建立適當的社群。

二、良好的設計師不多。雖然有音樂家本身也是作曲家，但是絕大多數都不是。一個好的程式設計師要兼顧著當良好的介面設計師是很難找的。

解決方案：建全開源碼社群的組織，讓使用介面設計師、優秀的測試師等都能加入，甚至更應該鼓勵使用者回饋其使用心得與建議。也就是在社群建立良好的開發者、設計師、測試、終端使用者間良好的互動。

為什麼優秀的設計師無法浮到檯面呢？

三、建議通常變成「歡迎自行補丁」。開源碼的一個現象就是，你有想法，請自行實現。建議很難被開發者擺入他們的心中。

解決方案：同樣的在社群活動中，應鼓勵這樣的行為，開發者應該把其他人的建議擺在第一位，而不是照自己的想法開發應用程式。當然，一個良好的 issue tracking 也不止是追踨臭蟲而應該加入任何建議。建議並不見得都是好的，良好的討論模式也應該被建立。

那為何開發者可以在面對臭蟲報告時的正向態度無法以同樣態度去面對可用性的建議呢？

四、難以衡量可用性，因而不被重視。其實有些共同項目是顯而易見的，例如啟動時間，佔用系統資源，執行速度，反應速度，運行時當機比例，但是這些對使用者來說都偏向隱含層面。真正的好用的軟體的操作介面設計是一門學問，而通常，這非開發者所關注與擅長。

解決方案：還是社群功能之一，建立測試與回饋機制。另外，開發者在開發軟體時，應該把使用的方便性擺在第一位，而不是功能的開發上。一般軟體在開發時，總是以追求功能性，甚少以負責任的態度把自己開發的軟體易用性擺第一位。

因此，缺乏良好的介面設計師引發了三個開源碼開發的文化問題：

五、軟體開發前缺乏設計流程。一般軟體開發流程講的都是先收集需求、進行規格設計、再進行開發，可是開源碼軟體卻相反，先開發，有人用了再來增加規格，最後才把需求收集完整。事實上能不能做到完整還得存疑。

解決方案：開源碼應該建立正規的軟體設計流程的文化。

六、人多嘴雜。這是一個難題，使用介面的設計是個見仁見智的問題，而且，誰也不服誰，加上前面說的，好的設計師通常無法自行實現想法。

解決方案：其實說多了都差不多，就是要有領導者，有一個值得信賴的人或組織願意領導大家，鼓勵建立這樣的機構是值得肯定的。

七、壟斷。舉例來說，開發者在編寫程式時會想到的操作介面通常是他們手邊的軟體，這雖然比較大眾化，但是不見得是優良的介面設計。

解決方案：鼓勵創新的設計，通過獎勵和其他宣傳來引領開發者。

開發者並未將專業的使用介面建議納入考量，這原因造成更多難解的問題：

八、孤芳自賞的心只追求自我滿足：開源碼的開發者通常開發出來的軟體是以同樣愛好者社群為使用群，滿足了這些人其實就像隔靴搔癢，無法滿足大部份群眾的操作習慣。

解決方案：最簡單的方式就是，鼓勵那些社群的人親自說服其身邊的親朋好友一起使用他們所開發的軟體，並且，誠心傾聽其建議。

九、被小細節打敗。很多小細節，改善應用程式的界面不是一件令人興奮的或能自我滿足的工作，也因此在開發者就功能面或技術面改善之前，他們大都不會花心力著墨在上面，惡性循環下引不起使用者興趣，因此開發者也得不到正向的回饋。

解決方案：在安排除錯的時候把除錯的時間因素放進去，這會使得開發者比較有機會注意到有些使用介面設計只需要花很少的時間。事實上這方案也常常無效，因為開發者會認為「那只是每個人對操作便利性不同的看法而已」。

十、更多的選擇可以安撫人們。若你受僱開發軟體，大抵上都沒有選擇權，就算不是你想要的你也得盡心盡力去完成，而開源碼軟體卻不然，常常都會讓開發者興起「此處不留爺，必有留爺處」，當然有能力的人就自己開發去了。

解決方案：產生一個強有力的社群維護者，以及一個單一的文化，建立一種更分散式的版本控制，讓人充分在標準與自訂之間游移，允許正式版本與變異版本共存。舉例來說像 kernel 就是。

十一、人多嘴雜：每個人意見不一，常常有人做了變動，可是外觀卻看不出來變化，當然也常常有人任意對開源碼做變動而不顧外觀上變化所產生的影響。

解決方案：提供像 google 關鍵字廣告這種商業宣傳，來對真正有貢獻的開發者作補償，並對影響使用介面的 source code 建立審查制度，並定期檢視「我們是否需要這一點」？

十二、開源碼的開發是「寬頻」的。因為開源社群都是分散在世界各地，因此各項聯繫幾乎都在網路上，但是，相反的，一般商業軟體卻大都是在同一建築物內。

解決方案：讓溝通更加無界限，發展和促進IP電話，視頻聊天，在虛擬白板上，人像素描，及動畫軟件，允許更容易溝通的設計理念，隨著國際互聯網。(此段純 google 翻譯)

十三、太早釋出軟體，太常釋出新版本，這會面臨不小的問題：先面臨到的當然就是因此使得差勁的使用介面變成很「自然」就出現了。

解決方案：前面有說過，開源碼的開發流程應該從軟體工程的角度出發，而不是依照自己的喜歡隨意開發。

十四、太任意就「模組化」。有些優良的開源碼都把使用介面與其核心功能分離，這當然是個好傳統，而且打從 Unix 時代就流行 pipeline 的方式讓眾多程式彼此合作。但是這樣的現象卻導致功能很強，卻沒有優秀的操作介面配合的窘境。

解決方案：在寫核心技術之前，先把操作介面設計出來。

十五、Gated development communities(不知道怎麼翻)：當你在用一個軟體系統時，常常是整合了不同的團隊所開發出來的模組，例如，你把你所見的這個網頁列印出來的時候，其實至少包括了瀏覽器核心，印表系統，視窗管理，各式各樣的 library，甚至還有驅動程式。而這些組成不見得都很好的整合過，以符合更佳的操作習慣。

解決方案：由「開源軟體」供應商居中協調跨組件工作。

原文寫的有點長，英文超過我的能力，因此我翻譯起來也相當辛苦，也正因為如此我才更需要試著去翻譯，若有錯誤請不吝指正。(註，錯誤是不小心的，漏掉是故意的)