Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

COSCUP 2019 國際開放原始碼專案經營 - 從失敗中學習

此為 COSCUP 2019 演講的投影片:
介紹:
開放原始碼軟體的專案,要能永續經營推廣,甚至國際化,最大的挑戰往往不在程式開發本身。鑑於國內第一手的經驗分享較少些,因而野人獻曝,從過去 15 年經營跨國 OSS 專案的經驗出發,分享過去遇到的挑戰、失敗的經驗、以及最後如何解決問題 (或無法解決),和 OSS 同好們一起取暖。

共筆: https://hackmd.io/SP-d0YEwSz23euQBgX3Mew

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen
  • Loggen Sie sich ein, um Kommentare anzuzeigen.

COSCUP 2019 國際開放原始碼專案經營 - 從失敗中學習

  1. 1. 國際開放原始碼專案經營 從失敗中學習 洪任諭 (PCMan) @ COSCUP 2019
  2. 2. 講者簡介 ● Appier Software Engineer ● 台大資訊工程研究所畢業 ● 前榮總風濕免疫科醫師 ● 陽明大學醫學系畢業 ● 15 年自由軟體開發 − LXDE / LXQt 桌面環境 − PIME 輸入法平台 − 新酷音輸入法 windows port − PCMan BBS client 全系列 − IE Tab Firefox 外掛 2
  3. 3. 無心插柳的漫長旅程... ● 2001 練習網路 socket 用法 → ● 2004 嘗試開發 Linux 版 → 此成為 Linux 使用者 ● 2004 上網求助 → 意外混入 Debian 社群 ● 2006 年練習開發 Linux 程式 → 意外成立 LXDE ● 2008 LXDE 走向國際 ○ 感謝 Asus EeePC 贊助 ○ 感謝德國 Mario Behling ● 2013 和來自歐洲的 Razor-qt 專案合併,成立 LXQt 3
  4. 4. 國際專案經營 - 我學到了什麼? ● 使用者需求 ● 開發者需求 ● 團隊內政治 ● 公關行銷 / 市場趨勢 4
  5. 5. 我的 UI 在中東壞掉了... 5
  6. 6. RTL Layout 問題 (BiDi支援) ● 文字 (例: 希伯來、阿拉伯) ● 圖示 (箭頭方向) ● UI layout 6
  7. 7. 使用者界面尺寸 ● 字串翻譯後寬度和高度會發生變化 https://www.w3.org/International/articles/article-text-size.en 7
  8. 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. 9. 外國使用者需求 ● 輸入法 (CJK) ● Keyboard Layouts &特殊鍵 − Alt-Gr key 常用右Alt (例: AltGr + C → ©, AltGr + 4 → € ) − Dead key (例:法文 ` A → à ) ● Locale: − 日期 − 數字格式 − 金額格式 − 文字排序 9
  10. 10. 排序有多難? O(NlgN) (誤) 10
  11. 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. 開發者需求 12
  13. 13. Code Quality 很重要 ● PCMan 2007: 不良的架構、naming 不一致 ● PIME: 修不完的 bugs 學到教訓: ● 要寫 tests ● Coding style, readability, design pattern 很重要 成功案例: ● pcmanfm: 因架構清楚可讀,後續有開發者順利接手 13
  14. 14. 重寫?別衝動! LXDE 檔案管理 PCManFM 重寫 3 次: 1. 原始版: 架構簡單但沒彈性 (後來衍生 SpaceFM) 2. 重新設計 UI 和 I/O 核心分離 3. Port to Qt: 原重複利用 libfm,最後完全用 C++ 重寫 學到教訓: ● 下次未必更好,可能問題更多 ● 流失現有開發者 / 使用者 (compiz-fusion 也有失敗案例) ● 使用者想要 "功能",不在意 "架構" ● 沒有完美架構,只有 Trade-off 14
  15. 15. 真不想承認啊, 這是我太過年輕而犯下的錯 15
  16. 16. 冷門技術,找不到開發者 (GTK+) LXDE 換 Qt / C++ (LXQt) → 開發團隊人數倍增 學到的教訓: ● 一人專案難維持,方便開發很重要! ● 慎選開發工具 16
  17. 17. 選錯 License 事後補救? ● Libfm → from GPL to LGPL ● git log 找到所有貢獻者 E-mail ● 逐一詢問是否同意 re-license ● 確保 code 裡面的 license 正確標示 (Debian 很要求) 17
  18. 18. 技術問題其實最好解決! 18
  19. 19. Software Skill 19
  20. 20. Software Skill 20
  21. 21. 長期經營,是妥協的藝術 21
  22. 22. 成員意見不合吵架 - 案例一 ● 我重寫了另外一個成員辛苦貢獻的模組 ● 後來成員離開... 學到的教訓: ● 不要隨便刪掉別人的 code (不管你覺得自己是否寫得比較好) ● 技術優劣無絕對,注意團隊成員感受 22
  23. 23. 成員意見不合吵架 - 案例二 ● 爭吵使用何種線上翻譯平台 ○ 自建 server? ○ 換商用系統? (原自建 server 維護者的心血被放棄) 學到教訓: ● 不要搶走別人貢獻的機會 23
  24. 24. 成員意見不合吵架 - 案例三 ● UI 該如何設計? ● 誰的實做方式比較優越? 學到教訓: ● 沒有絕對正確的設計 → 有錯再改 ● 別爭執芝麻綠豆大的事 (看長遠) ● 成功的 teamwork 來自妥協 ● 各自提出實做,理性討論,輪流退讓 24
  25. 25. 成員意見不合 - LXDE / Razor-Qt 合併 = LXQt = LXDE + Razor-Qt 衝突: ● Razor-Qt 的名稱不見了 解法: 客觀分析利害得失 ● LXDE 知名度可以帶來用戶 ● 補償:在 UI / Website 顯眼的地方感謝 Razor-Qt ● 開放態度: 未來可改 25
  26. 26. 跨國專案的困擾 ● 面對面,沒有一杯啤酒解決不了的問題 ● 如果有,就兩杯 ● But… 跨國專案你只有 E-mail,時區還相反 學到的教訓: ● 文字易生誤會 ● 專業人士自尊強,小心溝通 ● 用 code 輔助溝通 26
  27. 27. 公關 - 社群維持 27
  28. 28. Release Early, Release Often ● 持續發表消息,刷存在感 ● 要一直更新版本,就算很小 ● Forum 沒人回比沒有更糟... 28
  29. 29. 收到 Patch 時 ● 無論 code 或態度好壞,請保持友善 ● 如果 patch 品質不好? − 直接 reject 自己重寫 X − 往返討論,協助他改善 O 學到經驗: ● 犧牲當下效率,換長期參與者 29
  30. 30. 社群風氣維護 ● 成員對新手不友善 ● 成員對 PR 貢獻者不友善 ● 成員跟其他社群發生衝突 (Linux distribution) 學到教訓: ● 爭論易失焦,情緒化 ● 不要輕忽仇恨語言的傷害,需要即時緩頰或道歉 ● 盡量保持耐性,對新手友善 ● 行為準則? 30
  31. 31. 今天的新手,是明天的主要貢獻者 31
  32. 32. 成員離開 ● 開發理念不合 ● 爆發言語衝突 (常見) ● 對專案不再有興趣 ● 個人時間因素 即使曾發生衝突,還是別忘感謝他們的貢獻 Keep the door open 32
  33. 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. 34. 為什麼 Open Source 專案應該國際化? 34
  35. 35. 誰關注 Open Source? 35https://trends.google.com.tw/trends/explore?q=%2Fm%2F01pjyj
  36. 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. 37. 跨國合作挑戰多 ● 語言造成溝通障礙 – 用 code 溝通 ● I18n 議題 ● 文化差異 (注意禮貌) ● 來自世界各國, 各行各業的「人」 ● Version control systems ● 讀懂別人的code,並且修改 ● 外國人也想參加我們的專案! 37
  38. 38. 也許世界很大,我們很小 38
  39. 39. 透過 OSS,讓台灣被看見 39

×