はじめに

日々お世話になっている OSS への貢献をしたいと思いつつも、何から始めればよいか分からなかったり、心理的なハードルを感じている方は多いのではないでしょうか。実際のところ、OSS へのコントリビュートはコードの変更だけではなく、ドキュメント修正や Issue 報告等、様々な形で参加できます。

今回のブログでは、OSS コントリビュートの種類や進め方、CLA / DCO の署名、コミュニケーションのポイントについて紹介したいと思います。

コントリビュートはコードだけではない

OSS へのコントリビュートというと、バグ修正や新機能の実装をイメージする方が多いかもしれません。

しかし、Open Source Guides ではコード以外のコントリビュートも OSS の発展に大きく貢献すると説明されています。

コントリビュートの種類

種類	例
ドキュメント	README の改善、チュートリアルの執筆、翻訳
バグ報告	Issue での再現手順の提供、環境情報の記載
コードレビュー	他のコントリビュータの PR に対するフィードバック
テスト	テストケースの追加、既存テストの改善
コミュニティ支援	Issue のトリアージ、質問への回答、ラベル整理
コード	バグ修正、新機能の実装、リファクタリング

Open Source Guides によると、ドキュメント関連のコントリビュートは全体の 28% を占めているとのことです。ドキュメントの修正や改善は、コードの変更と比較して影響範囲が限定的であるため、初めてのコントリビュートとして取り組みやすいです。

初めてのコントリビュートにドキュメント修正を勧める理由

ドキュメント修正は、以下の理由から初めてのコントリビュートに適しています。

ローカルでのビルドやテスト実行が不要なケースが多い
変更の影響範囲が限定的で、既存機能を壊すリスクがない（極めて低い）
レビュアーの負担が小さく、マージまでの期間が短い傾向にある
プロジェクトのコントリビュートフロー（Fork → PR → レビュー）を一通り経験できる

ドキュメント修正を通じてプロジェクトの開発フローやコミュニティの雰囲気を把握した上で、コード変更を伴うコントリビュートに進むのが自然なステップです。

コントリビュートの進め方

プロジェクトの選び方

コントリビュート先のプロジェクトを選ぶ際は、以下の観点でプロジェクトの活性度を確認します。

デフォルトブランチの最新コミット日時が直近であること
オープンな Issue や PR にメンテナからの応答があること
コントリビュータの数が複数人いること
CONTRIBUTING.md や CODE_OF_CONDUCT.md が整備されていること

活性度の低いプロジェクトでは、PR を作成してもレビューされずに放置されるリスクがあります。

Issue を探す

Open Source Guides では、Issue に good first issue や help wanted のラベルが付いている Issue は、初めてのコントリビュータ向けにメンテナが用意したものであることが説明されています。

コントリビュートしたい Issue を見つけたら、まずその Issue のコメント欄を確認し、既に他の人が取り組んでいないかを確認します。自分が取り組む場合は、Issue にコメントを残して作業を宣言すると、重複作業を避けることができます。

また、自分で新しい Issue を作成する場合は、既に同様の Issue が報告されていないか、Issue の検索やディスカッションを確認した上で作成するようにします。

コントリビュート先を探すためのリソース

以下のプラットフォームでは、初めてのコントリビュータ向けの Issue やプロジェクトを探すことができます。

リソース	概要
GitHub Explore	GitHub がキュレーションしたプロジェクト一覧
First Contributions	初めての PR 作成を練習できるプロジェクト
Up For Grabs	初心者向けの Issue を集約したプラットフォーム
CodeTriage	Issue のトリアージを手伝うプロジェクトを紹介

コントリビュートガイドラインの確認

PR を作成する前に、プロジェクトの以下のドキュメントを必ず確認するようにします。

ドキュメント	確認する内容
`README.md`	プロジェクトの概要、セットアップ手順
`CONTRIBUTING.md`	コントリビュートの手順、コーディング規約、コミットメッセージ規約
`LICENSE`	ライセンスの種類（MIT, Apache 2.0, GPL 等）
`CODE_OF_CONDUCT.md`	コミュニティの行動規範

