ミッチェル・ハシモトはオープンソースソフトウェアエンジニアです。GitHubでホストされている彼のオープンソースプロジェクト「Vagrant」は、仮想開発環境の構築とデプロイのためのツールです。最近、ミッチェルはVagrantの開発を通して得たオープンソースソフトウェア開発に関する知見を共有する記事を執筆しました。

[[68368]]

以下が元の記事です。

Vagrant をオープンソースプロジェクトとして成功させるにはかなりの時間がかかりましたが、同時に多くのことを学びました。これまで、オープンソースプロジェクトから学ぶことについての記事はあまり読んでいませんでしたが、この知識は非常に重要なので、オープンソースソフトウェアに関する私の洞察をいくつか共有したいと思います。これらの洞察は、ソフトウェア開発だけでなく、オープンソースプロジェクトを効果的にマーケティングし、プロモーションする方法にも関係しています。

I. ソフトウェア開発に関する洞察

以下はソフトウェア開発に関する洞察です。

1. フレンドリーな態度

これが最も重要な点です。時には、ひどいアイデアを耳にしたり、質の低いコードばかりのプルリクエストを受け取ったり、一銭も払っていないユーザーからの苦情に耐えなければならないこともあるでしょう。こうした状況に遭遇した時は、覚えておいてください。たとえユーザーがあなたを尊敬していなくても、あなたはユーザーを尊敬しなければなりません。かつて私は、たった一つのことで激怒したことがありますが、今ではどんな状況でも友好的な態度を貫くと胸を張って言えます。ユーザーに対して友好的な態度を持つことは非常に重要です。なぜなら、あなたが友好的であれば、相手に親しみやすい印象を与えることができるからです。そして、ユーザーはあなたに助けを求めたり、プロジェクトに参加したりして、結果として貢献してくれるでしょう。これこそが、オープンソース運動の真髄です。

2. プロジェクトに過度に複雑なルールを設定しないようにしてください。

プロジェクトが非常に大規模でない限り、貢献者のコーディングスタイルについてあまり心配する必要はありません。プロジェクトに過度に複雑なルールを設定すると、開発者の参加を妨げてしまいます。空白やインデントといったコーディングスタイルに起因する問題は、手動で簡単に修正できます。したがって、貢献者のコーディングスタイルの違いに悩む必要はありません。むしろ、真に優れた貢献を喜んで受け入れるべきです。さて、これでオープンソースプロジェクトを改善する方法が分かりましたね？簡単です。優れた貢献を受け入れ、変更を加え、プルリクエストを送信するだけです。コーディングスタイルやテストの問題については全く心配していません。こうした貢献を喜んで受け入れています。

3. 開発ドキュメントの作成は非常に重要です。

具体的な証拠はありませんが、ほぼすべてのVagrantユーザーが、優れたドキュメントのおかげでVagrantを選んだと自信を持って言えます。開発ドキュメントの作成は、世界で最も面倒な作業と言えるかもしれませんが、適切なタイミングで作成できなければプロジェクトは失敗に終わります。さらに、開発者が容易にドキュメントにアクセスできるように、ドキュメントへのアクセス権限を与えることも忘れないでください。

4. 明確なコミュニケーション方法を持つ

IRC（インターネットリレーチャット）、メール、フォーラムなど、コミュニケーション手段は様々ですが、ユーザーが意見を表明できる明確かつタイムリーな方法を提供し、迅速な対応（通常は48時間以内が理想的）を保証する必要があります。Vagrantの場合、私は常にIRCチャンネルとメールを通じてユーザーと連絡を取り合っており、非常にうまく機能しています。さらに、ユーザーとのコミュニケーション手段が多ければ多いほど、プロジェクトへの信頼度は高まります。

5. すべてを知っているわけではない。

時には、実際には役に立たない機能であっても、機能改善の要望が寄せられることがあります。プロジェクトマネージャーにとって重要な仕事は、プロジェクト全体の開発を導くことであり、特定のミクロレベルの機能に焦点を当てることではありません。この機能はプロジェクト全体の方向性と合致していますか？ユーザーにとって、あるいはあなた自身にとって、役に立つものですか？プロジェクトの開発を導くには、これらの質問を検討する必要があります。そのため、思考を広げる必要があります。なぜなら、ユーザーはあなたよりも、本当に必要な機能についてよく知っているからです。しかし、忘れてはならないのは、プロジェクトの方向性を誰よりもよく理解しているのはあなた自身だということです。

II. マーケティングとプロモーションに関する洞察

ソフトウェアプロジェクトの開発は完了しました。では、ユーザーにプロジェクトをどのように伝えれば良いでしょうか？マーケティングに関する私の考えをいくつかご紹介します。

1. ハッカーニュース

Hacker Newsコミュニティは新しいことに挑戦することが大好きで、多くの開発者が参加しています。そこでプロジェクトを投稿すれば、どんな質問にも答える準備ができていることを示すことができます。ユーザーから批判を受けることもあるので、フレンドリーな姿勢で臨みましょう。

2. 優れたブログサイトに連絡する

