以下是詹金斯网站http://jenkins-ci.org上的总结。

简而言之，Jenkins CI是领先的开源持续集成服务器。它使用Java构建，提供了300多个插件来支持构建和测试几乎任何项目。

甲骨文现在拥有Hudson商标，但已在Eclipse EPL下授权使用。詹金斯在麻省理工学院的执照上。Hudson和Jenkins都是开源的。在我看来，基于你为谁工作以及个人对开源的偏好，这个决定很简单。

希望这对你有帮助。

詹金斯是新的哈德森。它实际上更像是一个重命名，而不是一个分支，因为整个开发社区都转移到了Jenkins。(甲骨文只能坐在角落里拿着他们的老球“Hudson”，但现在它只是一个没有灵魂的项目。)

c.f. Ethereal -> WireShark

三个月后，我对这件事的看法是:

詹金斯继续了原来哈德逊的道路，频繁发布包括许多小更新。

Oracle似乎已经将关于Hudson未来路径的大部分工作委托给Sonatype团队，Sonatype团队已经完成了一些重要的更改，特别是在Maven方面。他们已经共同将其转移到Eclipse基金会。

如果你喜欢这个声音，我建议你:

不太频繁的发布，但是在向后兼容性方面进行了更严格的测试(更多的是“企业风格”发布周期) 一个主要专注于强大的Maven和/或Nexus集成的产品(也就是说，你对Gradle和Artifactory等不感兴趣) Sonatype或Oracle提供的专业支持，而不是Cloudbees等 你不介意拥有一个较小的插件开发者社区等等。

，那么我建议你去哈德森。

相反，如果你喜欢:

more frequent updates, even if they require a bit more frequent tweaking and are perhaps slightly riskier in terms of compatibility (more of a "latest and greatest" release cycle) a system with more active community support for e.g., other build systems / artifact repositories support offerings from the original creator et al. and/or you have no interest in professional support (e.g., you're happy as long as you can get a fix in next week's "latest and greatest") a classical OSS-style witches' brew of a development ecosystem

那我建议詹金斯(正如一位评论者所指出的，Jenkins现在也有“LTS”版本，这是在一个更“稳定”的分支上维护的)

保守的做法是现在选择Hudson，如果必备功能不可用，则迁移到Jenkins。动态的过程是现在选择Jenkins并迁移到Hudson，如果追赶更新变得太耗时而无法证明是合理的。

对于那些提到和解作为哈德森和詹金斯潜在未来的人来说，事实上詹金斯将加入SPI，在这一点上他们不太可能和解。

使用詹金斯。

Jenkins是Hudson核心开发者最近的一个分支。要理解其中的原因，您需要了解项目的历史。它最初是开源的，并得到Sun的支持。就像Sun做的很多事情一样，它是相当开放的，但有一点善意的忽视。源代码、跟踪器、网站等都由Sun托管在他们相对封闭的java.net平台上。

后来甲骨文收购了Sun。出于各种原因，甲骨文并不羞于利用它所认为的资产。其中包括对哈德逊物流平台的一些控制，特别是对哈德逊名称的控制。许多用户和贡献者对此感到不舒服，决定离开。

所以这取决于Hudson vs Jenkins提供了什么。甲骨文的哈德森和詹金斯都有代码。Hudson拥有甲骨文和Sonatype的企业支持和品牌。Jenkins拥有大多数核心开发人员、社区和(到目前为止)更多的实际工作。

阅读我在上面链接的那篇文章，然后按时间顺序阅读其余的文章。为了达到平衡，你可以阅读Hudson/Oracle对它的看法。我很清楚谁在防守，谁对这个项目有真正的意图。

我有两点要补充:第一，Hudson/Jenkins是关于插件的。插件开发人员已经转向Jenkins，我们这些用户也应该如此。第二，我个人并不是甲骨文产品的忠实粉丝。事实上，我对他们避之唯恐不及。用在甲骨文解决方案的授权和硬件上的钱，你可以雇佣两倍的工程人员，还可以每周五买啤酒。