プロジェクトによってはコミットメッセージの形式（Conventional Commits 等）や、テストの実行方法、ラベルの付け方等が細かく定められています。これらの規約に従わない PR はレビュー以前にリジェクトされる可能性があるため、事前の確認が重要です。

ライセンスの確認

LICENSE ファイルでプロジェクトのライセンスを確認しておくことも重要です。 Open Source Guides では、MIT、Apache 2.0、GPLv3 が最も有名なオープンソースライセンスとして紹介されています。

ライセンス	特徴
MIT	最もシンプルで制約が少ない。著作権表示と許諾表示の保持のみが条件
Apache 2.0	MIT と同様に許容的だが、特許権の明示的な付与と変更箇所の明記が追加で求められる
GPLv3	コピーレフト型。派生物にも同じライセンスの適用が求められる

コピーレフト型ライセンス（GPL 等）のプロジェクトにコントリビュートする場合、自分が加えた変更もそのライセンスの下で公開される点を理解しておく必要があります。そのため、業務としてコントリビュートする場合は、所属組織のポリシとの整合性を事前に確認することが推奨されます。

例えば、業務時間中に書いたコードの著作権が会社に帰属する場合、GPL プロジェクトへの提出により会社のコードが GPL として公開される可能性があります。

また、Corporate CLA の署名が必要なプロジェクトでは会社としての承認手続きが求められることもあります。

Fork から PR 作成までの流れ

GitHub 公式ドキュメントに記載されている通り、OSS へのコントリビュートは以下の流れで進めます。

リポジトリの Fork

対象リポジトリのページで「Fork」ボタンをクリックし、自分のアカウントにフォークを作成します。

ローカルへのクローンと upstream の設定

ブランチの作成と変更

ブランチ名はプロジェクトの規約に従います。 fix/、feat/、docs/ 等のプレフィックスを付けるプロジェクトが多いです。 CONTRIBUTING.md にブランチ命名規則が記載されている場合は、それに従います。

PR の作成

変更をコミットしてフォークにプッシュした後、GitHub 上で PR を作成します。

PR の説明文には以下を含めることが推奨されています。

変更の目的と背景
関連する Issue 番号（Closes #123 の形式で記述すると、PR マージ時に Issue が自動クローズされる）
変更内容の概要
テストの実施状況やスクリーンショット（UI 変更の場合）

CLA と DCO

OSS プロジェクトによっては、PR を作成する際に CLA（Contributor License Agreement）または DCO（Developer Certificate of Origin）への署名が求められます。

CLA（Contributor License Agreement）

CLA は、コントリビュータがプロジェクトに対して著作権やライセンスに関する権利を付与する契約です。 Apache Software Foundation、Google、Microsoft 等の主要プロジェクトが CLA を採用しています。

CLA には個人向け（Individual CLA）と企業向け（Corporate CLA）の 2 種類があり、業務としてコントリビュートする場合は後者の署名が必要になるケースがあります。

多くのプロジェクトでは、PR を作成すると CLA 署名の Bot が自動的にコメントを追加し、署名ページへのリンクを提示してくれます。署名が完了するまで PR のマージはブロックされるため、初回コントリビュート時は CI のチェック結果を確認しておくとスムーズです。

DCO（Developer Certificate of Origin）

DCO は CLA よりも軽量な仕組みで、コミットメッセージに Signed-off-by 行を追加することで署名が完了します。 Linux Foundation が策定した DCO は、CLA のような個別の契約書への署名が不要であり、開発者にとって手続き上のハードルが低い点が特徴です。

Developer Certificate で公開されている DCO Version 1.1 では、コントリビュータが以下の 4 点を認証することが求められています。

コントリビュートの全部または一部が自分によって作成されたものであること
該当するオープンソースライセンスの下で提出する権利を有すること
第三者から提供された場合、その旨を明記すること
コントリビュートの記録が公開で保持されることに同意すること

DCO の署名は git commit 時に -s オプションを付けるだけです。

これにより、コミットメッセージに以下の行が自動追加されます。

CLA と DCO のどちらが採用されているかはプロジェクトによって異なるため、CONTRIBUTING.md やリポジトリのルートディレクトリにある DCO ファイル等を確認してください。

比較項目	CLA	DCO
署名方法	Web フォームや PDF での契約署名	コミットメッセージへの `Signed-off-by` 追加
企業向け対応	Corporate CLA が別途存在	個人単位での署名のみ
手続きの負担	初回の署名手続きが必要	`git commit -s` のみで完了
採用プロジェクトの例	Google / Microsoft / Apache	Linux Kernel / CNCF プロジェクト

コントリビュート時のコミュニケーション

PR やコメントの書き方

Open Source Guides では、コントリビュート時のコミュニケーションについて以下のポイントが挙げられています。

具体的なコンテキストを提供する（「Y を行った時に X が起きません」のように状況を明確にする）
自分で試した内容を明記する（調査や検証の過程を示す）
簡潔に要点を伝える
メンテナへの個別連絡は避け、公開の場でコミュニケーションを取る

レビュー対応

PR に対してレビューコメントが付いた場合は、真摯に対応することが重要です。コードの修正が求められた場合はフィードバックに従って対応し、意図が不明な場合は質問して確認します。

レビューが長期間行われない場合は、1 週間程度待った後に丁寧にリマインドすることが推奨されています。

PR がリジェクトされた場合でも、メンテナの判断を尊重し、フィードバックがあれば次回のコントリビュートに活かします。 Open Source Guides では、メンテナはあなたよりも長い期間プロジェクトと付き合っていることを念頭に置き、コミュニティの決定を尊重する姿勢が重要であると述べられています。

maintainers have to live with your decision longer than you will.

Ultimately, however, you’ll need to respect that this is their decision.

Issue で質問してはいけない？

OSS プロジェクトの Issue に「〜の使い方を教えてください」といった質問を投稿してよいかは、プロジェクトによって異なります。

Open Source Guides では、プロジェクトのコミュニケーションチャネルを以下のように分類しています。

チャネル	用途
Issue Tracker	プロジェクトに関連する具体的な問題やタスク
Discussion Forums	「どうやって〜するか」「〜についてどう思うか」等の議論
Chat Channels	カジュアルな会話やコラボレーション

GitHub Discussions が有効なプロジェクトでは、質問やアイデアの議論は Discussions で行い、具体的な作業スコープが決まった段階で Issue に移行するという使い分けが推奨されています。

Use discussions to ask and answer questions, share information, make announcements, and conduct or participate in a conversation about a project.

質問を Issue に投稿する前に、プロジェクトの CONTRIBUTING.md や README で、質問に関しては Discussions や Stack Overflow を利用するように促されていないか確認しておくと良いでしょう。

やってはいけないこと

Open Source Guides では、以下のような行動を避けるよう明記されています。

メンテナに個別でメッセージを送ること（機密情報を除く）

⚠️ Keep all communication public. Although it’s tempting, don’t reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation).

要求や指示的な態度を取ること

😢 Why can't you fix my problem? Isn't this your project?

コミュニティの決定に対して攻撃的な異議を唱えること

😢 Why won't you support my use case? This is unacceptable!

OSS プロジェクトへのコントリビュートは、あくまでコミュニティへの参加です。対等かつ敬意を持った態度でコミュニケーションを取ることが求められます。

おわりに

OSS コントリビュートは、必ずしもコードの変更を伴う必要はありません。ドキュメントの修正、Issue の報告、コードレビュー等、様々な形での貢献が OSS の発展を支えています。

初めてのコントリビュートでは、good first issue ラベルの付いた Issue やドキュメント修正から始めるのがお勧めです。 CONTRIBUTING.md の確認、Fork から PR 作成までの流れ、CLA / DCO の署名対応を押さえておけば、コントリビュートの手順自体は難しいものではありません。

普段使っているツールやフレームワークのドキュメントに誤りや分かりにくい点を見つけたら、それがコントリビュートの第一歩になります。

私自身も、業務中に見つけたドキュメントの誤りをきっかけに grafana/grafana へのドキュメント修正 PR や、pipe-cd/pipecd へのコード修正 PR を作成しました。最初の一歩は小さなもので十分だと思います。

【Tips】OSS コントリビュートの始め方