问开放源码软件项目中的需求是如何确定的？

EN

开放源码项目有时会有大量的用户反馈，有时公司只需花钱来使某些特性得到规划和实现(通过雇用自己的开发人员或原始开发人员)。

如果您的项目有100个用户，您可能可以开发任何最有趣的代码。

如果您的项目有100 k用户，很可能您已经有了一张大多数用户希望在下一版中修复的痛点列表，以及用户在问题跟踪器中请求并在论坛上不断询问的顶级N项功能列表。

有了这些反馈，您可以为您的核心团队编写需求文档，创建路线图以帮助独立贡献者理解您的愿景，并希望100 k用户中的一些人能够发送补丁。

自从1995年第一次听说linux以来，我就一直在关注开源，我不记得在这种情况下听说过'requirements‘这个词。

埃里克·雷蒙德有一篇很好的文章“大教堂和集市”，他在文章中谈到了“挠痒自己的痒”。如果您试图解决个人面临的问题，则不必参考需求文档来确定是否已经解决了问题。

这篇文章还谈到了倾听用户的意见，这对每个人来说都是很好的建议，而不仅仅是开源项目。开源项目往往是任人唯贤的，所以“谁写代码，谁就制定规则”，或多或少。

在公司内部软件开发中，通常通过一个正式的过程来确定需求，从而创建许多需求文档。

根据我的经验，这种情况在进行基于合同的开发时更为常见，特别是当外部公司为您的公司进行开发时，并且有对合同的法律需要。但许多其他公司却以不同的方式控制着自己的内部发展：

• 非正式交流
• 按优先级排列的需求/bug/问题/票证列表(这绝对不是“敏捷”社区的发明)

这与大多数开源项目的工作方式是一样的--因为不需要正式的合同，所以没有人会费心地想出大的、详细的、正式的需求文档，只有很小的、无痛的缺失特性列表，或者在问题跟踪器中收集的要解决的票。