OSSへの貢献ノウハウ〜LinuxカーネルからRookまでFeb 18, 2020サイボウズNecoプロジェクトsat1
View Slide
想定聴衆▌業務で有名どころのOSSを使っているlLinux, Kubernetes, MySQL…▌バグや機能不⾜で困っている▌OSSへ貢献したことがないl必要性がわからないlやりかたがわからない2
⽬次3▌貢献の利点▌貢献⽅法▌貢献時の課題▌貢献の具体例
貢献の利点4
よくあるケース51. バグ/機能不⾜で困る…2. OSSなんだから⾃社独⾃版を作ろう!3. 独⾃修正で解決した、やったね︕安定版独⾃修正
安定版がバージョンアップすると…6▌追加コストが⼤きい安定版独⾃修正古い安定版独⾃修正(変更が必要なことも)次の安定版からのバックポート
そして地獄へ…7▌ライフライクルが⻑いほど⼯数激増安定版独⾃修正古い安定版独⾃修正(変更が必要なことも)次の安定版からのバックポート古い安定版独⾃修正(変更が必要なことも)次の安定版からのバックポート次の次の安定版からのバックポート
安定版にマージしておくと…8▌コストはそれほど増えないl定期的なテスト®ression修正は必要安定版修正次の安定版修正次の次の安定版修正
その他9▌開発者のスキルアップl知⾒が豊富だと緊急時の対処がしやすい▌顧客へのアピールl「〇〇の熟練開発者がいます︕」▌社外開発者へのアピールlOSS開発したいエンジニアの採⽤に繋がるかも
貢献⽅法10
はじめの⼀歩▌「何から始めればいいかわからない…」l簡単なバグ報告/修正をやってみて慣れるのがオススメlドキュメント修正やテスト追加もよい⼊⼝ですl修正されるかどうか or 修正時期は気にしない▌「具体的にどうすればいいんだ…」l貢献⽅法が書いていそうなドキュメントを⾒るlDevelopment.mdやContribution.mdなどlGithub, slack, メーリスなどを⾒て真似する11
修正されやすくするコツ▌多くのユーザが嬉しくなることをアピールl× 「これが直らないと弊社が困るんです︕」l〇 「これはみんながハマりうる問題です︕」▌なるべく⾃分で修正PRを出すlメンテナ(*1)はみなさんのバグを直す義務はないl直したくても⼈的リソースは限られている12*1) master branchにコミット権がある⼈。コミッタとも呼ぶことも
気持ちを楽にする⼼構え▌最初から肯定的な反応を期待しない▌否定的な反応をされてもくじけないl反対は注⽬されているサインlしっかり議論して説得l無理筋なときは引き下がる。無理強いは嫌われる▌無視が⼀番困るl投稿を⾒直して注⽬されるよう書き直し13
⾃社が遭遇した課題を解決したい▌OSS使⽤時は様々な問題に遭遇するlバグ、機能不⾜…▌典型的な解決⽅法1. 既存issue/PRの有無を確認2. 無ければ⾃分でissue/PR発⾏3. 機能追加は⾃らPR出さないと解決は困難14
押さえておきたいこと15▌業務には問題解決済みの安定版を使いたい▌安定版にいつ⼊るか⾒積もっておきたい▌開発プロセスを知っておこうlマージ条件l開発版へのマージ時期l安定版リリース時期
開発プロセスの例▌具体例を紹介lLinuxカーネルlRooklk8s上で動くストレージソリューションのオーケストレーターl分散ストレージCephなど▌注意: 概要だけ書きますl詳細はドキュメントを参照16
Linuxカーネル(1/2)▌Master branchへのコミット権を持つのは1⼈だけlオリジナル開発者のLinus Torvalds⽒▌マージまでの順序1. サブシステム開発者たちによるレビュー2. サブシステムのメンテナが⾃⾝のツリーにマージ3. master branch(開発版)へのマージ4. 安定版リリース17
Linuxカーネル(2/2)▌2,3か⽉に⼀度安定版ををリリースl開発開始から2週間のみ新機能マージ可能l残りはバグ修正のみ▌安定版への新機能のバックポートはしない18
Rook▌master branchへのコミット権を4⼈が持つl新機能マージには3⼈のレビューが必要▌安定版x.yのリリース間隔は未定義lこれまでは3~6か⽉に⼀回▌新機能を安定版にバックポートすることも19
注意点20▌PRを出してもマージされる保証は無い▌常に代替案を⽤意しておこうl回避策を⾒つけるl⼀時的に⾃社独⾃版/開発版を使うl⾃社独⾃版を使い続けるl最後の⼿段。できれば避けよう
さらにその先へ(参考)▌プロジェクト全体を盛り上げよう1. ユーザ増加2. バグ報告/修正、機能追加増加3. 品質向上▌貢献し続けるとissue/PRに反応がもらえる傾向がある▌⽅法lドキュメント追加、バグ報告/修正、機能追加lコードレビュー/ユーザサポートlイベントで発表21
貢献における課題22
開発者の課題▌⼀般的な開発技術とは異なる能⼒が必要l⾒知らぬエンジニアに話しかける度胸l交渉能⼒▌主要開発者/メンテナはもっと⼤変l真夜中の定例ミーティングl海外カンファレンスへの頻繁な参加23
会社の課題: 社内規則▌勤怠システムl変則的な勤務に対応▌情報発信ルールlIssue/PR発⾏に上⻑の許可が必要、などは⾟い▌法務的なルールl著作権の帰属、CLAへの署名要否▌(参考) サイボウズのOSSポリシーlhttps://cybozu-oss-policy.readthedocs.io/ja/latest/24
会社の課題: 考え⽅▌⾃社の都合では進まないことを理解l×: 「次の安定版に絶対機能追加しろ」▌会社に直近で利益が無い活動も認めるl×: 「何でうちに関係ない機能開発してるの?」▌できる/やりたい⼈に任せるl前述のスキルを持っている/これから持ちたいl前述の勤務体系に同意できる▌興味の無い⼈にやらせてもパフォーマンスは出ない25
貢献の具体例NecoのRookへの貢献26
背景1. NecoのストレージはRook/Cephクラスタ2. ストレージは最重要lお客様のデータは何よりも優先l有事には即座に対処する必要がある▌前述の理由でプロジェクト全体を盛り上げたい▌主要開発者に、俺はなるlメンテナになる覚悟もある27
〜2019年夏▌2018年5⽉~lV1.0リリースl使⽤を決定、評価開始▌~2019年9⽉l評価中に⾒つけたバグのissue/PRを数個発⾏28
〜2019年12⽉▌2019年10⽉lv1.2に向けに2つの機能追加PRを発⾏▌2019年11⽉lKubeCon NAにおいてメンテナと会話l上記機能についての議論lNecoによる前述のコミット⽅針を表明▌2019年12⽉lv1.2に上記2つの機能をマージ29
〜2020年2⽉(現在)▌v1.3向け機能提案2つを提案l1つはマージ⾒込みlもう⼀つはreject→代替案で解決▌slackやissue上でユーザサポート中▌他社エンジニアと共同でKubeCon China向けProposalを準備中30
今後の活動予定▌テスト追加lV1.2リリース後に提案された▌V1.2に追加した機能の関連機能の追加lV1.2リリース前に提案されたl無くてもNecoは困らないけどやる▌その他諸々31
まとめ▌⻑期的に⾒ると低コストな場合が多々ある▌徐々にできる範囲からやろう▌開発プロセスを知ろう▌開発者、会社ともに課題があります32
おわりに▌会社の垣根を越えて⼀緒にOSSに貢献しましょう!▌我々は情報の出し惜しみはしません33
cybozuinsideout
k_koheyi
kazumax55
mashiike
devopstaiwan
linedevth
.png){kind=icon}
pharma_x_tech
shimacos
yoshitake_1201
hankehly
hiashisan
kyonmm
ewolff
jensimmons
smashingmag
jponch
paigeccino
trishagee
mclloyd
shpigford
zakiwarfel
thekraken
brianwarren
thoeni
paulrobertlloyd