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
AIツール開発ワークショップ(Dify)【サイボウズ新人研修2025】
cybozuinsideout
PRO
15
16k
モバイル【サイボウズ新人研修2025】
cybozuinsideout
PRO
3
3.3k
Git/GitHub を使う上で知っておくと嬉しいかも Tips【サイボウズ新人研修2025】
cybozuinsideout
PRO
11
8.8k
GitHub Copilot活用【サイボウズ新人研修2025】
cybozuinsideout
PRO
14
13k
ソフトウェアライセンス【サイボウズ新人研修2025】
cybozuinsideout
PRO
12
7.5k
エンジニアのためのアウトプット講座 〜知識をシェアするはじめの一歩〜【サイボウズ新人研修2025】
cybozuinsideout
PRO
6
4.1k
Docker入門【サイボウズ新人研修2025】
cybozuinsideout
PRO
12
10k
セキュリティ【サイボウズ新人研修2025】
cybozuinsideout
PRO
2
3k
TLS 1.3をざっと理解する【サイボウズ新人研修2025】
cybozuinsideout
PRO
2
1.8k
Other Decks in Technology
See All in Technology
DatabricksのOLTPデータベース『Lakebase』に詳しくなろう!
inoutk
0
160
スプリントレビューを効果的にするために
miholovesq
9
1.7k
Datasets for Critical Operations by Dataform
kimujun
0
120
完璧を目指さない小さく始める信頼性向上
kakehashi
PRO
0
110
クマ×共生 HACKATHON - 熊対策を『特別な行動」から「生活の一部」に -
pharaohkj
0
190
Wasmで社内ツールを作って配布しよう
askua
0
150
MCPに潜むセキュリティリスクを考えてみる
milix_m
1
880
[TechNight #91] Oracle Database 最新パフォーマンス分析手法
oracle4engineer
PRO
3
150
Snowflake のアーキテクチャは本当に筋がよかったのか / Data Engineering Study #30
indigo13love
0
280
AIを使っていい感じにE2Eテストを書けるようになるまで / Trying to Write Good E2E Tests with AI
katawara
3
1.9k
AIエージェントを支える設計
tkikuchi1002
11
2.3k
新規事業におけるAIリサーチの活用例
ranxxx
0
170
Featured
See All Featured
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
The Cost Of JavaScript in 2023
addyosmani
51
8.6k
Rails Girls Zürich Keynote
gr2m
95
14k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
47
9.6k
Designing for humans not robots
tammielis
253
25k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Thoughts on Productivity
jonyablonski
69
4.8k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
Unsuck your backbone
ammeep
671
58k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
720
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