Knativeを使ったオープンソース入門 パート1：オープンソース入門

公開日：2023年7月11日、  改訂日：2024年1月17日

Knativeを使ったオープンソース入門 パート1：オープンソース入門

著者：Calum Murray ソフトウェアエンジニアリングインターン @ Red Hat、および Leo Li ソフトウェアエンジニアリングインターン @ Red Hat

この入門ブログシリーズに再びようこそ！この記事では、オープンソースについて紹介します。オープンソースとは何か、なぜ気にする必要があるのか、そしてどのように参加できるのかについて説明します。

すでにオープンソースの経験が豊富な方は、この記事を完全にスキップして、次の記事に進んでください。次の記事では、**Knative**で作業するための開発環境のセットアップ方法について説明します。しかし、オープンソースが初めての方、もっと知りたい方、復習したい方は、オープンソースの何、なぜ、どのようにについて一緒に議論しましょう。

オープンソースとは？

では、オープンソースとは何でしょうか？オープンソースの背後にある重要な概念は、すべてのソースコードが公開されていることです。誰でもコードを読み、変更し、改善し、自由に配布できます[1]。

オープンソースソフトウェアと同様に、フリーソフトウェア（ユーザーの自由の観点からフリー - 無料の食べ物ではなく、言論の自由と考えてください）もあり、これは主に商業的側面が少ないという点でオープンソースとは異なります[2]。オープンソースソフトウェアとフリーソフトウェアの間には重要な哲学的違いがありますが、この記事では、より実践的なガイドとして意図されているため、それらについては詳しく説明しません。

オープンソースであることを知らなくても、おそらく以前に使用したことがある一般的なオープンソースソフトウェアがたくさんあります。たとえば、ブラウザのほとんどはオープンソースである可能性が高いです。Firefoxを使用している場合、ブラウザ（DRMコードを除く）はオープンソースです。Google ChromeやMicrosoft EdgeなどのChromiumベースのブラウザを使用している場合、名前が示すように、ブラウザはオープンソースプロジェクトChromiumに基づいていますが、ブラウザには独自のコンポーネントもあります。

さらに、Linuxオペレーティングシステムを個人的に使用していなくても、おそらくこの一般的なOSについて聞いたことがあるでしょう。MacOSを使用している場合、オペレーティングシステムはフリーでオープンソースのプロジェクトFreeBSDに関連していますが、MacOSにも多くの独自の（オープンソースではない）ソフトウェアが組み込まれています。したがって、オペレーティングシステムには少なくともいくつかのオープンソースコードが含まれている可能性が高いです。

さらに、この記事を読んでいるということは、おそらく以前にプログラミングをしたことがあるでしょう。これは、Python、Go、Rust、Javaなどのほとんどのプログラミング言語がオープンソースであるため、オープンソースソフトウェアを使用したことがあることを意味します。

オープンソースは、ソフトウェアを構築および共有するための、大規模で人気があり、革新的な方法です。重要なのは、**あなた**も参加できるプロセスであるということです。

なぜ参加する必要があるのですか？

オープンソースソフトウェアとは何か、そしておそらく遭遇したことがあるオープンソースソフトウェアの例をいくつか理解したので、なぜオープンソースに参加する必要があるのでしょうか？オープンソースに参加したいと思う理由はたくさんあるので、そのうちのいくつかと、参加することによって得られるメリットについて説明しましょう。

非常に一般的なシナリオは、あなたが何らかのソフトウェアのユーザーであり、あなたを悩ませている機能を追加したり、バグを修正したりしたいということです。したがって、その新しい機能を組み込んだり、バグを修正したりすることでプロジェクトにコードを提供したり、単に機能をリクエストしたり、バグを報告したりすることでプロジェクトに貢献したりするかもしれません（そうです - バグの報告は貢献する方法です！）。もう1つの一般的なシナリオは、ソフトウェアプロジェクトを信頼し、コミュニティの一員になって、より長期的にソフトウェアを改善するために取り組みたいということです。さらに別の一般的な状況は、公の場で他の才能のある人々と協力し、ネットワークを構築し、スキルを向上させることによって、キャリアをさらに発展させたいということです。

オープンソースプロジェクトまたはコミュニティに参加する理由に関係なく、多くのメリットは同じです。主なものは次のとおりです。

1. 最高のソフトウェアを作るために積極的に協力している活気のあるコミュニティの一員になる機会。

