1.
國際開放原始碼專案經營
從失敗中學習
洪任諭 (PCMan) @ COSCUP 2019

2.
講者簡介
● Appier Software Engineer
● 台大資訊工程研究所畢業
● 前榮總風濕免疫科醫師
● 陽明大學醫學系畢業
● 15 年自由軟體開發
− LXDE / LXQt 桌面環境
− PIME 輸入法平台
− 新酷音輸入法 windows port
− PCMan BBS client 全系列
− IE Tab Firefox 外掛
2

3.
無心插柳的漫長旅程...
● 2001 練習網路 socket 用法 →
● 2004 嘗試開發 Linux 版 → 此成為 Linux 使用者
● 2004 上網求助 → 意外混入 Debian 社群
● 2006 年練習開發 Linux 程式 → 意外成立 LXDE
● 2008 LXDE 走向國際
○ 感謝 Asus EeePC 贊助
○ 感謝德國 Mario Behling
● 2013 和來自歐洲的 Razor-qt 專案合併，成立 LXQt
3

4.
國際專案經營 - 我學到了什麼?
● 使用者需求
● 開發者需求
● 團隊內政治
● 公關行銷 / 市場趨勢
4

5.
我的 UI 在中東壞掉了...
5

6.
RTL Layout 問題 (BiDi支援)
● 文字 (例: 希伯來、阿拉伯)
● 圖示 (箭頭方向)
● UI layout
6

7.
使用者界面尺寸
● 字串翻譯後寬度和高度會發生變化
https://www.w3.org/International/articles/article-text-size.en 7

8.
不是能翻譯就好
● 不同語言複數型不同
− msg = n + (n > 1 ? ' files are found' : ' file is found') X
− msg = n + 'file(s)' X
− 使用 ngettext() O
● 文法不同，翻譯後參數順序可能改變
− 英文: "String `%s' has %d characters"
− 德文: "%d Zeichen lang ist die Zeichenkette `%s'" X
− GNU 擴充: "%2$d Zeichen lang ist die Zeichenkette
`%1$s'" O
● https://www.gnu.org/software/gettext/manual/gettext.html8

9.
外國使用者需求
● 輸入法 (CJK)
● Keyboard Layouts &特殊鍵
− Alt-Gr key 常用右Alt (例: AltGr + C → ©, AltGr + 4 → € )
− Dead key (例:法文 ` A → à )
● Locale:
− 日期
− 數字格式
− 金額格式
− 文字排序
9

10.
排序有多難?
O(NlgN) (誤)
10

11.
字串比大小
● strcmp()? ASCII 字典序？ → X
● Unicode: 符合語言學的順序 (collate)
● 檔名排序 - 需考慮數字
− "file_1000", "file_20", "file_300" X
− "file_20", "file_300", "file_1000" O
● 請用 Libraries:
− strcoll(), libICU, glib, Qt
11

12.
開發者需求
12

13.
Code Quality 很重要
● PCMan 2007: 不良的架構、naming 不一致
● PIME: 修不完的 bugs
學到教訓:
● 要寫 tests
● Coding style, readability, design pattern 很重要
成功案例:
● pcmanfm: 因架構清楚可讀，後續有開發者順利接手
13

14.
重寫？別衝動！
LXDE 檔案管理 PCManFM 重寫 3 次:
1. 原始版: 架構簡單但沒彈性 (後來衍生 SpaceFM)
2. 重新設計 UI 和 I/O 核心分離
3. Port to Qt: 原重複利用 libfm，最後完全用 C++ 重寫
學到教訓:
● 下次未必更好，可能問題更多
● 流失現有開發者 / 使用者 (compiz-fusion 也有失敗案例)
● 使用者想要 "功能"，不在意 "架構"
● 沒有完美架構，只有 Trade-off 14

15.
真不想承認啊，
這是我太過年輕而犯下的錯
15

16.
冷門技術，找不到開發者 (GTK+)
LXDE 換 Qt / C++ (LXQt) → 開發團隊人數倍增
學到的教訓:
● 一人專案難維持，方便開發很重要!
● 慎選開發工具
16

