オープンソースプロジェクトのどの段階で、コミュニティからの貢献を招待すべきですか？[閉まっている]

私のチームが開発する新しいオープンソース製品に貢献することを考えていました。できるだけ多くのコミュニティからできるだけ多くのサポートを得ることが奨励されていますが、これは多くの時間を費やし、オフィスの外にあるサードパーティがコード品質などに関して順調に進んでいることを確認できます。また、プロジェクトの開始時に、システムの設計、スパイクなどに関してコアチーム内で多くの非公式な議論が行われる可能性があり、これらをオンラインでコミュニティに参加させることは時間がかかり、議論はあまり効果的ではありません。

これにはもっと人間的な側面があり、おそらく検討する必要があります。設計プロセスへのコミュニティの関与を許可することは、プロジェクトの所有権の認識に関しても利点があり、初期の関与がコアの問題を拾う可能性が常にありますチームは気づいていません。

では、質問：オープンソースプロジェクトのどの段階で、コミュニティからの貢献を招待すべきでしょうか？

まさにその始まりです！あなたは、あなたのプロジェクトに真の利害関係があるとコミュニティに感じてもらいたいです。そうでなければ、彼らは自由な労働として使われているように感じます。

すべてのコミュニケーションは、パブリックメーリングリストまたはフォーラムを介して行う必要があります。これもまた、コミュニティのアイデアを高めます。

メーリングリストへの最初の投稿で明確なビジョンを提示することにより、「委員会による設計」問題を緩和できます。

「だから私たちはペットストア（JIRA-4に準拠）を表すドメインモデルを検討しています。このモデルに大きな問題はありますか？」

実際の物理的な貢献を受け入れるという点では、まずパッチを受け入れ、それらに対して公開コードレビューを実行する必要があります。そうすれば、寄稿者は、どの種類のコーディング標準を遵守する必要があるかをすでに公に知ることができます。あなたのコミットがコミットメーリングリストでも利用可能であることを確認してください-あなたは同じ基準を守る必要があります！

また、Wikiまたはそのようなドキュメントにプロジェクト標準を設定することも有効です。

オープンソースプロジェクトを成功させる方法の詳細については、http：//www.produceoss.orgを参照してください。

これは、SubversionのBrian FitzpatrickとBen Collins-Sussmanによる、Google IOトークの天才プログラマーの神話で詳細に議論されました。手短に言えば、彼らはまだそこに何もない（つまり、「私の素晴らしいプロジェクトを見てください！本当にここにはまだたくさんありませんが、たくさんの素晴らしいものが計画されています！」）または遅すぎると結論付けましたそのため、すべての決定はすでに行われています（ソロプロジェクトに一言もらえるのは難しいです）。

Martijn Verburgに同意します。あなたは、最初から寄付を募り始めるべきです。私はこれについて少し前に書きました。

その投稿の要約は、ソフトウェアが腐敗しているということです。新鮮に保ちたい場合は、メンテナンスを行う必要があります。そして、プロジェクトの人気が高まると、より多くのバグが発見され、より多くの機能が追加され、このメンテナンスタスクがますます手詰まりになります。

実際、これは非常に一般的な問題です。呼ばれる脂肪によって素晴らしい話がありますどのようなオープンソース＆なぜ私フィールそうはギルティは？このトーク（私はこれを見ることを強くお勧めします）で、彼はOSSプロジェクトの1つのストーリーを語り、時間の経過とともに、チケットのトリアージと管理タスクにほとんどの時間を費やしていることに気付きました。そして彼は、これがどれほどの損害を与えたかについて語っています。これは私が完全に共感できるものです。

解決策は、もちろん、プロジェクトに人々を早期かつ頻繁に追加することです。あなたの時間は限られており、貴重です。貢献者ベースの成長に投資してください。そうすれば、残りの問題は自分で解決し始めます。

私の投稿の最後で言ったように、「プロジェクトにとってより重要なものは、機能か未来か。いずれかを選択し、それに応じて努力に優先順位を付けてください。」