...Customers who are using SpringSource Enterprise, available under a subscription, will receive maintenance releases for three years from the general availability of a major new version. These customers receive ongoing, rapid patches as well as regular maintenance releases to address bugs, security vulnerabilities and usability issues, making SpringSource Enterprise the best option for production systems.After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. Subsequent maintenance releases will be available to SpringSource Enterprise customers. Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software...
This statement caused a large amount of discussion. Daniel Gredler speculated that the since fixes would still be contributed to the public source tree developers could still build their own releases from source. This was confirmed in a comment response by SpringSource's Mark Brewer. Given this InfoQ summarized the new policy as follows:
- The Spring source tree will remain public and open.
- SpringSource will continue to create official builds as needed for major and point releases.
- Enterprise customers will have access to all such builds.
- Open Source users will have access to such builds that occur within the first 3 months of a major release.
- The community can create builds but they are not officially supported by SpringSource.
InfoQ then asked SpringSource's Rod Johnson for comment on the new maintenance policy and our summary of the results:
With more and more releases of Spring used in production today, it’s impossible for SpringSource (or anyone else) to provide free, top quality maintenance of all those releases.The policy we have instituted serves the needs of the open source community, who want access to the latest source code, as well as the needs of conservative enterprise customers who require support on previous versions of Spring because they are unable or unwilling to follow the typical open source practice of upgrading to the latest release.
This policy doesn’t affect technologists who believe in open source. They can still access the source code that SpringSource employees are paid to develop. It only affects those who are unwilling to go near source code, or update to the latest version. For organizations with limited risk tolerance, the availability of 3 years of maintenance and 24x7 support from the source is a strong argument in favor of purchasing SpringSource Enterprise.
At SpringSource we are immensely proud of our contribution to open source. This extends beyond Spring: we’re also the leading contributors to Tomcat, the Apache HTTPD web server and involved in many other projects. We employ dozens of the most talented technologists in enterprise Java and we enable them to contribute to open source where many could not before.
Readers interested in the recent Spring announcement may also be interested in looking at Peter Mularien's recent analysis of Spring Core development and committers.
Community comments
New Revenue Stream
by Dave Rooney,
Compromise
by Geoffrey Wiseman,
Re: Compromise
by Rod Johnson,
New Revenue Stream
by Dave Rooney,
Your message is awaiting moderation. Thank you for participating in the discussion.
My experience over the past 4 years with Spring is that it's typically rock solid as soon as it goes GA. So, to me this just sounds like a new revenue stream for SpringSource. Maybe I'm just cynical.
What have others experienced?
Dave Rooney
Mayford Technologies
Compromise
by Geoffrey Wiseman,
Your message is awaiting moderation. Thank you for participating in the discussion.
This seems like a reasonable compromise, although I can't help but agree with those who argue that Spring is doing this work anyway, and not sharing it, so it's not about extra work, it's mostly about getting paid.
Re: Compromise
by Rod Johnson,
Your message is awaiting moderation. Thank you for participating in the discussion.
Note that we have amended the policy in a way that addresses the concerns some have raised about the initial policy. Any discussion should take that change into account.
@Dave, @Geoffrey: Yes, this policy is intended to further motivate enterprise users, who are unwilling to upgrade frequently (usually remaining on older versions when much of the broader open source community has moved on), usually do not contribute much if anything to the community, and need enterprise-grade SLAs, to subscribe to our SpringSource Enterprise product. Hitherto, such users have been subsidized by SpringSource, partly at the expense of the Spring community (because the more unpaid maintenance work we do, the less new work we do for the community). We believe the result is a fair balance--especially as risk-averse enterprises are generally happy to pay for software that is central to their stack. In their eyes, the availability of 3 year support for any given version of Spring is a major argument in favor of Spring.