How about Bug in their Website?! Go to top ] Posted by: Werner Keil

Posted on: September 19 2008 08:25 EDT

in response to Steve Mayhew 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 ;-) Reply to this Reply to original

You're either open source or you're not Go to top ] Posted by: marc schipperheyn

Posted on: September 19 2008 11:19 EDT

in response to Werner Keil 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 Reply to this Reply to original

Re: You're either open source or you're not Go to top ] Posted by: Alessandro Santini

Posted on: September 22 2008 12:24 EDT

in response to Jason Carreira You're right... If EJB hadn't sucked mightily, there would have been no Spring. Now that EJB sucks less mightily, does that remove the case for Spring? Not so much. I would agree with you if you said "does that remove the case for IOC containers?". If you use Spring as an IOC container, you can achieve the same with another, eventually adding some AOP code (e.g. transaction management when the new IOC container does not support this). If you are using the large amount of (imho useless) classes Spring provides, then you have fallen in what Rod hoped: a nice vendor lock-in that now he wants you to pay. Alessandro I would agree with you if you said "does that remove the case for IOC containers?". If you use Spring as an IOC container, you can achieve the same with another, eventually adding some AOP code (e.g. transaction management when the new IOC container does not support this). If you are using the large amount of (imho useless) classes Spring provides, then you have fallen in what Rod hoped: a nice vendor lock-in that now he wants you to pay. Alessandro Reply to this Reply to original

Re: You're either open source or you're not Go to top ] Posted by: Skandar De Anaya

Posted on: September 22 2008 07:23 EDT

in response to Vitaliy Semochkin Sounds like they're encouraging everyone to try Seam.



For what reason?

Seam is about EJB and JSF - both technologies are useless. This is an example of a real troll!. Go and do your homework and check what is EJB3 and specially 3.1. As the other commenter said without EJB Spring didn't born. I read somewhere that Rod Johnson it is giving advice to the EJB expert group for the next release. Spring 2.5 got the annotations to be compatible with EJB and even Rod encourage to use the compatible annotations. EJB and appserver got profiles that is also another thing Rod is agree and happy the expert group got right, even there is an article that Rod Johnson said JEE 6 is in the right direction. Sorry I dont have the links at hand but you can google them and find it easy. Regards. This is an example of a real troll!. Go and do your homework and check what is EJB3 and specially 3.1. As the other commenter said without EJB Spring didn't born. I read somewhere that Rod Johnson it is giving advice to the EJB expert group for the next release. Spring 2.5 got the annotations to be compatible with EJB and even Rod encourage to use the compatible annotations. EJB and appserver got profiles that is also another thing Rod is agree and happy the expert group got right, even there is an article that Rod Johnson said JEE 6 is in the right direction. Sorry I dont have the links at hand but you can google them and find it easy. Regards. Reply to this Reply to original

Re: You're either open source or you're not Go to top ] Posted by: Vitaliy Semochkin

Posted on: September 22 2008 08:03 EDT

in response to Skandar De Anaya Sounds like they're encouraging everyone to try Seam.



For what reason?

Seam is about EJB and JSF - both technologies are useless.



As the other commenter said without EJB Spring didn't born. Yeap, without EJB the book J2EE without EJB wouldn't appear ;-) I read somewhere that Rod Johnson it is giving advice to the EJB expert group for the next release. Maybe he wants to create STANDARD BASED framework that WORKS? Or maybe he wants a stamp (STANDARD BASED) on it's own project to get more money (why should I or you care)? Spring 2.5 got the annotations to be compatible with EJB and even Rod encourage to use the compatible annotations. Compatible for DI. Have you ever tried Spring for real? I've never heard that someone from Spring team encouraging to use either EJB or JSF. Both EJB and JSF are an perfect example of overengineering. With complex life cycle and lots of technology evangelists dancing around to sell it. Yeap, without EJB the book J2EE without EJB wouldn't appear ;-)Maybe he wants to create STANDARD BASED framework that WORKS? Or maybe he wants a stamp (STANDARD BASED) on it's own project to get more money (why should I or you care)?Compatible for DI. Have you ever tried Spring for real? I've never heard that someone from Spring team encouraging to use either EJB or JSF. Both EJB and JSF are an perfect example of overengineering. With complex life cycle and lots of technology evangelists dancing around to sell it. Reply to this Reply to original

