【翻译】Rod Johnson平衡的质疑：Spring维护策略的再次调整（上）

不管你承不承认，Spring实际上已经是实事上JAVA企业开发的标准 ，SpringSource最近策略维护策略变更已经在JAVA世界满城风雨 。 Rod终于忍不住在他的BLOG就SpringSource最近策略维护策略变更一事再次进行了新的调整，以求开源与商业达到平衡。Rod希望就此机会一扫大家的顾虑与疑问，表明 SpringSource坚持永远拥护开源的决心。原文请看：

 

http://blog.springsource.com/2008/10/07/a-question-of-balance-tuning-the-maintenance-policy/

 

 

正文

 

 

商业运作就像写代码一样：即使你知道你想实现什么，但一开始你并不总是对的。当必要的时候，如果你精益求精的反复修改，仍然会得到一个很好的结果。对 SpringSource 来说，最近的一系列对外宣称的维护策略已经表明我们的观点——使开源社区与企业用户和 Spring 创建者之间达到平衡，从而达到双赢。尽管一开始我们无法很快达到一个平衡，但这如同编码一样，商业运作的“重构”也是需要花时间的。

 

 

过去的几周里，我已经被庞大的 Spring 社区所惊醒，其中还夹着无数的愤怒。

 

 

我们现在正在倾听社区的反馈，不仅仅是那些耳熟能详的论坛，还包括许许多多的路径，比如说私聊和邮件。

 

 

在我们倾听的同时，发现两个突出的问题：

 

 

<!-- [if !supportLists]-->1.         <!-- [endif]-->关于 Spring 对社区定期发布的可用稳定最新版本的问题（已经说过，如果没有提供相应的二进制代码，可以请求 Spring 的 repositories 源代码库）

<!-- [if !supportLists]-->2.         <!-- [endif]-->对小型企业和小系统整合的收费问题。

 

 

我们也清楚人们觉得 Spring 的软件和我们的承诺都是改进 Java 企业开发；我们还知道他们想要 SpringSource 走向成功并继续保持改革创新。但现在我们确实听到一些用户实际关心的问题，并且打算将它们拿出来讨论讨论。

 

 

对于 Spring 社区中那些仍然心存疑问的人们，今天我想再重述一下我们的承诺，并且就我们收集到的反馈信息，解释我们对维护策略之所以做出这样巨大的改变。

 

 

 

 

我们的开源承诺

 

 

有些人关心 Spring 是不是不再开源了。“许可变更”的小道消息不胫而走。事实上，我们并没有改变 Spring 代码的任何许可。虽然这些推测都是无中生有，但关心仍然有必要。

 

 

“现在我就借此机会再次向大家保证—— Spring 会一如既往的对社区保持开源姿态，采取的许可同先前一样，仍然是基于 Apache 。”

 

 

如果你对此曾有过任何不同的看法，那一定是我和我的同事在宣布维护策略一事上做的不够到位，或者你也许只是道听途说。 SpringSource 的一切都是构建于 Spring 开源的基础之上，并且对社区一向是积极热情。首先，我们不可能将 Spring 闭源，否则那真是太错特错了。其次，我们也清楚即使不是绝大多数，但至少对许多 Java 项目或其它开源项目来说， Spring 扮演着中心角色。作为一个事实上的编程模型标准，闭源策略无疑会极大的伤害 Java 企业开发。再次，闭源策略是个十足糟透了的商业决策。

 

 

我们对开源的承诺仍然一如既往，并且还会继续加大力度。我们期望可以继续同社区并肩作战，在接下的数月及至数年里创造更多的辉煌。对于 Spring Framework3.0 的到来，我们欣喜若狂，其它的开源软件也会随之发布。我们因我们能够为开源做出越来越多的贡献而感到自豪。

 

 

 

 

稳定的社区发布

 

 

最初，我们的维护策略是当每个主要 Spring 版本发布后，社区的维护将维持三个月，来提供版本初始的稳定性，之后的维护发布将只提供给 SpringSource 企业版本用户（尽管源代码还是可以获得，只是没有版本号了）。

 

 

这么说的话，我们仅仅是对 3 个月后的主要发行版本改变了分发方式。我们仍然会将源代码基于当前许可。许可不会改变。

 

 

尽管如此，社区里的一些人还是关心是不是真的 3 个月后就无法从 Spring 的 repository 得到打上 tag 的源代码了。他们担心会因为二进制的发布问题从而让 Spring 与 Spring 社区产生隔阂，因为缺乏 tag 的源代码要想修复 Bug 是有困难的。还有一些人担心这还会造成 Spring 分发上的混乱，从而让 Spring 社区在交流的源代码的时候变得更加困难。

 

 

我们非常慎重的考虑了这些问题，然后我们最后的商量结果是：为了更好的向我们的社区（也许最重要的社区主要还是 Java 企业开发这块）诠释我们的承诺，我们应该进一步的满足用户的需求，从而确保它继续快速发展。

 

 

“鉴于社区的反馈，我们对我们做出的维护策略深感歉意。我们会继续从 Spring trunk 源码中向 Spring 社区提供二进制发布版本，不再是什么 3 个月的期限。对于每个 Spring 的版本，社区版本将仍然保持 trunk 或直到下一个稳定版本。”

 

 

一旦我们发布了某个项目新的 candidate 版本后，我们将通常就不再对开源社区发布它先前版本的 tag 或二进制版本。而 SpringSource 的企业用户对这些可用的发布版拥有三年的使用权。（注：也就是说社区得到的 tag 或二进制版本始终是最新的，后面有举例）

 

 

我们维护策略的关键目标是集中我们的资源来推动 Spring 更加饱满的向前进，并且继续引导 Java 企业开源的革命。随着我们开发资源的不断增长以及频繁的新版本发布，我们前进的步伐将会比以前更加迅速，从为社区带来了更多的特性。

 

 

举个例子， Spring 2.5.x 仍然是可以通过 SVN truck 的，那么在改动后维护策略下，不久我们仍然会为社区提供 Spring 2.5.6 版本。 Spring 3.0M1 很快也要发布了，而它的 trunk 自然是从 3.0 开始。一旦我们发布了 Spring 3.0 RC1 ，那么我们就不再提供任何 Spring 2.5.x 分支的任何 tag 或二进制发布。我们将会一心扑在 3.0 的开发上面，这样在 3.0 的第一个里程碑发布后，我们也可以尽快发布 3.0 的正式版了。

 

 

我们三年的支持策略是为那些不可能或不愿意升级的企业用户所服务的。其余的精力都放最新特性的开发上，从而让社区的开源用户从中享受好处。

 

 

 

 

未完待续。。。。。。。。