【翻译】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 社区所惊醒，其中还夹着无数的愤怒。

 

 

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

 

 

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

 

 

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

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

 

 

我们也清楚人们觉得 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 的正式版了。

 

 

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

 

 

 

小型商业公司付费

 

 

由于往往是大型企业侧重于我们的商业产品，使得一些小的公司认为我们忽悠了它们或者觉得我们不想与它们有业务上的往来。实际上不是这样的——我们不会简单的按照企业的规模才来决定为它定制服务。现在确实有的公司误解我们，还草草下了这个结论，在这里我对我们曾经制定的价格体系而让你们误导而道歉。

 

 

我们知道小型商业公司都是开源软件的活跃分子，他们对整个技术的发展做出了重要的贡献。因此，我们会引入一个新的产品，它的设计和定价都是专门针对一些有特殊需求的小型商业公司。因为这是BLOG，不适合谈论过多的商业细节，但我们还是会在近期发布一些关于此项产品的最新信息。（注：从这里我们可以看出，所谓的小型商业公司收费只是大型企业收费的延续，仍然针对的是有特殊需求的小企业，并不是说Spring对所有小公司要收费了。）

 

 

 

 

平衡

 

 

毋庸置疑，我们已经向我们的社区解释了我们的所作所为以及相关的必要性。

 

 

尽管如此，理解我们维护策略变更的意图仍然非常重要。第一，我们决不在没有向社区和我们客户解释清楚我们的承诺之前，轻易的宣布个维护策略变更。作为一个公司，我们总是在设法对社区开发透明，而不是独自闭门造车。有时候，交流上的不畅快往往都会导致其它公司立马转身，扬长而去。第二，策略是为了帮助我们从一些无法正常升级到最新版本，却又希望得到SpringSource的帮助来维护老版本的机构那里获得收入，也就是说社区不是我们的针对的目标。那些机构要的是稳定的，世界级的技术支持，当然了也包括我们提供的企业开发套件。

 

 

我们想成为一个大公司，可以支付得起为之奋斗的有才能的开发人员费用，可以获得一个合理的利润从而继续加大我们对开源软件的贡献。我们越成功，我们对Spring社区贡献的代码就越多。过去成长的2年里，我们编写开源代码速度越来越快，而在最近的12个月里，Spring的下载量也是越来越多，与此同时，要求会Spring技术的工作也是越来越多。

 

 

许多机构可以通过我们的企业产品，技术支持以及三年周期的版本维护从而认识到我们的价值。同样我们也清楚更多的人并不打算购买这些产品和服务。没关系！那也正是开源软件商业化的意义所在。如果我们可以继续对现有的软件加大投资力度，每个人都会获得的。

 

 

下面我要说到的策略是我期望能够实现的：

 

 

“如果你作为一个机构，在大量的生产环境中通过使用Spring从而享受到了巨大的好处，那么请你向SpringSource支付你所创建价值的1%。我们会将这些钱对于支付薪水，加大开源软件的投资从而获利。”

 

 

如果这个策略可以付诸于行动，那么真是太棒了。如果无法实现，我们只好将我们的维护策略集中服务于那些可以我们报酬的机构，它们可以用我们的产品，并还可以保证获得企业级的软件栈(software stack)；同时，我们还会继续保持开源，继续为社区提供卓越的软件。策略尽管并不是很完美，但我们相信我们现在所做的一切对于Spring的开源社区和那些需要SpringSource商业服务的机构来说达到了一个最佳的平衡。我们非常期待你的反馈，这样也会更加帮助我们去为社区做的更加出色。

 

 

 

不再玩更多的电话游戏(Telephone Game)[注１]

 

谁有更多的建议性意见可以通过论坛或发邮件给我，我会由衷的向你说声非常感谢。感谢你在Spring的这些问题上所给予的关注；感谢你花时间和我探讨和分享你的看法。请继续保持下去！

 

 

还有一个经验教训我要说的就是一定要让SpringSource，Spring团队以及Spring社区之间更加直接的交流。也许你玩过一个叫“电话游戏”小游戏，并且听说过这么一个有名的故事：

 

“在第一次世界大战时，一个将军需要传一个信息回司令部。他对他后面的人说：‘快发送增援请求，我们要前进了’。消息在行进的队伍中不断地向后传，最后它到达了总部，但是消息已经变成了‘发送三便士和四便士，我们正打算跳舞’。”

 

通过留言板和博客交流是很重要，但往往并不总是可靠的。

 

 

我非常希望有机会可以通过更好的方法与你交流思想。我已经采取了像在线聊天系统，日常开放电话会议等方式…..　Spring社区是属于你的社区，我知道你有更棒的想法…..

 

 

 

 

 

（全文完…..）

 

 

 

 

 

 

[注１]：也Chinese whispers。叫现在传话游戏在许多电视娱乐节目里很受欢迎，而且还有了个很好听的新名字“传声筒”，其实它也是一个非常经典的儿童游戏，在英语中叫做Chinese

whispers，从英文名字来看这个游戏是从中国传到国外的可能性很大哦。玩“传声筒”最大的乐趣就是一句话从前到后经过几个人的传递之后就走了样，经常产生意想不到的效果。