The news today, 190 days before April 1st, is that SpringSource has changed their policy for distributing patch releases. From now on, they will only be making patch releases available to non-paying customers up to three months after the release of the major version being patched.
- Three months after the release of a major version of Spring, it will no longer have patch releases made available publicly
- All fixes will continue to be committed to the public source repository and
- paying customers will have access to later point-releases, but
- those releases will not be tagged publicly
On the face of things, this seems more than a little petty. The most common reason for having an End of Life policy is to save money supporting old versions, but given these releases are being made anyway, how much time and money are you saving by not tagging something in CVS?
It makes more sense when you consider that the reasoning is not to save money but to make it. This decision is aimed at people like us1. People who who through the necessity of having to ship software can't keep up with the bleeding edge, and certainly can't afford to upgrade a major component of our application every three months, but at the same time haven't felt the need to buy enterprise-level support.
You can't begrudge people their right to make a bit of cash, especially when your pay-cheque comes from selling software built on top of their library. Still, it doesn't feel entirely right either.
I think the problem is that "professional open source" changes the language of open source software.
To a young open source project, downloads are king. You proudly proclaim on your website “Downloaded over 100,000 times this month.” People who use your software are your community, the reason for your project existing in the first place. And you know that some admittedly small percentage of those users will answer a few questions on the forums, or suggest a cool new feature, or even contribute a patch. Then when you quit your day job to run the project, the size of the community is what gives you a market into which to sell your support and consulting.
Then the language changes, often around the time the outside investors show up. The people who are downloading and using your software are no longer your community, they're the ones who are taking your code without giving anything back. They're the free-loaders. Or, to quote Rod Johnson in the Server Side thread:
SpringSource continues to expose our open source code, which costs us millions of dollars annually to develop. This policy does affect users who think that open source is a way for them to get extended maintenance of high quality enterprise software for free, without them lifting a finger.
You are doing work, and you deserve to get paid for that work especially if someone else is making a profit off your back. It's a perfectly valid point of view. It's the point of view behind every commercial software release. But it's the language of a commercial vendor talking about piracy, or a shareware author about why so few people register. It's a π radian turn from the reason you originally chose the Apache or BSD license for your project rather than, say, dual-licensing under the GPL.
The obvious response is a semi-fork. The source is still there and still Apache-licensed, so if the community is interested they can maintain an alt-spring vendor branch and tag off new releases themselves every so often. If demand for patch releases is high enough this will happen almost inevitably, so long as SpringSource keep their promise to keep everything in public CVS.
1 I do not speak for Atlassian.
This would be a good time to set up a mirror via Github, then we could create our own tags and backports.
"All fixes will continue to be committed to the public source repository" and "those releases will not be tagged publicly"
What *exactly* does this mean -- will there be an x.y branch, but no x.y.z tags, or will the only public availability of fixes be on trunk, meaning that they need to be backported to the x.y.(3 months) version?
@Tom: My understanding from reading the thread is that the fixes will be applied to the branch, they just won't tag the points at which they make a stable release.
I could be wrong, though.
The strange thing about this move is it seems it'll actually be _more_ work for them in the end, even though they are selling it like they don't want to do all this work for free. In addition to having a separate way to tag releases, you'll need a new Maven repo and separate release process to push the releases to it.
I've written a few thoughts about this. They should really split off the part of the organisation that maintains the open source code: SpringSource has a new business model.
Don,
You glossed over the bit explaining why Atlassian--an apparently highly successful closed source software vendor--has the right to expect SpringSource to subsidize it, by maintaining the older versions it needs to ship to its paying customers.
Rgds
Rod
Rod: that's exactly the change of language that I was talking about in the article. Seemingly overnight, a wide range of Spring-based applications have gone from being "Spring success stories" to being rather contemptible leeches.
(I don't want to make this about Atlassian because as I said above, I don't speak for the company. I will, however, note that before there even was a SpringSource, Atlassian was donating both software and hardware to host Spring project infrastructure.)
Charles,
Don brought Atlassian into it, not I.
Where did I say that Atlassian were "contemptible leeches?" I'm glad you are a successful company. However, I think you're taking a short term view on this issue. I would hope that you would stop and consider whether your success would have been possible at the same rate and development cost without Spring, and reflect that the maintenance costs that SpringSource incurs maintaining those old releases must be substantial.
Rgds
Rod
@Rod Hold up, when I said "we", I was meaning the Open Source community, not Atlassian. Like Charles, I don't attempt to speak for Atlassian and frankly, find myself an Open Source community member first, Atlassian employee second.
What I was getting at is the community, be it Open Source or commercial, will have the need for maintenance releases past the 3 month window for security fixes, if nothing else, so setting something up at Github, which encourages forking as a healthy aspect to Open Source development, seems like a good fit. Sure, the releases wouldn't be called "Spring" as I'm guessing that's trademarked, however, that just means everyone wins - teams that have a limited budget can use the forked releases, and companies that need the support and official stamp of SpringSource can use your product.
But say someone like Atlassian did decide to purchase SpringSource Enterprise...we give our source code away to paying customers and generally make everything available on the net as possible. Since the maintenance releases don't have any sort of license associated with them, what would stop an Atlassian customer from building Confluence, say, which brought down the Spring jar from our protected servers, then using that in their internal projects? What could Atlassian possibly do to prevent that?
It's a hard problem, making money off an Open Source product, and speaking as an ASF guy and Atlassian employee, I completely support the idea; it is the details that get tricky :)