太早发布开源软件[关闭]

过早发布开源软件的道德责任是什么？例如，尚未完全测试的接近完成的产品。

程序员的期望是什么？等待，直到它经过完全测试，或者发布到开源，然后继续进行进一步的开发，测试和改进？

担心的是软件是开源的，并有可能为消费者带来问题。

这是没有根据的恐惧吗？

相反，我认为您应该尽快发布一个开源软件。没有“太早”（但是应该编译）。

^{或者至少在不进行正式发布的情况下，非常早且连续地发布源代码（例如，通过频繁推送github）。}

但是，将其标记为alpha或beta阶段非常重要，并且如果可能的话（例如，在README或TODO文件中，以及在某些博客中等等）说出丢失，未经测试或状况不佳的内容。您还应该使用版本号传达此类信息。

使用免费软件，最好的选择是让别人浏览源代码并为您提供一个小补丁以对其进行改进。这就是为什么您使软件免费！

^{因此，您需要在免费软件上显示您的日常工作！如果外部贡献者的补丁程序无法与您的最新软件源代码一起使用或与您的最新软件源代码重复，则将被激怒。}

您应该担心的是没有人会对您的软件感兴趣（并对此有所贡献）。吸引外界对免费软件的兴趣（尤其是吸引外部贡献者）是一段漫长的旅程。

TL; DR：

提前发布。经常发布。

个人轶事：

我为正在从事的项目感到非常兴奋。喜欢，真的很兴奋。晚上我无法入睡。因此，我推动我的开发人员以比他想要的更快的速度发布v1.0。

太可怕了 一切都没有按预期的方式进行。到处都有错误，但是我们记录了它们并加以修复。我们甚至有一些早期采用者提交了我们可能找不到的错误。一两个星期后，我们发布了一个新版本，该版本解决了很多问题，然后又重新构建新功能。

尽早发布是我们本可以做的最好的事情。它使我们的产品摆在真实用户面前。这样做暴露了我们可能发现或可能没有发现的错误，并使我们的项目变得更好。它还使那些早期采用者知道我们对这个项目很认真。将会有更多的发行版和活跃的开发。

它本来可以很容易地以其他方式走了。我们本可以忽略这些错误报告。否则我们可能不会迅速做出反应。如果我们花了3个月的时间来发布v1.1，而不是花了几周的时间，那就可能是另一回事了。

它与封闭源软件相同。沟通很重要。

告知用户该软件的状态以及为什么可以下载该软件。

无论是否经过全面测试，软件始终会导致客户问题。大多数客户确实接受这一事实，而有些客户则从未接受。但是，如果软件导致的问题超出了合理预期的范围，则有道义上的义务告知客户所承担的风险。信息应采用简写形式（“ Alpha / Beta / EarlyAccess”标签）*，并应采用详细信息：已知问题，解决方法和特殊注意事项的列表，例如，是否可能损坏数据。

*请注意，某些大型软件公司曾培训过用户，以将“ Beta”视为软件相当稳定的状态，因此，告诉用户软件为“ Beta”通常是不够的信息。

没有任何道德责任。没有人被迫使用您的半熟软件。

唯一需要关注的是您的信誉。

我的经验是要实现平衡。

现在，我正在与一个开发人员合作（就回答问题和提供开发建议的意思，而没有看到任何代码），该开发人员使用我编写的代码来生产看起来非常令人兴奋的FOSS项目。长期以来，由于实现设计更改而使发布时间一再推迟，这将使该项目从长远来看会变得更好，但是这需要大量重写已经编写且已经“有效”的代码。我的观点是，一旦有工作可以展示，就发布了一个可行但不完善的版本，有关更改（和实际补丁）的想法可能来自对这个项目感兴趣的广大社区，因此可以加快进度而不是这些问题一次很慢地浮出水面，当开发人员想到它们时，并要求我本人和社区中其他感兴趣的成员提供设计反馈。因此，从这个角度来看，我非常主张“提早发布，经常发布”。

另一方面，低质量的发行版可能会使新项目在启动之前就显得很糟糕。我见过的一些陷阱包括：

• 具有接口定义但没有代码的骨架树。
• 除了开发人员之外，其他任何人都无法成功编译的代码。
• 没有有关如何生成/运行程序的说明。
• 没有有关什么方面可以正常工作的文档。
• 对程序什至会做什么的描述不清楚。
• 缺乏任何有用性的证明。

对于最后一点，我在想类似的事情：

• 甚至无法编译/运行hello-world类型程序的编译器/解释器。
• 至少不能运行某种示例程序或无法证明其正在做某事的模拟器。
• 图像处理工具，除了加载和重新保存未修改的图像外，无能为力。
• 游戏只有标题屏幕。

这些类型的问题会导致产生“蒸发器”图像，除非您对开始时缺乏有效的代码非常开放，否则很难动摇这些图像。

最后，使版本号有意义。不要将您的项目命名为“ 1.0”，直到它执行用户期望的操作而不会崩溃。我一直很幸运使用版本号“ 0.5”进行首次公开​​发行并从那里开始，但是我也看到诸如“ 0.1”或“ 0.10”之类的东西是有意义的。

在一种情况下，发布自由软件可能会带来负面影响。某些规范是在向公众发布的前提下发布给公众的所有实现都应完全符合规范。发布者在法律上禁止您分发规范的正在进行的实现。没有规范发布者的特定协商许可，您必须与任何人共享它，直到它通过所有测试。这迫使该规范的实现采用“大教堂模型”（如Eric S. Raymond所称）。

获得这种许可的一种规范是Java Language Specification。此限制适用于与JVM兼容的虚拟机的开发人员，但幸运的是，不适用于在JVM中运行的应用程序的开发人员。

Liu Qihao和Ciaran O'Riordan 的文章“ 关于Microsoft'Open Source'.NET的4个详尽的细节 ”提到可以解释Microsoft .NET库和运行时组件的专利承诺，以类似的方式排除不完整的CLR实现。但是同样，这不适用于在CLR中运行的应用程序。