OSS

OSSの定義¶

Open Source Initiative(OSI)が策定したOpen Source Definition(OSD)の条件

1. 自由な再頒布ができること

2. ソースコードが入手可能であること

3. 派生物を作成・頒布できること

4. 作者のソースコードの完全性を守る権利(パッチ形式での配布要求など)を認める余地

5. 個人やグループを差別しないこと

6. 利用分野を制限しないこと(商用利用も含む)

7. ライセンスがプログラムの再頒布に自動的に適用されること

8. 特定製品に依存しないライセンスであること

9. 他のソフトウェアを制限しないライセンスであること

10. ライセンスが技術中立であること

貢献の方法¶

コードでの貢献¶

• バグ修正(Bug Fix):Issueに上がっている不具合を直す。初心者にも入りやすい入口

• 新機能の実装(Feature):提案・議論を経てから着手するのが望ましい(いきなり大きなPRを送ると却下されやすい)

• パフォーマンス改善:プロファイリングして遅い箇所を最適化

• リファクタリング:可読性・保守性の向上。ただし大規模な変更は事前相談が無難

• テストの追加:カバレッジが低い箇所へのユニットテスト・統合テストの追加は歓迎されやすい

• 依存関係の更新対応:Dependabot/renovateが出すPRのレビューや、breaking changeへの追従

• 既存Issueのトリアージ:再現確認、原因の切り分け、重複Issueのクローズなど(コードを書かない貢献だが技術力は要る)

コード以外での貢献¶

• バグ報告

• 質問への回答: Discussions、GitHub Issues、Stack Overflow、Discordなどでの他ユーザーサポート

ドキュメント関連¶

• README/公式ドキュメントの改善:誤字修正から構成の見直しまで

• チュートリアル・ハウツー記事の執筆:ブログや公式docsへの寄稿

• APIドキュメント・docstringの補完:未文書化の関数・クラスへのコメント追加

• 多言語翻訳:README、docs、UIメッセージの翻訳(日本語ドキュメントが薄いプロジェクトは特に価値が高い)

• サンプルコード・レシピ集の追加:実践的な使用例

コミュニティ・エコシステム¶

• メンテナーになる

• コミュニティ運営:Discord/Slackのモデレーション、オンボーディング支援

• カンファレンス登壇・LT:プロジェクトの紹介、事例共有

• エコシステムツールの作成:プラグイン、拡張機能、周辺ライブラリの開発(本体に手を入れずに貢献できる)

• 他プロジェクトとの統合対応:自分の使っているツールとの互換性確保(例:type stubsの提供)

貢献を始める際の実務的コツ¶

• CONTRIBUTING.mdを最初に読む:粒度、コーディング規約、PRテンプレートが指定されていることが多い

• good first issueラベルを探す:初心者向けに難易度が調整されたIssue

• いきなり大きなPRを送らない:事前にIssueで方向性をすり合わせる方が、マージ率が上がり、メンテナーの負担も減る

• CLA/DCOへの署名が必要な場合がある:Sign-off(git commit -s)を求めるプロジェクトも多い

Issueの書き方¶

バグ報告¶

再現手順、環境情報、最小再現コード（Minimal Reproducible Example）を添えた報告を書く。
再現テストがあるとさらに良く、理想的（例：vitejs/vite#18244 ）

機能改善要望¶

「こういう機能が欲しい」だけでなく、「その機能がなぜ必要か」「解決したい課題は何か」を明確にすることが重要。
提案者自身が「機能」の形で要望を出してしまい、実はそれが「本質的な問題の解決になっていない」というパターンを避けたいため。

issueでは

• 実際に直面している課題

• 既存の回避策とそれが不十分な理由

• 機能追加以外の選択肢も含めた検討余地

を書くのが良い。（例：vitejs/vite#19273, vitejs/vite#15850）

PRの書き方¶

大切なのは、「この変更が安全で、かつ妥当である」とレビュアーに納得してもらい、マージされること

なぜこの方針なのか？を明確に¶

「この修正を、なぜこの形で実装したのか？」という理由の説明をつける

• 他の選択肢（方針）と比較して、なぜこの方法が最適だと思ったのか

• バグ修正の場合は、原因がどこにあり、どう修正したのか

例：vitejs/vite#19010, vitejs/vite#19646

なぜこの変更は安全なのか？を示す¶

• 該当箇所に対してユニットテストや統合テストを追加しているか

• 既存の挙動に影響を与えない設計になっているか

• ドキュメントや型定義など、周辺影響も確認されているか

例：vitejs/vite#19476 は不具合修正だけでなくテストも追加している

OSS開発者のインタビュー等¶

参考¶

OSS貢献を「依頼」から「協力」に変える、Issueとプルリクエストの書き方 - Findy Media