オープンソースプロジェクトで成功し、実績を残したいですか？そのためには、以下の「暗黙のルール」を遵守する必要があります。

スポーツにおける暗黙のルールと同様、これらのルールは公式文書や記録にはほとんど記載されません。例えば野球では、リードしている時に盗塁してはいけない、走者が初球を走った時に四球を与えてはいけないといったルールがあります。これらは外部の人間にとっては理解しにくく、無意味に思えるかもしれません。しかし、MVPを目指す選手にとっては、これらは当然のことなのです。

ソフトウェア開発、特にオープンソースソフトウェア開発には、暗黙のルールが存在します。他のチームスポーツと同様に、これらのルールはオープンソースコミュニティが開発者、特に新規参入者をどのように評価するかを大きく左右します。

[[191523]]

一歩一歩、徐々に

オープンソースプロジェクトなど、コミュニティに参加する前には、いくつかの基本的な作業を行う必要があります。先見の明のあるオープンソース貢献者にとって、これはコミュニティの目標を理解し、どこから始めるべきかを学ぶことを意味します。誰もがソースコードを提供したいと願っていますが、パッチのテスト、コードのレビュー、ドキュメントの作成、バグの修正といった骨の折れる作業を完遂する準備ができ、意欲と能力を備えている人はごくわずかです。こうしたあまり一般的ではない作業は、健全なコミュニティには不可欠です。

なぜエレガントなコードを書く前にこれを行うのでしょうか？それは信頼関係であり、さらに重要なのは、開発中の機能だけでなく、コミュニティ全体の動向にも焦点を当てることです。

学識があり、知識が豊富で、勤勉で高潔である

コミュニティ内で評判を確立したら、プロジェクトとそのコードを包括的に理解することが不可欠です。タスクレベルに留まらず、プロジェクト自体を深く掘り下げ、自分の専門分野を超えた概念を理解しましょう。開発者への理解に限定しないでください。そうすることで、自分の限られた利益だけを追い求めるのではなく、コードをより広範な影響を与えることに注力できるようになります。

例えば、ネットワークモジュールのテスト版が完成したとします。テストを終え、問題ないと判断しました。そして、より多くの人にテストしてもらいたいと思い、コミュニティにリリースしました。ところが、特定の方法でデプロイすると、セキュリティ設定が破られ、メインストレージがリークされる可能性があることが判明しました。この問題は、コードを個別に見るのではなく、コード全体を扱うことで解決できます。これは、プロジェクトのさまざまな部分がどのように連携し、相互作用しているかを深く理解する必要があることを示しています。パッチはバグを修正するためのものであり、バグを掘り下げるためのものではありません。これは、コミュニティリーダーになるための大きな一歩です。

不注意はトラブルを招きます。

コードを提出しただけでは仕事は終わりません。コードが承認された後も、変更点やよくある質問、そしてテストに関する議論が行われます。期限内に提出できるよう努め、コミュニティの他のメンバーに影響を与えずにコードとパッチを改善する方法を理解するよう努めてください。

調和して生きることは、自分自身と他人の両方に役立ちます。

オープンソースコミュニティは、競争の激しいジャングルではありません。私たちは、個人の貢献や成功よりも、プロジェクト全体の価値を重視しています。地位を高め、コミュニティのより重要なメンバーになり、コードを受け入れてもらいたいのであれば、他の人を助けるよう努めましょう。ネットワークに関する知識があれば、そのセクションをレビューし、専門知識を活かしてコードをより洗練されたものにしましょう。論理はシンプルです。専門家であるレビュー担当者は、専門家である貢献者と頻繁に交流しています。より多くの人を支援すればするほど、あなた自身の価値が高まります。

洗練されていて細心の注意を払っている

開発者として、オープンソースプロジェクトの特定の問題点を解決したいと考えることは多いでしょう。現在サポートされていないシステムでプロジェクトを実行したい場合や、コミュニティで現在使用されているセキュリティ技術を改革したい場合などです。新しい技術、特に物議を醸す技術を導入する最良の方法は、それらを誰もが抵抗できないものにすることです。そのためには、基盤となるコードを徹底的に理解し、あらゆる極端なケースを考慮する必要があります。既存の機能に影響を与えずに新しい機能を追加しましょう。ただ完成させるだけでは十分ではありません。機能を完璧に仕上げるための取り組みが必要です。

始まりがあるものはほとんどなく、終わりがあるものもほとんどありません。

オープンソースコミュニティにはカジュアルユーザーも多くいますが、一度約束したことは簡単に破ってはいけません。提出物が拒否されたからといって、コミュニティを離れてはいけません。理由を突き止め、バグを修正し、再度挑戦してください。開発中は、コードベース全体の一貫性を保ち、プロジェクトが変更されてもパッチが確実に使えるようにしてください。コードを他人に修正させるのではなく、自分で修正しましょう。そうすることで、誰もが自分なりの修正を加える、ポジティブなコミュニティの雰囲気が生まれます。

これらの「暗黙のルール」は一見シンプルですが、オープンソースプロジェクトへの貢献者の多くは、いまだにそれに従っていません。それに従う開発者は、自身のプロジェクトの成功だけでなく、オープンソースコミュニティ全体に貢献します。

著者について:

マット・ヒックスは、Red Hatのソフトウェアエンジニアリング担当バイスプレジデントであり、Red Hatオープンソースコラボレーションチームの創設メンバーです。彼は15年間、ソフトウェアエンジニアリング分野における開発、運用、アーキテクチャ、そしてマネジメントといった様々な役割を担ってきました。