Craig Walls says the way the new SpringSource Enterprise Maintenance Policy impacts people like us (vendors whose product leverages The Spring Framework) is that basically we will have to build the binaries ourselves. Minor annoyance I suppose, but a pretty reasonable ask. I imagine the SpringSource resources are busy trying to actually make a buck. The powers that be probably took a look at where their resources are spending their time and decided to lose the free loaders. Can't fault them for that.
Some people are making a big deal out of this, with all sorts of machiavellian conspiracy theories bouncing around, but at the end of the day the framework is still a friendly open source license (Apache 2) and there is always the ability to fork if worse comes to worse. Charles miller makes an interesting suggestion of a semi-fork. The idea would be to create a mirror of the SpringSource repository, and provide a site where users can download tagged builds. I think for this to fly, you would need a keeper of the mirror, so you'd have to create an operating entity - I hereby propose the name "SpringHat". You know where this is going right? Could SpringHat offer consulting and maintenance too?
Seriously though, it does make me wonder what other changes are coming down the pipe from ever more commercial SpringSource. I am definitely starting to think about risk mitigation strategies.
I don't envy SpringSource's position. They've made a huge investment in developing an excellent framework and fostering a community around it. They are looking to leverage that, but finding the right balance between commercial goals and keeping the hearts and minds of fickle developers with an abundance of choice is a very difficult thing to do. Dustin Marx nails it when he says: