Community Reacts to SpringSource Changes, CEO Rod Johnson Provides Clarification
...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.
New Revenue Stream
What have others experienced?
@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.