2. さまざまなテクノロジーを知り、イノベーションの最先端にいる機会。多くのイノベーションはオープンソースプロジェクトから始まります。

3. あなたの貢献が、非常に多くのユーザーがいる可能性のある大規模なプロジェクトに影響を与えるのを見ることができます（たとえば、Knativeリポジトリの1つには約1000万回のダウンロードがあります）。これは非常にやりがいのあることです。

そうは言っても、あなたがこれを読んでいるということは、おそらくすでにオープンソースプロジェクト（できれば**Knative**！）に参加したいと思っていることを意味しているので、貢献できるさまざまな方法について詳しく見ていきましょう。

貢献の種類

オープンソースプロジェクトに貢献できる方法はたくさんあり、一般的に言って、貢献は常に歓迎されます！**コミュニティによって、貢献の方法や、受け入れる貢献の種類（もしあれば）に関するガイドラインが異なる**ことに注意してください。貢献を開始する前に、コミュニティに確認して、時間を無駄にすることなく、確実に貢献していることを確認してください。特定のプロジェクトの場合、貢献ガイドラインは通常、リポジトリの`README.md`ファイルまたは`CONTRIBUTING.md`ファイルにあります。また、プロジェクトのWebサイトにある場合もあります。疑問がある場合は、コミュニティに尋ねてください！その注意点とともに、一般的な貢献方法について説明しましょう。

課題の作成

貢献する素晴らしい方法の一つは、GitHub/GitLab、またはコミュニティが使用している他のプラットフォームで「Issue」を作成することです。たとえば、KnativeはGitHubを使用してIssueを管理しています。Issueはバグ報告や機能リクエストなどです。使用しているオープンソースプロジェクトに問題がある場合は、Issueを作成して報告しましょう！同様に、必要な機能がある場合は、Issueを作成してリクエストしてください。プロジェクトのメンテナーがIssueを修正することを保証するものではありませんが、通常は対応しようとします。これは、コミュニティがあなたのようなユーザーがプロジェクトについてどのように考えているか、そしてどのような問題を抱えているかをよりよく理解するのに役立つため、プロジェクトに貢献する素晴らしい方法です。

**Issueのトリアージ**

多くのオープンソースプロジェクトは大量のIssueを受け取ります。そのため、メンテナーはそれらをトリアージするのに多くの作業を必要とします。しかし、これはプロジェクトに参加し始めるための素晴らしい方法であり、メンテナーはあなたの貢献を高く評価します。

Issueのトリアージを支援するには、バグレポートを再現して実際にバグであることを確認し、バグの修正が正しく行われていることを検証します。また、機能リクエストや提案を読み、質問をし、それらについて好きな点/嫌いな点、そしてその機能がプロジェクトを改善すると思うかどうかについてのフィードバックを提供することもできます。

**ドキュメントの作成**

オープンソースプロジェクトに貢献するもう一つの素晴らしい方法は、プロジェクトのドキュメントに貢献することです。たとえば、Knativeに貢献したい場合は、未解決のドキュメントIssueの修正に貢献することができます。ソフトウェアは進化していくため、ドキュメントは遅れがちになる傾向があります。プロジェクトをより使いやすくするためには、人々が積極的にドキュメントを最新の状態に保つことに貢献することが重要です。これは、概念を説明することで理解が深まるため、プロジェクトが技術的にどのように機能するかについてより深く学ぶための非常に良い方法でもあります。

**コミュニティイベントやミーティングへの参加**

中規模および大規模なプロジェクト（そして一部の小規模なプロジェクトも）は、ミーティングやコミュニティイベントを開催する傾向があります。これは、コミュニティのより多くの人々と出会い、アイデアを共有する絶好の機会です。たとえば、Knativeでは、ワーキンググループの週次および隔週のミーティングがあり、さまざまな貢献者が現在取り組んでいることについて話し合い、提案している機能に関するフィードバックをリクエストします。これらのミーティングにはぜひ参加してください。コミュニティで何が起こっているのか、プロジェクトがどのような方向に進んでいるのかを知るための素晴らしい方法です。Knativeのワーキンググループミーティングがいつ開催されるかについては、コミュニティカレンダーをご覧ください。

**プルリクエスト（PR）のレビュー**

より技術的な貢献は、プルリクエスト（PR）のレビューです。GitLabでは、これらはマージリクエスト（MR）とも呼ばれます。PRについて聞いたことがない場合、これは基本的に、プロジェクトのコードに変更を加えるようにリクエストする方法です。そのため、変更が正しく、適切に機能することを確認するために、これらを注意深くレビューすることが不可欠です。プロジェクトにあまりコードを貢献していない場合は、コードで何が起こっているのかを完全に理解することは難しいかもしれませんが、変更の全体的な品質を向上させるために、コードに関するコメントや質問を残すことができます。ただし、コードが本当に理解できない場合は、変更が機能することを確認する方がおそらく有用です。すべてが機能する場合は、その旨のコメントを残してください。そうでない場合は、PRの作成者に何かを修正する必要があることを知らせるコメントを残してください。

**コードの貢献**

おそらく、最も技術的な貢献はコードの貢献です。これは、このブログ記事の残りの部分とブログシリーズの残りの部分で焦点を当てる内容であり、多くのことが含まれています！しかし、怖がらないでください。しばらくすれば、コードを変更してコミュニティに貢献することに慣れるでしょう。

**コードを貢献する方法**

コードの貢献方法の詳細に入る前に、プロセスの全体像を見てみましょう。貢献の最初のステップは、変更したいものを持つことです。新しい機能かもしれませんし、バグ修正かもしれませんし、あるいは他の何かかもしれません。作業したいことがわかったら、コミュニティ/プロジェクトのメンテナーに確認して、自分が行いたい変更を彼らが行ってほしいかどうかを確認することをお勧めします。彼らがあなたの提案する変更に賛成している場合は、コーディングを開始しましょう！リポジトリのフォークに新しいブランチを作成し、コードを記述します。コードが機能したら、変更を含むPRを作成します。これらの変更に対処し、レビュアーによってPRが承認されると、作業は完了し、コードがマージされます！（マージとは、変更をコードベースのメインコードと組み合わせることで、誰もが使用できるようにすることです）。このフローは、以下の図に示されています。（図は省略）

さて、このプロセスに慣れていない場合、おそらく非常に混乱しているように感じるでしょう。そこで、さらに分かりやすくするために、各パートを分解して詳しく説明しましょう。

**変更の提案**

プロセスの最初のステップは、変更を提案することです。このステップは、新しい機能を追加する場合に非常に重要です。コミュニティが実際に必要な機能ではない場合や、あなたが考えているのとは異なる動作を望んでいる場合があります。どちらの場合も、機能を提案する前にコーディングを開始すると、多くの時間を無駄にすることになります。コミュニティごとに変更を提案し、承認するための慣行が異なるため、対象のコミュニティがどのように行っているかを確認してみてください（これは多くの場合、`CONTRIBUTING.md` に記載されています。リポジトリを見て回り、他の人が何をしているかを確認するか、プロジェクトのWebサイトで確認できます）。たとえば、Knativeでは、GitHubのIssueを使用して新しい機能を提案し、バグを報告し、`triage/accepted` ラベルを追加することで承認します。さらに、大規模な機能については、Issueに加えて機能提案ドキュメントを作成する必要があります。ただし、開発者向けドキュメントの修正などの非常に小さな機能の場合は、このステップをスキップして、PRを作成することで変更を行うこともできます。

新しい機能を提案したり、バグを報告する前に、コミュニティがIssueの追跡に使用しているプラットフォームで重複がないか**検索**してみてください。すでに存在し、承認されている場合は、先に進んでプロセスの次のステップに進むことができます。存在し、**まだ承認されていない**場合は、**Issueにコメント**して、このバグも経験した、またはこの機能が必要であることを示すことができます。最後に、**まだ存在しない**場合は、機能を**提案**するか、バグを**報告**する必要があります。提案/バグレポートにはできるだけ多くの詳細を含めてください。そうすることでプロセスがスピードアップします。変更が以前に提案されたか、自分で提案したかに関係なく、承認されたら次のステップに進むことができます！

**変更のコーディング！**

提案が承認されたら、変更をコーディングする時です。このセクションでは、コード自体の記述方法についてはあまり時間を割きません（ただし、Knativeコードの記述方法に興味がある場合は、このブログシリーズの残りの部分を確認してください！）。代わりに、コード 작성に関するすべてのプロセスに焦点を当てます。一般的に、変更をコーディングするために行くプロセスは次のとおりです。

1. プロジェクトをフォークし、ローカルにクローンする

2. ブランチを作成する

3. コミットする

