オープンソースプロジェクトのどの段階で、コミュニティからの寄稿を招待すべきですか？
私のチームが開発する新しいオープンソース製品に貢献することを考えていました。できる限り多くのコミュニティからのサポートを得ることが奨励されていますが、これにより多くの時間が吸収され、オフィスの外にあるサードパーティがコードの品質などを順調に進んでいることを確認できます。また、プロジェクトの開始時に、システムの設計、スパイクなどに関してコアチーム内で多くの非公式のディスカッションが行われる可能性が高く、コミュニティへの参加を可能にするためにこれらをオンラインで行うことは時間がかかり、想像できると思います議論の効果が低い。
これには、おそらく検討する必要があるより人間的な側面があります。設計プロセスへのコミュニティの関与を許可することには、プロジェクトの認識された所有権に関する利点もあり、初期の関与がコアの問題に気付く可能性が常にあります。チームは気づいていません。
それで、質問：オープンソースプロジェクトのどの段階で、コミュニティからの貢献を招待する必要がありますか？
まさに最初に！あなたはコミュニティに彼らがあなたのプロジェクトに本物の利害関係を持っていると感じてもらいたいです、さもなければ彼らは彼らが自由労働として使われているように感じるでしょう。
すべてのコミュニケーションは、公開メーリングリストまたはフォーラムを介して行う必要があります。これにより、コミュニティのアイデアが強化されます。
メーリングリストへの最初の投稿に明確なビジョンを提示することで、「委員会による設計」の問題を軽減できます。
「つまり、私たちは（JIRA-4に従って）ペットストアを表すドメインモデルを検討しています。このモデルに大きな問題がある人はいますか？」
実際の物理的な貢献を受け入れるという観点からは、まずパッチを受け入れ、それらに対して公開コードレビューを実行する必要があります。このようにして、寄稿者は、自分が遵守する必要のあるコーディング標準の種類をすでに公に見ることができます。コミットがコミットメーリングリストでも利用できることを確認してください。同じ基準を守る必要があります。
また、Wikiまたはそのようなドキュメントにプロジェクト標準を設定することにもメリットがあります。
成功するオープンソースプロジェクトを実行する方法の詳細については、 http://www.producingoss.org を参照してください。
これはGoogleで詳細に議論されましたIOトーク 天才プログラマーの神話 、SubversionのBrian FitzpatrickとBen Collins-Sussmanによって。まだ何もないほど早くない（つまり、「私の素晴らしいプロジェクトを見てください！ここにはまだ多くはありませんが、たくさんの素晴らしいことが計画されています！」）か、遅すぎるので、すべての決定はすでに行われています（ソロプロジェクトでWordを使用するのは難しいです。）
私 Martijn Verburgと同意する 。あなたは最初から寄付を募り始める必要があります。私は これについて少し 前に書いた。
その投稿の要約は、ソフトウェアが腐敗するということです。新鮮に保ちたい場合は、メンテナンスが必要です。そして、プロジェクトの人気が高まるほど、より多くのバグが発見され、より多くの機能が追加され、このメンテナンスタスクがあなたを困惑させます。
実際、これは非常に一般的な問題です。 Fatによる素晴らしい講演があります オープンソースとは何か＆なぜ私は罪悪感を感じるのですか？ この講演（私はこれを強くお勧めします）で、彼はOSSプロジェクトの1つのストーリーとその方法について語っています時間の経過とともに、彼は自分の自由時間のほとんどをチケットのトリアージと管理タスクに費やしていることに気付きました。そして彼はこれがいかに損害を与えたかについて話します。それは私が完全に共感できるものです。
もちろん、解決策は、プロジェクトに早期に頻繁に人を追加することです。あなたの時間は限られていて、貴重です。あなたの貢献者ベースを成長させることにそれを投資してください、そしてあなたの残りの問題は彼ら自身の世話をし始めます。
私の投稿の最後に書いているように、「プロジェクトにとってより重要なことは、機能か将来か、どちらかを選択し、それに応じて作業に優先順位を付けることです。」