Re: You're either open source or you're not Go to top ] Posted by: Skandar De Anaya

Posted on: September 22 2008 08:21 EDT

in response to Vitaliy Semochkin Maybe he wants to create STANDARD BASED framework that WORKS? Or maybe he wants a stamp (STANDARD BASED) on it's own project to get more money (why should I or you care)? Or maybe he wants to be part of the next Standard as you said why we should care but I care that EJB3.1 it will be smooth to work with and it is a JCP standard neutral of implementers. Compatible for DI. Have you ever tried Spring for real? I've never heard that someone from Spring team encouraging to use either EJB or JSF. Both EJB and JSF are an perfect example of overengineering. With complex life cycle and lots of technology evangelists dancing around to sell it. Yes I mean compatible for the DI and I only use right now the Spring DI. I didnt mean to encourage to use EJB or JSF I mean just the annotations as JSR-250 and EJB 3 annotations JSR-220 as: @Resource @PostConstruct @PreDestroy Or maybe he wants to be part of the next Standard as you said why we should care but I care that EJB3.1 it will be smooth to work with and it is a JCP standard neutral of implementers.Yes I mean compatible for the DI and I only use right now the Spring DI. I didnt mean to encourage to use EJB or JSF I mean just the annotations as JSR-250 and EJB 3 annotations JSR-220 as: @Resource @PostConstruct @PreDestroy Reply to this Reply to original

Re: You're either open source or you're not Go to top ] Posted by: Skandar De Anaya

Posted on: September 22 2008 08:42 EDT

in response to Skandar De Anaya Conclusion, IMHO I was happy to work with Spring DI but this is it, It also happened to me at when Redhat 9 was a desktop OS and Redhat changed the game and went with subscriptions and maybe this is the way for open source projects to make business but for my projects and my customers we are small to medium business this is not a good move and even I don't trust anymore what it will be next with SpringSource but if really I have to use Spring I will pay for the Enterprise subscription if not I will go to the standard with EJB3.1 when is available and as I said the code is decoupled, it's not a big deal to move from one DI container to other or back again to Spring. SpringSource wants to do their business good choice is their choice and with the open source model and Good luck, maybe in the future I will be a "Enterprise Spring" subscriber of Spring Source or maybe not. Best Regards. Reply to this Reply to original

Re: You're either open source or you're not Go to top ] Posted by: peter lin

Posted on: September 19 2008 11:54 EDT

in response to marc schipperheyn 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. Reply to this Reply to original

Re: You're either open source or you're not Go to top ] Posted by: Gabriel Axel

Posted on: September 19 2008 12:49 EDT

in response to peter lin 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 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 Reply to this Reply to original

Clarification Go to top ] Posted by: Rod Johnson

Posted on: September 19 2008 17:40 EDT

in response to Werner Keil 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 Reply to this Reply to original

Re: Clarification Go to top ] Posted by: Peter Mularien

Posted on: September 19 2008 18:29 EDT

in response to Rod Johnson 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). 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). Reply to this Reply to original

Re: Clarification Go to top ] Posted by: Chris Richardson

Posted on: September 19 2008 18:51 EDT

in response to Rod Johnson 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 Reply to this Reply to original

Re: Clarification Go to top ] Posted by: Michael Jouravlev

Posted on: September 19 2008 19:58 EDT

in response to Chris Richardson 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." 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 updateswill be issued for three months. Subsequent maintenance releaseswill be available to SpringSource Enterprise customers." Reply to this Reply to original

Re: Clarification Go to top ] Posted by: Alessandro Santini

Posted on: September 19 2008 19:55 EDT

in response to Rod Johnson 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 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 Reply to this Reply to original

Re: Clarification Go to top ] Posted by: Gabriel Axel

Posted on: September 19 2008 20:04 EDT

