OSSへの貢献ノウハウ 〜LinuxカーネルからRookまで〜

Transcript

1. OSSへの貢献ノウハウ 〜LinuxカーネルからRookまで Feb 18, 2020 サイボウズNecoプロジェクト sat 1

2. 想定聴衆 ▌業務で有名どころのOSSを使っている lLinux, Kubernetes, MySQL… ▌バグや機能不⾜で困っている ▌OSSへ貢献したことがない l必要性がわからない lやりかたがわからない 2

3. ⽬次 3 ▌貢献の利点 ▌貢献⽅法 ▌貢献時の課題 ▌貢献の具体例

4. 貢献の利点 4

5. よくあるケース 5 1. バグ/機能不⾜で困る… 2. OSSなんだから⾃社独⾃版を作ろう! 3. 独⾃修正で解決した、やったね︕ 安定版 独⾃修正

6. 安定版がバージョンアップすると… 6 ▌追加コストが⼤きい 安定版 独⾃修正 古い安定版 独⾃修正 (変更が必要なことも) 次の安定版からの バックポート

7. そして地獄へ… 7 ▌ライフライクルが⻑いほど⼯数激増 安定版 独⾃修正 古い安定版 独⾃修正 (変更が必要なことも) 次の安定版からの バックポート

   古い安定版 独⾃修正 (変更が必要なことも) 次の安定版からの バックポート 次の次の安定版からの バックポート

8. 安定版にマージしておくと… 8 ▌コストはそれほど増えない l定期的なテスト&regression修正は必要 安定版 修正 次の安定版 修正 次の次の安定版 修正

9. その他 9 ▌開発者のスキルアップ l知⾒が豊富だと緊急時の対処がしやすい ▌顧客へのアピール l「〇〇の熟練開発者がいます︕」 ▌社外開発者へのアピール lOSS開発したいエンジニアの採⽤に繋がるかも

10. 貢献⽅法 10

11. はじめの⼀歩 ▌「何から始めればいいかわからない…」 l簡単なバグ報告/修正をやってみて慣れるのがオススメ lドキュメント修正やテスト追加もよい⼊⼝です l修正されるかどうか or 修正時期は気にしない ▌「具体的にどうすればいいんだ…」 l貢献⽅法が書いていそうなドキュメントを⾒る lDevelopment.mdやContribution.mdなど

    lGithub, slack, メーリスなどを⾒て真似する 11

12. 修正されやすくするコツ ▌多くのユーザが嬉しくなることをアピール l× 「これが直らないと弊社が困るんです︕」 l〇 「これはみんながハマりうる問題です︕」 ▌なるべく⾃分で修正PRを出す lメンテナ(*1)はみなさんのバグを直す義務はない l直したくても⼈的リソースは限られている 12

    *1) master branchにコミット権がある⼈。コミッタとも呼ぶことも

13. 気持ちを楽にする⼼構え ▌最初から肯定的な反応を期待しない ▌否定的な反応をされてもくじけない l反対は注⽬されているサイン lしっかり議論して説得 l無理筋なときは引き下がる。無理強いは嫌われる ▌無視が⼀番困る l投稿を⾒直して注⽬されるよう書き直し 13

14. ⾃社が遭遇した課題を解決したい ▌OSS使⽤時は様々な問題に遭遇する lバグ、機能不⾜… ▌典型的な解決⽅法 1. 既存issue/PRの有無を確認 2. 無ければ⾃分でissue/PR発⾏ 3. 機能追加は⾃らPR出さないと解決は困難

    14

15. 押さえておきたいこと 15 ▌業務には問題解決済みの安定版を使いたい ▌安定版にいつ⼊るか⾒積もっておきたい ▌開発プロセスを知っておこう lマージ条件 l開発版へのマージ時期 l安定版リリース時期

16. 開発プロセスの例 ▌具体例を紹介 lLinuxカーネル lRook lk8s上で動くストレージソリューションのオーケストレーター l分散ストレージCephなど ▌注意: 概要だけ書きます l詳細はドキュメントを参照 16

17. Linuxカーネル(1/2) ▌Master branchへのコミット権を持つのは1⼈だけ lオリジナル開発者のLinus Torvalds⽒ ▌マージまでの順序 1. サブシステム開発者たちによるレビュー 2. サブシステムのメンテナが⾃⾝のツリーにマージ

    3. master branch(開発版)へのマージ 4. 安定版リリース 17

