オープンソースソフトウェアプロジェクトで要件はどのように決定されますか？

企業の社内ソフトウェア開発では、一般的な要件を正式なプロセスで決定し、多くの要件ドキュメントを作成します。オープンソースソフトウェア開発では、これはしばしば存在しないようです。したがって、私の質問は次のとおりです。オープンソースソフトウェアプロジェクトで要件はどのように決定されますか

「要件の決定」とは、単に「特定のソフトウェアの一部としてどの機能などを開発する必要があるかを特定する」ことを意味します。

オープンソースプロジェクトにはユーザーフィードバックの激しいストリームがあり、企業は特定の機能を計画し、実装するために（独自の開発者または元の開発者を雇うことで）単純に支払うことがあります。

プロジェクトに100人のユーザーがいる場合は、おそらく最も楽しいコードを開発できます。

プロジェクトに10万人のユーザーがいる場合は、ほとんどのユーザーが次のリリースで修正する必要がある問題点のリストと、ユーザーが課題トラッカーでリクエストし、フォーラムで質問し続ける上位N個の機能のリストを既に持っている可能性があります。

このフィードバックにより、コアチームの要件ドキュメントを作成し、独立した貢献者があなたのビジョンを理解できるようにロードマップを作成し、10万人のユーザーの一部がパッチを送信することを期待できます。

1995年ごろにLinuxについて最初に聞いて以来、私はオープンソースを追い続けてきました。

エリック・レイモンドには良いエッセイ「大聖堂とバザール」があり、そこで「自分のかゆみを掻く」ことについて話しています。個人的に直面している問題を解決しようとしている場合、要件ドキュメントを参照して解決したかどうかを判断する必要はありません。

その同じエッセイは、ユーザーの意見を聞くことについても話します。これは、オープンソースプロジェクトだけでなく、すべての人にとって良いアドバイスです。オープンソースプロジェクトは実力主義的である傾向があるため、「コードを作成し、ルールを作成する人」は多かれ少なかれです。

企業の社内ソフトウェア開発では、一般的な要件を正式なプロセスで決定し、多くの要件ドキュメントを作成します。

私の経験では、これは契約ベースの開発を行う場合、特に外部の会社があなたの会社の開発を行っている場合に非常に一般的であり、契約の法的必要性があります。しかし、他の多くの企業は、社内の開発を異なる方法で自社の従業員によって管理しています。

• 非公式コミュニケーション

• 優先順位付けされた要件/バグ/問題/チケットリスト（そして、それは間違いなく「アジャイル」コミュニティからの発明ではありません）

これは、ほとんどのオープンソースプロジェクトが機能するのと同じ方法です-正式な契約が不要であるため、大きな、詳細な、正式な要件ドキュメント、不足している機能の小さな、痛みのないリスト、または問題で収集されたチケットを作成する人はいません解決するトラッカー。

問題がコンパイラやブラウザの作成などの一般的なものである場合、要件は言語標準、ターゲットオペレーティングシステム、ターゲットハードウェアなどの形で与えられます。

GNU Emacsのようなものは、テキストエディターであるという当初の目標を十分に達成することに加えて、多くの人にとって多くのものであり、拡張する広大な範囲のために要件は理にかなっていると思います。チャット、メール、ニュースグループ、コード編集、バージョン管理が思い浮かびます。Emacspeakに取り組んでいる研究科学者がいます。同様のことがブラウザや拡張機能を許可する他のことについても言えると思います。

ソフトウェアが非オープンソースのソフトウェアでのみ利用可能な機能をキャッチしている場合、要件はほとんど再び与えられます。

編集：

オープンソースソフトウェアがメンテナンスに進み、満たされていない元の要件が少なくなると、ほとんどの要件はバグ、マルチコアCPUなどの新しいプラットフォームに適応する必要性、悪用されたときにパフォーマンスが向上するその他のハードウェアなどになります。

GNU Hurdのような完全に研究ベースのプロジェクトでは、要件は研究結果と論文から来ると思います。

総括する、

• 開始時に、一般的な問題を解決しようとするソフトウェアの要件は、標準文書から来ることができます

• 他の既存のソフトウェアに追いついているソフトウェアの場合、要件は、既存のソフトウェアの機能セットのすべてまたは大部分と、開発者/ユーザーが興味を持っていると思う他の機能を生成することです。

• 研究プロジェクト、論文、その他の出版物については、要件を設定できます

• メンテナンス時、バグ、新しい環境に適応する必要がある場合、要件の主要なソースになる可能性があります

確かではありませんが、一度提案するのはアジャイルのような方法論を使用することです。JIRAのようなものを使用して要件がチケット（または「カード」）として上げられ、各チケットは機能または要件を表します。その後、各チケットを、より小さな作業単位を表す他のチケットに分解できます。

アプリケーションやソフトウェアが何をすべきかを実際に理解することに関しては、単純な答えは「他の開発者と話すこと」です。:)この場合の「話す」とは、電子メールの配布リスト、フォーラム、IRCなど、さまざまなタイムゾーンや地理的な場所にいる人々がチャットできるものを意味します。