4. PRを作成する

5. レビューをリクエストする

6. リクエストに応じて変更を行う

7. PRが承認される

8. コードがマージされる！

まず、一般的にプロジェクトのフォークで作業する必要があります。フォークは、自分が好きなように変更できる権限を持つ、あなた個人のリポジトリのコピーと考えることができます。これは、コードを変更する権限がない可能性のあるメインプロジェクトのリポジトリとは異なります。GitHubでフォークを作成するには、この手順に従ってください。GitLabでフォークを作成するには、この手順に従ってください。ここで重要な用語は、フォークしたリポジトリは一般に「アップストリーム」リポジトリと呼ばれ、あなたのフォークは通常、ローカルのGitリモートが設定される方法であるため、「オリジン」と呼びます。フォークしたリポジトリを簡単にクローンし、Gitリモートを適切に設定するには、ここからインストールできる`git clonefork`コマンドを使用できます。または、git cloneおよびgit remoteコマンドを使用して、フォークのローカルコピーを設定することもできます。アップストリームリポジトリにリモートを追加する必要があること、そしてこのリモートは一般に「アップストリーム」と呼ばれることに注意してください。このリモートは、フォークをアップストリームプロジェクトの変更と同期させるために使用されます。手動でクローンするには、`git clone <フォークのURL>`を実行します。次に、アップストリームリモートを手動で追加するには、新しくクローンされたリポジトリに`cd`で移動し、`git remote add upstream <アップストリームリポジトリのURL> && git remote set-url --push upstream no_push`を実行します。フォークとアップストリームリモートのURLを取得するには、各リポジトリに移動し、GitHubの「Code」ボタン、またはGitLabの「Clone」ボタンを探します。このボタンをクリックすると、コピーできるURLが表示されます。

フォークを作成し、ローカルにクローンし、リモートを適切に設定したら、変更を行うための新しいブランチをチェックアウトする必要があります。ブランチとは何か、どのように作成するかわからない場合は、この記事を読むことをお勧めします。また、メインブランチとは別のブランチで変更を行い、メインブランチをアップストリームのメインブランチと同期させておくことをお勧めします。こうすることで、メインブランチで同じ履歴を共有するため、フォークに将来の変更を簡単に取り込むことができます。フォークのメインブランチをアップストリームのメインブランチと同期するには、GitHub UI/GitLab UIを使用して、それらの変更をローカルのメインブランチにプルするか、`git checkout main && git pull upstream main`を実行します（メインブランチに変更をコミットしていないと仮定）、その後、メインブランチをオリジンにプッシュします。ローカルメインとオリジンのメインをアップストリームメインと簡単に同期するには、ここからインストールできる`git sync`コマンドを使用できます。

自分のフォークしたブランチで作業を開始したので、いよいよ変更をコーディングしましょう！コードを書く際に留意すべき重要な点の1つは、プロジェクトのコードスタイルです。すべての変数が camelCase である場合、変数名も camelCase にする必要があります。エラー処理の一般的な方法がある場合は、同じ方法でエラーを処理する必要があります。多数の単体テストがある場合は、変更内容を単体テストする必要があります（Knative のテストについては、後のブログ記事で詳しく説明します）。他の開発者が、自分が書いたコードと残りのコードを区別できない場合、プロジェクトのスタイルにうまく従っていることになります。コードの作業中に留意すべき事項の便利なリストは次のとおりです。

1. 変数、関数、およびクラスの命名規則

2. プロジェクトで使用されているコードのフォーマット/自動フォーマッタ

3. コミットメッセージの規則はありますか？

4. ファイルの命名規則

5. パッケージのインポート規則

6. パッケージのインストールポリシー（ポリシーがあるかどうか、または必要なものをインストールできるかどうかを確認してください）

ある程度の進捗があった場合や変更が完了したと感じた場合は、必ずコミットを作成してください。コミットの作成に関する詳細は、こちらをご覧ください。Git コミットにはメッセージが必要なので、何かを提供するようにしてください。これにより、他の開発者が変更内容を理解しやすくなります。たとえば、「バグ修正に取り組んだ」は**適切なコミットメッセージではありません**が、「クラッシュを防ぐために try catch ブロックを追加した」は**変更内容を説明している**ため、より適切です。

PR/MRの作成

