O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

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

3.220 visualizações

Publicada em

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

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

Publicada em: Software
  • Login to see the comments

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

×