本記事では、「OSS応援企画」として記事末に「応援ボタン」を設置しています。1回の応援につき、Findyが100円をOSS団体などへ寄付し、エンジニアの成長とOSSの発展を応援する取り組みです。開発者の想いや取り組みに共感した気持ちが、OSSの支援にもつながっていく、そんな前向きな循環をFindyは目指しています。「応援ボタン」は、1日1回まで押すことができます。記事を読んで「いいな」と感じたら、ぜひボタンを押してあなたの応援の気持ちを届けてください。
こんにちは、中田（@sanposhiho）といいます。とある海外のスタートアップで社内向けのPlatformの開発をしています（フルリモートなので日本在住です）。
2021年からKubernetesというオープンソースに貢献しており、現在はSIG-Schedulingのテックリードとチェアーを兼任しています。
前回の記事では、「となりのテックノート」として、技術的な側面からKubernetes Schedulerの実装や最近の機能についての紹介を行いました。対して今回は、Kubernetesのオープンソースとしての開発の進められ方や、どのように貢献を始めることができるかなどを紹介できればと思います。
Kubernetes開発の裏側と参加のチャンス
ここまではかなり技術的な内容に触れてきましたが、ここからはKubernetesの開発がどのように行われているか、そしてどのように貢献を始めるのがおすすめかなどを紹介したいと思います。
ご存知の通り、KubernetesはGitHub上で開発が行われており、GitHub Issueでの議論、そしてPull Requestがベースです。
KubernetesにはSIG (Special Interest Group)と呼ばれるグループを中心に議論、意思決定がなされています。そして、複数のSIGにまたがる課題などに対してはWG (Working Group)と呼ばれるグループが存在します。
例えば、僕がリードしているSIG-Schedulingはその名の通りKubernetesのPodのスケジュール周りの開発をしているグループで、WG Batchなど複数の関連するWGにも所属しています。
ただ、大きな変更はここまでの話でも度々登場したKEP（Kubernetes Enhancement Proposal）によって管理されています。そのため、Kubernetesの最先端な機能に興味があれば、KEPを確認するのが一番の近道となります。
KEPは決まったフォーマットで議論が行われ、必要なSIGからの承認が最終的に必要になります。
また、リリースサイクルの決まった流れまでに、提案が承認され、実装がマージされ、ドキュメントが提出される必要があります。
コードだけじゃない！Kubernetesへの関わり方いろいろ
さて、では貢献にはどのような形があるでしょうか？
まず、実装への貢献です。新しい機能を実装したり、バグを直したりとKubernetesには非常に大量にやることがあります。詳しくは次のセクションで解説しようと思います。
次にドキュメントへの貢献という道もあります。英語のドキュメントももちろんなのですが、Kubernetesには公式の日本語ドキュメントもあり、貢献のファーストステップとして良いかもしれません。
そして、GitHub上で議論に参加したり、新機能提案に対して社内のユースケースを提供したり、バグを報告したりするのも貢献のうちの一つです。
また、あまり詳しくないので多くは語れませんが、リリースチームへの参加するという方法もあります。前述のように、Kubernetesの特にKEPはリリース内に締め切りがあったりします。KEPの数はリリース毎にかなり多く、直近のv1.34では72個のKEPが存在していたようです。リリースチームは内部で幾つかのロールに分かれており、それらのKEPそれぞれのステータスを管理したり、リリースブログの管理を担っていたり、CIを監視していたりと、幅広くリリース周り全般のコントロールをしています。
リリースサイクルが始まる前に大抵募集があるのでメーリングリストを見ておくと良いと思います。
また、少し別の角度ですが、貢献の始め方として、メンターしてもらえる機会を利用するという手があります。
実際、僕が貢献を始めたのはGoogle Summer of Codeと呼ばれるプログラムがきっかけでした。その他だと、Linux fundationがLFX mentorshipと呼ばれるプログラムを行なっています。
これらは、実際のメンテナがメンターとして付いて完全サポートしてくれる最高の機会になるので、時間がガッツリ取れるのであれば、非常に良い選択肢になると思います。
実装に飛び込むための準備と最初の一歩
実装への貢献に関しては、まずは自分の興味のある分野を絞るのが第一歩となります。Kubernetesと言っても、各種コントローラー、スケジューラー、Kubelet、などなど多くのコンポーネントに分かれています。すべてを実装レベルで把握している人は、メンテナーでもほぼいないと思いますし、僕はもちろん理解してないです。
どこになにの実装があるかを把握するくらいにして、基本的には1つのコンポーネントに絞って理解を深めていくのが1番良いと思います。
ある程度長期的に貢献することを考えているのであれば、貢献を開始するのはざっくり実装を理解したうえで行うことをおすすめしています。例えば、タイポを直したりするPull Requestを積み重ねても、開発のフローに慣れるという視点では良いと思うのですが、理解を深めたり次の貢献につながるきっかけにはあまりならないと思うためです。また、メンテナー的な目線からすると、タイポの修正レベルのPRは優先度が低く、結果として無視されることもあるでしょう。
ただ、「“ざっくり”実装理解ってどのくらい？」ともなると思います。スケジューラーでいうと、この記事の前半で紹介したような、スケジューラーの基本的なサイクルを理解し、大体どのあたりで何が行われてるのかを知るくらいでちょうど良いと思います。そこからさらに深掘りし、隅々まで理解するのは何かしらのIssueにアサインされた後に必要であれば、くらいで良いでしょう。
次にタスクの探し方です。まず、はじめのうちは既存のIssueから探すのがおすすめです。実装を読んでいてバグっぽいものを見つけたとしても、Issueを開いたうえでメンテナーとの議論からスタートした方が良いです。
Issueの探し方ですが、あなたの選んだコンポーネントに対応するラベル(sig/scheduling etc)のIssueのうち、王道はhelp-wantedやgood-first-issueが付いたissueを探していくことになります。ただ、世界中で多くの人が貢献の機会を伺っているため、それらのIssueの倍率はかなり高いと覚悟する必要があります。
実際メンテナーがすべての簡単なIssueにそれらのラベルを逐一つけているかと言われればそうではないので、あまりこだわらず広くIssueを探すのがおすすめです。
kind/cleanupが付いているIssueは簡単なものが多いと思うので、穴場かもしれません。
PRを進めている際に、質問などがあった場合はメンテナーに積極的に聞くことをお勧めします。ただ、もちろんですが、詰まるたびにすぐに質問するのではなく、ある程度自分で理解を深めた上で的を絞った質問をする方が、メンテナーのエネルギーを消費しないのでお勧めです。
「積極的に」とお勧めしているのは、例えば、ある程度実装に選択肢があるとします。その時、「わからんけどとりまこれで！」と言う感じでPRになって投げられてくるより、「これこれこれの選択肢がありますけど、どれが良いっすかね？」と事前に聞いてもらった方が、メンテナー的にも後のレビューで大幅修正を伝える必要がなくなりますし、コントリビューター的にもそこで実装方針決定の思考プロセスや、プロジェクト内での慣習などを習う良い機会になると思います。
また、kubernetesにはkubernetes orgやkubernetes-sigs orgに多くのサブプロジェクトがあります。サブプロジェクトと言っても超有名なもの、革新的なアイデアを実現しようとしているものなど、興味深いものがたくさん見つかると思います。Kubernetes本体は実装が巨大すぎたり、簡単なissueがすぐに取られてしまったり、ハードルが高く始めにくいと感じる人にとっては、サブプロジェクトから貢献を始めるというのも良いアイデアだと思います。
目指せステップアップ！Kubernetesで広がる役割と道
Kubernetesの貢献において、いくつか目標として目指すことができるマイルストーンがあります。
まずは、K8sのGithubのorgメンバーです。いくつか貢献を積み、スポンサーとなってくれるメンテナーを2人見つけることで、K8sのGithubのorgに入れてもらうことができます。感覚的には10個弱のPRを提出していれば、十分だと思います。
その次に目指すのはReviewerとApproverになります。これらはエリアごとに分かれている権限です(SIG-Scheduling reviewer/approver etc)。20個／30個のPRがエリア内でマージされ、レビューの経験も必要になります。
役割としてはReviewerは1つ目のレビューを行えるSIG公認のレビュアー、Approverは最終的なPRの承認を行えるレビュアーという形になります。
そしてその先にSIG Lead (Chair and Tech Lead)が存在します。彼らは文字通りSIGの方向性を決定するリーダー的な存在で、SIGごとに3人前後存在します。
また、少し違った角度でContributor Awardというのも存在します。これはReviewer etcのようにロールではないのですが、その年に大きな成果を残した貢献者が表彰されます（Chair/Tech leadを除く）。
といった感じで、多くのマイルストーンが存在しているため、自分の現状に応じて目標にしてみるとモチベーションにつながると思います。
オープンソースを長く続けるための“個人的な”アドバイス
最後に個人的なアドバイスを書いて、記事を締めくくろうかと思います。
オープンソースに貢献しよう！という意思を持ってもらえるのは、同じ人間としてもKubernetesのメンテナーとしても非常に嬉しいです。
ただ、現実的な話になりますが、そういった形で貢献をはじめ、その後会社にサポートをもらえる人は非常に少なく、自分の時間を使って趣味のような形で貢献を続けることになります。
そのため、長く貢献を続けるには、強いモチベーションが必要になります。
例えば、貢献することで転職に役に立つであったり、社内の評価に良い影響がある、のような**実際の利益**を得ることが大切だと個人的に思っています。会社の業務に役に立つというのも利益のひとつではありますが、個人的には個人の時間使ってるならその人自身の直接的な利益になった方が健全だと思っています。
オープンソースでの大きな実績は、客観的に技術力/知識を示す証明として非常に有用です。実際僕のすべての転職はオープンソース活動経由で話をいただいたことがきっかけです。
また、オープンソースでの繋がりも他では得難い価値のあるものです。僕は、Kubeconで集まる際にはご飯などに行くことはもちろん、個人的にポーランドに旅行した時にご自宅にお邪魔したりと、いろいろと繋がりを得ることができました。優秀な人々と知り合い、議論を交わし、機能をともに育て、技術的な部分以外でもそうして深い繋がりになることができるというのは、僕が感じているオープンソースの醍醐味のうちのひとつかもしれません。
また、モチベーションの部分から離れますが、僕は普段強く「自分のペースを守る」と言うのを意識しています。僕のオープンソース活動は仕事ではなく趣味です。例えば、辛い思いをしながら毎日夜更かしをレビューをこなす、みたいな義務感で動き出すと楽しく長く続けることができないと思っています。（とはいえ、コードフリーズ直前は流石に忙しかったりはしますが…）
なので、僕はどれだけレビューが溜まっていようが、土日に旅行の予定があれば旅行に行くし、平日も仕事が忙しければあまり浮上しません。そのように、あくまでも「これは仕事ではないし、義務ではない」と言う意識を強く持ちつつ、ゆるく自分のペースで続けるのが1番の長続きのコツかもしれません。
ということで2つの記事にわたり長くだらだらとした内容になってしまいましたが、どこか参考になるようなパートが一部分でもあれば幸いです！
何か質問があれば KubernetesのSlackで連絡してもらえれば、お答えすることができるかもしれないです。
では皆さん、良いオープンソースライフを！