18. Linuxカーネル(2/2) ▌2,3か⽉に⼀度安定版ををリリース l開発開始から2週間のみ新機能マージ可能 l残りはバグ修正のみ ▌安定版への新機能のバックポートはしない 18

19. Rook ▌master branchへのコミット権を4⼈が持つ l新機能マージには3⼈のレビューが必要 ▌安定版x.yのリリース間隔は未定義 lこれまでは3~6か⽉に⼀回 ▌新機能を安定版にバックポートすることも 19

20. 注意点 20 ▌PRを出してもマージされる保証は無い ▌常に代替案を⽤意しておこう l回避策を⾒つける l⼀時的に⾃社独⾃版/開発版を使う l⾃社独⾃版を使い続ける l最後の⼿段。できれば避けよう

21. さらにその先へ(参考) ▌プロジェクト全体を盛り上げよう 1. ユーザ増加 2. バグ報告/修正、機能追加増加 3. 品質向上 ▌貢献し続けるとissue/PRに反応がもらえる傾向がある ▌⽅法

    lドキュメント追加、バグ報告/修正、機能追加 lコードレビュー/ユーザサポート lイベントで発表 21

22. 貢献における課題 22

23. 開発者の課題 ▌⼀般的な開発技術とは異なる能⼒が必要 l⾒知らぬエンジニアに話しかける度胸 l交渉能⼒ ▌主要開発者/メンテナはもっと⼤変 l真夜中の定例ミーティング l海外カンファレンスへの頻繁な参加 23

24. 会社の課題: 社内規則 ▌勤怠システム l変則的な勤務に対応 ▌情報発信ルール lIssue/PR発⾏に上⻑の許可が必要、などは⾟い ▌法務的なルール l著作権の帰属、CLAへの署名要否 ▌(参考) サイボウズのOSSポリシー

    lhttps://cybozu-oss-policy.readthedocs.io/ja/latest/ 24

25. 会社の課題: 考え⽅ ▌⾃社の都合では進まないことを理解 l×: 「次の安定版に絶対機能追加しろ」 ▌会社に直近で利益が無い活動も認める l×: 「何でうちに関係ない機能開発してるの?」 ▌できる/やりたい⼈に任せる l前述のスキルを持っている/これから持ちたい

    l前述の勤務体系に同意できる ▌興味の無い⼈にやらせてもパフォーマンスは出ない 25

26. 貢献の具体例 NecoのRookへの貢献 26

27. 背景 1. NecoのストレージはRook/Cephクラスタ 2. ストレージは最重要 lお客様のデータは何よりも優先 l有事には即座に対処する必要がある ▌前述の理由でプロジェクト全体を盛り上げたい ▌主要開発者に、俺はなる lメンテナになる覚悟もある

    27

28. 〜2019年夏 ▌2018年5⽉~ lV1.0リリース l使⽤を決定、評価開始 ▌~2019年9⽉ l評価中に⾒つけたバグのissue/PRを数個発⾏ 28

29. 〜2019年12⽉ ▌2019年10⽉ lv1.2に向けに2つの機能追加PRを発⾏ ▌2019年11⽉ lKubeCon NAにおいてメンテナと会話 l上記機能についての議論 lNecoによる前述のコミット⽅針を表明 ▌2019年12⽉ lv1.2に上記2つの機能をマージ

    29

30. 〜2020年2⽉(現在) ▌v1.3向け機能提案2つを提案 l1つはマージ⾒込み lもう⼀つはreject→代替案で解決 ▌slackやissue上でユーザサポート中 ▌他社エンジニアと共同でKubeCon China向け Proposalを準備中 30

31. 今後の活動予定 ▌テスト追加 lV1.2リリース後に提案された ▌V1.2に追加した機能の関連機能の追加 lV1.2リリース前に提案された l無くてもNecoは困らないけどやる ▌その他諸々 31

32. まとめ ▌⻑期的に⾒ると低コストな場合が多々ある ▌徐々にできる範囲からやろう ▌開発プロセスを知ろう ▌開発者、会社ともに課題があります 32

33. おわりに ▌会社の垣根を越えて⼀緒にOSSに貢献しま しょう! ▌我々は情報の出し惜しみはしません 33