经营一家公司在至少一个方面就像编写代码一样：即使你知道自己想实现什么，你也不总是一次就能做好——但如果你愿意在必要时进行返工，最终确实会取得更好的结果。在SpringSource，我们对最近宣布的维护策略有一个清晰的愿景：在开源社区、企业用户和Spring的创造者之间取得平衡，以造福所有人。然而，我们第一次并没有完全达到平衡，现在是时候进行一些重构了。

在过去的几周里，我再次体会到了 Spring 社区的庞大以及其中许多人的热情。

我们一直认真倾听社区的反馈——不仅是从那些在公开论坛上最为活跃的声音，还包括通过许多渠道，例如私下交流和电子邮件。

在倾听社区意见的过程中，有两个问题尤为突出：当前 Spring 版本能否定期向社区提供稳定的发布版本（通过在 Spring 开源仓库中标记源代码来体现，即使不提供二进制文件）；以及面向小型企业和小型系统集成商的定价问题。我们知道人们对 Spring 软件和我们致力于改进企业 Java 的承诺感到非常满意；我们知道他们希望 SpringSource 取得成功并持续创新。但我们也听到了真实的担忧，并已将其纳入考量。

今天，我想重申我们对社区的承诺，以消除任何疑虑，并解释我们如何根据收到的反馈对维护策略进行重大调整。

我们的开源承诺

有些人担心 Spring 将不再是开源的。 “许可变更”这个说法被反复提及——尽管我们并没有更改任何 Spring 代码的许可。虽然这种猜测毫无根据，但仍然令人担忧。如果您获得了任何不同的印象，那么我和我的同事一定在沟通维护策略方面做得不够好——或者，您可能听到了不准确的二手信息。SpringSource 所做的一切都建立在 Spring 是开源的基础上，以及与社区的积极互动。首先，我们不会将 Spring 闭源，因为那样做是错误的。其次，我们明白鉴于 Spring 在许多，如果不是大多数，企业 Java 项目以及许多其他开源项目中扮演的核心角色，并且作为事实上的标准编程模型，其影响将严重损害企业 Java。第三，这将是一个愚蠢的商业决策。

我们对开源的承诺一如既往地坚定，并且在不断增长。我们期待在未来的几个月和几年里与社区携手合作，构建更多优秀软件。我们对 Spring Framework 3.0 和其他即将发布的开源版本感到兴奋，并为我们能够对开源进行越来越大的投入而感到自豪。

稳定的社区发布

我们最初的维护策略规定，在每个主要 Spring 版本发布 3 个月后，二进制发布版本将仅提供给 SpringSource Enterprise 客户，尽管源代码始终可用（但不带版本标签）。

因此，我们仅在主要版本发布 3 个月后改变了分发模式。我们仍然保留所有源代码，并遵守当前的许可。没有许可变更。

然而，社区中的一些人对发布 3 个月后仓库中将不再提供标签表示担忧。他们担心社区可用的二进制发布版本之间会存在一个延长的窗口期，而缺少标签可能会使得获取错误修复变得困难。一些人还担心不同 Spring 发行版之间可能出现的混淆，从而导致 Spring 社区内部沟通困难。

我们非常认真地对待这些担忧，并经过反思后决定，我们要超越用户的要求，以证明我们对社区——可能是企业 Java 中最重要的社区——的承诺，并确保它继续快速发展。

一旦我们发布了一个项目的候选版本，通常不会再向开源社区发布早期版本的标签或二进制构建。这些版本将提供给 SpringSource Enterprise 客户三年。

我们维护策略的一个关键目标是集中资源，大力推动 Spring 功能向前发展，并继续在企业 Java 开源领域发挥领导作用和进行创新。随着我们增加开发资源，我们旨在比以往任何时候都更快地前进，通过频繁的主要版本为社区带来新功能和能力。

例如，Spring 2.5.x 仍然是主干，因此根据这项策略修订，我们将很快向社区发布 Spring 2.5.6。Spring 3.0M1 将在之后不久发布，主干将用于 3.0 的开发。一旦我们发布 Spring 3.0 RC1，我们将不再为 2.5.x 分支提供标签或发布。我们将专注于 3.0 的开发，以便在第一个里程碑之后尽快发布 3.0。

