SpringSource and the Lost Tag
SpringSource and the Lost Tag
Join the DZone community and get the full member experience.Join For Free
FlexNet Code Aware, a free scan tool for developers. Scan Java, NuGet, and NPM packages for open source security and open source license compliance issues.
For those who don’t know, how does it work? I will try to explain: SpringSource will develop and still make the source code available; they will also incorporate and render publicly available all the fixes. Where’s the catch then? The baselines. SpringSource will tag stable baselines for the first three months from the release of a new major version (e.g. 2.0, 2.5, etc.); after that, the next tags will be available only to paying customers. The next available tag for open source users will be the next major release.
I am not debating the objective of SpringSource making money from their flagship product. I am instead debating a number of other issues that arise from this:
- Changing the licensing terms on the run is, let me say, unfair. Either a product is open source or it is not. If it is, source code and tags must still be available. There are a lot of other ways of making money with enterprises: extra features available to paying customers only, priority support, customization, and possibly many others. Restricting a license is like a stab in the back: they let the cows pasture in the field and then lock them in within the fence.
- This episode stacks up to similar cases and is raising understandable doubts over open source adoption by small businesses. If enterprises have deep enough pockets to cater for an additional license, small companies with tight budgets may suffer from an unexpected cost for a framework that, one week before, was totally available for free.
- Other products / frameworks - what I said in the previous point might also create a valuable precedent for all those products currently released as open source but actually developed by real businesses: Alfresco, Liferay, GWT, Guice, etc. - if Spring Source’s model will succeed, we shall expect more of this.
- Raising an issue and problem determination will become a nightmare: with what “baseline” of Spring did the user encounter the problem? Were all the SVN commits applied?
- Spring ecosystem: there are other products that are heavily relying up on Spring, CXF and Liferay just to name a couple. How will this new policy affect their development? How shall they keep in sync with Spring tags? Shall they package their own release? Or what else?
I am fairly concerned about what has happened. Besides any consideration about Spring (I've used it only for IOC and transaction management), the consequences of this highly debatable move can be disastrous. I can only manifest my disapproval for an unfair choice that can be detrimental for the whole open source community.
I will keep track of the ongoing developments. In the meantime, I will have a look at Tapestry 5’s and Guice's IOC containers. I am sure they are providing most of the features for which Spring has been so much followed and praised.
Opinions expressed by DZone contributors are their own.