Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OSSへの貢献ノウハウ 〜LinuxカーネルからRookまで〜

Cybozu
February 27, 2020

OSSへの貢献ノウハウ 〜LinuxカーネルからRookまで〜

Cybozu

February 27, 2020
Tweet

More Decks by Cybozu

Other Decks in Technology

Transcript

  1. OSSへの貢献ノウハウ
    〜LinuxカーネルからRookまで
    Feb 18, 2020
    サイボウズNecoプロジェクト
    sat
    1

    View full-size slide

  2. 想定聴衆
    ▌業務で有名どころのOSSを使っている
    lLinux, Kubernetes, MySQL…
    ▌バグや機能不⾜で困っている
    ▌OSSへ貢献したことがない
    l必要性がわからない
    lやりかたがわからない
    2

    View full-size slide

  3. ⽬次
    3
    ▌貢献の利点
    ▌貢献⽅法
    ▌貢献時の課題
    ▌貢献の具体例

    View full-size slide

  4. 貢献の利点
    4

    View full-size slide

  5. よくあるケース
    5
    1. バグ/機能不⾜で困る…
    2. OSSなんだから⾃社独⾃版を作ろう!
    3. 独⾃修正で解決した、やったね︕
    安定版
    独⾃修正

    View full-size slide

  6. 安定版がバージョンアップすると…
    6
    ▌追加コストが⼤きい
    安定版
    独⾃修正
    古い安定版
    独⾃修正
    (変更が必要なことも)
    次の安定版からの
    バックポート

    View full-size slide

  7. そして地獄へ…
    7
    ▌ライフライクルが⻑いほど⼯数激増
    安定版
    独⾃修正
    古い安定版
    独⾃修正
    (変更が必要なことも)
    次の安定版からの
    バックポート
    古い安定版
    独⾃修正
    (変更が必要なことも)
    次の安定版からの
    バックポート
    次の次の安定版からの
    バックポート

    View full-size slide

  8. 安定版にマージしておくと…
    8
    ▌コストはそれほど増えない
    l定期的なテスト&regression修正は必要
    安定版
    修正
    次の安定版
    修正
    次の次の安定版
    修正

    View full-size slide

  9. その他
    9
    ▌開発者のスキルアップ
    l知⾒が豊富だと緊急時の対処がしやすい
    ▌顧客へのアピール
    l「〇〇の熟練開発者がいます︕」
    ▌社外開発者へのアピール
    lOSS開発したいエンジニアの採⽤に繋がるかも

    View full-size slide

  10. 貢献⽅法
    10

    View full-size slide

  11. はじめの⼀歩
    ▌「何から始めればいいかわからない…」
    l簡単なバグ報告/修正をやってみて慣れるのがオススメ
    lドキュメント修正やテスト追加もよい⼊⼝です
    l修正されるかどうか or 修正時期は気にしない
    ▌「具体的にどうすればいいんだ…」
    l貢献⽅法が書いていそうなドキュメントを⾒る
    lDevelopment.mdやContribution.mdなど
    lGithub, slack, メーリスなどを⾒て真似する
    11

    View full-size slide

  12. 修正されやすくするコツ
    ▌多くのユーザが嬉しくなることをアピール
    l× 「これが直らないと弊社が困るんです︕」
    l〇 「これはみんながハマりうる問題です︕」
    ▌なるべく⾃分で修正PRを出す
    lメンテナ(*1)はみなさんのバグを直す義務はない
    l直したくても⼈的リソースは限られている
    12
    *1) master branchにコミット権がある⼈。コミッタとも呼ぶことも

    View full-size slide

  13. 気持ちを楽にする⼼構え
    ▌最初から肯定的な反応を期待しない
    ▌否定的な反応をされてもくじけない
    l反対は注⽬されているサイン
    lしっかり議論して説得
    l無理筋なときは引き下がる。無理強いは嫌われる
    ▌無視が⼀番困る
    l投稿を⾒直して注⽬されるよう書き直し
    13

    View full-size slide

  14. ⾃社が遭遇した課題を解決したい
    ▌OSS使⽤時は様々な問題に遭遇する
    lバグ、機能不⾜…
    ▌典型的な解決⽅法
    1. 既存issue/PRの有無を確認
    2. 無ければ⾃分でissue/PR発⾏
    3. 機能追加は⾃らPR出さないと解決は困難
    14

    View full-size slide

  15. 押さえておきたいこと
    15
    ▌業務には問題解決済みの安定版を使いたい
    ▌安定版にいつ⼊るか⾒積もっておきたい
    ▌開発プロセスを知っておこう
    lマージ条件
    l開発版へのマージ時期
    l安定版リリース時期

    View full-size slide

  16. 開発プロセスの例
    ▌具体例を紹介
    lLinuxカーネル
    lRook
    lk8s上で動くストレージソリューションのオーケストレーター
    l分散ストレージCephなど
    ▌注意: 概要だけ書きます
    l詳細はドキュメントを参照
    16

    View full-size slide

  17. Linuxカーネル(1/2)
    ▌Master branchへのコミット権を持つのは1⼈だけ
    lオリジナル開発者のLinus Torvalds⽒
    ▌マージまでの順序
    1. サブシステム開発者たちによるレビュー
    2. サブシステムのメンテナが⾃⾝のツリーにマージ
    3. master branch(開発版)へのマージ
    4. 安定版リリース
    17

    View full-size slide

  18. Linuxカーネル(2/2)
    ▌2,3か⽉に⼀度安定版ををリリース
    l開発開始から2週間のみ新機能マージ可能
    l残りはバグ修正のみ
    ▌安定版への新機能のバックポートはしない
    18

    View full-size slide

  19. Rook
    ▌master branchへのコミット権を4⼈が持つ
    l新機能マージには3⼈のレビューが必要
    ▌安定版x.yのリリース間隔は未定義
    lこれまでは3~6か⽉に⼀回
    ▌新機能を安定版にバックポートすることも
    19

    View full-size slide

  20. 注意点
    20
    ▌PRを出してもマージされる保証は無い
    ▌常に代替案を⽤意しておこう
    l回避策を⾒つける
    l⼀時的に⾃社独⾃版/開発版を使う
    l⾃社独⾃版を使い続ける
    l最後の⼿段。できれば避けよう

    View full-size slide

  21. さらにその先へ(参考)
    ▌プロジェクト全体を盛り上げよう
    1. ユーザ増加
    2. バグ報告/修正、機能追加増加
    3. 品質向上
    ▌貢献し続けるとissue/PRに反応がもらえる傾向がある
    ▌⽅法
    lドキュメント追加、バグ報告/修正、機能追加
    lコードレビュー/ユーザサポート
    lイベントで発表
    21

    View full-size slide

  22. 貢献における課題
    22

    View full-size slide

  23. 開発者の課題
    ▌⼀般的な開発技術とは異なる能⼒が必要
    l⾒知らぬエンジニアに話しかける度胸
    l交渉能⼒
    ▌主要開発者/メンテナはもっと⼤変
    l真夜中の定例ミーティング
    l海外カンファレンスへの頻繁な参加
    23

    View full-size slide

  24. 会社の課題: 社内規則
    ▌勤怠システム
    l変則的な勤務に対応
    ▌情報発信ルール
    lIssue/PR発⾏に上⻑の許可が必要、などは⾟い
    ▌法務的なルール
    l著作権の帰属、CLAへの署名要否
    ▌(参考) サイボウズのOSSポリシー
    lhttps://cybozu-oss-policy.readthedocs.io/ja/latest/
    24

    View full-size slide

  25. 会社の課題: 考え⽅
    ▌⾃社の都合では進まないことを理解
    l×: 「次の安定版に絶対機能追加しろ」
    ▌会社に直近で利益が無い活動も認める
    l×: 「何でうちに関係ない機能開発してるの?」
    ▌できる/やりたい⼈に任せる
    l前述のスキルを持っている/これから持ちたい
    l前述の勤務体系に同意できる
    ▌興味の無い⼈にやらせてもパフォーマンスは出ない
    25

    View full-size slide

  26. 貢献の具体例
    NecoのRookへの貢献
    26

    View full-size slide

  27. 背景
    1. NecoのストレージはRook/Cephクラスタ
    2. ストレージは最重要
    lお客様のデータは何よりも優先
    l有事には即座に対処する必要がある
    ▌前述の理由でプロジェクト全体を盛り上げたい
    ▌主要開発者に、俺はなる
    lメンテナになる覚悟もある
    27

    View full-size slide

  28. 〜2019年夏
    ▌2018年5⽉~
    lV1.0リリース
    l使⽤を決定、評価開始
    ▌~2019年9⽉
    l評価中に⾒つけたバグのissue/PRを数個発⾏
    28

    View full-size slide

  29. 〜2019年12⽉
    ▌2019年10⽉
    lv1.2に向けに2つの機能追加PRを発⾏
    ▌2019年11⽉
    lKubeCon NAにおいてメンテナと会話
    l上記機能についての議論
    lNecoによる前述のコミット⽅針を表明
    ▌2019年12⽉
    lv1.2に上記2つの機能をマージ
    29

    View full-size slide

  30. 〜2020年2⽉(現在)
    ▌v1.3向け機能提案2つを提案
    l1つはマージ⾒込み
    lもう⼀つはreject→代替案で解決
    ▌slackやissue上でユーザサポート中
    ▌他社エンジニアと共同でKubeCon China向け
    Proposalを準備中
    30

    View full-size slide

  31. 今後の活動予定
    ▌テスト追加
    lV1.2リリース後に提案された
    ▌V1.2に追加した機能の関連機能の追加
    lV1.2リリース前に提案された
    l無くてもNecoは困らないけどやる
    ▌その他諸々
    31

    View full-size slide

  32. まとめ
    ▌⻑期的に⾒ると低コストな場合が多々ある
    ▌徐々にできる範囲からやろう
    ▌開発プロセスを知ろう
    ▌開発者、会社ともに課題があります
    32

    View full-size slide

  33. おわりに
    ▌会社の垣根を越えて⼀緒にOSSに貢献しま
    しょう!
    ▌我々は情報の出し惜しみはしません
    33

    View full-size slide