通过让软件易于测试，使其易于贡献

问题：如何让更多开发者为一个自由和开源软件项目做贡献？贡献是 FOSS 社区的命脉。没有贡献，社区就无法超越最初的项目创始人而发展壮大。人们不会凭空出现就准备好工作。他们很可能从用户开始，甚至在羽翼未丰的软件真正开始成型为强大的解决方案之前就开始使用它。

让我们从“软件工程师”的角度，而不是从“社区组织者”的角度来探讨如何让更多开发者参与进来这个问题，并提出一个不同的问题：我们为什么要使用软件版本控制，也称为软件配置管理工具？

缺乏一致的版本控制是我在过去 30 多年里见过的最奇怪的事情之一。在很长一段时间里，IT 领域的开发团队并没有严格使用版本控制工具（在某些地方可能仍然如此）。优秀的软件团队，无论是内部开发复杂的企业应用程序、销售产品，还是在 Web 上协作开源软件项目，都会毫不犹豫地使用它们。

乍一看，我们使用版本控制工具是因为没有它们，我们将永远无法构建我们今天构建的复杂软件解决方案（实际上是过去几十年来的）。如果没有某种形式的软件版本控制，我们就无法跟踪实验，或者针对特定情况（如不同的芯片组或屏幕尺寸）的替代开发路线，或者让两位开发者尝试解决问题的替代方法。

在这个层面上，软件版本控制和配置管理工具使保持源代码“同步”变得简单，而无需复杂的手动树克隆，后者很容易丢失在一组不同的实验中引入的所有差异。它始终使我们能够知道：哪些源代码工件被组装到这个正在运行的软件中。

版本控制工具带来可扩展性

没有这些知识，我们将永远无法将软件扩展到超过几个用户。这是优秀的开发者严格使用此类工具库的真正原因。人们需要知道正在执行什么软件，才能知道要做出哪些更改，才能回答有关意外行为的问题，才能改进和修复软件中的错误，才能发展软件。软件非常动态，并且总是会随着人们发现问题、错误并希望以新的方式扩展软件而通过使用发生变化。没有软件版本控制引擎，软件就无法发展。

没有这种工具支持，我们将永远无法可靠地构建软件的已知可执行实例，无论是运行网站还是用于广泛分发的二进制文件。唯一知道的方法是严格管理软件版本的配置，以及将源文件和其他工件转换为可执行软件的配方。Git、subversion 和 Mercurial 等工具为我们做到了这一点。  

这暗示了下一个要求：配方。无论您使用的是简单的 makefile 还是集成开发环境的配方二进制表示形式，选项设置以及库、头文件的顺序，甚至步骤的顺序都至关重要地定义了软件可执行文件的运行实例。不知道软件是如何构建的，就无法回答有关其行为的问题。

将产品扩展到扩展项目

这意味着将永远无法经济高效地提供支持。如果您必须检查二进制文件并确定其来源、构建结构和配置，则支持成本将飙升。如果您无法支持软件，它就无法发展。这对于内部应用程序开发、广泛分发的 ISV 产品、移动应用程序，尤其是广泛协作的开发项目（也称为开源软件）都是如此。

[请理解，任何说“更新是因为新版本应该解决该问题”的人最好知道，它这样做是有充分理由的，这与运行严格的配置管理环境息息相关。]

有些人甚至会管理用于交付二进制文件的工具链的配置。切换编译器的版本可能会引入各种差异，从库和预处理器依赖性的高阶结构，到默认的命令选项和实际的二进制输出，无论语言本身在编译器上是否向后兼容。

每个导致软件运行可执行实例的工件都需要被捕获和编目，以便我们可以可靠地将软件重建到已知状态。  

那么，这对于开源软件和社区发展来说，为什么甚至有点重要呢？

如果不能可靠地构建软件到已知状态，就没人能改进它。如果由于 FOSS 项目没有使其变得容易，导致达到已知状态花费的时间太长，那么想要贡献的用户就不得不花费不合理的时间来尝试将软件构建到已知状态。 这甚至是在他们进行更改、测试更改，然后开始将更改打包为项目可能（不保证）选择采纳的贡献之前。如果此流程中存在任何摩擦，项目就有可能失去外部开发者关注和时间的难得机会。  

如果不能使更改可重复且可靠地变得容易，项目就无法超越少数几个知道所有复杂性魔法咒语的人而发展壮大，这些魔法咒语可以将源代码和构建工件的集合变成软件的工作可执行实例。

最佳实践是通用的

优秀的开发者知道这一点。这就是软件供应商采用此类工具的原因。否则，他们将永远无法适当地将其支持扩展到其客户群。这就是为什么许多企业 IT 部门的软件配置管理实践如此松懈的原因——他们不理解“开发生命周期结束”时期的支持成本与此类前端开发工具在生命周期开始时提供的支持成本之间的关系，而且从历史上看，此类工具本身价格昂贵，必须加以证明。Git 今天可能是免费的，但 Aide-de-Camp（第一个将版本管理问题表示为变更集而不是版本的专有工具集）价格昂贵。 

在当今世界，有大量的此类配置管理工具可以作为免费和开源软件使用，从版本控制引擎（CVS、svn、Mercurial、Git）到构建引擎、自动化测试引擎（xUnit、JUnit）到完全集成的开发和部署环境（Eclipse），没有理由不解决生成已知软件的问题。 开源世界很幸运，所有关键组件都可以在 Github、codeplex.com、SourceForge、Google Code 等代码托管站点免费获得。

(参与 opensource.com 投票：您使用哪个存储库？)

让其他人轻松“制作”您的软件到已知起始状态将使他们更容易修复和改进您的软件。让人们轻松可靠地达到已知状态，使人们可以试验它并做出贡献。仅仅使其“易于 Fork”是不够的。它需要易于构建。它需要易于测试到已知状态。（测试树/测试框架/测试用例是配置的一部分，对吗？）这些工具平台是 FOSS 社区将用户和开发者社区扩展到项目成功的唯一途径，就像软件产品团队可以将开发和支持扩展到产品成功一样。

这就是 FOSS 项目的开发者如何让更多开发者参与进来的方法。通过让软件易于配置、构建和测试到已知状态，使其易于贡献。您为可能有兴趣贡献的外部开发者节省的时间越多，他们就有更多的时间来处理他们想要做出的贡献，而不是浪费时间和可能的兴趣来尝试完成软件的构建。

如果您正在寻找更多信息，领导 Jenkins 社区的 Kohsuke Kawaguchi 就让参与变得容易的整个想法发表了精彩的演讲。

最初发布在 Outercurve 基金会博客上。经许可转载。