我们为期 3 年的支持策略（以及 SpringSource Enterprise）为那些无法或不愿意频繁升级的企业客户提供了安心。将更多的社区开发精力集中在最新功能上，有利于开源用户。

小型企业定价

由于我们商业产品主要面向大型企业，一些小型公司产生了 SpringSource 不关心他们或不想与他们做生意的印象。事实并非如此——我们只是优先考虑了企业级订阅。但我可以理解人们为何会得出这样的结论，并为我们的定价结构造成了这种印象而道歉。

我们理解小型企业积极采用开源，并且它们对整体技术进步做出了重要贡献。因此，我们将推出一项新的产品，该产品专门为小型企业和小型 SI 设计和定价。这个博客不是描述具体商业产品的地方，但我们将在不久的将来发布有关新产品的信息。

公平的平衡

很明显，我们可以做得更好，主动与社区沟通，解释我们的做法和原因。

然而，理解我们制定维护策略的意图很重要。首先，我们从未有过维护策略，也不能永远这样下去，而不明确我们对社区和客户的承诺。作为一个公司，我们正试图对社区保持开放，而不是暗箱操作。有时这包括沟通其他公司可能会试图回避的令人不快的事实。其次，该策略旨在帮助我们从那些不与社区紧密合作、无法或不愿意定期升级到最新版本以帮助提升 Spring 质量的组织那里获得收入，而这些组织通过接收旧版本的维护更新来找到价值。这些类型的组织需要极其稳定的性能、世界一流的支持以及我们 Enterprise 产品套件提供的附加软件。

我们希望建立一家伟大的公司，能够支付我们才华横溢的开发人员薪资，获得合理的利润，并继续扩大我们对优秀开源软件的贡献。我们越成功，我们就能为 Spring 社区贡献越多优秀的代码。在过去两年里，我们随着增长，产生开源代码的能力增长得更快，结果也显而易见，过去 12 个月 Spring 下载量以及要求 Spring 专业知识的工作岗位创造数量都创了新高。

许多组织将从我们的 Enterprise 产品、技术支持和三年的定期维护发布中获得价值。我们也知道许多用户会选择不购买这些产品和服务。没关系。商业开源就是这样运作的。如果我们能继续增加我们对优秀软件的投资，每个人都会受益。

这是我 *希望* 能够实施的策略

如果您是一个通过在大型生产环境中使用 Spring 而从中获得巨大价值的组织，请向 SpringSource 支付您通过使用 Spring 所获得价值的 1% 的支票。我们将用这笔钱支付薪资，增加我们在开源方面的投资，并获得利润。

如果这样的策略能够实际运作，那将是极好的。但事实并非如此，因此我们制定了维护策略，旨在从那些在生产中使用 Spring 并要求其软件堆栈具有企业级保证的组织那里获得收入。与此同时，通过保持源代码的开放，我们继续为社区提供优秀软件。策略本质上是不完美的，但我们相信我们所选择的道路是在 Spring 开源社区的需求与 Spring 背后的开源业务需求之间取得的最佳平衡。而且，我们很高兴您的反馈帮助我们使其对社区更加有效。

没有更多传话游戏了？

对于那些在论坛或邮件中向我提出建设性意见的人，我想表示衷心的感谢。感谢您关心 Spring，并花时间思考这些问题；感谢您抽出时间陈述您的想法并与我分享。请继续保持！

我想从中得出的另一个教训是，努力实现 SpringSource 和 Spring 团队与 Spring 社区之间更直接的沟通。您可能玩过一个叫做 传话游戏 的派对游戏，并听说过那个著名的故事，关于英军前线的信息“增援已到，我们将发起进攻”经过多次传递后，在总部变成了“送来三个便士，我们要去跳舞”。信息在论坛和博客圈中的传播很重要，但不总是可靠。

我欢迎有机会听取您关于更好沟通方式的看法。我愿意接受诸如 IRC 聊天、定期公开电话会议等建议……这也是您的社区，我知道您有很多好主意……