Hey Rod, You Are Killing Your Company
(Via The Fishbowl)
Unnamed PR firm for SpringSource: After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. Subsequent maintenance releases will be available to SpringSource Enterprise customers. Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software.
A lot of people have voiced their opinions about this policy, and an open revolt, a.k.a. a fork, is called for from open source advocates.
Rod Johnson and company is too smart to have not anticipated such reactions. The fact that they went ahead with the plan anyway indicates to me that they are pursuing some other goals. And the way words like "enterprise", "subscription" and "customers" are used indicates that it is money they are after.
I don't fault them for wanting to make money. It is wonderful to have paying customers for your software product, especially an open source one.
However, the policy of differentiating paying customers and community users by the releases that they may or may not receive simply goes against the grain of open source thinking. The community is rightfully "outraged." But we already know that they don't care.
The key here is the response from the paying customers. And I do think that they have some legitimate questions to ask:
- The extra patched releases that I receive after three months (but within three years), are they still open source? Can I redistribute it, with source, to the world?
- If what I receive is not open source anymore, have I been "bait-and-switched" into thinking that I'm going with open source when I selected Spring?
- SpringSource has taken the first steps of abandoning the open source community. Will the product lose its luster?
- Am I locked in? Will the subscription price go higher each year?
Once again, SpringSource is too smart to have not thought about these, and the effects on their open-source-oriented customers (that they will be gone).
That leaves only their paying customers who don't care about the open source thing that much.
Even for them, there are still some key questions:
- I know we don't care about open source. But SpringSource ought to care, they are, after all, an open source company. Why are they alienating their own community?
- They must be desperate for money. How long can they last?
- What if my biggest competitor bought SpringSource?
I'm sure Rod Johnson and company has good answers to all of the above questions.
Re: Hey Rod, You Are Killing Your Company
The extra patched releases that I receive after three months (but within three years), are they still open source? Can I redistribute it, with source, to the world?Nothing in the press release or what I've seen from the SpringSource folks said that the license is changing (and Rod & co have repeatedly asserted that it won't). And since the patches are going in the main source, they will obviously be ASL as well. So unless there's some reading of the ASL I'm not aware of, the answer to your question is "Of course." Which would seem to answer the other questions as well...
Re: Hey Rod, You Are Killing Your Company
Under what license are the SpringSource Enterprise maintenance releases distributed? The SpringSource Enterprise maintenance releases are distributed under our commercial license […]
And also:
I redistribute Spring in my closed source product. How does this policy affect me? You can redistribute up to the last community release in that branch or redistribute your own patched versions of Spring compiled from the source tree. […]
One more try, please :-)
Do you know the difference between "maintenance release" and "maintenance patch"?
Its just like when I needed a binary release of a python library that linked up with Oracle's drivers. Somebody was making binary releases conveniently, but not for my platform. Was he giving me the finger by not supporting my platform? Heck no! He did his best to distribute his project, but he couldn't distribute to EVERYTHING. Is Spring supposed to backport to everything to every version they ever release? Or should they focus their resources to working on new features, and releasing those to us, as their policy says they will (while still making special binary releases to paying customers that can't upgrade yet?)
For the record, I am the project lead for Spring Python, a Spring Extension. However, I do NOT work for SpringSource nor receive a nickel of their money (or from their VC).
Do you know the difference between "maintenance release" and "maintenance patch"?
Yes, I do know the difference between "release" and "patch". I work for a company that support open source software.
What I'm trying to point out is that the new policy actually *discourages* the adoption of the SpringFramework by non-paying customers.
Say I'm starting an open source project and I choose to use a just released version of Spring, version x.y. 0. And 95 days into the project, I found a bug, fixed it, and sent a patch to SpringSource.
Under normal open source protocols, the patch will be reviewed and either applied or rejected. Let's say, it was accepted and the patch is applied to the x.y tree.
According to the new policy, I won't get a release. I understand that because I'm not a paying customer.
Let's assume 60 days from the day my patch went into the x.y tree, a paying customer also found a bug, a patch is submitted and, because it's from a paying customer, a new release, x.y.1 is made.
Under the new policy, there is no way I can get this release x.y.1 without becoming a paid customer of SpringSource, even though it has my patch in it, and is what I want.
That simply goes against the open source spirit.