Spring's New Maintenance Policy
Just another vendor of a proprietary framework?
SpringSource, the company behind the popular Spring Framework has announced a new maintenance policy: SpringSource Enterprise Maintenance Policy, effective September 2008. After a lot of discussion in the community they have now added a Frequently Asked Questions document.
Spring Framework was originally created to overcome the limitations of Enterprise Java Beans (version 1 and 2) and make it easier to build J2EE applications. It has introduced dependency injection to a broad audience and changed the way many enterprise applications are built today. For many years it has been a vendor independant Open Source project available under the Apache Software License. Some time ago the creators of Spring Framework started their own company, received venture capital and things started to change. They've added new products like a new application server, bought Covalent and are looking for opportunities to gain some money.
In contrast to their new proprietary products which require a commercial license there has not been a real opportunity to make money from SpringFramework itself. Community support was fine, regular maintenance updates fixed the issues that were discovered and there was no need for commercial support. The recent announcement of their new maintenance policy seems to be their answer to that. They try to create a need for their support offerings. So the new policy basically states:
- Free maintenance updates will only be available for three months after a major release
- Maintenance releases will be available to paying customers under a commercial license for three years after a major release
- Bug fixes will be commited to a maintenance branch but minor releases will not be tagged after the three month period so the community will not know which versions are stable
Though the major releases will remain Open Source the bug free minor versions (three months later) will not. Spring Framework 2.0 was released in October 2006, Spring Framework 2.5 in November 2007 which means that the community will be without minor releases for more than 9 months if the frequency of their releases remains similar.
Sure, you can always build from the sources but this looks like a bad idea given that SpringSource refuses to tag consistent and tested versions.
I can understand the desire to make cash from SpringFramework but I am not sure this way will be successful. For me the products of SpringSource have lost their strong advantage of being vendor independant and fully Open Source. Upcoming projects will have to consider this fact and investigate alternatives.
Update 2008-10-08
SpringSource has listened to the community and updated its maintenance policy: A Question of Balance: Tuning the Maintenance Policy. They've dropped the 3 month window and will provide community releases from trunk for each version of Spring while it remains the trunk or until the next version is stable.References
Re: Spring's New Maintenance Policy
It’s bad for Spring popularity, so it’s bad for vacancies with Spring requirements.
There is also big thread about it:
http://www.theserverside.com/common/printthread.tss?thread_id=50727
Do You see good alternative for Spring?
Guice frozen. And It is only DI as many others.
May be next JEE version?
Re: Spring's New Maintenance Policy
What comes to my mind for DI is: Guice, JBoss Seam and EJB 3.1.
Spring Framework is more than just the DI container however, it provides some nice abstractions for JDBC (JdbcTemplate), remoting, javax.mail and a lot more. The "correct" way to address these needs is probably to fix the APIs themselves. With the tendency to keep everything backwards compatible this will prove difficult for at least the APIs owned by Sun (JDBC, javax.mail, ...).
I am not sure where this new direction of Spring Source will lead to but I think it push a lot of new and innovative ideas. We should remember that Spring Framework itself is the answer to the pain caused by EJB 1 and 2, so the question is what will be the answer to the pain we see now.