在开源软件项目中如何确定需求？

在公司内部软件开发中，通常需要通过正式流程来确定需求，从而创建许多需求文档。在开源软件开发中，这似乎常常不存在。因此，我的问题是：如何在开源软件项目中确定需求？

“确定需求”仅表示“确定应将哪些功能等开发为特定软件的一部分”。

开源项目有时会收到大量用户反馈，有时公司会付费以计划和实施某些功能（通过雇用自己的开发人员或原始开发人员）。

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

如果您的项目有10万用户，则很可能已经有了大多数用户希望在下一版本中解决的痛点列表，以及用户在问题跟踪器中要求并在论坛上不断询问的N大功能列表。

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

自从大约在1995年首次听说linux以来，我一直在关注开源。我不记得曾经听说过在这种情况下使用的“要求”一词。

埃里克·雷蒙德（Eric Raymond）有一篇不错的文章，《大教堂和集市》，他在书中谈到“抓痒”。如果您要解决个人面临的问题，则无需参考需求文档即可确定是否已解决。

同一篇文章还谈到了倾听用户的声音，这对每个人都是好建议，而不仅仅是开源项目。开源项目往往是有功的，所以“写代码的人，制定规则的人”或多或少。

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

我的经验，这是很多做基于合同的开发时，具有特别的时候比较常见的外部公司做开发的公司，并有一个合同的法律需求。但是许多其他公司也由自己的人以不同的方式控制内部开发：

• 非正式交流

• 按优先级排序的需求/错误/问题/票务列表（绝对不是“敏捷”社区的发明）

这与大多数开源项目的工作方式相同-因为不需要正式合同，没有人会费心去制定庞大，详细，正式的需求文档，只需少量，轻松的缺少功能清单，或在问题中收集的票证跟踪器有待解决。

如果问题是常见的问题，例如编写编译器或浏览器，则要求以语言标准，目标操作系统和目标硬件等形式给出。

对于GNU Emacs之类的东西，除了出色地实现其成为文本编辑器的原始目标之外，还有很多其他事情，我认为这些要求是合理的，因为有扩展它的巨大范围。想到聊天，电子邮件，新闻组，代码编辑，版本控制。Emacspeak上有一位研究科学家。我认为可以对浏览器和其他允许扩展的内容说类似的话。

如果该软件正在追赶仅在非开源软件中可用的功能，那么将再次给出很多要求。

编辑：

当开源软件继续维护且未满足的原始需求减少时，大多数需求可能来自错误，需要适应新平台（例如多核CPU和其他硬件），而这些新平台在被利用时可以提供更好的性能，等等。

在像GNU Hurd这样的完全基于研究的项目中，我认为要求来自研究结果和论文。

总结一下，

• 刚开始时，尝试解决常见问题的软件要求可能来自标准文档

• 对于赶上其他现有软件的软件，要求可能是产生所有或大部分现有软件的功能集以及开发人员/用户觉得很有趣的一些其他功能

• 对于研究项目，论文和其他出版物可以设定要求

• 在维护时，需要适应较新环境的错误可能是需求的主要来源

我不确定，但是曾经有人建议使用类似敏捷的方法，即使用JIRA之类的方法将需求作为票证（或“卡片”）提出，每张票证都代表一个功能或需求。然后可以将每张票分解为代表较小工作单位的其他票。

至于实际弄清楚应用程序或软件应该做什么，最简单的答案是“与其他开发人员交谈”。:)在这种情况下，“交谈”可能意味着电子邮件分发列表，论坛甚至IRC，它使任何位于不同时区和地理位置的人们都可以聊天。