PR/MRを開きたいと思われるシナリオは2つあります。1つ目は、変更が完了し、プロジェクトにマージする準備ができたと感じている場合です。2つ目は、ある程度の進捗はしたがまだ完了しておらず、変更に関する早期のフィードバックや支援を得たい場合です。どちらの場合も、PRまたはMRを作成するための基本的なフローを実行する必要があります。GitHubを使用していて、その方法がわからない場合は、こちらの指示に従ってください。GitLabを使用していて、その方法がわからない場合は、こちらの指示に従ってください。

PR/MRを作成する際には、変更を行う理由、変更内容、および変更をテストする方法のコンテキストを提供することが重要です。PR/MRが対処している issue へのリンクを含め、行った変更の簡単な説明を提供することをお勧めします。さらに、PR/MRには、レビュアーが内容を明確に理解できるように、簡潔でわかりやすいタイトルを付ける必要があります。

変更が不完全な場合は、PR/MRを**ドラフト**としてマークして、レビュアーに作業が完了していないことを示す必要があります。GitHub の手順はこちら、GitLab の手順はこちらです。PR/MRのタイトルを「[WIP]: <わかりやすいタイトル>」（WIP は「作業中」の略）とすることもできます。変更について質問がある場合は、このドラフトPR/MRで質問するのが最適です。回答者は、これまでの作業内容のコンテキストをすべて把握しているからです。変更が完了/準備完了したと感じたら、PR/MRをドラフト状態から準備完了状態に変換できます。GitHub の手順はこちら、GitLab の手順はこちらにあります。

PR/MRがドラフトであるかレビューの準備ができているかに関わらず、作業が完了したとは思わないでください！レビュープロセスでかなりの時間を費やし、コードがプロジェクトにマージされる準備が整うまで改善する可能性が非常に高いです。次に、このレビュープロセスについて説明しましょう。

PR/MRレビュープロセス

準備ができた PR/MR があると、1 人以上の担当者が変更をレビューし、フィードバックを提供します。プロジェクトへの最初の貢献の1つである場合は、多くのフィードバックを期待してください！その後、それらのコメントに対処するために変更を加えるのはあなた次第です。これを行うには、PRを作成したのと同じブランチに新しいコミットを作成し、変更をオリジンにプッシュするだけです。

レビュアーが、機能していると考えているコードに変更を提案するとイライラするかもしれませんが、彼らの目標はプロジェクト全体の品質を向上させることであることを忘れないでください。彼らは、あなたのコーディングスキルを洗練し、向上させるためにフィードバックを提供しています！フィードバックを個人的に受け止めるのではなく、学習の機会と捉えてみてください。要求された変更を実装できない理由がある場合は、提案が実現不可能と思われる理由を説明するコメントに遠慮なく返信してください。ただし、そのような状況がない限り、提案されたすべての変更を取り入れるようにしてください。このアプローチにより、生産的で協力的なコードレビュープロセスが促進されます。

もう1つ留意すべき点は、多くのプロジェクトには**自動テスト**があり、PRで実行されて、変更後もすべてが正常に機能していることを確認することです。テストが失敗しているように見える場合は、その理由を調査し、修正できるかどうかを確認してください。テストが失敗する理由がわからない場合は、PRにコメントを残して、その旨を伝え、ヘルプを求めることができます。テストが不安定に動作することがあり、「フレーキー」テストと呼ばれます。テストの失敗がコードの変更の結果ではないと確信している場合は、テストを再実行してみる価値があるかもしれません。

PRのテストに合格し、変更がレビュアーによって承認されると、コードはプロジェクトメンテナによってアップストリームのメインブランチにマージされます。おめでとうございます！プロジェクトにコードを貢献し、プロジェクトとコミュニティに影響を与えました！

結論

この記事で見てきたように、貢献できる素晴らしいオープンソースプロジェクトが数多くあります。興味がある場合は、1つを選んで貢献してください！貢献する方法はたくさんあり、プロジェクトが貢献を受け入れている限り、あなたの貢献は高く評価されます。貢献（特にコードの貢献）は複雑なプロセスになる可能性がありますが、非常にやりがいのある経験でもあります。そのため、オープンソースと Knative に貢献していただければ幸いです！

この記事を楽しんでいただき、オープンソースに貢献することに自信を持っていただければ幸いです。次の記事でお会いできるのを楽しみにしています！

追伸：オープンソースへの貢献を始めることに興味がある場合は、CNCF のこの記事をご覧ください。素晴らしい出発点となります。