经营企业至少在一点上类似于编写代码：即使你清楚自己想要实现什么，但第一次也不总是能做到完美，但如果你准备好根据需要重构，最终确实会得到更好的结果。在 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 质量）并相反地从接收旧版本的维护版本中获得价值的组织那里获得收入。这些类型的组织希望获得坚如磐石的稳定性、世界一流的支持 并重视我们企业产品套件提供的附加软件。

我们希望建立一家伟大的公司，能够支付其有才华的开发人员的薪水，获得合理的利润，并能够继续增加我们对优秀开源软件的贡献。我们越成功，我们就能为 Spring 社区贡献越多的优秀代码。在过去的两年里，我们的发展速度越来越快，我们生成开源代码的能力也随之提高，其结果不言而喻，在过去的 12 个月中，Spring 下载量和对 Spring 专业知识的需求都超过以往任何时候。

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

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

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

如果这样的策略在实践中有效就好了。但它不会，因此我们实施了维护策略，以从在生产中使用 Spring 并需要其软件堆栈中提供企业级保证的组织那里获得收入。同时，通过保持源代码开放，我们继续为社区提供优秀的软件。策略本身并不完美，但我们相信我们采取的路线是在 Spring 开源社区的需求和 Spring 背后的开源业务的需求之间取得最佳平衡的方案。而且，我们很高兴您的反馈帮助我们使其更好地为社区服务。

不再玩“传话游戏”？

对于在论坛或通过电子邮件向我提出建设性意见的人，我谨表示衷心的感谢。感谢您足够关心 Spring，以考虑这些问题；感谢您抽出时间写下您的想法并与我分享。请继续保持！

我从中学到的另一件事是，尝试在 SpringSource、Spring 团队和 Spring 社区之间实现更直接的沟通。你可能玩过一个叫做“传话游戏”（Telephone Game）的派对游戏，并且听说过一个著名的故事，讲的是英国军队中的一条来自前线的讯息“增援部队，我们即将发起进攻”，经过多次传递后到达总部时变成了“派三个四便士，我们要去跳舞”。在留言板和博客圈中进行沟通很重要，但并不总是可靠的。

我欢迎有机会听到您对改进沟通方式的想法。我乐于接受各种建议，例如 IRC 聊天会话、定期公开电话会议等等……这也是您的社区，我知道您有很多好主意……