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
3.2k
OSSへの貢献ノウハウ 〜LinuxカーネルからRookまで〜
Cybozu
PRO
February 27, 2020
Tweet
Share
More Decks by Cybozu
See All by Cybozu
不具合の先にある面白さ~配属3か月目の新卒QAのいま~
cybozuinsideout
PRO
0
41
kintone開発チームの紹介
cybozuinsideout
PRO
1
77k
kintone開発のプラットフォームエンジニアの紹介
cybozuinsideout
PRO
0
140
AIツール開発ワークショップ(Dify)【サイボウズ新人研修2025】
cybozuinsideout
PRO
20
24k
モバイル【サイボウズ新人研修2025】
cybozuinsideout
PRO
3
3.9k
Git/GitHub を使う上で知っておくと嬉しいかも Tips【サイボウズ新人研修2025】
cybozuinsideout
PRO
14
11k
GitHub Copilot活用【サイボウズ新人研修2025】
cybozuinsideout
PRO
15
15k
ソフトウェアライセンス【サイボウズ新人研修2025】
cybozuinsideout
PRO
14
8.5k
エンジニアのためのアウトプット講座 〜知識をシェアするはじめの一歩〜【サイボウズ新人研修2025】
cybozuinsideout
PRO
7
4.8k
Other Decks in Technology
See All in Technology
Data Hubグループ 紹介資料
sansan33
PRO
0
2.2k
Zephyr(RTOS)にEdge AIを組み込んでみた話
iotengineer22
0
160
Performance Insights 廃止から Database Insights 利用へ/transition-from-performance-insights-to-database-insights
emiki
0
310
CoRL 2025 Survey
harukiabe
1
220
ガバメントクラウドの概要と自治体事例(名古屋市)
techniczna
3
240
プレーリーカードを活用しよう❗❗デジタル名刺交換からはじまるイベント会場交流のススメ
tsukaman
0
180
Railsの話をしよう
yahonda
0
160
コンテキストエンジニアリング入門〜AI Coding Agent作りで学ぶ文脈設計〜
kworkdev
PRO
3
1.7k
Findy Team+ QAチーム これからのチャレンジ!
findy_eventslides
0
440
Wasmの気になる最新情報
askua
0
130
React19.2のuseEffectEventを追う
maguroalternative
2
500
LLMアプリの地上戦開発計画と運用実践 / 2025.10.15 GPU UNITE 2025
smiyawaki0820
1
640
Featured
See All Featured
RailsConf 2023
tenderlove
30
1.3k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
31
2.7k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.7k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
Building Adaptive Systems
keathley
44
2.8k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.2k
Building a Modern Day E-commerce SEO Strategy
aleyda
44
7.8k
The Pragmatic Product Professional
lauravandoore
36
6.9k
Practical Orchestrator
shlominoach
190
11k
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