in response to Rod Johnson 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 Reply to this Reply to original

Re: Clarification Go to top ] Posted by: Magnus Heino

Posted on: September 20 2008 03:39 EDT

in response to Rod Johnson 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 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 Reply to this Reply to original

Defuse Go to top ] Posted by: Martin Flower

Posted on: September 20 2008 12:38 EDT

in response to Magnus Heino 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 Reply to this Reply to original

Re: Defuse Go to top ] Posted by: Skandar De Anaya

Posted on: September 20 2008 14:02 EDT

in response to Rod Johnson 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. Reply to this Reply to original

Overreaction Go to top ] Posted by: Rod Johnson

Posted on: September 20 2008 14:32 EDT

in response to Martin Flower 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 MartinSince 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.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., which costs us millions of dollars annually to develop. This policyaffect 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 Reply to this Reply to original

Re: Overreaction Go to top ] Posted by: Magnus Heino

Posted on: September 20 2008 16:17 EDT

in response to Rod Johnson 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 Rod: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 Reply to this Reply to original

Misunderestimation Go to top ] Posted by: Mikael G ueck

Posted on: September 20 2008 20:19 EDT

in response to Rod Johnson 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. Reply to this Reply to original

Re: Misunderestimation Go to top ] Posted by: marc schipperheyn

Posted on: September 21 2008 05:55 EDT

in response to Mikael G ueck 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 +1 Reply to this Reply to original

Re: Overreaction Go to top ] Posted by: Ingo Boegemann

Posted on: September 21 2008 05:26 EDT

in response to Rod Johnson 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! Reply to this Reply to original

Re: Overreaction Go to top ] Posted by: Alessandro Santini

Posted on: September 21 2008 06:37 EDT

in response to Ingo Boegemann 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. 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).I personally would go for the old, stable one. It is risk management.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. Reply to this Reply to original

Re: Overreaction Go to top ] Posted by: William Louth

Posted on: September 21 2008 09:02 EDT

in response to Alessandro Santini 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. 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 Reply to this Reply to original

My thoughts Go to top ] Posted by: Joseph Ottinger

Posted on: September 21 2008 09:13 EDT

in response to William Louth 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. (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 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 isthe 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. 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. How do we know Spring's not going to change their licenseto 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. Reply to this Reply to original

Re: My thoughts Go to top ] Posted by: Joseph Ottinger

Posted on: September 21 2008 10:37 EDT

in response to William Louth 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. 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. Reply to this Reply to original

Re: My thoughts Go to top ] Posted by: Skandar De Anaya

Posted on: September 21 2008 11:01 EDT

in response to Joseph Ottinger 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. Reply to this Reply to original

Re: My thoughts Go to top ] Posted by: Rod Johnson

Posted on: September 21 2008 15:25 EDT

in response to Joseph Ottinger I'm checking out Guice. If the transaction management stuff is easy enough, we can switch it in as an alternative to Spring. I don't want to get into a Spring vs Guice flame war here (people should always choose whatever technology works best for them), but besides the obvious fact that Spring does a huge amount more than Guice, I can't resist pointing out that AFAICS the last GA release of Guice dates from March 2007. Our maintenance policy guarantees reliable 3 year enterprise support and far more frequent releases than that to the community. Rgds Rod JoeI don't want to get into a Spring vs Guice flame war here (people should always choose whatever technology works best for them), but besides the obvious fact that Spring does a huge amount more than Guice, I can't resist pointing out that AFAICS the last GA release of Guice dates from. Our maintenance policy guarantees reliable 3 year enterprise support and far more frequent releases than that to the community. Rgds Rod Reply to this Reply to original

Re: My thoughts Go to top ] Posted by: Joseph Ottinger

Posted on: September 21 2008 19:49 EDT

in response to Rod Johnson Joe

I'm checking out Guice. If the transaction management stuff is easy enough, we can switch it in as an alternative to Spring.

