经营一家公司至少有一点像写代码：你不会总是第一次就做对，即使你知道想要达到什么目标——但是如果你准备好在必要时重做一些事情，最终你确实会得到更好的结果。在 SpringSource，我们对最近宣布的维护策略有一个清晰的愿景：平衡开源社区、企业用户和 Spring 创作者的需求，使所有人受益。然而，我们第一次做得不够平衡，现在是时候进行一些重构了。

在过去的几周里，我再次意识到 Spring 社区的规模及其众多成员的热情。

我们一直在认真听取社区的反馈——不仅是公共论坛上最活跃的声音，还通过许多渠道，包括私人对话和电子邮件。

在听取社区意见时，两个问题突出出来：Spring 当前版本定期稳定发布的社区可用性（如果未提供二进制文件，通过在 Spring 开源仓库中对源代码打标签的请求表达出来）；以及面向小型企业和小型系统集成商的定价。我们知道人们对 Spring 软件以及我们改进企业级 Java 的承诺感到满意；我们知道他们希望 SpringSource 取得成功并持续创新。但我们听到了真正的担忧，并将其认真对待。

今天，我想向任何可能心存疑虑的人重申我们对社区的承诺，并解释我们如何根据收到的反馈对维护策略做出重大调整。

我们的开源承诺

有些人表达了对 Spring 将不再开源的担忧。“许可证变更”这个词被不断提及——尽管事实上我们并未更改任何 Spring 代码的许可证。虽然这种猜测毫无根据，但它仍然令人担忧。如果你得到了任何不同的印象，那肯定是我的同事和我未能很好地传达我们的维护策略——或者，也许你听到了不准确的二手信息。SpringSource 所做的一切都基于 Spring 的开源性质以及与社区的积极互动。首先，我们不会让 Spring 闭源，因为这样做是错误的。其次，我们理解，鉴于 Spring 在许多（如果不是大多数）企业级 Java 项目以及许多其他开源项目中的核心作用，以及作为事实上的标准编程模型，这样做会对企业级 Java 造成重大损害。第三，这将是一个愚蠢的商业决策。

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

稳定的社区发布版本

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

因此，我们只改变了主要版本发布后 3 个月之外的分发模式。我们仍然根据现有许可证保留了所有源代码。没有许可证变更。

然而，社区中的一些人对 3 个月后仓库中将不再提供标签的事实表示担忧。他们担心社区可用的二进制发布版本之间的时间窗口过长，因为没有标签可能难以获取错误修复。一些人还担心不同 Spring 发行版之间可能造成的混淆，从而使 Spring 社区之间的沟通变得困难。

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

一旦我们发布了项目新版本的候选发布版本，我们通常将不再向开源社区发布该项目早期版本的进一步标签或二进制构建。此类发布版本将为 SpringSource 企业版客户提供三年支持。

我们维护策略的一个关键目标是集中资源大力推动 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。

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

小型企业定价

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

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

公平的平衡

显然，我们在与社区沟通、解释我们在做什么以及为什么有必要这样做方面可以做得更好。

然而，重要的是要理解我们制定维护策略的意图。首先，我们以前从未有过维护策略，不可能永远不明确我们对社区和客户的承诺。作为一家公司，我们正努力对社区保持开放，而不是秘密行事。有时这涉及沟通一些不受欢迎的事实，其他公司可能会试图回避。其次，此策略旨在帮助我们从那些不会与社区紧密互动、不能或不愿定期升级到最新版本以帮助提升 Spring 质量，而是在旧版本上通过接收维护版本找到价值的组织那里产生收入。这类组织需要坚如磐石的稳定性、世界一流的支持以及我们企业产品套件提供的额外软件。

我们希望建立一家伟大的公司，能够支付优秀开发人员的薪水，获得合理的利润，并继续增加我们对优秀开源软件的贡献。我们越成功，就能为 Spring 社区贡献越多的优秀代码。在过去两年中，我们的开源代码生成能力增长得更快，成果斐然，过去 12 个月内的 Spring 下载量以及需要 Spring 专业知识的工作岗位数量都创下历史新高。

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

这是我希望我们能够实施的政策

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

如果这样的政策能够实际可行就好了。但它不可行，因此我们制定了维护策略，以便从那些在生产环境中使用 Spring 并需要企业级软件堆栈保障的组织那里产生收入。同时，通过保持源代码开放，我们继续为社区提供优秀的软件。政策本身并非完美，但我们相信我们所采取的路线是 Spring 开源社区需求与 Spring 背后的开源业务需求之间的最佳平衡。而且，我们很高兴您的反馈帮助我们使其更好地服务于社区。

不再玩传话游戏？

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

从中我想汲取的另一个教训是，努力实现 SpringSource 和 Spring 团队与 Spring 社区之间更直接的沟通。你可能玩过一种叫做传话游戏的聚会游戏，并听说过那个著名的故事：英国军队前线发出的信息“派增援，我们要进攻了”经过多次传递后到达总部变成了“派三和四便士，我们要去跳舞”。消息板和博客圈的沟通很重要，但并不总是可靠。

我很乐意听取关于更好沟通方式的建议。我接受各种建议，比如 IRC 聊天会话、定期的开放电话会议……这也是你的社区，我知道你有很多好主意……