ほぼすべてのコミュニティ、特にRubyコミュニティには、優れたブログがたくさんあります。特定の言語や手法を用いて開発されたクールなプロジェクトを喜んで共有してくれます。これらのブログを見つけて、ブロガーに連絡を取り、あなたのプロジェクトへの参加を呼びかけましょう。そうすることで2つのメリットがあります。彼らが参加を希望すれば、あなたのプロジェクトはより多くの注目を集めるだけでなく、あなたのアイデアをより効果的にテストできるようになります。

3. パーティーでスピーチをする（正式な会議に出席する前に）。

プロジェクトに興味を持つ人々が集まる地元の集まりに参加し、プレゼンテーションを行いましょう。初めての場合は、事前にプレゼンテーションの準備をしておきましょう。マニュアルを添付してプロジェクトを宣伝するのではなく、プロジェクトの今後の方向性を広く示すようにしましょう。初めてのプレゼンテーションであれば、すぐに正式なカンファレンスに参加するのは避けましょう。失敗は記憶に残り、次回のプレゼンテーションが難しくなるからです。集まりに参加する方がより良いアプローチです。さらに、集まりでは、プロジェクトを心から大切に思っている開発者から貴重なフィードバックを得ることができます。

4. 正式な会議でスピーチをする

いくつかの集まりに出席した後は、地域のカンファレンスで講演を始められるようになります。これらのカンファレンスは通常規模は小さいですが、トピックは優れており、スピーチスキルの低さを理由に参加者から見下されることはありません。一方、大規模なカンファレンスでは、新しいプロジェクトについて発表する機会は少ないでしょう。さて、いよいよ聴衆の前に立ち、40分間のプレゼンテーションを行う機会です。講演前には、十分な準備をしておきましょう。プレゼンテーション中は、笑顔を忘れずに、自分のビジョンを聴衆に伝え、受け取ったフィードバックはメモを取りましょう。

5. 大規模な会議でスピーチをする

さて、VelocityConfやQConのような大規模なカンファレンスについてお話ししたいと思います。主催者は、通常500人以上という非常に大規模な聴衆の前で講演する機会を与えてくれます。聴衆は、業界の優秀なプロフェッショナルで構成されています。もしあなたのプロジェクトが聴衆にとってあまり馴染みのないものであるなら、成功事例を必ず用意して、その成果を実証する必要があります。この事例は、プロジェクトの優れたパフォーマンスを示すために、理想的にはユーザーからの事例であるべきです。これらの大規模カンファレンスには、CIOや技術担当副社長など、著名人が集まることが多いです。

III. ソフトウェア工学に関する知識

ソフトウェアがリリースされるまでには、やるべきことがたくさんあります。ソフトウェアエンジニアリングに関する私の考えを述べたいと思います。

1. テスト

これについて詳しく説明する必要はないと思いますが、非常に重要なので、改めて私の考えを述べさせていただきます。テストは必須です。早期に開始し、頻繁にテストを実施する必要があります。さらに、統合テストも忘れてはいけません。私はこれまで多くの統合テストを実施してきましたが、Vagrantがリリースされる前は、統合テストが最も価値のあるテストの一つでした。単体テストは基本的なバグを素早く検出できますが、統合テストはリリース前に最も重大なバグを発見することができます。

2. Windowsをできるだけ早くサポート

VagrantのWindowsサポートは素晴らしいです。Vagrantは今ではパワフルですが、かつては悪夢でした。当初は多くの開発者がWindowsで作業しておらず、コード内の多くの関数がWindowsでは動作しませんでした。Windowsをサポートするには、基盤となるコードに大幅な変更を加える必要があり、どれほどの作業が必要だったか想像もつきませんでした。さらに、多くのWindows開発者はLinuxスタイルのツールを使いたがっていました。

3. 外部関数呼び出しインターフェース (FFI) の使用を避けます。

これはRuby特有の問題です。RubyのFFIライブラリはC標準ライブラリほどシンプルではありません。私はFFIに18ヶ月を費やしました。おそらく私がFFIを最も頻繁に使用していた一人だったのでしょう。私が頭を悩ませていたのは、FFIライブラリが定期的に更新され、パッチ版までリリースされていたことです。FFIのコンパイルの問題が原因で、VagrantがWindows上で正常に動作しないことに、ハッと気づくこともありました。さらに、FFIを使用するとコールバック関数の実行とメモリ管理が非常に困難になることも分かりました。Vagrantバージョン0.9より前は、深刻なメモリリークの問題がありました。最終的に、私はFFIを放棄し、より優れたライブラリに切り替えました。今では、Vagrantは再びC標準ライブラリを呼び出すことができます。

4. メンテナンスに参加している開発者と友達になりましょう。

特定のライブラリを深く理解している開発者なら誰でも、そのライブラリ内にバグを見つけるでしょう。Vagrantの開発の歴史を通して、私はこれまで使用したすべての依存関係にバグを発見してきました。Vagrantのメンテナンスに携わっているすべての開発者と良好な関係を築いているので、問題が発生した際にはすぐに「これはあなたのバグですか？修正にはどれくらい時間がかかりますか？」と尋ねることができます。最悪のシナリオは、依存関係にバグがあるにもかかわらず、メンテナーがそれを修正せず、更新版もリリースしないことです。

まだ学ぶべきことはたくさんありますが、これらの経験がオープンソースに取り組む開発者の役に立つことを願っています。

オリジナルの英語テキスト: オープンソースソフトウェアの構築から学んだ教訓