我一直在想为我的团队将要开发的新开源产品做出贡献。我们鼓励我们尽可能地从更广泛的社区中获得支持，但是我也可以看到这花费了大量的时间，以确保位于办公室外的第三方能够按计划处理诸如代码质量之类的事情。同样在项目开始时，我们可能会在核心团队中进行许多有关系统设计，峰值等的非正式讨论，将这些在线获取以允许社区参与将非常耗时，我可以想象可以使讨论效果较差。
这可能需要考虑更多的人性化方面：允许社区参与设计过程也可以从感知到的项目所有权方面受益，并且总是有可能早期参与可以解决核心问题。团队没有注意到。
那么问题来了：您应该在开源项目的哪个阶段邀请社区的贡献？
Answers:
就在一开始！您希望社区感觉到他们在您的项目中拥有真正的利益，否则他们会觉得自己被当作免费劳动力。
所有交流都应通过公共邮件列表或论坛进行，这再次增强了社区的观念。
您可以通过在邮件列表的初始帖子中列出清晰的愿景来缓解“委员会设计”问题，例如
“因此，我们正在研究一种域模型来表示我们的Pet Store（根据JIRA-4）。有人看到该模型有任何重大问题吗？”
在接受实际的实际贡献方面，您应该首先接受补丁并对补丁进行公共代码审查。这样，贡献者就可以公开看到他们需要遵循哪种编码标准。确保您的提交也可以在提交邮件列表中使用-您需要遵守相同的标准！
在Wiki或某些此类文档上具有项目标准也很值得。
阅读http://www.productionoss.org，以获取有关如何运行成功的开源项目的更多详细信息。
Subversion的Brian Fitzpatrick和Ben Collins-Sussman 在google IO演讲《天才程序员的神话》中对此进行了详细讨论。简而言之，他们得出结论：现在还不算早，还不算太早（即“来看看我的出色项目！这里还没有很多东西，但是很多很棒的事情已经计划好了！”）或为时已晚所以所有的决定都已经制定了（很难在一个单独的项目中一言不发。）
我同意Martijn Verburg的观点。您应该从一开始就开始募捐。我以前写过一些。
那篇文章的摘要是软件烂了。如果要保持新鲜，则必须进行维护。一个项目越受欢迎，将发现更多的错误，将添加更多的功能，而这个维护任务将使您陷入困境。
实际上，这是一个非常普遍的问题。Fat有一个很棒的演讲，叫做什么是开源，为什么我感到如此内Gui？在本次演讲中（我强烈建议您观看），他讲述了他的一个OSS项目的故事，以及随着时间的流逝，他发现自己大部分时间都花在了票务分类和管理任务上。他谈到了这有多有害。我完全可以理解这一点。
当然，解决方案是尽早并经常增加人员。您的时间有限且宝贵。投资它以增加您的贡献者基础，其余的问题将开始解决。
正如我在文章末尾所说的那样：“对您的项目而言，更重要的是功能或未来？选择一个，并据此对您的工作进行优先排序。”