継続的コントリビュートの始め方(Tips)と半年間OSSコントリビューターをした感想
はじめに
こんにちは、がんがんです。
私は 2024 年の初めから OSS に対する積極的なコントリビュートを行なっています。
2024 年 1 月から 6 月までの半年間で 200 弱 くらいのコントリビュートを行いました。
コントリビュートの主戦場は主に Nuxt と Vue.js コミュニティです。
時期によってはデイリーコントリビューターも行なっておりコントリビュートに対する知見がある程度溜まってきました。
本記事では半年間コントリビューターを行なってきた感想、どんなところに着目して継続的コントリビュートを行なっているのかについてまとめていきます。
本記事の対象読者とそうでない読者
本記事では以下のような読者を対象としています。
- コントリビューターになってみたい人
- 初めてのコントリビュートは既に終えた。今後もコントリビュートを実施していきたい人
- 積極的にコントリビュートしたいがどうすれば継続できるかを探している人
逆に以下のような方は本記事の対象ではありません。関連する記事を読んで頂いた方が良いです。
- これから初めてのコントリビュートを行う方
- Issue 作成方法、環境構築について、fork の仕方など、PR 作成までの手順は本記事では扱いません。
現在の戦績
私は主に Nuxt と関連ライブラリを中心にコントリビュートを行なっています。大体 200 弱くらいはやれてたりします。
Nuxt にはNuxtersというコントリビューターランキングみたいな面白いプロジェクトがあります。Nuxters は Nuxt Organization、Nuxt Modules Organization 対象にポイントを算出しています。
これを見る限りだと現在 70 弱くらいの PR を出せており、現在ランキング 38 番まで上がってこれました 🎉
ただ、メンテナーチームの面々は何倍も貢献しているので今後も精進したいです。
他にも Hono や Panda CSS などにもちょっとだけコントリビュートしてます。
きっかけは...
全てのきっかけはこのポストから始まりました。
ここ半年で利用している OSS に対して何か貢献できないかと考えたのがきっかけでした。「ポストすれば逃げられなくなってどうにか考えるでしょう」くらいのノリでポストしました。
半年間コントリビューターを行った感想
そもそも、なぜ OSS にコントリビュートするのか？
私は以下 3 点の目的でコントリビュートしています。
- 自分が使うものは自分で直せば良いし、自分で作れば良い
- 「OSS への貢献は難しいことではない」と悩んでいる人に行動で示したい
- 将来的なリクルーティングを見据え、自分が広告塔になる
1. 自分が使うものは自分で直せば良いし、自分で作れば良い
学生時代から開発環境の効率化や自動化、省力化を得意とし shell スクリプト や CLI をよく作っていました。学生時代に Shell + Docker で擬似 k8s を作ったり、新卒で Shell だけで対話式 CLI を作ったのは良い思い出です。
ただ、プロダクトチーム内でこれを実施すると
- 作ったはいいが誰も使ってくれない(そもそも知らない)
- タスクの優先度が高くないため自分もメンテできない
という課題に直面していました。
チーム内が効率よく回るために作成したもののチーム内の熱量はバラバラであり結果的に自己満で終わる、これはエンジニアならばあるあるかと思います。
正社員・リーダー・マネージャー・業務委託さん、それぞれの視座や目的は異なるので当然といえば当然です。
また、現在の私は1人チームで活動することがほとんどであり、自分が作ったツールのメンテで自分が苦しめられるという構図となっています。
そこで 自分が使うもの・自分が欲しいものは自分で作成し OSS に PR を出す。自分が欲しいものはどんどん提案してイシューで議論する という方針にシフトしました。
「OSS に貢献することで対外的な評価も得られ、合わせて自分が使うものを自分で良くして自分で直せる」などの良い恩恵を受けることに繋がっています。メンテ・運用って逃げられない課題です...
2. 「OSS への貢献は難しいことではない」と悩んでいる人に行動で示したい
学生時代や新卒 1 年目の時には「OSS への貢献は難しいものであり、英語でやり取りするのはハードルが高い。自分にはあまり出来ない」と思ってました。
しかし、今では 小さなことでも積極的に OSS に貢献し、自分が使う道具は自分で良くした方が良い という思考にシフトしました。ただ、一人だけ思考が変化してもあまり意味はないです。一人の力と活動時間は限りがありますし、一人でやっていてメンテが潰えた OSS も数知れずあります。
なので、OSS 貢献の輪を広げていくのが大事だと私は考えています。合わせて「言ってるやつがやってないのはどうなの？」と言われないように私も日々貢献を続けています。
OSSへの貢献方法はコードへのコントリビュートだけではありません。私が主戦場としているVue.jsのコミュニティーガイドには以下のような記載があります。
Vue コミュニティーへの貢献の形は、コードの貢献だけではありません。Discord やフォーラムで仲間の Vue ユーザーの質問に答えることも、価値ある貢献と見なされます。
ユーザーの困りごとを助ける、バグのイシューを起票する、コードに commit する、コミュニティを運営する、記事を執筆する、などなど全ては OSS 貢献に繋がる行為とされています。
「コミュニティの輪を広げ、多くのコミュニティユーザーに大なり小なりの影響を与えて自分らしく貢献する」、これが大事ではないかと考えています。
上記では Vue.js のガイドラインを引用していますが、この考え方は Vue.js に限らずどのコミュニティでも共通なのかなと思います(所感)
私がコードに対するコントリビュートのみならず、執筆やコミュニティ活動を積極的に行っている源泉はここにあります。
3. 将来的なリクルーティングを見据え、自分が広告塔になる
現在の私は 1 人チームで活動しており基本的にリクルーティングを行う必要がありません。ただ、今後リクルーティングを行いたい、人を増員したいとなることは容易に想像できます。そうなってから準備しても大体遅いか、出遅れることが大半でしょう。
そのため、「私の執筆・OSS 活動は将来のリクルーティング活動の一環であり、自分が広告塔になることで出会える・貢献できる人に対しての先行投資である」という考えの元で行っています。
私の行動が少しでも誰かのためになっていたらそれだけで嬉しいです。
今すぐ始めやすいコントリビュートの Tips
私が半年間継続的にコントリビュートを続けられた気付きを書いていきます。あくまで私が観測・思考したものであり全てのコミュニティ・OSS に該当するものではありません。メンテナーに依存します。
以下で話す内容はあくまで継続的にコントリビュートを続けるためのものです。
積極的に貢献したい という方は是非とも機能開発・バグ修正を積極的に行ってください(新規機能開発も楽しいですよね、時間ある方は是非チャレンジしてみてほしい)
Tips1: typo や文言の修正漏れは割とある
ドキュメントを眺めていると typo を見かけることがあると思います。また、文言が以前のものでありメンテが間に合っていないこともあります。
機能開発を優先すると細部まで見れないケースは多々ありますので、このようなものは PR 出してもらえると喜ばれます。
以下は実装内で修正したケース例です
Tips2: ドキュメントのリンクは切れがち
機能開発が進んでいくと、過去のモジュール名のままのリンクや現在は使われていないモジュールに対するリンクが残っていたりします。
リンク不一致は間違い探しのようなものであり、メンテナー側としては優先度の下がる事項です。しかし、ユーザー側からすると正しい情報が得られず混乱してしまうかもしれません。「文言とリンクが全然異なって戸惑った」という経験を持った方は多いのではないかと思います。
そのため、リンク切れを直すことで双方に対してメリットが生まれます。
以下は実装内で修正したケース例です
Tips3: CI/CD 環境、Linter / Test 環境などの開発運用補助が狙い目
私は CI/CD や開発環境の構築周りに対して強みを持っています。そのため、自分の強みで貢献できないかなと考えました。
リポジトリをいろいろ見てみると以下の点で貢献できそうでした。
- GitHub Issue / PR テンプレートを整備しメンテナー・レビュアーの負担を軽減すること
- Renovate や Dependabot に対しての対応を実施する
- GitHub Actions を用いた効率的な運用体験を提案する(eg. キャッシュを用いたテストの高速化)
私は主に Renovate の追従などで PR 投げています。
また、直近であればESLint Flat ConfigおよびESLint v9への対応はどのリポジトリでも抱えている課題です。
機能開発ではないため優先度は落ちるもののメンテナーチームとしては早めに対処したい頭の痛い課題です。
この頭の痛い課題はコントリビュートしたい人からすると狙い目です。
ESLint 対応は Flat Config に対する知見を必要としたり、ESLint エラーをひたすら潰していく大変な作業です。
ですが、この時の経験は自身のプロダクトでマイグレーション作業を行うときに活きてきます。チャレンジしてみる価値は高いと思います(私は Vue.js の v2 -> v3 マイグレーションやってる時に欲しかった経験値です)
Tips4: Owner やメンテナーメンバーの PR 作成状況を観測する
OSS にはオーナーやメンテナーメンバーが必ずいます。会社のプロダクトであれば PO や PdM のような存在です。
そのような存在がどんな PR や Issue 作成しているのか、これを観察することで見えてくる流れがあります。
例えば、私が実際に観測していた例を挙げてみます。以下のような PR を観測しました。
この PR を観測したとき「ドキュメントの指針として Nuxt CLI 利用に寄せていきたいのではないか。他のモジュールや Repo でも同様の PR はないか」と探してみました。すると仮説通り PR を観測しました。
上記はあくまで一例ですがメンテナーメンバーのPRなどの流れを追うことでより重要度の高い・意味のあるPRを作成することが出来ます。
メンテナーチームにとってより恩恵の高いものはマージ待ち期間も短くなる傾向にあります。
Tips5: 執筆して広報する
コードに対するコントリビュートとは外れますが、1 番早く始められるものは 実際に利用し、利用状況を執筆し、そして X などで公開して利用者を増やすこと です。
時間をかけて作ったものが使われずにプロダクトの生涯を終える、延命措置でメンテし続ける 、経験がある人にとってはよく分かると思いますが非常に辛いです。
企業プロダクトはビジネス観点が含まれており、場合によっては多くの金を投じて対処することもあります。
しかし、OSS においては同じことが出来ません。OSS コントリビューターは総じてボランティアです。
OSS コントリビューターが「作ってよかった。メンテしてよかった」と思えるためには使ってもらう必要があります。
使ってもらうためには広報・紹介するしかありません。広報という貢献方法を 1 番行えるのが利用者です。どんどん執筆して広めていき、たくさんの知見をコミュニティに蓄積させ、そして改善のサイクルを一緒に回していきましょう。
Tips まとめ
- ドキュメントの修正は大体後回しになりがち。みんなで助けてあげてほしい
- メンテナーメンバーは機能開発に注力してもらうために、開発運用に関する改善で貢献できる
- メンテナーメンバーの動向や動きをウォッチし、その流れに寄り添って行動する
おわりに
本記事では私が半年間コントリビューターを続けてきた感想とコントリビュート時に得た Tips について書きました。
どの OSS でも継続的なコントリビューターを求めており、コントリビューターはずっと足りていません。
迷っているならば その一歩 を是非踏んでみてほしいです。
1 人だとその一歩が不安という方がいればコミュニティや個人でサポートも行っています。是非お声掛けください。
Discussion