I don't want to get into a Spring vs Guice flame war here (people should always choose whatever technology works best for them), but besides the obvious fact that Spring does a huge amount more than Guice, I can't resist pointing out that AFAICS the last GA release of Guice dates from March 2007. Our maintenance policy guarantees reliable 3 year enterprise support and far more frequent releases than that to the community.



Rgds

Rod Rod, I'm not debating the amount that the frameworks do, nor am I debating which one is more applicable for us and our customers. For all intents and purposes, politically and technologically, Spring is the best choice for leveraging OpenSpaces. That said... I'm concerned. I don't think many (any?) of our users will reject OpenSpaces just because of interpretation of a recent Spring policy, nor should they, but this does not enhance my confidence, nor preserve it. Rod, I'm not debating the amount that the frameworks do, nor am I debating which one is more applicable for us and our customers. For all intents and purposes, politically and technologically, Spring is the best choice for leveraging OpenSpaces. That said... I'm concerned. I don't think many (any?) of our users will reject OpenSpaces just because of interpretation of a recent Spring policy, nor should they, but this does not enhance my confidence, nor preserve it. Reply to this Reply to original

Re: My thoughts Go to top ] Posted by: Skandar De Anaya

Posted on: September 21 2008 21:43 EDT

in response to Joseph Ottinger Joe

I'm checking out Guice. If the transaction management stuff is easy enough, we can switch it in as an alternative to Spring.

I don't want to get into a Spring vs Guice flame war here (people should always choose whatever technology works best for them), but besides the obvious fact that Spring does a huge amount more than Guice, I can't resist pointing out that AFAICS the last GA release of Guice dates from March 2007. Our maintenance policy guarantees reliable 3 year enterprise support and far more frequent releases than that to the community.



Rgds

Rod Rod, I'm not debating the amount that the frameworks do, nor am I debating which one is more applicable for us and our customers. For all intents and purposes, politically and technologically, Spring is the best choice for leveraging OpenSpaces.



That said... I'm concerned. I don't think many (any?) of our users will reject OpenSpaces just because of interpretation of a recent Spring policy, nor should they, but this does not enhance my confidence, nor preserve it. This days everything is "Enterprise" hype. But what about small to medium business?. We will be forgotten in the dust just for the 3 months bug fixing because cant afford for a license for the "Enterprise" maintenance?, It will be discounts of something like that for small and medium business?. It will be affordable the license fee for Spring framework maintenance?. This days everything is "Enterprise" hype. But what about small to medium business?. We will be forgotten in the dust just for the 3 months bug fixing because cant afford for a license for the "Enterprise" maintenance?, It will be discounts of something like that for small and medium business?. It will be affordable the license fee for Spring framework maintenance?. Reply to this Reply to original

Re: Overreaction Go to top ] Posted by: Jürgen Lind

Posted on: September 21 2008 07:24 EDT

in response to Rod Johnson 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. Rod,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. Reply to this Reply to original

Re: Overreaction Go to top ] Posted by: Martin Flower

Posted on: September 21 2008 11:49 EDT

in response to Rod Johnson 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 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 Reply to this Reply to original

Re: Overreaction Go to top ] Posted by: Heimo Laukkanen

Posted on: September 21 2008 12:43 EDT

in response to Martin Flower 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. 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. Reply to this Reply to original

Conversation Go to top ] Posted by: Rod Johnson

Posted on: September 21 2008 14:02 EDT

in response to Martin Flower 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 Martin, Thank you for your thoughtful questions.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 Reply to this Reply to original

Overreaction? Pardon? Go to top ] Posted by: Daniel Fernandez

Posted on: September 21 2008 11:51 EDT

in response to Rod Johnson 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 Rod, I have been, and still am, a very happy user (and evangelist) of Spring, for which Ithank you. But these two assertions:and...are, imho,, 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 thein 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 theor instead to the. 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.Just because, and you certainly know this, releases are much more than a ".jar" file in a maven repo. They are also a. 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.. And not for adding specialized features here and there, as it would be normal with standard open source, no... Just for adding. 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 yourargument 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)...Of which your named, 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.. And that creates frustration and an important lack of confidence. If you do this...not good, not safe enough. Many of the people who made Spring so popular simply because theyit (yeah, you know, they liked others working for them) are now considering switching to otheralternatives. 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. 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".imho, easy: Just apply that "three-month-only" condition to minor releases inmajor 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, 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 Reply to this Reply to original

