コントリビューションをあれこれ考える
「OSS」への「コントリビューション」で、普段雑多にやってることの整理。
前提
ここでの「コントリビューション」は、GitHubのリポジトリ上でテキストで公開されているものよりも、 もうちょっと広いものを指している。
とはいえ、基本的にはGitHubを始めとしたGitリポジトリのサービスを前提としていることが多い。
「使うだけ」もコントリビューション
よくある話ではあるのだけれど、「OSSを使う」ことそれ自体もコントリビューションとして立派な要素となっている。 ただし、「使っていることを表明する」まで出来ると一段階進んだコントリビューションになる。
個人ベースにしても、コミュニティベースにしても、利用者がいて肯定的な反応をしてくれるということは、 それだけでモチベーションの要素になる。 OSSは性質上「それだけで生活には困らない」というような収益要素を生むのが極めて困難であるため、 こういった「好意的な利用者が存在する」ことを認知出来ることが「OSSプロダクトの死」を少しでも遠ざけることになる。
「使うだけ」以外のコントリビューション
ここから先では、自分が普段している内容を整理する。 （やってないことは書かない）
GitHubでStarをつける
割と楽な「使うだけの一歩先」な手法として挙げられるもの。 通知が来るということは無かったとは思うが、少なくとも「好んでいる・関心を持っている」ということを、 外部ユーザーにも伝える手段になりうる。
最近だと、単純なStarではなくラベルのように使えるようになったので、 気になるものはカジュアルにStarをつけておくと良いかもしれない。
不具合を報告する
実際に使ってみた際に不具合と思わしきものに遭遇した際に取れる手法。 ソフトウェアである以上は「適切な条件で適切に動くこと」を期待されるものであるため、 不審・不可解な挙動をした場合は一度Issue作成などで共有するのが良いことが多い。
ただし、意識するべき注意事項みたいなものはあり、以下のようなことは気をつける必要がある。
具体的な報告が可能か？
環境情報を含めて、安定している再現手順を提供できるか？
可能であれば「報告先プロダクトの挙動に起因している」と判断している理由を添えられるか？
これらを踏まえた上で、報告先のガイドラインに沿っている振る舞いか？
（任意）自分で改善・改修が可能か？
修正フィードバックを送る
主に前述の「不具合を報告する」の過程で、「原因はここではないか？」といった推定（または特定）まで到達することがある。 その場合は、自分の手で修正の実装を行った上でフィードバックすることも出来る。 GitHubなどでの公開リポジトリの場合だと、フォークした上でのプルリクエストが基本的なアプローチになる。
気をつけるのはべき点としては、これらとなる。
コード修正・追加に関する目的・意図が分かるようにする。
修正内容が、変更していない箇所に悪影響を与えないことを担保する。 必要な場合を除いて、既存のテストコードはパスされている状態を保つ。
（特に新規実装の場合）動作を担保するテストコードもなるべく用意する。
また、ドキュメントのようなコードを伴わない内容への不備（タイポや翻訳ミス）などの場合も、 フィードバックとしてPRを出すと良い。 [1] 特にこちらのアプローチの場合、コードそのものに対する対応力がほぼ不要なために、難易度が幾分か低いのも特徴。
自分でOSSプロダクトを作成して公開する
自分の性格上の理由を含めて、一番多いのはこの「OSSプロダクトを開発して公開する」という動きとなっている。
「自分の設計・実装」を「自分の手で開発」して公開するという性質上、コントリビューションとしては飛び抜けて自由度が高い。 その代わりに、自分以外の需要が無いケースもあり、その場合はモチベーション維持が極めて難しい。
なお、実際に公開すると今までに挙げたようなコントリビューションを受ける立場になることもある。 勢いで実装・公開した後に長く利用する算段がついている場合は、コントリビューションを受けやすいような工夫をしておくことで活性化しやすくなる。
整形されたコードにする
テストコードも用意して、実コーの挙動を担保する
GitHub Actionsのようなワークフローを用意して、テストのパスを担保する
ドキュメントなどを用意して、利用しやすくする
コントリビューションガイドを用意して、フィードバック時に守ってほしいことを明確にする
※脚注