この記事は何？
OSSのメンテナーを2年続けてみての雑感をまとめています （過去記事の焼き増しです）。
あなたは誰？
株式会社グロービスのデジタルプラットフォーム部門でSite Reliability Engineerをしており、AWS,K8s(EKS)周りを中心に扱っています。クラウドインフラ分野を主軸と置きつつ、プロダクト開発チームと一緒に運用・監視の改善やインフラリソースへの扱いに対する心理的ハードルを下げる取り組みをしています。
何のメンテナーしてるの？
argo-helmという、Argo CD, Argo WorkflowsなどのArgoシリーズをK8sにインストールするためのHelm Chart(K8s用のパッケージマネージャー) projectのメンテナーをしています。
Argo CD, Argo Workflowsとは別のGitHub repositoryとして存在しており（GitHub Orgとしては同じargoprojの傘下）、それら（本体/上流にあたるためupstreamと呼ばれたりします）の更新に追従したHelm Chartを提供することを目的としています。
やってること
-
Pull Requestに出されたもののレビュー
- upstreamのバージョンアップなどがあればそれに対するPRを作成
-
Issuesに挙げられた質問・改善要望・不具合への対応
- バグの報告であれば修正PRを作成する
- 疑問・質問に関する回答やデバッグ
-
CNCF Slackにくる質問などの対応
- Issuesと同じ感じ
-
Discussionに挙げられた質問・改善要望・不具合への対応
- Issuesと同じ感じ
活動状況
-
2022年
-
2023年
-
2024年
経緯
キッカケ
業務でArgoシリーズを利用していることもありargo-helmは日常的に利用しているのですが、argo-workflows Helm Chart v0.15.0辺りでArgo Workflowsでの権限不足によるエラーを観測しました。
Helm Chart側の定義によるものなので「誰かが対応するのを待つのも良いけど、せっかく見つけたし直すかー」と思い立って修正PRを出したのが始まりでした。
※こう書くとフットワーク軽そうだな〜と思われるかもしれませんが、今まではOSSへのコミットなどは一切してこなかったこともあり、心理的ハードルはとても高かったです。もしも暴言吐かれたり無視されたら二度と立ち直れない...なんて思いながらPRを出しました（小声）。
継続的なISSUE解決
最初の修正PRを機にISSUEを眺めることが度々あり、その際に意外にも自分でもシュッと対応できそうなものがあることに気づきました。例えば「特定リソースに対して任意のannotationを付与できるようにしてほしい」というようなISSUEです。
既存定義に対する破壊的変更もなく、利用者が好きな値を付与できるような機能追加は比較的受け入れられやすいだろうという見立てもあったので、こういったものは率先して対応していきました。
※もちろん「出ているISSUEに対して全て真に受けてPRを作れば良い」という訳ではないので、「このISSUEは確かに対応することで利用者（と言う名の自分）が喜びそうだな」と思えるものをピックアップして対応しました。
最初のPRマージを経験すると不思議なことに2度目・3度目のPRは非常にフットワーク軽く出せました（慣れってすごいですね...）。
時々変なPRを出して（しかもそのままマージされて出荷される）revert対応するような肝を冷やす経験をしたのも、今となっては良い思い出です。
CODEOWNERSに参加するための条件
（途中で知ったのですが）argo-helmの場合には以下のpinned ISSUEでCODEOWNERSに自己推薦する条件が記載されています（他のコミュニティでも同じように記載がありそう?）。
We could always do with more reviewers! If you’ve submitted some PRs, and maybe done a few reviewers, you can self-nominate by submitting a PR adding yourself to the CODEOWNERS file.
私はCODEOWNERSに自己推薦するまでに出したPRは10件程度でしたが、当時はまだ「もうちょっと継続できたら自己推薦してみようかなー」と思っていました。....が、メンテナーの方に「そろそろ自己推薦してみてもええんちゃう？」と言っていただいたのでアッサリ自己推薦に踏み切りました。
これにより晴れてargo-helmのメンテナーとなりました。その後なんやかんや活動を継続した末にargo-helm全体のメンテナー（リードメンテナー??）となりました。
振り返り
良かったこと
外部コミュニティとの関わり
メンテナーのコミュニティに参加したことで、OSSとしてargo-helmをどう運営していくかなどの議論を経験しました。
会社員とは違ってコミット度合いの違いや組織としての方向性を定めることが難しいOSS活動において、コミュニケーションや意思決定をどのようにしていくのが良いかについて思いを巡らせる良い機会となりました（模索中ですが..）。
またメンテナーは英国・米国・EU・日本など世界中に在籍しており、誰もが知るビックテックで働いている方も参加していたりと、普段では会えない方々と一緒に活動できて非常に刺激的です。
Argoシリーズの仕様により詳しくなれた
argo-helm自体はあくまでもArgoシリーズが出しているK8s manifestをHelm Chart化して提供するものであり、ConfigMapやDeploymentなどへの設定値追従などはしますが個別の細かな機能については特に触れません。
一方でISSUEなどで挙げられるものはArgoシリーズの本体側のバージョン更新に伴う対応であったりすることもあります。機能要望や不具合報告を通して今まで知らなかった機能や仕様についても調査するきっかけになり、Argoシリーズの仕様により詳しくなりました。
英語でのやり取りに(多少)慣れた
私の家庭では英語を家庭内言語としていますが、家族以外の人と英語でやり取りすることはほとんどないため第三者と英語でやり取りする練習になり自信にも繋がりました。
特に家庭内だと自身の英語力の低さを家族がある程度考慮してくれるのでなんとかなることが多いですが、全くの初対面の方（かつ相手も非ネイティブだったりすることも多い）との英語のやり取りは本当にいい経験になりました。
学んだこと・気づいたこと
メンテナー不足
ArgoシリーズはCNCF Graduated projectであるためかなりの規模と安定さを持つプロジェクトであり、それをK8sにインストールする方法としてHelm Chartは比較的メジャーな流れなのでargo-helmのコミュニティもさぞ磐石なことだろうと思われるかもしれませんが、メンテナーは常に募集中です。
argo-helmに限らずOSSメンテナンスは有志でやっている人が多いこともあり、人材確保は大変だなと感じます。
共通認識構築の重要性
寄せられてくるISSUEやPRには懇切丁寧に背景や再現手順を記載したものから何も書いてないものまで様々なものがあります。また起票者の人となりが分からないためどこまで信用して良いのかも分かりません。
こういった状況において適切な対応をしていくためには、普段の仕事以上にヒアリングを通しての共通認識を気づくことの大切さを改めて感じました。
お互いが同じ前提のもと同じことに対して話をするということは会話をする上での前提条件だとは思いますが、一方で当たり前過ぎて蔑ろにされがちなものでもあると思います。OSS活動を通して共通認識を築くことの大切さを再認識しました。
ほどほど力の大事さ
OSSあるあるだとは思いますが、ISSUEやPRをあげっぱなし/投げっぱなしにされるケースは多々あります。こちらがレビューしたり質問に回答しても無視されてそのままcloseされるISSUE/PRも多かれ少なかれ存在するため、燃え尽きないほどほどの距離感でやることの重要性を自ずと意識するようになりました（特に自分は完全ボランティアとして活動しているので..）。
コミュニティに貢献したいという気持ちは今でも高いですが、その気持だけではやっていくのは難しいなというのが現実なため、バランス感覚を持って活動することが心の平安を保つ上で重要だと考えています。
OSSコントリビュートに興味がある方へ
多くの方（ご多分に漏れず以前の私も）にとってはOSSへのコントリビュートに対する心理的ハードルは高いと思いますし、そもそもコントリビュートに繋がるキッカケになるシーンなんてあるのか？という話もあると思います。
一方でOSSメンテナー側からすると、ほとんどのOSSコミュニティにおいて第三者が（そのコミュニティのルールを守った上で）ISSUEやPRを出すのは大歓迎だと思います。特にISSUEに基づいて対応が必要と判断された場合にPRまで出してもらえると泣いて喜びます！
ご自身が仕事などでよく使うライブラリについて、不具合（なんならtypoレベルでも！）やdocに不足している情報を見つけたり、改善案を思いついた際には是非ともISSUEとして声を上げて頂きたいと思っています！
Tips
そうは言ってもISSUEやPRの作法なんてどうやって会得すれば良いのか？と疑問に思う方も多いと思いますので、自身が実践したtipsを少しだけ紹介します。
-
CONTRIBUTING.mdを確認する- 多くのプロジェクトにはコントリビュートにあたってのガイドラインがCONTRIBUTING.mdにまとまっているので、まずはそちらを覗いてみるのが良いと思います。
- 実運用でどこまで厳密に適応されているかはコミュニティによりますが、守っておいて損することはありません。
- 逆に言うと、全然ガイドラインを守っていないISSUE/PRなどはそもそも誰も見てくれません
- argo-helmの例: CONTRIBUTING.md
- 先人のマージされたPRや動きが活発だったISSUEを参考にする
-
CONTRIBUTING.mdを読んでも詳細の部分などはわからないと言った場合もあると思いますので、具体的なケースについては先人たちのPRや、過去ちゃんとやりとりがなされているISSUEを探してみることでお作法などの勘所がつかめます。 - 例えばISSUE（これによって対応の必要性や方向性についてメンテナーとの共通認識を築くことができる）も無しにいきなり巨大PRを投げたり、再現手順や設定情報などをシェアせずに「このバージョンから急に動かなくなった！バグだ！」といったISSUEを挙げても誰も見てくれません。
-
- ひとまずDraftでPRを作る
- いざPRを作っていく段になっても、いきなりレビュワーの目に晒されると非常にドキドキします（レビュワーのタイムゾーンが違うと24時間コメントが飛んできます...）
- PRをreadyにするとレビューワーに通知が飛ぶようになっているprojectが多いと思いますが、Draftであれば通知は飛びません。
- そのため、体裁を整えてからレビュー依頼を出したい場合には、PR作成時にDraft状態で作成するのが心理的ハードルを下げられます。
Discussion