Re: Huge contribution to Tomcat and Apache HTTPD ? Go to top ] Posted by: Otengi Miloskov

Posted on: September 22 2008 13:50 EDT

in response to William Louth Why suffer dear developer?, Better move on and get in to Erlang, Python, Ruby, Haskell and forget about IoC and all the suffering that Java developers went throw all this years. This is real evil, I would call to this company $pringo, it only care to make a cash cow and not care their developers or community. Why pay for a hype or subscription that actually their community are calling them the SS elite?, this is hilarious. Don't suffer my friend developer, there is choices as in real life, we have lot of choices to choose from, Go on and move on and don't stay in something that doesn't have any value and even their workers wearing a tie are the disgrace of this move. Rest in peace, $pringo. Reply to this Reply to original

A little disappointed Go to top ] Posted by: Martijn Verburg

Posted on: September 19 2008 10:36 EDT

in response to Steve Mayhew 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. Reply to this Reply to original

Also highly disappointed Go to top ] Posted by: Grant Gochnauer

Posted on: September 19 2008 17:27 EDT

in response to Alessandro Santini 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. Reply to this Reply to original

Re: Also highly disappointed Go to top ] Posted by: Holger Hoffst??tte

Posted on: September 19 2008 21:10 EDT

in response to Grant Gochnauer ..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. 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. Reply to this Reply to original

3.0 Go to top ] Posted by: Rod Johnson

Posted on: September 20 2008 16:08 EDT

in response to Grant Gochnauer 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 GrantNothing 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 Reply to this Reply to original

Thanks! Go to top ] Posted by: Grant Gochnauer

Posted on: September 20 2008 16:43 EDT

in response to Rod Johnson 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. Reply to this Reply to original

Re: More than a little disappointed Go to top ] Posted by: David McCoy

Posted on: September 19 2008 18:13 EDT

in response to Alessandro Santini +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. 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. Reply to this Reply to original

Re: More than a little disappointed Go to top ] Posted by: Paolo Denti

Posted on: September 20 2008 08:41 EDT

in response to David McCoy ... 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. 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. Reply to this Reply to original

Re: More than a little disappointed Go to top ] Posted by: David McCoy

Posted on: September 22 2008 10:00 EDT

in response to Paolo Denti ... 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. Then you wait for the next version. How exactly is this really different than what currently goes on? Perhaps, I'm different(or lucky), but I only upgrade to releases, as opposed to nightly builds. Also, I tend to let that new release bake just in case something comes up. All they are doing is answering the question "What do I get for paid subscriptions?" Answer: Something better than what the free guys get. More timely fixes. You'll get them sooner than the free guys(who will get them in version 2.5.1, instead of 2.5 and 93 days. And that's unreasonable? Then you wait for the next version. How exactly is this really different than what currently goes on? Perhaps, I'm different(or lucky), but I only upgrade to releases, as opposed to nightly builds. Also, I tend to let that new release bake just in case something comes up. All they are doing is answering the question "What do I get for paid subscriptions?" Answer: Something better than what the free guys get. More timely fixes. You'll get them sooner than the free guys(who will get them in version 2.5.1, instead of 2.5 and 93 days. And that's unreasonable? Reply to this Reply to original

Re: More than a little disappointed Go to top ] Posted by: Artur Karazniewicz

Posted on: September 22 2008 10:26 EDT

in response to David McCoy You'll get them sooner than the free guys(who will get them in version 2.5.1, instead of 2.5 and 93 days.