17.
選錯 License 事後補救?
● Libfm → from GPL to LGPL
● git log 找到所有貢獻者 E-mail
● 逐一詢問是否同意 re-license
● 確保 code 裡面的 license 正確標示 (Debian 很要求)
17

18.
技術問題其實最好解決!
18

19.
Software Skill
19

20.
Software Skill
20

21.
長期經營，是妥協的藝術
21

22.
成員意見不合吵架 - 案例一
● 我重寫了另外一個成員辛苦貢獻的模組
● 後來成員離開...
學到的教訓:
● 不要隨便刪掉別人的 code
(不管你覺得自己是否寫得比較好)
● 技術優劣無絕對，注意團隊成員感受
22

23.
成員意見不合吵架 - 案例二
● 爭吵使用何種線上翻譯平台
○ 自建 server?
○ 換商用系統? (原自建 server 維護者的心血被放棄)
學到教訓:
● 不要搶走別人貢獻的機會
23

24.
成員意見不合吵架 - 案例三
● UI 該如何設計？
● 誰的實做方式比較優越？
學到教訓：
● 沒有絕對正確的設計 → 有錯再改
● 別爭執芝麻綠豆大的事 (看長遠)
● 成功的 teamwork 來自妥協
● 各自提出實做，理性討論，輪流退讓
24

25.
成員意見不合 - LXDE / Razor-Qt 合併 =
LXQt = LXDE + Razor-Qt
衝突:
● Razor-Qt 的名稱不見了
解法: 客觀分析利害得失
● LXDE 知名度可以帶來用戶
● 補償：在 UI / Website 顯眼的地方感謝 Razor-Qt
● 開放態度: 未來可改
25

26.
跨國專案的困擾
● 面對面，沒有一杯啤酒解決不了的問題
● 如果有，就兩杯
● But… 跨國專案你只有 E-mail，時區還相反
學到的教訓：
● 文字易生誤會
● 專業人士自尊強，小心溝通
● 用 code 輔助溝通
26

27.
公關 - 社群維持
27

28.
Release Early, Release Often
● 持續發表消息，刷存在感
● 要一直更新版本，就算很小
● Forum 沒人回比沒有更糟...
28

29.
收到 Patch 時
● 無論 code 或態度好壞，請保持友善
● 如果 patch 品質不好?
− 直接 reject 自己重寫 X
− 往返討論，協助他改善 O
學到經驗:
● 犧牲當下效率，換長期參與者
29

30.
社群風氣維護
● 成員對新手不友善
● 成員對 PR 貢獻者不友善
● 成員跟其他社群發生衝突 (Linux distribution)
學到教訓：
● 爭論易失焦，情緒化
● 不要輕忽仇恨語言的傷害，需要即時緩頰或道歉
● 盡量保持耐性，對新手友善
● 行為準則?
30

31.
今天的新手，是明天的主要貢獻者
31

32.
成員離開
● 開發理念不合
● 爆發言語衝突 (常見)
● 對專案不再有興趣
● 個人時間因素
即使曾發生衝突，還是別忘感謝他們的貢獻
Keep the door open
32

33.
最大的困境 - Governance
Free-style: 任何成員都自由貢獻
造成問題:
● 一致性 (UI / UX, Design decisions)
● 未來 Roadmap 如何決定?
● Core team? Committee? Membership? Foundation?
● 誰代表 "官方"?
● 誰有網站管理權?
33參考: Five years on the Rust core team: a retrospective by Steve Klabnik

34.
為什麼 Open Source 專案應該國際化?
34

35.
誰關注 Open Source?
35https://trends.google.com.tw/trends/explore?q=%2Fm%2F01pjyj

36.
誰開發 Open Source 軟體?
https://medium.com/@hoffa/github-top-countries-201608-13f642493773#.wmm24st82
Top countries by number of github pushes
(Aug 2016, by Felipe Hoffa)
36

37.
跨國合作挑戰多
● 語言造成溝通障礙 – 用 code 溝通
● I18n 議題
● 文化差異 (注意禮貌)
● 來自世界各國, 各行各業的「人」
● Version control systems
● 讀懂別人的code，並且修改
● 外國人也想參加我們的專案!
37

38.
也許世界很大，我們很小
38

39.
透過 OSS，讓台灣被看見
39