Q&A with Rod Johnson over Spring's maintenance policy changes

This is the content of a Q&A I did with Rod Johnson, concerning the uproar over Spring's announced changes in their maintenance release publication. Hopefully, this clears up not only what's going on, but why.

1. Assume I'm a new user of Spring - I'm considering it for a green-field project. What license am I going to see?

   Spring remains licensed under the Apache License. There is no change of license. [Author's note: See "What does it MEAN?", from the ASL 2.0's FAQ page, on what the ASL says, in layman's terms.]

2. What does the enterprise support license offer me?

   Subscribers get maintenance releases on whichever version of the framework they are running, for up to 3 years. They also get 24x7 support, which isn't available in the community. Subscribers also receive the SpringSource Enterprise package, which consists of three significant value adds above Spring: the SpringSource Tool Suite (comprehensive Eclipse-based solution for optimizing Spring development); SpringSource Application Management Suite (advanced management and monitoring of Spring-based applications in development and production); and advanced connectivity to Oracle RAQ and AQ.

3. Now, for the more likely scenario: I'm a longtime user of Spring, I've downloaded every release up to 2.5.5. What am I going to see as far as the releases go?

   With each major version (3.0, 3.1, 4.0...) you will see packaged releases during the first 3 months. After that, you can build your own binaries if you wish to remain on that version--the source will remain open--or you can upgrade to the next major version when it's released.

4. How do I get the latest and greatest revision of Spring?

   Go through SpringFramework.org and download as you always did. [Author's note: this is exactly what the release policy is changing! Basically, if you're don't have the enterprise support license, the publicly available download might not be the same as the version the support license holders will see. The releases won't be the same if: a major release is more than three months old and updates are available for that major release.]

5. I use Maven - and as an enterprise customer of Spring, I have access to release versions that the community has to build manually. My customers may or may not be enterprise customers - so they might not have access to the same repositories I have access to. What happens to them?

   We are aware of this issue and will be helping our customers to resolve it.

6. Why did you make this change?

   We need to balance the needs of enterprise class customers with those of the open source community.

   SpringSource makes a huge investment in Spring development--millions of dollars per year. As more and more releases of Spring are used in production, we cannot divert resources for *free* maintenance of all those releases for conservative customers. We want to be able to focus our efforts for the community on adding new features--we can't afford to have conservative enterprises effectively subsidized by the community. The Federal government may subsidize Wall St: I don't think that SpringSource or the Spring community should be doing so.

   We put a lot of thought into how to balance these concerns, and I think we have a very good solution. This change enables us to serve both types of stakeholders. The community still has access to all the source. Enterprise customers are happy paying for enterprise support and maintenance--for them, having the guarantee of 3 year support is a strong reason in favor of using Spring.

   We believe that this will be good for our business. But we shouldn't have to apologize for that. I've always argued strongly that long term success of open source requires a strong revenue model behind it.

7. What would you say to those community members who've supported you throughout Spring's lifetime, and feel like you're cutting them off?

   We're concerned at any upset among the Spring community. But I do ask people to make a little effort to understand what we're doing and why we're doing it. I think we've earned that right.

   We are not cutting off the community. Our source code remains open. We continue to make a huge investment in providing what is probably the highest quality open source code base in enterprise Java. We've made something like 100 open source releases this year.

   The only people who are affected by this policy are those who won't or can't upgrade to the latest release, or won't compile Spring under any circumstances. Those people can pay to receive maintenance releases and many other benefits. People who won't touch source under any circumstances and won't pay under any circumstances don't believe in open source: They believe in other people doing work for them for free.

8. There are people suggesting that Spring be forked, basically taking the codebase and storing it elsewhere for patches, retaining the availability of the public revisions. There are some obvious difficulties with this: keeping compatibility for updates in the main Spring repository would necessarily make the forks almost identical to Spring itself, for example, and there's the obvious "sour grapes" feel to such a thing, but what are your opinions of a potential fork?

   Forks historically don’t tend to succeed, and aren’t in the best interests of open source projects, for obvious reasons.

   I think it would make sense to fork Spring if we were doing a poor job of stewardship of Spring. The reality is that we are delivering an enormous amount of new open source software, with a high quality level and a constant stream of innovation and new features. I don’t see anyone doing a better job, or even anything at remotely the same level.

   I think the community would see through it pretty quickly if a third party company attempted to set up a fork without doing the heavy lifting behind Spring. Will we see an Oracle or the like try to do that? I don’t think so, because I think it would backfire with the community while failing to deliver value to enterprise customers, who want support backed by the developers behind the software. I don’t think any credible software company is naïve enough to try something like that, or wants to incur the bad karma it would bring.

   I wouldn’t be surprised if we do see community builds out there, and they may fulfill a useful need for non enterprise-class customers.

   But above all, it’s hard to see a rational case for forking Spring when the Spring source code is available from the main repository.

Basically, the result is this: if you build Spring from the source repositories, you're always going to have the most recent version, with the most recent fixes. As Rod said: "People who won't touch source under any circumstances and won't pay under any circumstances don't believe in open source: They believe in other people doing work for them for free," and it looks like that's driving this decision more than anything else: an intent to leverage something of great value that they've given to the community.

It's hard to fault them for that.

If you want to know more, Spring has a FAQ on the maintenance policy changes online as well.