[[142923]]

今年のOSCONカンファレンスで、Red Hatのトム・キャラウェイ氏は「なぜ失敗するのか：オープンソースプロジェクトでは避けられないミスが依然として起こる」と題したプレゼンテーションを行いました。キャラウェイ氏は2009年にChromiumプロジェクトに参加しましたが、プレゼンテーションの中で、その経験は不快なものだったと述べています。

キャロウェイ氏は、挑戦は好きだと語るものの、プロジェクトに息苦しさを感じ、最終的に辞職に至ったという。（キャロウェイ氏によると、 Chromiumのコードベース自体は悪くなかったものの、膨大な作業量であり、Googleはプロジェクト開発中に完全には完成させていなかったという。）こうした状況がキャロウェイ氏を極度のフラストレーションに陥れ、人々は彼の経験について知りたがっていた。キャロウェイ氏は、自身の挫折をより深く分析するため、このリストを作成した。彼はこれを「失敗点」と呼んでいる。

キャロウェイ氏はブログ投稿で注目を集めようとしていたわけではありませんでしたが、それでも彼の経験は人々の注目を集め、議論を巻き起こしました。このリストは彼の観察と経験の要約に過ぎなかったため、複数のメディアから講演依頼が寄せられ、他のウェブサイトでも関連記事が掲載され、オープンソースプロジェクトの役職表まで登場しました。しかし、失敗点理論を掘り下げる前に、キャロウェイ氏はまず真の成功を定義したいと考えました。開発者のソフトウェアを人々が楽しく使えるかどうかは、成功を測る重要な基準の一つです。次に（そしてこれが私が最も好きな議論のテーマですが）、成功を確実なものにするためには健全なコミュニティ環境が必要です。より多くの人々が製品ソリューションの改善に参加し、互いに助け合い、定期的にアップデートをリリースすることを望んでいます。そして最も重要なのは、私たちの仕事が「フレンドリーに分散」されていることです。「フレンドリーに分散」されたオープンソースプロジェクトとは、事前にパッケージ化されている必要があるという意味だとキャロウェイ氏は説明しました。

Linuxユーザーの多くは、依然としてディストリビューションに含まれるソフトウェアパッケージを通じてソフトウェアを入手しています。これは、人々が新しいソフトウェアを探す際に最も重視するプラットフォームです。Callawayは成功の定義を説明した後、失敗の指標として以下の指標を示しています。

1.コードベースが大きすぎると、ユーザーのダウンロード意欲とダウンロード能力が制限されます。

2. 今は2015年です。オープンソースプロジェクトが公開ソースコード管理メカニズムを提供しない理由はありません。これは、人々がプロジェクトに貢献しやすく、各コミットの日付に基づいてプロジェクトの現状を判断できるようにするためです。

3. ソース コード管理メカニズムが Web ビューアやドキュメントを提供していない場合は、すぐに解決策を見つけてください。この 2 つの要素は非常に重要です。

4. 質の悪いコードは、コードがないよりも悪いです。このソースコードを使用してプロジェクト全体をビルドする方法を説明するドキュメントを提供する必要があります。

5. ビルド ツールを使用します。

6. バンドル アプローチを使用することで、プロジェクトの保守性が失われるわけではありません。バンドルとは、フォークできるということだけを意味します。

7. 特定のディレクトリにソフトウェア プロジェクトをインストールするように強制する。

キャロウェイは、次の条件が満たされた場合、 プロジェクトは失敗したと述べています。

1. コードが Microsoft Visual Studio または同様のソフトウェアに依存している場合 (***失敗)。

2. プロジェクトがシステムでホストされているが冗長性が欠けている場合、または近くの通常のコンピューターで直接実行されている場合。

3. 適切なコミュニケーション ツール (メーリング リスト、Web サイト、バグ追跡ツールなど) がない場合。

4. コードが別のプロジェクトからフォークしたものであり、メインの開発者が同時にその親プロジェクトのプログラミング作業に関与していない場合。

5. コードがオープンソースになる前に独自のソフトウェアだった場合 (過去を変えることはできません)。

6. コード ライセンスに一貫性がない場合。

7. コードにドキュメントがない場合。

8. メーリングリストを通じて送信されたメッセージのほとんどが返信されない場合、または嘲笑や侮辱を受ける場合。

9. プロジェクト貢献者の 50% 以上が同じ会社に勤務している場合。

10. コードがローカリゼーション サポートを提供していない場合。

11. プロジェクトを管理していない場合、または管理をコード配布ベンダーに頼っている場合。

元のタイトル:これがオープンソースプロジェクトが失敗する理由です