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
33
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
ユーザーの声とAI検証で進める、プロダクトディスカバリー
sansantech
PRO
1
140
Wasmのエコシステムを使った ツール作成方法
askua
0
180
AI時代こそ求められる設計力- AWSクラウドデザインパターン3選で信頼性と拡張性を高める-
kenichirokimura
3
320
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
12
80k
[Keynote] What do you need to know about DevEx in 2025
salaboy
0
170
AWS Top Engineer、浮いてませんか? / As an AWS Top Engineer, Are You Out of Place?
yuj1osm
2
210
「れきちず」のこれまでとこれから - 誰にでもわかりやすい歴史地図を目指して / FOSS4G 2025 Japan
hjmkth
1
310
GoでもGUIアプリを作りたい!
kworkdev
PRO
0
150
JAZUG 15周年記念 × JAT「AI Agent開発者必見:"今"のOracle技術で拡張するAzure × OCIの共存アーキテクチャ」
shisyu_gaku
1
160
RDS の負荷が高い場合に AWS で取りうる具体策 N 連発/a-series-of-specific-countermeasures-available-on-aws-when-rds-is-under-high-load
emiki
2
1k
20201008_ファインディ_品質意識を育てる役目は人かAIか___2_.pdf
findy_eventslides
2
640
WEBサービスを成り立たせるAWSサービス
takano0131
1
160
Featured
See All Featured
Into the Great Unknown - MozCon
thekraken
40
2.1k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
Automating Front-end Workflow
addyosmani
1371
200k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
For a Future-Friendly Web
brad_frost
180
10k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
115
20k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.1k
RailsConf 2023
tenderlove
30
1.2k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
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