And that's unreasonable? Yes it's seems to be unreasonable, as You describe it. Note that in most cases our code relies on external libraries using spring. The best examples are CXF and struts2. Even if I get "better" release, CXF guys don't. I don't develop my applications based exclusively upon Spring, I depend on 3rd party libraries whose depends on Spring also. How is new policy is gonna work in this case - even if I'm Enterprise Customer? I've never, since Spring 2.0 found bug in Spring myself. But CXF guys did, a few, and those bugs were fixed well after 3 months after major release. This move, hurts me also. Not only I pay for support, but this seems hurt my business in terms of free of choice (CXF). Not to mention that I expect that I will get, having paid SS, something more than I get now. "Something more" means - I cannot imagine that I could get new release, with limited rights (eg. I expect I'll be able to freely redistribute it, as I can now) or, even worse, without source code... Artur Yes it's seems to be unreasonable, as You describe it. Note that in most cases our code relies on external libraries using spring. The best examples are CXF and struts2. Even if I get "better" release, CXF guys don't. I don't develop my applications based exclusively upon Spring, I depend on 3rd party libraries whose depends on Spring also. How is new policy is gonna work in this case - even if I'm Enterprise Customer? I've never, since Spring 2.0 found bug in Spring myself. But CXF guys did, a few, and those bugs were fixed well after 3 months after major release. This move, hurts me also. Not only I pay for support, but this seems hurt my business in terms of free of choice (CXF). Not to mention that I expect that I will get, having paid SS, something more than I get now. "Something more" means - I cannot imagine that I could get new release, with limited rights (eg. I expect I'll be able to freely redistribute it, as I can now) or, even worse, without source code... Artur Reply to this Reply to original

Re: More than a little disappointed Go to top ] Posted by: David McCoy

Posted on: September 22 2008 14:51 EDT

in response to Artur Karazniewicz Well, don't use it then. The problem seems very edge case and seems to be a huffing point more for people who had pre-existing bias against Spring than the emergence of a real problem. Spring has released 5 or 6 versions since 2.0 with fairly regular frequency so even in the situation you describe, a fixed would have been made available fairly quickly. If I'm using 1.2.4, how long is Spring supposed to provide bugfixes? For infinity? This is the one dark side of open source. People think everything should be free always. And then berate someone that at someone point, something has to foot the bill. Look at the Linux guys when attacking AMD(ATI) or Nvidia. And the worst thing they've done is to say, "Unless you pay, you'll get the bugfix a little later than sooner. And even then, the fix is still FREE!" Who else does that?!?!? When was the last time you offered your customer free fixes? Or told you boss, "I'll fix it this weekend. Don't pay me for it." Personally, I like eating. Boo-hoo. I've seen far worse policies than what Spring is doing and they've had years to really consider how to stick it to the community. I suspect that you won't find many orgs up in arms about this change. Spring, Hibernate, GWT, all this stuff is great and you didn't PAY for it. Back in the day, 2000, we paid more than $100k for Weblogic 5.1 and tens of thousands for Oracle to get comparable features and service. Wake me when a real problem arises. Reply to this Reply to original

Re: More than a little disappointed Go to top ] Posted by: Steve Cresswell

Posted on: September 20 2008 12:47 EDT

in response to David McCoy



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. +1 Me neither. Reply to this Reply to original

What about licensing of maintenance releases? Go to top ] Posted by: Mrinal Kanti

Posted on: September 19 2008 10:44 EDT

in response to Steve Mayhew 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? Reply to this Reply to original

What does it mean? Go to top ] Posted by: Gabriel Axel

Posted on: September 19 2008 12:32 EDT

in response to Steve Mayhew 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 Reply to this Reply to original

Re: What does it mean? Go to top ] Posted by: Will Hartung

Posted on: September 19 2008 12:50 EDT

in response to Gabriel Axel 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. 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. Reply to this Reply to original

Re: What does it mean? Go to top ] Posted by: Mark Brewer

Posted on: September 19 2008 13:48 EDT

in response to Gabriel Axel 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. Reply to this Reply to original

Re: What does it mean? Go to top ] Posted by: William Louth

Posted on: September 19 2008 14:33 EDT

in response to Mark Brewer 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 Hi Mark,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 Reply to this Reply to original

Re: What does it mean? Go to top ] Posted by: Magnus Heino

Posted on: September 19 2008 14:33 EDT

in response to Mark Brewer Yes, the community will receive any set 