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

by Cybozu

Embed

Start on current slide

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

貢献の利点 4

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

貢献⽅法 10

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

貢献における課題 22

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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