|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 250
Messages: 250
Messages: 250
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
New Spring maintenance policy
Looks like we'll need to buy support on Spring to get ongoing bug fixes. I just saw that SpringSource formalized a maintenance policy http://www.springsource.com/node/558 for Spring and we'll now need to buy commercial support if we want maintenance releases after a new release is out for 3 months. I know other open source companies do this, but that's some big news for Spring.
[Editor: following excerpted from the news release]
SAN MATEO, Calif.—September 17, 2008 – SpringSource, the company behind Spring, the de facto standard in enterprise Java, today announced that it has implemented a new maintenance policy for Spring. The policy provides Spring production users with a long-term, stable application platform to build, run and manage their Spring-powered applications.
Customers who are using SpringSource Enterprise, available under a subscription, will receive maintenance releases for three years from the general availability of a major new version. These customers receive ongoing, rapid patches as well as regular maintenance releases to address bugs, security vulnerabilities and usability issues, making SpringSource Enterprise the best option for production systems.
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 . . .
|
|
|
Message #268860
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How about Bug in their Website?!
Thanks for that,
I don't know if we also need to pay more money to make this work, but following your URL onto the "News and Events" page I got some nasty error message from SpringSource site:
---
user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DESC LIMIT 0, 10' at line 1 query: SELECT DISTINCT(node.nid), field_date_value, node.title AS node_title, node.changed AS node_changed, node_data_field_date.field_date_value AS node_data_field_date_field_date_value FROM node node INNER JOIN node_access na ON na.nid = node.nid WHERE (na.grant_view >= 1 AND ((na.gid = 0 AND na.realm = 'all') OR (na.gid = 1 AND na.realm = 'workflow_access') OR (na.gid = 0 AND na.realm = 'workflow_access_owner'))) AND ( (node.status = '1') AND (node.type IN ('press_release')) ) ORDER BY DESC LIMIT 0, 10 in /var/www/domains/springsource.com/www/drupal/current/includes/database.mysql.inc on line 172.
---
Maybe SpringSource instead of Sun had better bought MySQL ??!
See
http://www.springsource.com/newsandevents
unless they fixed it?
At least I am not the only one using Drupal ;-)
|
|
|
Message #268861
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How about Bug in their Website?!
The link worked for me several times, Werner. Maybe they're only supporting IE <grin>.
|
|
|
Message #268863
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How about Bug in their Website?!
The link doesn't work in IE or Firefox for me. Only difference is that in IE the error message text is missing.
Must say that I find it slightly amusing that the Spring guys expose the SQL and their domain model to the user when an error, or maybe they can blame Drupal? :-)
/Ragnar
|
|
|
Message #268869
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A little disappointed
I realise that enterprises based on Open Source models have to make their money somehow, but it always makes me a little sad when I see announcements like this. The community helps build the product and then they get priced out of some of the benefits? It seems a shame that potentially useful fixes won't make it back to the community after that initial 3 months.
|
|
|
Message #268870
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What about licensing of maintenance releases?
Does that mean that the maintenance patches would be released under a proprietary license other than Apache 2? If it is a proprietary license then it may impose restrictions for ISVs who distribute Spring as a part of their product. Will there be a different licensing model for those ISVs?
Say for example, I have a product released under Apache 2 and I distribute Spring as a part of my product. Depending upon the SpringSource maintenance license I may not be able to provide free support (under Apache 2 license) for my product if changes to my product involve the fixes of Spring.
Can someone explain the implications in details?
|
|
|
Message #268872
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
You're either open source or you're not
The press release reads:
"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."
I think this is disgraceful. This is an open source product, built, improved and used by the community. It is distributed under the Apache license, version 2.0, which reads
"2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form."
It also states:
"4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, ..."
So, I dont see how they can make this work, both legally and practically. Their updated sources will be available in public source repositories and it seems unlikely that they can prevent anyone from legally publishing any of those "commercial patches" to the community.
However, the license also states
"You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License."
I guess a patch could be considered a derivative work, even though that is stretching the term a little. Not sure how the jurisprudence on this is. It is certainly stretching the spirit of the license beyond breaking point.
But it is clear that all those who are betting their applications and companies on Spring and therefore it's open source nature, have now gotten a head's up that this may be a mistake. The greedy boys have come to town!
Cheers,
Marc
|
|
|
Message #268873
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: You're either open source or you're not
Sounds like they're encouraging everyone to try Seam.
|
|
|
Message #268874
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: You're either open source or you're not
The world isn't black/white. From first hand experience, many users of open source projects are free loaders, who never contribute a line of code. I can understand why spring and redhat do what they do, even if I don't necessarily agree with the approach.
those who have never contributed code to a project and then complain the access to the software is getting expensive should suck it up and pay for a subscription. Many OSS developer do it out of love of coding, and want to do it for a living. I'm not one of those, but they should have the freedom to do that. Plus, the code is there. If you need a patch urgently, then patch it yourself or pay for it.
for those who contribute to a project and don't like paying for a subscription, it sucks a bit. There's all kinds of open source.
|
|
|
Message #268876
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: You're either open source or you're not
There are certainly all kinds of open-source. Spring was one kind of open-source project - a project that became successful in part because it provided free and timely updates.
Now, apparently, Spring is a different kind of open-source project - a project that requires users to pay for support if they want a guarantee of timely updates.
On the surface that seems like a pretty big and very disappointing switch.
Chris
Spring free loader
(And author of POJOs in Action, ...)
www.chrisrichardson.net
|
|
|
Message #268877
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What does it mean?
Let's say Spring 3.0 GA is out, and we get 3.0.x releases for three months. After three months and a day let's say Spring 3.0.5 is out - will it be unavailable for the community? Will we have to wait for Spring 3.1 or Spring 4 after that? Or does it simply mean that after no more than three months 3.1 will be out and we will get 3.1.x releases, but only commercial customers will get 3.0.x releases?
If the former is true, than it's turning the back to the community, meaning a non-paying customer may get stuck with a bugged release of Spring, even though a fixed release exists for paying customers.
If the latter is true then I don't think it's such a bad thing, as maintaining old releases consumes resources which would otherwise be used to advance Spring and add new features, and therefore it actually hurts the community. If customers insist on staying with 3.0.1 instead of upgrading to 3.1 for example, they should pay the price for the extra work that SpringSource does to allow it.
I think a SpringSource representative should clear this up.
Gabriel
|
|
|
Message #268878
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: You're either open source or you're not
Of course, I don't know any unpublished details about SpringSource's new maintenance policy (I've read the notices on SpringSource's website), but I can take a guess about how they might handle the licensing aspect.
After SpringSource releases a new major version and three months have passed, they can produce further maintenance updates under an alternate (non-Apache) license to their subscription customers.
Cheers,
David
Flux - Java Job Scheduler. File Transfer. Workflow.
|
|
|
Message #268879
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: You're either open source or you're not
those who have never contributed code to a project and then complain the access to the software is getting expensive should suck it up and pay for a subscription.
There are many ways to contribute: by committing code, testing and reporting bugs, writing documentation, providing help in forums, writing plugins etc.
The fact that a person does not directly code the software doesn't mean he/she doesn't help the project and can be considered as a member in the community.
If the only people who contribute code would have a moral legitimation to get the software for free, then open source would be meaningless - it would be like writing a proprietary code inside your own company which is to be used only for your products. That's what the "open" in open source is all about.
I do agree that customers who want enterprise-level support should pay for it, but withholding code which exists (and possibly was written by a member of the community) from the community is not the right thing to do in my opinion.
Gabriel
|
|
|
Message #268880
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What does it mean?
Let's say Spring 3.0 GA is out, and we get 3.0.x releases for three months. After three months and a day let's say Spring 3.0.5 is out - will it be unavailable for the community? Will we have to wait for Spring 3.1 or Spring 4 after that? Or does it simply mean that after no more than three months 3.1 will be out and we will get 3.1.x releases, but only commercial customers will get 3.0.x releases?
That's what it sounds like to me. Basically, they're keeping two trees -- the internal tree, and the external, public tree.
For 3 months, they'll keep the two in sync. After that, they only have the internal tree which is distributed to their commercial clients. In theory it would have to be distributed under a closed license to their clients, otherwise the clients may well release the changes (though, more than likely not).
Basically, what they're doing by this is saying that the community isn't doing anything for them any more. Because it would be a bit mad for someone to contribute a change that they're not going to get back, isn't it?
So, all of the development (and copyrights) remain in house and they control distribution from here on out.
|
|
|
Message #268886
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What does it mean?
Yes, the community will receive any set of fixes (i.e. 3.0.1, 3.0.2, etc.) that are made during the first three months after a major release. From that point forward, until a new major release (which means a change in the number on either side of the first decimial point - 3.1 or 4.0 would both apply), only SpringSource Enterprise customers will receive further maintenance releases. However, the code for fixes will be in the public open source tree.
As Gabriel points out, Enterprise customers will have the added benefit of 3 years of support for any major version that they are running.
|
|
|
Message #268887
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The scariest thing
No comment from anybody at SpringSource so far...
I responded just a few minutes ago ... and I work for SpringSource.
Mark Brewer
|
|
|
Message #268896
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What does it mean?
Hi Mark,
However, the code for fixes will be in the public open source tree.
So what is the difference other than the commercial version is packaged, patched, distributed and supported for paying customers?
I would assume you are trying to reduce operating costs with this move and only committing to the additional effort when it is paid for by subscriptions. What is the organizational effort in having both minor & major release streams for the community and customers? Is the effort so great that it consumes a significant amount of the company's revenue which apparently has doubled this year.
SpringSource Grows Business Over 250 Percent
http://www.springsource.com/node/549
William
|
|
|
Message #268897
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What does it mean?
Yes, the community will receive any set of fixes (i.e. 3.0.1, 3.0.2, etc.) that are made during the first three months after a major release. From that point forward, until a new major release (which means a change in the number on either side of the first decimial point - 3.1 or 4.0 would both apply), only SpringSource Enterprise customers will receive further maintenance releases.
You do realize that that policy would make the current Spring 2.5 branch unusable if it was applied to that branch? Then most of us would be using Spring 2.5.1, and not the current 2.5.5.
What will be the policy for how often a new major release will be available?
What will be the policy for new features? Does this mean that all new features always go into a new major release?
/Magnus
|
|
|
Message #268908
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The end of a over-hyped framework
I have to admit that until yesterday I was ranting with my colleagues; my company wants the legal department to have the last word, when a product is making use of open source libraries and frameworks. Now I understand that.
Thanks SpringSource for contributing in taking your framework out of the market, and thanks for increasing the mistrust companies in general have towards open source.
Who knows, maybe Tapestry 5, after receiving so many insults, will suddenly become trendy? Will its IOC container be the next must-have-in-my-cv technology?
Just one last question - how will SpringSource merge the non-opensource license fixes with the opensource ones when developing the next major release? Will be interesting to know.
|
|
|
Message #269093
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: More than a little disappointed
Such are the perils of commercial, company-driven, vc-founded 'open' source. However there is a positive aspect in this move. The unfounded, marketing-driven ("the de facto standard in enterprise Java") Spring hype is definitely over. Great!
|
|
|
Message #269204
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: More than a little disappointed
+1
The hype is over and in a few weeks everybody will start pointing at how bad and bloated Spring was. Such is the life of software engineers following trends.
|
|
|
Message #269232
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Fork?
I think you share the same concern of many developers.
I am not a legal man, but I believe that if Spring, holding an open source license, begins incorporating amendments released under a commercial license, then it cannot hold an OS license anymore.
|
|
|
Message #269313
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Also highly disappointed
I cannot believe Spring would go this route. I've been a firm Spring supporter in my company and with my clients. It's an excellent platform but this just makes me very sad.
Mark Brewer brought up an interesting point though. If fixes are in the public source, what's the difference between me building a new version (or grabbing a nightly build) versus what an Enterprise customer would get?
Right now I monitor and watch all incoming commits to Spring, partly for my own edification, and also to see progress here: http://fisheye1.atlassian.com/viewrep/springframework/
Will the Enterprise customers still get the same code from this repo?
I noticed Spring 3.0 is not being actively worked on in any public repository. It seems the Spring 3.0 development has been very secretive and less transparent than any other version previously. No JIRA issues for 3.0M1 have been resolved and no code committed on the public repo.
I just hope I can still be a champion for Spring both internally at my company and with clients after this change.
Grant
Vodori Inc.
|
|
|
Message #269378
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Clarification
What the maintenance policy will mean to you:
For the open source community: If you are happy to track the latest major release of Spring (e.g. 3.0, 3.1 or 4.0), all fixes go into the next major release. You get all the latest features and up-to-date fixes--what you would expect from any healthy open source project.
For enterprise production users: If you are an enterprise customer that cannot or will not regularly upgrade to the latest release--that is, your use of open source differs from normal open source culture of following the latest release--you can subscribe to our SpringSource Enterprise products. By doing this you help to ensure that innovation continues to be available to the community. Given that such customers have little tolerance for risk, running open source in the core of their applications without support makes no sense anyway.
As the number of versions of Spring used in production grows, it is impossible for us to provide free maintenance for multiple releases and perform backports of issues. Doing so would unfairly subsidize conservative customers who want to remain on a previous version, at the cost of the open source community.
SpringSource contributes a huge and growing amount of open source to the community. Check out the around one hundred releases this year across the many open source projects we are involved in. Providing a clear maintenance policy will ensure that we can continue to do so.
Rod Johnson, Spring Founder & CEO, SpringSource
|
|
|
Message #269398
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What does it mean?
Yes, the community will receive any set of fixes (i.e. 3.0.1, 3.0.2, etc.) that are made during the first three months after a major release. From that point forward, until a new major release (which means a change in the number on either side of the first decimial point - 3.1 or 4.0 would both apply), only SpringSource Enterprise customers will receive further maintenance releases. However, the code for fixes will be in the public open source tree.
As Gabriel points out, Enterprise customers will have the added benefit of 3 years of support for any major version that they are running.
Actually, I can live with that. In our use, Iwehaven't encountered any major bugs and only upgraded to major releases anyway.
Even then, we tested the release and only deployed if we didn't have any issues.
So, <Shrug>, just looks like a play to demostrate value-add to paying customers. I got no beef with it.
|
|
|
Message #269399
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: More than a little disappointed
+1
The hype is over and in a few weeks everybody will start pointing at how bad and bloated Spring was. Such is the life of software engineers following trends.
The only ones who will complain are
1) The people who don't like Spring anyway. "Hype" is a term coined by people who think they are smarter than everyone else. As if everyone else isn't intelligent enough to understand if they need something like Spring or not. In other words, they won't be missed.
2)People who don't seem to get the gist of the policy. How many here just drop major releases the day they are released without testing them. If you upgrade, test it. If you find a problem, within 3 months, there's a good possiblity that it will get fixed.
If that version doesn't get fixed, wait until the next version. How big of a difference will there be between say 2.5 and 2.6? Probably not much.
This doesn't seem like a big deal to me.
|
|
|
Message #269400
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: How Open Source is Spring? An Analytical Investigation
Thanks for the link.
Just to clarify - my objective analysis (which you can view through the link) was done (ironically) before I knew anything about this announcement.
There is discussion in my blog entry about where Spring 3.0 is, and once again I would like to thank Juergen for his help.
|
|
|
Message #269401
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Clarification
your use of open source differs from normal open source culture of following the latest release--you can subscribe to our SpringSource Enterprise products. By doing this you help to ensure that innovation continues to be available to the community. Given that such customers have little tolerance for risk, running open source in the core of their applications without support makes no sense anyway.
This is a good point, and understandable. It's something I've seen with at least one client already (who ironically went to a third-party -- not SpringSource -- for support with Spring).
|
|
|
Message #269402
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Clarification
Rod,
I don't have a problem with you not supporting older releases for free. I prefer to use the latest and greatest.
What I do have a problem with is charging for access to the minor releases (or the bug fixes therein) that occur 3 months after the major release.
As someone pointed our earlier on this thread, 2.5 was released on 2007-11-19 so presumably under this new policy releases 2.5.3 onwards would not be freely available.
IMHO this is not what Spring has been about for all of these years. A key attribute of an open-source product is the willingness and ability of the project's committers to quickly make fixes freely available. It's disappointing that the corporate desire for profit has led to this switch to this pseudo open-source model.
Chris
|
|
|
Message #269403
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Clarification
What the maintenance policy will mean to you:
For the open source community: If you are happy to track the latest major release of Spring (e.g. 3.0, 3.1 or 4.0), all fixes go into the next major release. You get all the latest features and up-to-date fixes--what you would expect from any healthy open source project.
For enterprise production users: If you are an enterprise customer that cannot or will not regularly upgrade to the latest release--that is, your use of open source differs from normal open source culture of following the latest release--you can subscribe to our SpringSource Enterprise products. By doing this you help to ensure that innovation continues to be available to the community. Given that such customers have little tolerance for risk, running open source in the core of their applications without support makes no sense anyway.
As the number of versions of Spring used in production grows, it is impossible for us to provide free maintenance for multiple releases and perform backports of issues. Doing so would unfairly subsidize conservative customers who want to remain on a previous version, at the cost of the open source community.
SpringSource contributes a huge and growing amount of open source to the community. Check out the around one hundred releases this year across the many open source projects we are involved in. Providing a clear maintenance policy will ensure that we can continue to do so.
Rod Johnson, Spring Founder & CEO, SpringSource
Rod, I personally would like the following to be clarified instead:
- How will SpringSource manage the inclusion of commercial-license fixes into the publicly available one, without affecting the license, right to redistribute, etc.
- How will Spring users be reassured that no license changes will occur, such to require licenses to be purchased in order to use Spring within their own applications;
- If and how the license is preventing the community from forking the Spring framework project.
Thanks
|
|
|
Message #269405
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Clarification
Rod,
I don't have a problem with you not supporting older releases for free. I prefer to use the latest and greatest.
What I do have a problem with is charging for access to the minor releases (or the bug fixes therein) that occur 3 months after the major release.
It seems to me that the policy wording does not match what Rod said. The policy says: "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."
I believe that to match Rod's clarification it should say the following instead: "After a new major version of Spring is released, community maintenance updates to the previous version will be issued for three months. Subsequent maintenance releases to all versions except the current release will be available to SpringSource Enterprise customers."
|
|
|
Message #269404
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Clarification
Thanks for the clarification Rod,
As I wrote earlier I completely agree with the logic that commercial costumers who refuse to upgrade to the newest major releases shouldn't cause SpringSource to consume resources to provide support for them for free at the expanse of writing the next major release.
However I think there is a better way to implement this. If three months after a major release a new bug is found but the next major release is not finished, the community will be stuck with a knows bug and a fix which is available only to paying costumers. Instead I suggest this alternative policy: minor releases will be available to the community exactly until the next major release, be it a week or a year. This way no one will be in danger of being left with no fix to a bug at any time and everyone stays happy.
Gabriel
|
|
|
Message #269406
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thank You Sir, may I have another?
As far as the announcement goes, they are repeating other companies' mistakes by the book - fascinating to see. Not only is it questionable to ship bug fixes to "enterprise" customers first without greater exposure to the larger world (remember: other people can program and find bugs too!); accelerated deployment cycles are usually the *last* thing that paying customers want because most already have enough problems on their own. MySQL did exactly the same, the whole thing backfired spectactularly and people still got "enterprise" builds from ProvenScaling. Net benefit: a lot of shit on their shoes.
AFAICT everybody wants SS to be profitable and successful in the future, but the wording and ambiguous interpretation of this "policy" is very unfortunate.
|
|
|
Message #269407
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: You're either open source or you're not
..but I can take a guess about how they might handle the licensing aspect..
If you have to guess or talk to a salesrobot for clarification then the policy is in dire need of fixing.
|
|
|
Message #269408
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Count your blessings....
http://news.cnet.com/8301-13505_3-10046470-16.html
Matt @ Alfresco "My only question is whether the company should even be providing those first three months of bug fixes on community distributions, given that this might be considered a service for which Spring users should pay."
Yeah, that's Matt for you. Of course everybody should also have to fill out forms and take paid exams before we are worthy to drop our infidel bugreports or completely misguided patches into JIRA. How dare we?
|
|
|
Message #269409
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Also highly disappointed
..Mark Brewer brought up an interesting point though. If fixes are in the public source, what's the difference between me building a new version (or grabbing a nightly build) versus what an Enterprise customer would get?
Nothing, and that is what the more competent (mentally agile?) customers will start doing/continue to do. Other companies had exactly the same experience. The result: customers pressure the vendor into support contracts for the publicly available, non-enterprisey software. And you know what? That's actually smarter than most probably realize because it reduces lock-in and increases the value proposition of the entire ecosystem surrounding the project.
What SS needs to understand is that branches of the same product without really distinguihing features or without compelling added value are not only not sustainable from a maintenance point-of-view, they send a confusing message and eat resources for little or even negative return.
The main customers of infrastructure software are the developers and the computer. Make them happy and the rest follows.
|
|
|
Message #269411
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Clarification
What the maintenance policy will mean to you:
This is not a clarification if you not at the same time provide a policy for major releases.
This could mean that a non-enterprise customer finds a serious bug after the initial 3 months, reports it, you fix it and supply it to your enterprise customers, and the guy that discovered it has to wait for months to get a new version, unless he is willing to track svn and backport and compile himself.
/Magnus
|
|
|
Message #269451
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What does it mean?
Dear Rod,
what i totally dislike about SS decision is that it is based on a principle which is the most negative possible for open source projects: "in order to force companies to give money to SS, instead of giving additional advantages to the paying customers, let's force disadvantages to the non-paying customers".
i am a paying user for several "enterprise" solutions even when a "community" edition is available but, if i understand well your sentences, i will never be an enterprise customer of SS because you are simply unfair.
I had great times with Spring, i developed very good and successful projects with Spring, and even if i did not wrote a single line of spring code, i contributed giving help on forums, blogs, ...
Well, life began to be boring after so many years of Spring: you gave me the right kick in the ass to start finding something new, more interesting, more innovative and, finally, more fair.
So long Spring
|
|
|
Message #269452
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: More than a little disappointed
... How big of a difference will there be between say 2.5 and 2.6? Probably not much.
This doesn't seem like a big deal to me.
and what if an important bug (let's say a security bug on acegi for example) is found after 3 months the major release has been thrown out ? Do I simply have to live with the bug ? nope ...
It this is the situation (and i am not sure that it is because the SS sentences are not very clear for me), Spring is no more the right product for any of my projects.
|
|
|
Message #269453
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
That was expected,and expect more...
since springSource first changed its policy in licensing and decided to release their new app server under the GPL ,i expected a major switch in their policy toward the community,this remind me of the attitude company behind ExtJs ajax library where after becomming a major player and got a tremendous code and feedback from the community,changed their license from bsd to lgpl to gpl forcing every one to purchase a commercial license
what i wanna say here that we must expect more community unfriendly steps from springsource ,first new products under different license,then change in the support strategy,then......(imagine). they begin the chain reaction and trust me ,it will continue
joe
|
|
|
Message #269454
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: That was expected,and expect more...
Fu** SpringSource!!, That is all I will say. We the community helped and contributed to grow Spring Framework and with this is like a stab on the back.
Welcome EJB3.1 and the standard, I think I have to take a serious look at Seam or another alternative maybe Guice?. Spring Source just ruined it self. Mr.Rod I hoped more from you, Really, I hoped you ware our savior but it resulted with the same sh** as everything in the Open Source.
|
|
|
Message #269455
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: That was expected,and expect more...
SpringSource is playing with fire here really this could be their dismiss with the Java community. This will be the point when begin the forks and alternatives and this will fragment more the community.
This is a bad move, and Yes I'm pissed with this news.
|
|
|
Message #269456
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: That was expected,and expect more...
I will not pay a dime just for the DI container, If I need all the stack and portfolio of SpringSource ok I will think about it but just for the DI Container I will have to pay?, nope, better I wait for EJB3.1 the "STANDARD" or I could use Guice or even Tapestry 5 DI container.
|
|
|
Message #269459
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Just fork the source
Since spring uses APL, just fork the code. Isn't that the whole point of using APL license. You can take it and monitize it, or fork it.
|
|
|
Message #269460
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Defuse
So if I understand the debate correctly, the best way to defuse the argument would be to distribute the head point releases to everyone, and to restrict previous version point releases to enterprise subscribers for the agreed three years. So we can all look forward to 3.0.x, but only subscribers will be able to look forward to 2.5.9 or 1.3.8 (or is that branch outside the maintenance scope ?).
I'm also a bit confused about bugs fixes not being publicly available - is there more than one repository ? One public and one SpringSource internal ?
Cheers
Martin
|
|
|
Message #269461
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What does it mean?
is the most negative possible for open source projects: "in order to force companies to give money to SS, instead of giving additional advantages to the paying customers, let's force disadvantages to the non-paying customers
I think this is an excellent point and it highlights the unimaginative nature of the way SpringSource has decided to capitalize on their work. I'm not at all against Spring Source making a lot of money from their open source product. But keep the product open source.
The very reason of Spring's success is it open source nature. Nobody would know the name "Spring" today if it hadn't been an open source project. As great as it is technically, no-one would have cared to integrate their own projects towards Spring.
I guess letting a great techie run a corporation, is like promoting your top auto mechanic to manager. You're not doing what you're best at and start f..... things up. There are many more imaginative ways to make money of Spring and by forcing disadvantage on non paying customers, i.e. the community, you're attacking the core of your success. "Everybody" uses Spring because it's a great tool AND it's open source. Unbelievably short sighted. Swallow your pride and go back while you still can.
Cheers,
Marc
|
|
|
Message #269462
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: More than a little disappointed
The only ones who will complain are
1) The people who don't like Spring anyway. "Hype" is a term coined by people who think they are smarter than everyone else. As if everyone else isn't intelligent enough to understand if they need something like Spring or not. In other words, they won't be missed.
2)People who don't seem to get the gist of the policy. How many here just drop major releases the day they are released without testing them. If you upgrade, test it. If you find a problem, within 3 months, there's a good possiblity that it will get fixed.
If that version doesn't get fixed, wait until the next version. How big of a difference will there be between say 2.5 and 2.6? Probably not much.
This doesn't seem like a big deal to me.
+1
Me neither.
|
|
|
Message #269463
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What does it mean?
Spring Framework is an Open Source project that reuse the work of other contributors and projects. They didn't do alone it was all the Java community that supported this folks and now they gain and want more but now just gives us the back.
They make money this way:
"We make money by:
* Providing world class support and services. This includes dependable 24×7 support, outstanding training and consulting services and indemnification for enterprise customers who are understandably risk-averse.
* Adding subscription products that deliver value to complement the Spring Portfolio.
* Selling subscriptions to enterprise editions of our full-stack products."
They sell the full-stack that Im agree but we the community and contributors just ask something in return let the DI intact and opensource and just try to fix the bugs so others can use it and don't put restrictions on the DI container, that's all.
Or if I'm wrong correct me please.
|
|
|
Message #269466
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Defuse
Martin
I'm also a bit confused about bugs fixes not being publicly available - is there more than one repository ? One public and one SpringSource internal?
Mark's post earlier in this thread made this clear. SpringSource fixes will go into open source.
Rgds
Rod
|
|
|
Message #269465
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Just fork the source
Since spring uses APL, just fork the code. Isn't that the whole point of using APL license. You can take it and monitize it, or fork it.
And this will probably happen, sooner or later *if* this policy should be executed literally (and probably will be).
Thanks God Spring Framework is not rocket science, and we have great community around.
Artur
|
|
|
Message #269467
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I think it is fair
Yes, the community will receive any set of fixes (i.e. 3.0.1, 3.0.2, etc.) that are made during the first three months after a major release. From that point forward, until a new major release (which means a change in the number on either side of the first decimial point - 3.1 or 4.0 would both apply), only SpringSource Enterprise customers will receive further maintenance releases.
Given that major releases include both first and second digits (i.e. 3.0 and 3.1 will be considered major releases) I think it is completely fair.
I also assume that there will be only one source tree, so if developers want to get the latest and greatest (and riskiest) they can (similarly with RedHat). Enterprises want to mitigate risk, so they will probably stick with the official versions.
Spring is a great framework and would not be so without many people working full time on it. We, as a community, need to be agile and allow SpringSource to be an strong entity so as SpringSource can continue to innovate. I think that given the above SpringSource is striking a good balance of community and commercial value.
This actually compares pretty well against other OpenSource solutions such as RedHat and MySQL.
|
|
|
Message #269468
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Defuse
Can you please clear more this?.
So it means for example SS Release Spring Framework 2.6, SS will bug fix until 3 month pass then they will put the code in the source tree open for anybody to pickup and continue the bug fixing and washing their clothes?.
Hmm sounds ok but why no better we fork the code and make Summer or Autumn ID container and without a Consulting "proprietary/OSS" behind it. As someone said Spring DI container is not rocket science perhaps we could use already Guice or soon EJB3.1.
I suggest, people lets move on, I was a supported and fan of Spring until today, The people that continue to drink the kool-aid good luck but all your contributions will be for SS gain.
|
|
|
Message #269469
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Spring maintenance policy
Since I work for big enterprise and we use spring framework for virtually everything, and I'm also active member of spring framework community and also work for my side projects (based on Spring) I have two standpoints:
* Enterprise perspective. Virtually every enterprise requires *support* and *maintenance* for products they use. In the case of Open Source it means 'healthy community' at least. Without this we cannot use bits. Take into account Spring Framework now - after 3 months since major release, without Enterprise Subscription, I wouldn't be able to use spring. As I'm unable to use Windows NT on workstation. As simple as this. Having said that - I'm fine with the paid support/patches. But I really don't like when rules change during the match. Really.
Moreover - before spring beat everything because of price/value ratio. Now, it's not so obvious - maybe WebSphere or Bea will win in the next run. I should rethink my EJB 3.0 standpoint.
But, even I don't like the idea I have to maintain one more contract, I see more serious problems. We use lot of 'spring based' stuff. And don't tell me that 'OK 3 months support is enough'. See CXF or Grails as perfect example. They discover *serious* problems with Spring a Year after release. Even though I have Enterprise license - CXF guys, for example, probably won't. Should I use different versions of spring for my infrastructure and for CXF? It doesn't make sense.
* Open Source perspective - is even worse than Enterprise one. How will You, for example deal with critical security hole discovered 4 months after release? I don't tell You about minor features, or minor bugs. How we could deal with bugs? Since most of the modern Web frameworks base on Spring (Struts2, Grails etc.).
I still hope that I misunderstand this policy. But in the other case I see no other choice, than just... fork Spring Framework. Hopefully we have a lot of supporters available (thousands of projects on Apache, code house, some brilliant companies, lots of developers - probably Apache umbrella would be perfect choice). Well, never thought I could say this. But this may be the best choice, in this - worst - scenario...
Artur
|
|
|
Message #269470
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Just fork the source
Since spring uses APL, just fork the code. Isn't that the whole point of using APL license. You can take it and monitize it, or fork it.
You have the code. You don't have the name!
|
|
|
Message #269471
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: New Spring maintenance policy
I have a big personal investment in Spring. If I were just a regular user, then might be thinking seriously about just dumping Spring and going for something a bit more open, even if (to begin with) it was a bit inferior.
Instead, I have spent a lot of time working on a framework which extends Spring to add features that you won't find elsewhere. It's not something that I would want to throw away.
The direction that Spring is going at the moment does disturb and depress me. When Spring first came out a few years ago, it really was a breath of fresh air. It's beginning to smell a bit stale for the wrong reasons.
It's one thing to have value added products (tools, etc.) available on a commercial basis. It's another to have a different release policy on existing open source products, which effectively makes open source users second class citizens in its user base.
My advice to Rod Johnson - stop trying so desperately hard to make money out of Spring. There are better ways of creating a billion dollar company. Instead, put more effort into retaining the values that made Spring great in the first place.
Phil Zoio
http://impala.googlecode.com/ - Impala dynamic modules for Spring
Spring reloaded, fast and simple!
|
|
|
Message #269472
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Overreaction
Martin
I'm also a bit confused about bugs fixes not being publicly available - is there more than one repository? One public and one SpringSource internal?
Since this question gets to one of the core issues, I thought it worth going into more detail.
There's a lot of overreaction on this thread. This policy does not hurt the open source community. By open source community, I mean those folk who are happy to follow source repository activity, compile open source code and perhaps contribute. Obviously no one who doesn't do the first two activities can do the third in any useful way. 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. These are typically companies who can't or won't upgrade to the current version of Spring--in contrast to the typical open source culture of following the latest and greatest release. These folk will still get the latest versions of Spring--and furthermore, typically are enterprises of a scale and risk profile that they are happy to pay for rock solid support. From their point of view, the availability of 3 year support from SpringSource is a good thing, and a strong argument in favor of using Spring, rather than a problem. Frankly, anyone who refuses to compile an open source project under any circumstances doesn't really believe in open source: they believe in other people working for them for free.
We're proud of the huge contribution we make to open source--not merely in Spring projects, but in Tomcat, Apache HTTPD and many other projects. Anyone who really cares about open source should be willing to read and compile code, or pay for those who create open source to do it for them. Folks who aren't willing to do this can complain, but I have little sympathy for them.
Rgds
Rod
|
|
|
Message #269475
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
3.0
Grant
I noticed Spring 3.0 is not being actively worked on in any public repository. It seems the Spring 3.0 development has been very secretive and less transparent than any other version previously. No JIRA issues for 3.0M1 have been resolved and no code committed on the public repo.
Nothing mysterious here. Most of the work thus far has been on the feature set and prototypes on individual developers' machines that aren't ready for any repository. The focus of development is about to shift to 3.0 and there will be code to see soon.
Remember 2.0M1, and the amount of code that only appeared in CVS just before the release? -- because that's when it got written.
Rgds
Rod
|
|
|
Message #269476
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Overreaction
Rod:
in contrast to the typical open source culture of following the latest and greatest release. These folk will still get the latest versions of Spring--and furthermore, typically are enterprises of a scale and risk profile that they are happy to pay for rock solid support.
I don't know about you, but most of us expects the "latest and greatest release" to be a official jar with a specific version, not a snapshot from what the current trunk might look like at the time the bugfix is merged into it.
How can the "open source culture" get this release if no new releases will be made after the initial 3 months?
All I ask for is to always make the latest release from the current major version of Spring available as official jar from SpringSource.
/Magnus
|
|
|
Message #269477
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thanks!
Rod --
Thank you for the clarifications both on the new support model and on the 3.0 development. You and your team have always provided high quality releases and as someone who will always be leveraging the latest and greatest, if not milestone releases, I'm happy to know things shouldn't change.
I'm very excited about the 3.0 release which was one reason I asked the question about 3.0 and the repository. I haven't heard much news about it lately and I know you guys are working hard on it so I was curious what the status was :). Are there plans to blog about some of the new exciting features? :P
Thanks
Grant
Vodori Inc.
|
|
|
Message #269478
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The blogshere already chimes in
It is worth noting that both G2One and SS are backed by the same VC so I am not sure they see such a concern as real.
Same VC, no problem. Commercial 'open' source at work. Oh the irony ...
|
|
|
Message #269480
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Misunderestimation
Rod, SpringSource are not monetizing your code or hard work, it's monetizing the fact of the wide adoption of Spring Framework.
This move just seems so incredibly counterproductive in every way.
You're putting giant unknowns in the path of 90% of the people who, while not paying you anything, are the actual reason anyone would consider paying for a Spring license, or renewing their subscription some years from now.
Money isn't a problem. The unknowns are.
Technology isn't a problem. The psychological blow of tainting the real value of a rare island of consistency through the introduction of these unknowns is.
|
|
|
Message #269481
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Just fork the source
Since spring uses APL, just fork the code. Isn't that the whole point of using APL license. You can take it and monitize it, or fork it.
You have the code. You don't have the name!
What good is the name? all I care about is code and being useful.
|
|
|
Message #269482
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
This is Classic!!!
Rod, you are the man!
I personally hate how this policy applies to new releases, and think it is a bad move on your part. But I have to admit I have a pretty big smile on my face right now.
I love how you just gave your community the big middle finger. I like Spring, but have never liked Spring fan boys much. At lest this move will most likely shut them up.
ha ha ha ha
|
|
|
Message #269483
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: This is Classic!!!
Damn it, This is so Hilarious, Specially the middle finger to the community.
Bye bye Spring, It was great until last.
|
|
|
Message #269484
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: This is Classic!!!
I believed Spring framework already was a standard more than the expert group more than JCP even more than SUN, Springsource make their money with consulting and another extra to the stack but this just ruined all, This ruined Rod vision of lightweight middle-ware as standard, Maybe SpringSource now got to much ambitious.
It is sad but well I have to stop believing and dreaming and go back to the real thing the standards, anyway are not bad they are based on Spring idea, thanks god.
As I said, Bye bye Spring.
Peace everyone.
|
|
|
Message #269485
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
it was about time...
to move on to something else. In my opinion too many things already depended on Spring (in many projects) - so it was about the time to do some cleanup.
thanks to SpringSource
|
|
|
Message #269486
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Overreaction
Rod
I think I'm one of many people who use Spring for nothing but simple DI.
The value increase of Spring over the last few years was not by Spring itself but by other frameworks who supported Spring by allowing a Spring based configuration (ActiveMQ, Mule, Camel etc.)
The only newish feature of Spring itself that made a difference to me was Namespaces. And this only because it made the above nicer to configure.
I've choosen Spring because I did NOT want an enterprise product but a lightweight alternative to configure my apps.
A few questions therfore:
Do you believe it's reasonable to have to pay a subscription for a simple DI container?
Should I rather than use the latest and greatest version and risk unfixed issues try to stay with the boldest and oldest version which still had all the fixes put into it's branch?
How much of your profit will be shared with these frameworks like Camel and co that made me choose Spring over and over again rather than alternative DI containers?
Where do you think your, by now, ubiquitous DI container exceeds other ubiquitous libraries such as the Apache commons ones? Or should I have to take out for every software product going forward at least 20-30 different support contracts?
I understand that you want to make money, and hey - feel free to take any value adding features added to your DI container and make people pay for them.
But the value of core-spring, the DI-container, does not lie with the huge amount of complex code in it, but by us, the community, having made it the DI container of our choice.
Will be interesting to see how much google searches for Guice and Tapestry shot up over the last few days!
|
|
|
Message #269487
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Misunderestimation
Rod, SpringSource are not monetizing your code or hard work, it's monetizing the fact of the wide adoption of Spring Framework.
This move just seems so incredibly counterproductive in every way.
You're putting giant unknowns in the path of 90% of the people who, while not paying you anything, are the actual reason anyone would consider paying for a Spring license, or renewing their subscription some years from now.
Money isn't a problem. The unknowns are.
Technology isn't a problem. The psychological blow of tainting the real value of a rare island of consistency through the introduction of these unknowns is.
+1
|
|
|
Message #269489
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Just fork the source
Since spring uses APL, just fork the code. Isn't that the whole point of using APL license. You can take it and monitize it, or fork it.
You have the code. You don't have the name!
Well, then let's call it "autumn", this has worked for other programs also (more -> less ;)
|
|
|
Message #269491
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Overreaction
Do you believe it's reasonable to have to pay a subscription for a simple DI container?
Ingo, Spring has not been the first IOC containter and certainly won't be the last (Guice, the Tapestry 5 IOC container, the old Picocontainer to name a few).
Should I rather than use the latest and greatest version and risk unfixed issues try to stay with the boldest and oldest version which still had all the fixes put into it's branch?
I personally would go for the old, stable one. It is risk management.
be interesting to see how much google searches for Guice and Tapestry shot up over the last few days!
I definitely agree with you, Ingo. The only helpful feature I found in Spring was the transactional demarcation, but that's something I can re-write myself for another container. I totally agree that, as other people said, they are trying to monetize over adoption rather than over additional features.
But again (I said this in another post) that's where the development community glaringly failed: also where the new risks lay:
1) The community took a framework, blessed it to the highest skies, and used it as a standard, not as a framework. The trick here is that Spring promotes IOC and loose coupling, but using Spring as a whole means getting stick to its classes (especially with DAO, Web Services, WebFlow, and transaction demarcation). As a result Spring became pervasive where it should have freed the developers from dependencies. It's a bit (not quite) like Microsoft.
2) Licensing - I think that changing licensing on the run is dodgy to say the least. Either a product is free, either it is not. If Springsource changes mind, it can stop the project and build a new one under a different license. The community, needless to say, may be forking from the old one. I am sure there are people who know Spring as well as the SpringSource guys do.
3) This case stacks up to the list of precedents with open-source-licensed suddenly become (semi-)commercial. There are many other frameworks that are good candidates - ZKK, Guice, GWT, Echo, and theoretically many others. A community that accepts this only harms the open source adoption within the enterprise field: open source often enters being free-good-quality software, especially in the small businesses market. Suddenly their cost estimates fail because they must cater for *mandatory* support contracts. Are we really sure we want this?
I am going to keep far from Spring from now on, even if they would make up their minds again over this highly debatable license. That has become a risk, especially where budgets are tight.
|
|
|
Message #269492
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Overreaction
Rod,
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. These are typically companies who can't or won't upgrade to the current version of Spring--in contrast to the typical open source culture of following the latest and greatest release. These folk will still get the latest versions of Spring--and furthermore, typically are enterprises of a scale and risk profile that they are happy to pay for rock solid support. From their point of view, the availability of 3 year support from SpringSource is a good thing, and a strong argument in favor of using Spring, rather than a problem. Frankly, anyone who refuses to compile an open source project under any circumstances doesn't really believe in open source: they believe in other people working for them for free.
while I agree with you on your point that companies who use the Spring framework in their productive environment should be able to pay for professional support, I still have a problem with abruptly changing terms in the middle of the game.
In many projects I have worked on, an evaluation of the technology to use was based on various aspects and licensing costs being one of these aspects. In those cases were Spring was chosen to be base technology, I will now have to tell our customers that things have changed and that they will have to buy commercial support if they want to receive critical updates in a timely manner. They will not be happy about that.
For upcoming projects, I do not have a problem with the new Spring maintenance scheme as I can inform the customer what to expect and then they can make their decision on that basis. What I really dislike are the reactions of those customers who I recommended Spring to and who will now be unsatisfied with my advice.
J.
|
|
|
Message #269493
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Hilarious
As Mikael and others already commented, the psychological ramifications are much greater than anything else and this has been a hilarious blunder from spring source to not to manage the discussion on the subject.
Great way to give finger to the community and people who have spoken so fondly about Spring framework and made it's adoption to what it is. Great job. Really.
Realistic options for people building on top of spring are either:
1) pay the subscription
2) take risk with trunk
3) keep on upgrading Spring constantly in your software and having the trouble of weeding out bugs while maintenance releases are still given, and hope that next release will come soon
4) fork
Option 1 might not be a bad option, but as the licencing prices and structure are not available online it is hard to know. Can anyone here spill out the beans and tell how much the licences cost?
Options 2, 3 and 4 all sound and feel crappy choises unless lots of people pool resources together and form similar structure as Centos is to Redhat EL. Many of use don't need the 3 year maintenance that enterprise customers like to have, but don't either want to be left dark and work with the unknowns as Spring Source's current plans would mean.
As I've made large commitments to skills in Spring, I'm not yet about to dump it. But let's say that this has opened up our previously almost monogamous relationship status to 'Complicated' or 'Seeing someone, but looking'.
Disappointment.
Oh well. Times are changing.
|
|
|
Message #269494
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Hilarious
Option 1 might not be a bad option, but as the licencing prices and structure are not available online it is hard to know.
I'm not sure, here. Ok, I have no problem ask my manager to pay SS maintenance fees. But, the problem is that what I get is... spring framework itself. Since Spring is infrastructure stack, it is obviously, not only used by my code. It's used by a lot o bits I do use - CXF, Grails, Struts2, WebWork, ActiveMQ and lots of other spring-based stuff. Now what? If guys from CXF will find bug in Spring - how they get it fixed, and being fixed back for them? There are a lot of cases as such in Spring JIRA:
http://jira.springframework.org/browse/SPR-4584
Artur
|
|
|
Message #269495
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Overreaction
A community that accepts this only harms the open source adoption within the enterprise field: open source often enters being free-good-quality software, especially in the small businesses market.
Is this not the disconnect which is causing all the grief? It is not the openness of the code it is the price (free) that the vast majority of customers, sorry community, are buying (not commercially that is) into.
The last time I was at a TTS conference in Las Vegas we got to hear from SS (then Interface21), Alfresco, and others on how OSS significantly reduced development costs (more like testing if you ask me) and improved the quality of the design and code and yet Rod has just told us all that is costs "millions", yes "millions" to develop and maintain the code base with no one outside SS is in anyway contributing. Someone is clearly telling tales here.
Commercial OSS is only free whilst a vendor is gaining market share. This is no different than supermarkets offering goods below cost just to entice customers into the shop and to kill off the competition. The one big difference is that it is illegal in most countries.
http://www.competitionbureau.gc.ca/epic/site/cb-bc.nsf/en/01729e.html
"....while the Act encourages vigorous price competition, it also ensures that marketplace transactions are conducted on the basis of fair, competitive rivalry rather than through anti-competitive behaviour. Unreasonably low pricing is one example of such behaviour. It means involvement in a policy of selling below cost in order to deter entry into a market, or to force competitors out of a market. While consumers may benefit from the resulting low prices for a brief period, they can be harmed in the long-run if the low pricing leads to diminished competition and, ultimately, higher prices or reduced levels of service, product quality or innovation."
It is even worse for the consumer when there is no standard i.e. more than implementation of a runtime or API.
William
|
|
|
Message #269496
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
My thoughts
(Also posted on my blog...)
I'm all for SpringSource or anyone else making money. I don't even mind this, not too much, but it's .. weird.
It reminds me of Red Hat. They used to have a free version, then monetized, and now they have the redheaded stepchild, Fedora, and the "real version," Red Hat. People who used Red Hat before the commercial version got screwed... and started using Debian (and now, Ubuntu, or in my case, Solaris) or bought the subscription.
This is not that big of a deal, except psychologically, and it's a huge warning for companies that leverage Spring.
Like mine.
Let's be clear here: I like the Spring Framework. I was ambivalent for a long time, even though its strengths were clear, because I thought (and continue to think) their stance towards Java EE is political rather than real, and I wasn't sure that configuration in XML (the Spring way, back in 1.0, 2.0) was really that much better than configuration in XML (the J2EE way.)
Sure, it was a lot easier to declare dependencies on instances in Spring compared to J2EE, but then again, J2EE's dependencies were always intended to be "heavier" than Spring's, and that seemed obvious: when your opponent is trying to solve problem A, saying "but they don't solve problem B, which we do" seems... underhanded.
But... with Spring 2.5, the gates opened. Namespaces and annotations - particularly annotations - made everything all right. I finally swallowed the ... whichever pill it is that made me believe (sorry, I didn't like The Matrix), and dove in. Spring's now a standard library for my projects.
The reason the license change bothers me so much is not the specific change. It bothers me because Spring has done a good job embedding itself in successful projects, and now they've shown that they're willing to change the license.
Customers who buy our application server are going to be using Spring, because we leverage the heck out of it.
Now they're forced (for all intents and purposes) to buy a Spring license, too. Chances are, they already do this, but that was their choice.
How do we know Spring's not going to change their license again to something actually onerous, and not just annoying like this one is?
Answer: we don't. Just like a man who's had an affair can never be trusted the same way again, Spring's jilting us - even in a minor way - and we can never trust them like we did.
Thanks, SpringSource. I've appreciated everything you've done, even from afar - and yes, I know, you've held my "not-a-fanboi" stance against me - but now I feel like I was right for listening to my gut feelings.
I'm checking out Guice. If the transaction management stuff is easy enough, we can switch it in as an alternative to Spring.
|
|
|
Message #269497
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Hilarious
I'm not sure, here. Ok, I have no problem ask my manager to pay SS maintenance fees. But, the problem is that what I get is... spring framework itself. Since Spring is infrastructure stack, it is obviously, not only used by my code. It's used by a lot o bits I do use - CXF, Grails, Struts2, WebWork, ActiveMQ and lots of other spring-based stuff.
True, it is clear that this change has great implications for lots of projects - Mule being first in mind for me as they went the spring way for version 2.
But let's play a little and think about a positive scenario.
Spring source releases new versions quite often, putting out new point release roughly every three months. Every release includes nice fixes and feature upgrades. Updates are most of the time designed to be as drop in replacements and most of the time we could continue with life as it was before... Except if the time between releases is more than three months and community is left in the dark.
Not so positive scenario after all.
There was a good suggestion in the thread about having bugfixes to the community in timely fashion untill a newer version is available. It would be fair for the community and set the commitment between SS and the community to play well with the latest and greatest, and aim for subscription in cases where you want to have the stability of one specific version for longer time.
It will be fun to see what are the end results of this change - as people have made large commitments to spring and clearly will feel betrayed. I would hate to see this lead to another framework war, where things are reinvented just for the fun of it and net results is having lots of unnecessary competition that just divides the mindshare and skills.
Spring's adoption is still it's greatest asset. Though many of the people responsible for it's wide adoption in real life have not made any commitments to the codebase, they have made lot of the work to bring spring into the status where it is now.
It is huge misjudgement on behalf of SS to just piss on the hand that has not directly fed it, but has been opening doors and has been in vocal support of it everywhere.
This change might actually not be a big deal, if new releases are done in timely fashion and life goes on normally. But as so many have already pointed out, this policychange changes the implicit contract that the community and spring source has had about the latest and greatest.
Let's say that three months has passed since the latest release and a major bug is discovered within the core or let's say for example in spring security. If you were the product manager at Spring Source, wouldn't you be tempted to _not_ to push the next release out fast - but rather wait for people to hop on board with subscriptions or see people to try to patch their setups on their own.
And as is said in:
http://enigmastation.com/pebble/default/2008/09/21/1222008840000.html
"How do we know Spring's not going to change their license again to something actually onerous, and not just annoying like this one is?
Answer: we don't. Just like a man who's had an affair can never be trusted the same way again, Spring's jilting us - even in a minor way - and we can never trust them like we did. "
Yep. Nicely played Spring Source!
|
|
|
Message #269498
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: My thoughts
Hi Joseph,
You and your company would not be so peeved if you had given risk management much more than lip service. Hint: open standard versus open source code? I suspect there would have been more external contributions than there is currently.
William
|
|
|
Message #269500
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: My thoughts
Hi Joseph,
You and your company would not be so peeved if you had given risk management much more than lip service. Hint: open standard versus open source code? I suspect there would have been more external contributions than there is currently. Errrr.... what? My company isn't peeved at all. That was me speaking as myself. I do not think Spring is a "bad bet" in any way.
My company's integration of Spring is merely a part of our product line, not a core aspect; you can get every benefit of the product without touching Spring.
|
|
|
Message #269502
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: My thoughts
Sorry for many comments but this is disappointed but I suggest for the people that just use the DI container your code is decoupled so move to another framework right now as OpenEJB or Guice or even Tapestry 5 DI, I'm agree with some comments don't fork spring, it could get a big mess with many forks.
Anyway for people that really need all the features of Spring Stack prepare your wallet, it is not disclosed even the price of the license, it could be $3000US every year per developer? for medium to small business just for the DI it doesn't make sense to pay, For medium company that use the stack it some expensive. I think this license it's just for fortune 500 that already got the Spring kool-aid.
This is my 2c and I'm still really pissed, I think I'll still pissed for weeks for this geez.
|
|
|
Message #269503
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Overreaction
There's a lot of overreaction on this thread.
Rod, I don't know if it's overreaction, but it is certainly a strong reaction. SpringSource's announcement clarifies the relationship that the Company wishes to have with its Enterprise users and it does it in a reassuring way. The statement does not say enough about what relationship the Company wants to have with its "Community" users : those who have enjoyed the product for free. I have not made any contributions to the success of SpringSource (other than one JIRA report) - but I've bought the books, I've been to the Conferences, I've banged my head against the wall to get the stuff to work and I've married my career to it. What kind of a relationship does SpringSource want to have with people like me in the future ? As someone suggested, this would make an excellent subject for your next blog, as there are a number of voices in this thread who think that from now on the "Community" doesn't matter any more in your business model. I'm inclined to disagree - I would say that if the "Community" disappears, so will the Spring Framework. What do you think ?
Martin
|
|
|
Message #269507
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Overreaction? Pardon?
Rod,
I have been, and still am, a very happy user (and evangelist) of Spring, for which I really thank you. But these two assertions:
[...] Frankly, anyone who refuses to compile an open source project under any circumstances doesn't really believe in open source: they believe in other people working for them for free.
and
[...] Anyone who really cares about open source should be willing to read and compile code, or pay for those who create open source to do it for them. Folks who aren't willing to do this can complain, but I have little sympathy for them.
...are, imho, dramatically wrong, and, sincerely, I feel quite affected by them. I cannot say "insulted", that would be too much, but frankly I don't feel fine reading things like these.
I believe in open source. Period. I have founded myself three open source java projects in the last four years (of which I abandoned the first one, and I am about to publish the third); I have invested lots and lots and lots of my sleep and spare hours in creating open source code for free, while working for a non-os software company during the day. So I always thought that I could say I belonged to the open source community in any of its definitions.
Yet, I never compiled the Spring Framework, and I will probably never do. So I am confused... maybe I don't belong to the open source community as you define it, do I? Do you refer to the open source community or instead to the Spring contributors community?. Are they the same for you? If I don't compile Spring... do you really think that what I believe in is people working for me?
I will read your code -as I have done many times-, but I will not compile it to create my own version in case you release a bug fix I need. In that case, I will simply avoid using your bugged feature somehow, and go on. Don't you feel sympathy for me because of that? Well, I'm sorry. I never intended to make you feel unhappy about me. In fact, I certainly feel sympathy for you, as you created and contributed some incredible, milestone software to the java industry. Even if you aren't willing to compile my open source code.
And why won't I compile and create my own bugfixing release of Spring?
Just because, and you certainly know this, releases are much more than a ".jar" file in a maven repo. They are also a reference. A version. Versioning is a basic tool in software development management, which allows us to be able to know that we are using exactly the same version of this or that among our set of open source dependencies. If we now have to compile ourselves Spring whenever a new bug is fixed... how many unofficial versions of Spring will there appear? Thousands. And not for adding specialized features here and there, as it would be normal with standard open source, no... Just for adding official bug fixes. Oh, well... bye bye, version control. Welcome chaos.
You certainly know this. And you certainly know, also, that creating packages for minor releases once you have the code in your repository is not real "effort". Come on, people's effort creates the bug-fixing code, people's effort creates documentation for each major release... but it's scripts that create the release packages most of the times. Once you already have that code in your source repository, real effort has already been invested. So I find your releases mean effort for us argument quite weak.
This said, I understand this is only a marketing move by SpringSource. You make things a little more "tasty" for your corporate, spring-licensing customers (most of which will probably not even understand the difference)... at the cost of making things more uncomfortable for the real people who made Spring be where it is: those who use it without ever remotely considering about compiling it. The simple users. Of which your named open source community, believe me, are only an incredibly tiny subset.
And many of those users, Rod, are now angry. Not because this really affects them, as it probably doesn't even if they think it does. They are angry because you changed the rules of the game in the middle of it. And that creates frustration and an important lack of confidence. If you do this... which will be your next steps? Maybe reducing that three months to one? Maybe discarding freely available releases and making everyone go to the source repository?... not good, not safe enough. Many of the people who made Spring so popular simply because they used it (yeah, you know, they liked others working for them) are now considering switching to other safer alternatives. Or do you really believe that Spring is so popular because of your bunch of licensing customers or the hundreds (maybe some thousands) of patch contributors? ROFL. You need much more people to get where you are. You need enormous amounts of plain users.
But don't get me wrong... can you do this? Of course, it is YOUR product. Will it make me stop using Spring? no way (or at least not until you change the game again, which I am afraid you will). Will you lose user base... I am sorry to say "Yes. A lot".
How to change this and avoid the "SpringSource-has-propietarized-Spring" hype that is about to start and probably make your product lots of harm? imho, easy: Just apply that "three-month-only" condition to minor releases in old major releases. This is, if you are in 4.0, release freely all 4.0.x versions until you release 4.1. Once you have 4.1 released, release 4.0.x's freely just for a period (or even don't do it at all) and make people pay for any further 4.0.x bugfixing releases. At least this way you will offer a "way out" to your users: move forward, just switch to the new version. If they don't want to... well... anyone would think it is fair to pay for that. No one will question your open-sourcedness in that scenario.
In brief, in my country we say "you shouldn't bite the hand that feeds you", and I truly believe you have just done it. But hey, I am not a marketing strategist... they probably know better. About marketing, I mean.
Or maybe I just didn't understand a thing about what is being discussed here... which, of course, can be. English is not my native language and well... In that case, I humbly apologise.
Regards,
Daniel Fernández
Jasypt project leader
|
|
|
Message #269505
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The actual change: no binaries
Aside from the large "Let's burn the Spring logo" sentiment I understand that this whole change boils down to:
"You'll get binaries only in the 3 month period after the major release."
This isn't a great tragedy as it seems. Many OSS projects do not provide binaries for all platforms in the world. Do you get Windows binaries for your [insert-favourite-linux-project] by default? Usually, they are built and distributed by a passionate fan who provides them to the community.
What prevents the community to follow this model? (As the source is available in the repository, the only concern is to download and build the binaries in the intermediate period and distribute them accordingly.)
|
|
|
Message #269506
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Overreaction
As someone suggested, this would make an excellent subject for your next blog, as there are a number of voices in this thread who think that from now on the "Community" doesn't matter any more in your business model. I'm inclined to disagree - I would say that if the "Community" disappears, so will the Spring Framework. What do you think ?
Even though Rod would really give the finger ( for example in a short youtube video ) to all of us who have voiced our worries and opinions, there would not be many short term negative impacts on spring framework - not in terms of innovations, adoption or revenue. Well maybe in revenue if many of us would bite the bullet and buy subscriptions.
However longer term changes are more important as well as what the relationship with developers and spring framework on psychological level will be from now on. Going from open source java development posterboy to Larry Ellison can happen over night, and though it can be labeled as over reaction - such is human psyche and any CEO and marketer should know that. No matter what the message actually was or what the intention was, how it is interpreted matters.
As many of us have made commitments to spring framework in our skillsets, in our projects for our employers and in jobmarkets through the wide adoption of spring as de facto stack, there is really no way for spring framework disappear quickly even if they did something as silly as started to require developer subscriptions valued at $49 / developer / year or mandate that developers name their firstborns as Rod, no matter what the sex of the baby was.
But no questions asked about the value of spring framework. It simply is a great framework - a whole stack - for application development and for a while me and many others were already asking whether we need not so good standards that come out of JCP when we have the benevolent de facto spring stack with constant streams of innovation. Who would have thought that Spring source would answer that question so quickly.
So all and all this might be just a healthy announcement for all of us to take what spring gives with a grain of salt. After all what Rod giveth, Rod can taketh away.
|
|
|
Message #269508
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The actual change: no binaries
I understand that this whole change boils down to:
"You'll get binaries only in the 3 month period after the major release."
If you are right that would be fine. The real clarification of this is still missing.
As far as I understand, fixes to a more than 3 months old version will be available publicly only in new major versions.
I doubt fixes made for one of the 'subscription' clients to an older versions will be available in any public repository - binary or sources. Otherwise we would have another company compiling them and selling the subscription for less ....
So the choices boil down to risking a (hopefully available) new major version with potential new bugs or buying the subscription, should a bug arise.
|
|
|
Message #269509
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The actual change: no binaries
Aside from the large "Let's burn the Spring logo" sentiment I understand that this whole change boils down to:
"You'll get binaries only in the 3 month period after the major release."
The problem is - that WE HAVE to interpret things. Sorry, but we have no clear answer from SS official so far.
I wouldn't pay to get binaries. I cannot imagine how such a model could even work. It would be most weird model I have seen ever. Let's assume then I'll get source together with binary distribution. Now, assume that this would be ASF licence. Now - who will stop me making diff agains 'publicly available' repo and publish it to community? If so? What's the deal besides spreading confusion?
Everything we need, and - as a spring community - we deserve is clear statement - what exactly is going to be done by SS?
Many OSS projects do not provide binaries for all platforms in the world. Do you get Windows binaries for your [insert-favourite-linux-project] by default? Usually, they are built and distributed by a passionate fan who provides them to the community.
The problem is, that in this case - this passionate fan is gonna have Enterprise Support. As I read "policy" literally. It's not clear what and in which form will land in public repo.
Artur
|
|
|
Message #269510
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The actual change: no binaries
This is not about binaries and compile, I can do that anytime in my spare time in the evening, This is an insult to the community, it's a back stab and rules changed in the middle of the game.
Spring is reusing open source projects, they grow with the community, It is retard to think this folks after this policy are doing good to the community or even open source. What about all the open source projects that depend of Spring(ex.Grails), It is RUINED people, get it?.
This is hilarious, This sucks, Spring Source sucks big time!!.
I'm done this thread. Bye.
|
|
|
Message #269511
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The actual change: no binaries
I'm done this thread. Bye.
You mean you're finished trolling?
(slow clap)
- Tom
|
|
|
Message #269512
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The actual change: no binaries
Ingo
I understand that this whole change boils down to:
"You'll get binaries only in the 3 month period after the major release."
If you are right that would be fine. The real clarification of this is still missing.
You're exactly right, and such a change hardly justifies the overreaction on this thread. Both Mark Brewer and I have clearly stated that we plan to leave the source open--that message just seems to have gotten lost through folks jumping to conclusions.
For example, contrary to the more far-fetched speculation, we are not contemplating any license change. What we are doing, as various posters point out, is very similar to a number of other successful projects.
Rgds
Rod
|
|
|
Message #269513
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The actual change: no binaries
Artur
Aside from the large "Let's burn the Spring logo" sentiment I understand that this whole change boils down to:
"You'll get binaries only in the 3 month period after the major release."
The problem is - that WE HAVE to interpret things. Sorry, but we have no clear answer from SS official so far.
I thought we were quite clear on this.
Rgds
Rod
|
|
|
Message #269514
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The actual change: no binaries
Rod
Sorry, you might have meant to be clear, but I'm not clear, yet.
Can you categorically promise that all fixes made to the sources, incl. former versions, will be publicly available in a repository? Even if that fix has been made three months after that release.
To avoid more confusion:
- V 3.0 comes out
- V 3.1 comes out three months later
- subsequently a bug is found in 3.0
- you fix it for a subscription client
- I can go into a free and open repository and retrieve source code for version 3.0 (let's call it 3.0.1) that includes the fix.
Can you state the above is true?
|
|
|
Message #269518
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Conversation
Martin,
Thank you for your thoughtful questions.
SpringSource's announcement clarifies the relationship that the Company wishes to have with its Enterprise users and it does it in a reassuring way. The statement does not say enough about what relationship the Company wants to have with its "Community" users : those who have enjoyed the product for free. I have not made any contributions to the success of SpringSource (other than one JIRA report) - but I've bought the books, I've been to the Conferences, I've banged my head against the wall to get the stuff to work and I've married my career to it. What kind of a relationship does SpringSource want to have with people like me in the future? As someone suggested, this would make an excellent subject for your next blog, as there are a number of voices in this thread who think that from now on the "Community" doesn't matter any more in your business model. I'm inclined to disagree - I would say that if the "Community" disappears, so will the Spring Framework. What do you think ?
Blogging about this topic is a very good suggestion. We care very much about the Spring community, and these changes are not intended to hurt it. I would definitely class as "overreaction" much of the wild speculation on this thread, including references to license changes and many posters apparently not reading my or Mark's comments.
Perhaps a blog would help to establish a more productive conversation. We do always try to listen to feedback from the community--which doesn't include anti-Spring zealots who have lost the technical arguments over the years, are always clutching at straws to support their position and don't care in the least for the Spring community.
Equally, the community should listen to our position, consider the enormous contribution we have made and will continue to make to open source and understand that enterprise customers being further incented to pay towards production usage is in everyone's interests.
Rgds
Rod
|
|
|
Message #269515
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The actual change: no binaries
This is the true. Why I will be trolling?, I'm furious and I will not post in this thread just for trolling around, This is serious, My Projects depend of this, This is my opinion as a user and Spring contributor.
I'm not trolling around, It is the simple true that this framework is ruined, My feeling is telling me this so sorry I have to move on as many people here express.
Do you contributed something in this thread? or here maybe you are the troll.
|
|
|
Message #269516
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The actual change: no binaries
Also Mr.Rod looks he ignore common users here, I asked for clarification about his intentions but I just see he respond to named people as Martin Flower, But the rest of users seems we are nothing for Mr.Rod expectations, it is sad.
If there is more clear clarification as Ingo Boegemann posted:
"To avoid more confusion:
- V 3.0 comes out
- V 3.1 comes out three months later
- subsequently a bug is found in 3.0
- you fix it for a subscription client
- I can go into a free and open repository and retrieve source code for version 3.0 (let's call it 3.0.1) that includes the fix.
Can you state the above is true?"
I would like someone from SS respond to it.
|
|
|
Message #269517
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The actual change: no binaries
or here maybe you are the troll.
Yep, you got me figured out lock stock and barrel.
You're certainly not trolling when your first of nine entries started off with "Fu** SpringSource!!".
Give me a break.
Tom
|
|
|
Message #269522
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The actual change: no binaries
Ingo
Rod
Sorry, you might have meant to be clear, but I'm not clear, yet.
Can you categorically promise that all fixes made to the sources, incl. former versions, will be publicly available in a repository? Even if that fix has been made three months after that release.
To avoid more confusion:
- V 3.0 comes out
- V 3.1 comes out three months later
- subsequently a bug is found in 3.0
- you fix it for a subscription client
- I can go into a free and open repository and retrieve source code for version 3.0 (let's call it 3.0.1) that includes the fix.
Can you state the above is true?
Correct. We intend to continue to expose all our code to the open source community.
Rgds
Rod
|
|
|
Message #269519
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The actual change: no binaries
To avoid more confusion:
- V 3.0 comes out
- V 3.1 comes out three months later
- subsequently a bug is found in 3.0
- you fix it for a subscription client
- I can go into a free and open repository and retrieve source code for version 3.0 (let's call it 3.0.1) that includes the fix.
Can you state the above is true?
The answer is here http://www.springsource.com/node/558
"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."
So the answer to your question must be no afaik.
/Magnus
|
|
|
Message #269520
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The actual change: no binaries
@Thomas Fuller, Of course that was my first reaction I could not believe this. Anyway I don't need this, I give you your break. It is great that the idea of a DI is decoupled code so I'll just move to another framework and that's it.
Thank you.
|
|
