有一个想法遭到更广泛的软件社区的双重反对：可以完成软件。这种抵制表现出无数形式，也许最常见的想法是，没有收到很多提交的git存储库被放弃或不值得使用。就我而言，我认为大多数时候旨在完成的软件都值得。
项目受两个变更源的影响：外部和内部。内部更改源是例如计划中的功能或发现的错误。外部的变更源是，例如，当某个依赖项进行了重大更改并且您的软件必须相应地进行更新时。有些项目通常需要将不确定的外部变化源考虑在内，这通常是其价值主张的一部分。 youtube-dl会不断发展以添加新的站点和解决方法，wlroots会继续增长以利用新的图形和输入硬件功能，等等。
随着错误修正的累积，任何维护的程序都会随着时间的推移自然增加稳定性，达到某个有限的最大值。但是，变化推动了这一趋势的逆转。引入新功能，应对外部变化因素，修复错误，所有这些通常都会带来新问题。如果您要生产可靠，健壮和稳定的软件，那么对变更进行管理就成为了必备条件。
为此，软件项目可以并且经常应该画出终点。或者，即使不是终点线，也可以通过一条曲线逐渐退出功能介绍，从而提高了考虑新功能的重要性阈值。
例如，Sway在一段时间后“完成”。我们不再接受大多数主要的功能请求，只喜欢外部来源进行的必要的实现更改：尤其是在i3中实现的功能，该项目旨在取代。 i3项目本周宣布，它将对新功能采用类似的政策，因此，sway的变更管理的范围再次缩小到仅解决错误和性能。 Sway已经完成了其价值主张，现在我们的唯一目标是在交付产品时变得越来越稳定和可靠。
scdoc是另一个已达到其既定目标的项目。它的主要外部变化源是roff-已有近50年的历史了。因此，自发布以来，它在过去的几年中主要积累了错误修正和健壮性，用户因此而享有很高的可靠性和稳定性。成为一个“行之有效的”工具，并且无需再三思而行，这是我们前进的唯一目标。
下次您看到一个git repo时，它只会缓慢地进行提交，不必将其废弃就注销。缓慢的提交动作是旨在确保稳定和可靠的软件的最终命运。而且，作为您自己的项目的维护者，请记住，对新功能的请求持批判态度，并在复杂性和稳定性方面评估其成本是用户依赖于您的另一项责任。