Download as PDF, PPTX
Uploaded byJen Yee Hong
COSCUP 2019 國際開放原始碼專案經營 - 從失敗中學習
這份文件探討了國際開放原始碼專案的經營經驗，強調從失敗中學習的重要性。講者分享了開發過程中的用戶和開發者需求、團隊合作的挑戰，以及技術決策的影響。內容涵蓋項目管理、溝通技巧和社群維護，提供了實際的案例和教訓，有助於提升開放原始碼專案的成功率。
COSCUP 2019 國際開放原始碼專案經營 - 從失敗中學習
- 1. 國際開放原始碼專案經營 從失敗中學習 洪任諭 (PCMan) @COSCUP 2019
- 2. 講者簡介 ● Appier SoftwareEngineer ● 台大資訊工程研究所畢業 ● 前榮總風濕免疫科醫師 ● 陽明大學醫學系畢業 ● 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.
- 6. RTL Layout 問題(BiDi支援) ● 文字 (例: 希伯來、阿拉伯) ● 圖示 (箭頭方向) ● UI layout 6
- 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.
- 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.
- 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.
- 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.
- 19.
- 20.
- 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.
- 28. Release Early, ReleaseOften ● 持續發表消息，刷存在感 ● 要一直更新版本，就算很小 ● Forum 沒人回比沒有更糟... 28
- 29. 收到 Patch 時 ●無論 code 或態度好壞，請保持友善 ● 如果 patch 品質不好? − 直接 reject 自己重寫 X − 往返討論，協助他改善 O 學到經驗: ● 犧牲當下效率，換長期參與者 29
- 30. 社群風氣維護 ● 成員對新手不友善 ● 成員對PR 貢獻者不友善 ● 成員跟其他社群發生衝突 (Linux distribution) 學到教訓： ● 爭論易失焦，情緒化 ● 不要輕忽仇恨語言的傷害，需要即時緩頰或道歉 ● 盡量保持耐性，對新手友善 ● 行為準則? 30
- 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.
- 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.
- 39.