私が特に満足していないさまざまなオープンソースプロジェクトがいくつかあります。たとえば、Linuxのサウンドのさまざまな側面は、Windowsと比較すると単純にぞっとするようなものだと感じています。これは、サウンドカードメーカーがWindows用のハードウェアを製造しているためであり、サポートが非常に悪いのはおそらく彼らのせいです。しかし、私たちはもっとうまくやれると確信していますよね？
たとえば、pulseaudioは非常にバグが多いことがわかりました。私は自分のネットワーク上でpulseaudioを動作させようとしましたが（スピーカーを共有できるように）、何年も前から存在している「既知のバグ」がたくさんあるため、これは動作しませんでした。
また、もう1つの不満は、SkypeがPulseaudioのSkypeのひどいサポートを非難していることです。
私の質問は、新しいLinuxサウンドプロジェクトを開始する（そして潜在的に混乱を増す）価値があるのか、それともパッチを提出することでpulseaudioを支援する価値があるのかということです。
オープンソースプロジェクト内およびその周辺での議論に参加することは、貢献するための優れた方法です。できる限り積極的に貢献している場合は、パッチがより真剣に検討されます。既存のプロジェクトに参加するということは、すでに興味を持っている他の人々がいることを意味し、すでに多くの時間を費やしているので、彼らは新しいプロジェクトへの移行に対してより抵抗力があるかもしれません。既存の関心を利用して、すでに進行中の何かに参加してください！
純粋に私の意見：オープンソースはコミュニティのサポートに大きく依存しているため（私にとってはキーワードは「コミュニティ」です）、既存のものと同様のプロジェクトを開始することは、コミュニティをまとめるのではなく、実際に分割することです。つまり、既存のプロジェクトに飛び込んで知識を捧げてください。教育を受けた熟練した人が乗船できることを誰もが喜んでいると確信しています。
私はpulseaudioを手伝うことを選びます。そうすれば、競合他社と競合するのではなく、既存のインフラストラクチャを構築できるからです。ホイール（またはホイール製造プロセス）を再発明しても意味がありません。
FOSSの場合、既存のソフトウェアプロジェクトが完全に壊れていて、それらに希望がないと思われる場合にのみ、新しいプロジェクトを開始することをお勧めします。（またはもちろん、教育経験として）
新しいプロジェクトを開始するときは、対処されていない問題を見つけて、それを修正する方法を知っているときです...
ドメインがLinuxオーディオの場合、「修正方法を知っている」と主張する前に、知っておくべきことがたくさんあります。ALSA、PulseAudio、およびその他のプロジェクトの責任者は、この問題について考えています。
あなたが認識している問題についてすでに考えている賢くて有能な人々がいるという可能性は非常に高いです。あなたはほぼ間違いなく、彼らが最初からやり直すのを手伝うほうがよいでしょう。
また、実際の問題は、コードの基礎ではなく、構成と展開の1つである可能性があることにも注意してください。そして、それは貢献するより簡単な問題かもしれません。
Yet Another Linux Audio System を起動しないでください。何かをコーディングする前に、Linux audio: it's a messとWelcome To The Jungleを読んでください。
パッチを提出します。そうしないと、車輪の再発明をして混乱を助長するリスクがあります。
Joelはこれについて間接的に書いています。
フォークする必要があるかどうかわからないときに、先制的にプロジェクトをフォークするのはばかげています。パッチを送信します。それらがレスポンシブに処理されていない場合 (または設計全体をやり直す必要がある場合)は、おそらく分岐することを検討してください。