Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
OSSへの貢献ノウハウ 〜LinuxカーネルからRookまで〜
Search
Cybozu
PRO
February 27, 2020
Technology
2
2.8k
OSSへの貢献ノウハウ 〜LinuxカーネルからRookまで〜
Cybozu
PRO
February 27, 2020
Tweet
Share
More Decks by Cybozu
See All by Cybozu
Recruitment Pitch in New Business Division
cybozuinsideout
PRO
0
12
サイボウズ Office/メールワイズチームの改善の取り組み「困りごと共有会」
cybozuinsideout
PRO
1
16
サイボウズのOSPO
cybozuinsideout
PRO
1
91
非エンジニアの私が試行錯誤の末見出したスクラムマスターの道
cybozuinsideout
PRO
2
130
Kubernetes でもJava アプリでTLS 接続を終端したい
cybozuinsideout
PRO
2
150
Google I/O - 2024 What’s new in flutter
cybozuinsideout
PRO
2
260
Waffle Festival2024(斉藤裕希)
cybozuinsideout
PRO
3
560
主体的な活動で巨大な影響範囲のテストを乗りこなしていく話
cybozuinsideout
PRO
2
360
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
9
40k
Other Decks in Technology
See All in Technology
DDDにおける認可の扱いとKotlinにおける実装パターン / authorization-for-ddd-and-kotlin-implement-pattern
urmot
4
390
初中級者用如何使用backlog -VALE TUDOEDITION-
in0u
0
140
20240724_cm_odyssey_hibiyatech
hiashisan
0
110
シフトレフトで挑む セキュリティの生産性向上
sekido
PRO
0
270
フルリモートワークはエンジニアの夢を叶えたか? #cm_odyssey
mamohacy
2
600
dxd2024-生成AIに振り回された3か月間の成功と失敗/dxd2024-link-and-motivation
lmi
2
260
OSSコミットしてZennの課題を解決した話
dyoshikawa1993
0
150
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
0
190
20240717_イケコパ代表Copilot_in_Teams会社でこう使ってます
ponponmikankan
2
430
AWS IAMのアンチパターン/AWSが考える最低権限実現へのアプローチ概略(JAWS-UG朝会#59資料改修20分版)
htan
0
330
ソフトウェアエンジニアリングの知見を活かして データ基盤をいい感じにする on Snowflake [MIERUNE BBQ #10]
mtpooh
2
150
E2Eテスト自動化プラットフォームにおけるAIの活用
shift_evolve
0
180
Featured
See All Featured
Being A Developer After 40
akosma
72
580k
The Cult of Friendly URLs
andyhume
75
5.9k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
502
140k
What the flash - Photography Introduction
edds
65
11k
Fontdeck: Realign not Redesign
paulrobertlloyd
79
5.1k
RailsConf 2023
tenderlove
16
720
Learning to Love Humans: Emotional Interface Design
aarron
269
39k
Building Your Own Lightsaber
phodgson
101
5.9k
How to Think Like a Performance Engineer
csswizardry
4
590
The Straight Up "How To Draw Better" Workshop
denniskardys
229
130k
Web Components: a chance to create the future
zenorocha
307
41k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
35
6.3k
Transcript
OSSへの貢献ノウハウ 〜LinuxカーネルからRookまで Feb 18, 2020 サイボウズNecoプロジェクト sat 1
想定聴衆 ▌業務で有名どころのOSSを使っている lLinux, Kubernetes, MySQL… ▌バグや機能不⾜で困っている ▌OSSへ貢献したことがない l必要性がわからない lやりかたがわからない 2
⽬次 3 ▌貢献の利点 ▌貢献⽅法 ▌貢献時の課題 ▌貢献の具体例
貢献の利点 4
よくあるケース 5 1. バグ/機能不⾜で困る… 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カーネル lRook lk8s上で動くストレージソリューションのオーケストレーター 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