Discussions

News: New Spring maintenance policy

  1. New Spring maintenance policy (250 messages)

    Looks like we'll need to buy support on Spring to get ongoing bug fixes. I just saw that SpringSource formalized a maintenance policy http://www.springsource.com/node/558 for Spring and we'll now need to buy commercial support if we want maintenance releases after a new release is out for 3 months. I know other open source companies do this, but that's some big news for Spring. [Editor: following excerpted from the news release] SAN MATEO, Calif.—September 17, 2008 – SpringSource, the company behind Spring, the de facto standard in enterprise Java, today announced that it has implemented a new maintenance policy for Spring. The policy provides Spring production users with a long-term, stable application platform to build, run and manage their Spring-powered applications. Customers who are using SpringSource Enterprise, available under a subscription, will receive maintenance releases for three years from the general availability of a major new version. These customers receive ongoing, rapid patches as well as regular maintenance releases to address bugs, security vulnerabilities and usability issues, making SpringSource Enterprise the best option for production systems. After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. Subsequent maintenance releases will be available to SpringSource Enterprise customers. Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software . . .

    Threaded Messages (250)

  2. How about Bug in their Website?![ Go to top ]

    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 ;-)
  3. Re: How about Bug in their Website?![ Go to top ]

    The link worked for me several times, Werner. Maybe they're only supporting IE .
  4. Re: How about Bug in their Website?![ Go to top ]

    The link doesn't work in IE or Firefox for me. Only difference is that in IE the error message text is missing. Must say that I find it slightly amusing that the Spring guys expose the SQL and their domain model to the user when an error, or maybe they can blame Drupal? :-) /Ragnar
  5. 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
  6. Re: You're either open source or you're not[ Go to top ]

    Sounds like they're encouraging everyone to try Seam.
  7. Re: You're either open source or you're not[ Go to top ]

    Sounds like they're encouraging everyone to try Seam.
    For what reason? Seam is about EJB and JSF - both technologies are useless.
  8. For what reason?
    Seam is about EJB and JSF - both technologies are useless.
    Ignorant guy is ignorant. EJB is one step in evolution of enterprise software development. If there was no EJB, there would be no Spring son. At least post as anonymous coward if you gonna make yourself sound funny. I cant comment on JSF though.
  9. 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.
  10. 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
  11. Jason, Maybe he was referring to the fact that without the Java enterprise services built on standards Spring (or any other framework) would not have such a relatively easy time entering the space at the time they did. This could be said for the whole tool eco system. Spring has not actually delivered an implementation of any of the enterprise API's (JMS, JDBC, JCA...) that does not proxy some underlying API - discounting straw man implementations. William
  12. You're right... If EJB hadn't sucked mightily, there would have been no Spring.
    IoC is a workaround for the misdesigned constructors in Java, just like Templates are a comical but necessary clone of domain-specific closures. None of this had anything to do with EJB.
  13. Care to elaborate[ Go to top ]

    Care to elaborate on the "IoC is a workaround for the misdesigned constructors in Java" ?
  14. IoC is a workaround for the misdesigned constructors in Java, just like Templates are a comical but necessary clone of domain-specific closures. None of this had anything to do with EJB.
    I sense Scala zealot here. In before "Scala is silver bullet" response.
  15. IoC is a workaround for the misdesigned constructors in Java, just like Templates are a comical but necessary clone of domain-specific closures. None of this had anything to do with EJB.


    I sense Scala zealot here. In before "Scala is silver bullet" response.
    That's interesting, but wrong; what I think of Scala has nothing to do with it. Fwiw I'm also not particularly interested in discussing this here.
  16. I'm also not particularly interested in discussing this here.
    I respect your decision, though I would appreciate if you have some links/materials one could read regarding 'misdesigned constructors'. PS I'm being honest here, no flame whatsoever.
  17. Im not sure but a Scala guru can confirm it but what I know is with Scala you don't need a DI(Spring) because the type system help you and also have Mixins. You can configure with straight Scala, even you don't need xml or annotations or frameworks. That's why people keep saying Scala is the next Java.
  18. 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.
  19. 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.
  20. 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
  21. even there is an article that Rod Johnson said JEE 6 is in the right direction
    Here is the link that Rod said JEE 6 gets it right. http://blog.springsource.com/2007/07/03/java-ee-6-gets-it-right/
  22. 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.
  23. Maybe he wants to create STANDARD BASED framework that WORKS?
    Could you be more specific? Do you refer to EJB3+ specification as non-working?
  24. 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.
  25. There are certainly all kinds of open-source. Spring was one kind of open-source project - a project that became successful in part because it provided free and timely updates. Now, apparently, Spring is a different kind of open-source project - a project that requires users to pay for support if they want a guarantee of timely updates. On the surface that seems like a pretty big and very disappointing switch. Chris Spring free loader (And author of POJOs in Action, ...) www.chrisrichardson.net
  26. "I wanted to reflect on where Spring is positioned in the Java open source community, and how open the Spring Core project is to work done by the public. ... I was curious whether ... the majority of development on the “Spring Core” projects (including Spring MVC and what we would consider “classic Spring”) is performed solely by SpringSource employees." http://www.mularien.com/blog/2008/09/19/how-open-source-is-spring-an-analytical-investigation/
  27. Thanks for the link. Just to clarify - my objective analysis (which you can view through the link) was done (ironically) before I knew anything about this announcement. There is discussion in my blog entry about where Spring 3.0 is, and once again I would like to thank Juergen for his help.
  28. 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
  29. Of course, I don't know any unpublished details about SpringSource's new maintenance policy (I've read the notices on SpringSource's website), but I can take a guess about how they might handle the licensing aspect. After SpringSource releases a new major version and three months have passed, they can produce further maintenance updates under an alternate (non-Apache) license to their subscription customers. Cheers, David Flux - Java Job Scheduler. File Transfer. Workflow.
  30. ..but I can take a guess about how they might handle the licensing aspect..
    If you have to guess or talk to a salesrobot for clarification then the policy is in dire need of fixing.
  31. Clarification[ Go to top ]

    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
  32. Re: Clarification[ Go to top ]

    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).
  33. Re: Clarification[ Go to top ]

    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
  34. Re: Clarification[ Go to top ]

    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."
  35. Re: Clarification[ Go to top ]

    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
  36. Re: Clarification[ Go to top ]

    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
  37. Re: Clarification[ Go to top ]

    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
  38. Defuse[ Go to top ]

    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
  39. Re: Defuse[ Go to top ]

    Martin
    I'm also a bit confused about bugs fixes not being publicly available - is there more than one repository ? One public and one SpringSource internal?
    Mark's post earlier in this thread made this clear. SpringSource fixes will go into open source. Rgds Rod
  40. Re: Defuse[ Go to top ]

    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.
  41. Overreaction[ Go to top ]

    Martin
    I'm also a bit confused about bugs fixes not being publicly available - is there more than one repository? One public and one SpringSource internal?
    Since this question gets to one of the core issues, I thought it worth going into more detail. There's a lot of overreaction on this thread. This policy does not hurt the open source community. By open source community, I mean those folk who are happy to follow source repository activity, compile open source code and perhaps contribute. Obviously no one who doesn't do the first two activities can do the third in any useful way. SpringSource continues to expose our open source code, which costs us millions of dollars annually to develop. This policy does affect users who think that open source is a way for them to get extended maintenance of high quality enterprise software for free, without them lifting a finger. These are typically companies who can't or won't upgrade to the current version of Spring--in contrast to the typical open source culture of following the latest and greatest release. These folk will still get the latest versions of Spring--and furthermore, typically are enterprises of a scale and risk profile that they are happy to pay for rock solid support. From their point of view, the availability of 3 year support from SpringSource is a good thing, and a strong argument in favor of using Spring, rather than a problem. Frankly, anyone who refuses to compile an open source project under any circumstances doesn't really believe in open source: they believe in other people working for them for free. We're proud of the huge contribution we make to open source--not merely in Spring projects, but in Tomcat, Apache HTTPD and many other projects. Anyone who really cares about open source should be willing to read and compile code, or pay for those who create open source to do it for them. Folks who aren't willing to do this can complain, but I have little sympathy for them. Rgds Rod
  42. Re: Overreaction[ Go to top ]

    Rod:
    in contrast to the typical open source culture of following the latest and greatest release. These folk will still get the latest versions of Spring--and furthermore, typically are enterprises of a scale and risk profile that they are happy to pay for rock solid support.
    I don't know about you, but most of us expects the "latest and greatest release" to be a official jar with a specific version, not a snapshot from what the current trunk might look like at the time the bugfix is merged into it. How can the "open source culture" get this release if no new releases will be made after the initial 3 months? All I ask for is to always make the latest release from the current major version of Spring available as official jar from SpringSource. /Magnus
  43. Misunderestimation[ Go to top ]

    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.
  44. Re: Misunderestimation[ Go to top ]

    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
  45. Re: Overreaction[ Go to top ]

    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!
  46. Re: Overreaction[ Go to top ]

    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.
  47. Re: Overreaction[ Go to top ]

    A community that accepts this only harms the open source adoption within the enterprise field: open source often enters being free-good-quality software, especially in the small businesses market.
    Is this not the disconnect which is causing all the grief? It is not the openness of the code it is the price (free) that the vast majority of customers, sorry community, are buying (not commercially that is) into. The last time I was at a TTS conference in Las Vegas we got to hear from SS (then Interface21), Alfresco, and others on how OSS significantly reduced development costs (more like testing if you ask me) and improved the quality of the design and code and yet Rod has just told us all that is costs "millions", yes "millions" to develop and maintain the code base with no one outside SS is in anyway contributing. Someone is clearly telling tales here. Commercial OSS is only free whilst a vendor is gaining market share. This is no different than supermarkets offering goods below cost just to entice customers into the shop and to kill off the competition. The one big difference is that it is illegal in most countries. http://www.competitionbureau.gc.ca/epic/site/cb-bc.nsf/en/01729e.html "....while the Act encourages vigorous price competition, it also ensures that marketplace transactions are conducted on the basis of fair, competitive rivalry rather than through anti-competitive behaviour. Unreasonably low pricing is one example of such behaviour. It means involvement in a policy of selling below cost in order to deter entry into a market, or to force competitors out of a market. While consumers may benefit from the resulting low prices for a brief period, they can be harmed in the long-run if the low pricing leads to diminished competition and, ultimately, higher prices or reduced levels of service, product quality or innovation." It is even worse for the consumer when there is no standard i.e. more than implementation of a runtime or API. William
  48. My thoughts[ Go to top ]

    (Also posted on my blog...) I'm all for SpringSource or anyone else making money. I don't even mind this, not too much, but it's .. weird. It reminds me of Red Hat. They used to have a free version, then monetized, and now they have the redheaded stepchild, Fedora, and the "real version," Red Hat. People who used Red Hat before the commercial version got screwed... and started using Debian (and now, Ubuntu, or in my case, Solaris) or bought the subscription. This is not that big of a deal, except psychologically, and it's a huge warning for companies that leverage Spring. Like mine. Let's be clear here: I like the Spring Framework. I was ambivalent for a long time, even though its strengths were clear, because I thought (and continue to think) their stance towards Java EE is political rather than real, and I wasn't sure that configuration in XML (the Spring way, back in 1.0, 2.0) was really that much better than configuration in XML (the J2EE way.) Sure, it was a lot easier to declare dependencies on instances in Spring compared to J2EE, but then again, J2EE's dependencies were always intended to be "heavier" than Spring's, and that seemed obvious: when your opponent is trying to solve problem A, saying "but they don't solve problem B, which we do" seems... underhanded. But... with Spring 2.5, the gates opened. Namespaces and annotations - particularly annotations - made everything all right. I finally swallowed the ... whichever pill it is that made me believe (sorry, I didn't like The Matrix), and dove in. Spring's now a standard library for my projects. The reason the license change bothers me so much is not the specific change. It bothers me because Spring has done a good job embedding itself in successful projects, and now they've shown that they're willing to change the license. Customers who buy our application server are going to be using Spring, because we leverage the heck out of it. Now they're forced (for all intents and purposes) to buy a Spring license, too. Chances are, they already do this, but that was their choice. How do we know Spring's not going to change their license again to something actually onerous, and not just annoying like this one is? Answer: we don't. Just like a man who's had an affair can never be trusted the same way again, Spring's jilting us - even in a minor way - and we can never trust them like we did. Thanks, SpringSource. I've appreciated everything you've done, even from afar - and yes, I know, you've held my "not-a-fanboi" stance against me - but now I feel like I was right for listening to my gut feelings. I'm checking out Guice. If the transaction management stuff is easy enough, we can switch it in as an alternative to Spring.
  49. Re: My thoughts[ Go to top ]

    Hi Joseph, You and your company would not be so peeved if you had given risk management much more than lip service. Hint: open standard versus open source code? I suspect there would have been more external contributions than there is currently. William
  50. Re: My thoughts[ Go to top ]

    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.
  51. Re: My thoughts[ Go to top ]

    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.
  52. Re: My thoughts[ Go to top ]

    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
  53. Re: My thoughts[ Go to top ]

    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.
  54. Re: My thoughts[ Go to top ]

    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?.
  55. Re: My thoughts[ Go to top ]

    It will be discounts of something like that for small and medium business?. It will be affordable the license fee for Spring framework maintenance?.
    The SpringSource Enterprise subscription not only includes maintenance and support, but offers additional features above Spring, including the SpringSource Tool Suite, SpringSource AMS and advanced integration with Oracle RAC and AQ. Subscription is priced per CPU unit/developer, so costs are modest for small and medium businesses. There's also of course the option of compiling from the source for free--there's no license needed for that. Rgds Rod
  56. Re: My thoughts[ Go to top ]

    Thank your Rod for your answer, I really appreciate it. Regards.
  57. Re: Overreaction[ Go to top ]

    Rod,
    This policy does affect users who think that open source is a way for them to get extended maintenance of high quality enterprise software for free, without them lifting a finger. These are typically companies who can't or won't upgrade to the current version of Spring--in contrast to the typical open source culture of following the latest and greatest release. These folk will still get the latest versions of Spring--and furthermore, typically are enterprises of a scale and risk profile that they are happy to pay for rock solid support. From their point of view, the availability of 3 year support from SpringSource is a good thing, and a strong argument in favor of using Spring, rather than a problem. Frankly, anyone who refuses to compile an open source project under any circumstances doesn't really believe in open source: they believe in other people working for them for free.
    while I agree with you on your point that companies who use the Spring framework in their productive environment should be able to pay for professional support, I still have a problem with abruptly changing terms in the middle of the game.
    In many projects I have worked on, an evaluation of the technology to use was based on various aspects and licensing costs being one of these aspects. In those cases were Spring was chosen to be base technology, I will now have to tell our customers that things have changed and that they will have to buy commercial support if they want to receive critical updates in a timely manner. They will not be happy about that.
    For upcoming projects, I do not have a problem with the new Spring maintenance scheme as I can inform the customer what to expect and then they can make their decision on that basis. What I really dislike are the reactions of those customers who I recommended Spring to and who will now be unsatisfied with my advice. J.
  58. Re: Overreaction[ Go to top ]

    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
  59. Re: Overreaction[ Go to top ]

    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.
  60. Conversation[ Go to top ]

    Martin, Thank you for your thoughtful questions.
    SpringSource's announcement clarifies the relationship that the Company wishes to have with its Enterprise users and it does it in a reassuring way. The statement does not say enough about what relationship the Company wants to have with its "Community" users : those who have enjoyed the product for free. I have not made any contributions to the success of SpringSource (other than one JIRA report) - but I've bought the books, I've been to the Conferences, I've banged my head against the wall to get the stuff to work and I've married my career to it. What kind of a relationship does SpringSource want to have with people like me in the future? As someone suggested, this would make an excellent subject for your next blog, as there are a number of voices in this thread who think that from now on the "Community" doesn't matter any more in your business model. I'm inclined to disagree - I would say that if the "Community" disappears, so will the Spring Framework. What do you think ?
    Blogging about this topic is a very good suggestion. We care very much about the Spring community, and these changes are not intended to hurt it. I would definitely class as "overreaction" much of the wild speculation on this thread, including references to license changes and many posters apparently not reading my or Mark's comments. Perhaps a blog would help to establish a more productive conversation. We do always try to listen to feedback from the community--which doesn't include anti-Spring zealots who have lost the technical arguments over the years, are always clutching at straws to support their position and don't care in the least for the Spring community. Equally, the community should listen to our position, consider the enormous contribution we have made and will continue to make to open source and understand that enterprise customers being further incented to pay towards production usage is in everyone's interests. Rgds Rod
  61. Overreaction? Pardon?[ Go to top ]

    Rod, I have been, and still am, a very happy user (and evangelist) of Spring, for which I really thank you. But these two assertions:
    [...] Frankly, anyone who refuses to compile an open source project under any circumstances doesn't really believe in open source: they believe in other people working for them for free.
    and
    [...] Anyone who really cares about open source should be willing to read and compile code, or pay for those who create open source to do it for them. Folks who aren't willing to do this can complain, but I have little sympathy for them.
    ...are, imho, dramatically wrong, and, sincerely, I feel quite affected by them. I cannot say "insulted", that would be too much, but frankly I don't feel fine reading things like these. I believe in open source. Period. I have founded myself three open source java projects in the last four years (of which I abandoned the first one, and I am about to publish the third); I have invested lots and lots and lots of my sleep and spare hours in creating open source code for free, while working for a non-os software company during the day. So I always thought that I could say I belonged to the open source community in any of its definitions. Yet, I never compiled the Spring Framework, and I will probably never do. So I am confused... maybe I don't belong to the open source community as you define it, do I? Do you refer to the open source community or instead to the Spring contributors community?. Are they the same for you? If I don't compile Spring... do you really think that what I believe in is people working for me? I will read your code -as I have done many times-, but I will not compile it to create my own version in case you release a bug fix I need. In that case, I will simply avoid using your bugged feature somehow, and go on. Don't you feel sympathy for me because of that? Well, I'm sorry. I never intended to make you feel unhappy about me. In fact, I certainly feel sympathy for you, as you created and contributed some incredible, milestone software to the java industry. Even if you aren't willing to compile my open source code. And why won't I compile and create my own bugfixing release of Spring? Just because, and you certainly know this, releases are much more than a ".jar" file in a maven repo. They are also a reference. A version. Versioning is a basic tool in software development management, which allows us to be able to know that we are using exactly the same version of this or that among our set of open source dependencies. If we now have to compile ourselves Spring whenever a new bug is fixed... how many unofficial versions of Spring will there appear? Thousands. And not for adding specialized features here and there, as it would be normal with standard open source, no... Just for adding official bug fixes. Oh, well... bye bye, version control. Welcome chaos. You certainly know this. And you certainly know, also, that creating packages for minor releases once you have the code in your repository is not real "effort". Come on, people's effort creates the bug-fixing code, people's effort creates documentation for each major release... but it's scripts that create the release packages most of the times. Once you already have that code in your source repository, real effort has already been invested. So I find your releases mean effort for us argument quite weak. This said, I understand this is only a marketing move by SpringSource. You make things a little more "tasty" for your corporate, spring-licensing customers (most of which will probably not even understand the difference)... at the cost of making things more uncomfortable for the real people who made Spring be where it is: those who use it without ever remotely considering about compiling it. The simple users. Of which your named open source community, believe me, are only an incredibly tiny subset. And many of those users, Rod, are now angry. Not because this really affects them, as it probably doesn't even if they think it does. They are angry because you changed the rules of the game in the middle of it. And that creates frustration and an important lack of confidence. If you do this... which will be your next steps? Maybe reducing that three months to one? Maybe discarding freely available releases and making everyone go to the source repository?... not good, not safe enough. Many of the people who made Spring so popular simply because they used it (yeah, you know, they liked others working for them) are now considering switching to other safer alternatives. Or do you really believe that Spring is so popular because of your bunch of licensing customers or the hundreds (maybe some thousands) of patch contributors? ROFL. You need much more people to get where you are. You need enormous amounts of plain users. But don't get me wrong... can you do this? Of course, it is YOUR product. Will it make me stop using Spring? no way (or at least not until you change the game again, which I am afraid you will). Will you lose user base... I am sorry to say "Yes. A lot". How to change this and avoid the "SpringSource-has-propietarized-Spring" hype that is about to start and probably make your product lots of harm? imho, easy: Just apply that "three-month-only" condition to minor releases in old major releases. This is, if you are in 4.0, release freely all 4.0.x versions until you release 4.1. Once you have 4.1 released, release 4.0.x's freely just for a period (or even don't do it at all) and make people pay for any further 4.0.x bugfixing releases. At least this way you will offer a "way out" to your users: move forward, just switch to the new version. If they don't want to... well... anyone would think it is fair to pay for that. No one will question your open-sourcedness in that scenario. In brief, in my country we say "you shouldn't bite the hand that feeds you", and I truly believe you have just done it. But hey, I am not a marketing strategist... they probably know better. About marketing, I mean. Or maybe I just didn't understand a thing about what is being discussed here... which, of course, can be. English is not my native language and well... In that case, I humbly apologise. Regards, Daniel Fernández Jasypt project leader
  62. Hi Rod, Could you develop please when you speak about huge contribution to Tomcat and Apache HTTPD ? I know very well the Tomcat community (developpers / commiters), and today the largest company support came from JBOSS/Redhat people. That's why I'll be happy to know where and how you contribute to Tomcat / Apache HTTPd ?
  63. SpringSource (through it's acquisition of Covalent in January) has been very active in the Apache Tomcat and HTTPD projects for many years. In fact, over the past two years more than 75% of the commits on Apache Tomcat have been made by SpringSource employees. And our engineers have been the most active members on the Apache HTTPD project for more than five years. This is not to say that we "own" those projects as that is not possible , however, it does show that we are very committed and significantly involved in them. Our support and committment to the Apache Software Foundation and these projects in particular - Tomcat and HTTPD - will continue to grow. - Mark Brewer
  64. By that same logic then Oracle has in competition with itself for a number of years actively contributing to WebLogic.
  65. 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.
  66. Springsource manifesto[ Go to top ]

    http://blog.springsource.com/main/2008/05/27/open-source-open-strategy-the-springsource-manifesto/ Not much in there seems to be valid anymore, only 4 months later. How come? /Magnus
  67. Re: New Spring maintenance policy[ Go to top ]

    Link works for me...
  68. A little disappointed[ Go to top ]

    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.
  69. Such are the perils of commercial, company-driven, vc-founded 'open' source. However there is a positive aspect in this move. The unfounded, marketing-driven ("the de facto standard in enterprise Java") Spring hype is definitely over. Great!
  70. Re: More than a little disappointed[ Go to top ]

    +1
  71. +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.
  72. Also highly disappointed[ Go to top ]

    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.
  73. Re: Also highly disappointed[ Go to top ]

    ..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.
  74. 3.0[ Go to top ]

    Grant
    I noticed Spring 3.0 is not being actively worked on in any public repository. It seems the Spring 3.0 development has been very secretive and less transparent than any other version previously. No JIRA issues for 3.0M1 have been resolved and no code committed on the public repo.
    Nothing mysterious here. Most of the work thus far has been on the feature set and prototypes on individual developers' machines that aren't ready for any repository. The focus of development is about to shift to 3.0 and there will be code to see soon. Remember 2.0M1, and the amount of code that only appeared in CVS just before the release? -- because that's when it got written. Rgds Rod
  75. Thanks![ Go to top ]

    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.
  76. +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.
  77. Re: More than a little disappointed[ Go to top ]

    ... 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.
  78. Re: More than a little disappointed[ Go to top ]

    ... 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?
  79. 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
  80. 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.
  81. Re: More than a little disappointed[ Go to top ]

    Wake me when a real problem arises.
    +1.
  82. Re: More than a little disappointed[ Go to top ]



    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.
  83. The blogshere already chimes in[ Go to top ]

    "Spring tried to reinvent every library under the sun while ignoring great existing solutions like XFire." "If you are a technology manager, and you care about the future of open source, please consider not financially supporting any open source company that consistently betrays the trust of their users." http://abotar.com/blog/2008/09/20/are-all-funded-open-source-companies-destined-for-the-dark-side/
  84. Re: The blogshere already chimes in[ Go to top ]

    http://abotar.com/blog/2008/09/20/are-all-funded-open-source-companies-destined-for-the-dark-side/ "One company that should be especially concerned is G2One, the company behind Grails. Grails is built on Spring, and is enjoying increasing awareness and the impending release of a book....This disturbing SpringSource trend could tip the scale and derail Grails." It is worth noting that both G2One and SS are backed by the same VC so I am not sure they see such a concern as real. William
  85. Re: The blogshere already chimes in[ Go to top ]

    It is worth noting that both G2One and SS are backed by the same VC so I am not sure they see such a concern as real.
    Same VC, no problem. Commercial 'open' source at work. Oh the irony ...
  86. 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?
  87. What does it mean?[ Go to top ]

    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
  88. Re: What does it mean?[ Go to top ]

    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.
  89. Re: What does it mean?[ Go to top ]

    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.
  90. Re: What does it mean?[ Go to top ]

    Hi Mark,
    However, the code for fixes will be in the public open source tree.
    So what is the difference other than the commercial version is packaged, patched, distributed and supported for paying customers? I would assume you are trying to reduce operating costs with this move and only committing to the additional effort when it is paid for by subscriptions. What is the organizational effort in having both minor & major release streams for the community and customers? Is the effort so great that it consumes a significant amount of the company's revenue which apparently has doubled this year. SpringSource Grows Business Over 250 Percent http://www.springsource.com/node/549 William
  91. Re: What does it mean?[ Go to top ]

    Yes, the community will receive any set of fixes (i.e. 3.0.1, 3.0.2, etc.) that are made during the first three months after a major release. From that point forward, until a new major release (which means a change in the number on either side of the first decimial point - 3.1 or 4.0 would both apply), only SpringSource Enterprise customers will receive further maintenance releases.
    You do realize that that policy would make the current Spring 2.5 branch unusable if it was applied to that branch? Then most of us would be using Spring 2.5.1, and not the current 2.5.5. What will be the policy for how often a new major release will be available? What will be the policy for new features? Does this mean that all new features always go into a new major release? /Magnus
  92. Re: What does it mean?[ Go to top ]

    Yes, the community will receive any set of fixes (i.e. 3.0.1, 3.0.2, etc.) that are made during the first three months after a major release. From that point forward, until a new major release (which means a change in the number on either side of the first decimial point - 3.1 or 4.0 would both apply), only SpringSource Enterprise customers will receive further maintenance releases. However, the code for fixes will be in the public open source tree.

    As Gabriel points out, Enterprise customers will have the added benefit of 3 years of support for any major version that they are running.
    Actually, I can live with that. In our use, Iwehaven't encountered any major bugs and only upgraded to major releases anyway. Even then, we tested the release and only deployed if we didn't have any issues. So, , just looks like a play to demostrate value-add to paying customers. I got no beef with it.
  93. Re: What does it mean?[ Go to top ]

    Dear Rod, what i totally dislike about SS decision is that it is based on a principle which is the most negative possible for open source projects: "in order to force companies to give money to SS, instead of giving additional advantages to the paying customers, let's force disadvantages to the non-paying customers". i am a paying user for several "enterprise" solutions even when a "community" edition is available but, if i understand well your sentences, i will never be an enterprise customer of SS because you are simply unfair. I had great times with Spring, i developed very good and successful projects with Spring, and even if i did not wrote a single line of spring code, i contributed giving help on forums, blogs, ... Well, life began to be boring after so many years of Spring: you gave me the right kick in the ass to start finding something new, more interesting, more innovative and, finally, more fair. So long Spring
  94. Re: What does it mean?[ Go to top ]

    is the most negative possible for open source projects: "in order to force companies to give money to SS, instead of giving additional advantages to the paying customers, let's force disadvantages to the non-paying customers
    I think this is an excellent point and it highlights the unimaginative nature of the way SpringSource has decided to capitalize on their work. I'm not at all against Spring Source making a lot of money from their open source product. But keep the product open source. The very reason of Spring's success is it open source nature. Nobody would know the name "Spring" today if it hadn't been an open source project. As great as it is technically, no-one would have cared to integrate their own projects towards Spring. I guess letting a great techie run a corporation, is like promoting your top auto mechanic to manager. You're not doing what you're best at and start f..... things up. There are many more imaginative ways to make money of Spring and by forcing disadvantage on non paying customers, i.e. the community, you're attacking the core of your success. "Everybody" uses Spring because it's a great tool AND it's open source. Unbelievably short sighted. Swallow your pride and go back while you still can. Cheers, Marc
  95. Re: What does it mean?[ Go to top ]

    Spring Framework is an Open Source project that reuse the work of other contributors and projects. They didn't do alone it was all the Java community that supported this folks and now they gain and want more but now just gives us the back. They make money this way: "We make money by: * Providing world class support and services. This includes dependable 24×7 support, outstanding training and consulting services and indemnification for enterprise customers who are understandably risk-averse. * Adding subscription products that deliver value to complement the Spring Portfolio. * Selling subscriptions to enterprise editions of our full-stack products." They sell the full-stack that Im agree but we the community and contributors just ask something in return let the DI intact and opensource and just try to fix the bugs so others can use it and don't put restrictions on the DI container, that's all. Or if I'm wrong correct me please.
  96. I think it is fair[ Go to top ]

    Yes, the community will receive any set of fixes (i.e. 3.0.1, 3.0.2, etc.) that are made during the first three months after a major release. From that point forward, until a new major release (which means a change in the number on either side of the first decimial point - 3.1 or 4.0 would both apply), only SpringSource Enterprise customers will receive further maintenance releases.
    Given that major releases include both first and second digits (i.e. 3.0 and 3.1 will be considered major releases) I think it is completely fair. I also assume that there will be only one source tree, so if developers want to get the latest and greatest (and riskiest) they can (similarly with RedHat). Enterprises want to mitigate risk, so they will probably stick with the official versions. Spring is a great framework and would not be so without many people working full time on it. We, as a community, need to be agile and allow SpringSource to be an strong entity so as SpringSource can continue to innovate. I think that given the above SpringSource is striking a good balance of community and commercial value. This actually compares pretty well against other OpenSource solutions such as RedHat and MySQL.
  97. springframework.org free?[ Go to top ]

    Is springsource.com not just a commercial offering of Spring? Seems you can still always get Spring free from http://www.springframework.org/
  98. The scariest thing[ Go to top ]

    No comment from anybody at SpringSource so far...
  99. Re: The scariest thing[ Go to top ]

    No comment from anybody at SpringSource so far...
    I responded just a few minutes ago ... and I work for SpringSource. Mark Brewer
  100. The end of a over-hyped framework[ Go to top ]

    I have to admit that until yesterday I was ranting with my colleagues; my company wants the legal department to have the last word, when a product is making use of open source libraries and frameworks. Now I understand that. Thanks SpringSource for contributing in taking your framework out of the market, and thanks for increasing the mistrust companies in general have towards open source. Who knows, maybe Tapestry 5, after receiving so many insults, will suddenly become trendy? Will its IOC container be the next must-have-in-my-cv technology? Just one last question - how will SpringSource merge the non-opensource license fixes with the opensource ones when developing the next major release? Will be interesting to know.
  101. Count your blessings....[ Go to top ]

    http://news.cnet.com/8301-13505_3-10046470-16.html Matt @ Alfresco "My only question is whether the company should even be providing those first three months of bug fixes on community distributions, given that this might be considered a service for which Spring users should pay."
  102. Re: Count your blessings....[ Go to top ]

    http://news.cnet.com/8301-13505_3-10046470-16.html

    Matt @ Alfresco "My only question is whether the company should even be providing those first three months of bug fixes on community distributions, given that this might be considered a service for which Spring users should pay."
    Yeah, that's Matt for you. Of course everybody should also have to fill out forms and take paid exams before we are worthy to drop our infidel bugreports or completely misguided patches into JIRA. How dare we?
  103. Re: New Spring maintenance policy[ Go to top ]

    Extremely disappointing...
  104. Fork?[ Go to top ]

    Would it be legal according to the APL? Just asking...
  105. Re: Fork?[ Go to top ]

    I think you share the same concern of many developers. I am not a legal man, but I believe that if Spring, holding an open source license, begins incorporating amendments released under a commercial license, then it cannot hold an OS license anymore.
  106. Bye Bye Spring![ Go to top ]

    we realy had a good time...
  107. As far as the announcement goes, they are repeating other companies' mistakes by the book - fascinating to see. Not only is it questionable to ship bug fixes to "enterprise" customers first without greater exposure to the larger world (remember: other people can program and find bugs too!); accelerated deployment cycles are usually the *last* thing that paying customers want because most already have enough problems on their own. MySQL did exactly the same, the whole thing backfired spectactularly and people still got "enterprise" builds from ProvenScaling. Net benefit: a lot of shit on their shoes. AFAICT everybody wants SS to be profitable and successful in the future, but the wording and ambiguous interpretation of this "policy" is very unfortunate.
  108. That was expected,and expect more...[ Go to top ]

    since springSource first changed its policy in licensing and decided to release their new app server under the GPL ,i expected a major switch in their policy toward the community,this remind me of the attitude company behind ExtJs ajax library where after becomming a major player and got a tremendous code and feedback from the community,changed their license from bsd to lgpl to gpl forcing every one to purchase a commercial license what i wanna say here that we must expect more community unfriendly steps from springsource ,first new products under different license,then change in the support strategy,then......(imagine). they begin the chain reaction and trust me ,it will continue joe
  109. Fu** SpringSource!!, That is all I will say. We the community helped and contributed to grow Spring Framework and with this is like a stab on the back. Welcome EJB3.1 and the standard, I think I have to take a serious look at Seam or another alternative maybe Guice?. Spring Source just ruined it self. Mr.Rod I hoped more from you, Really, I hoped you ware our savior but it resulted with the same sh** as everything in the Open Source.
  110. SpringSource is playing with fire here really this could be their dismiss with the Java community. This will be the point when begin the forks and alternatives and this will fragment more the community. This is a bad move, and Yes I'm pissed with this news.
  111. I will not pay a dime just for the DI container, If I need all the stack and portfolio of SpringSource ok I will think about it but just for the DI Container I will have to pay?, nope, better I wait for EJB3.1 the "STANDARD" or I could use Guice or even Tapestry 5 DI container.
  112. Just fork the source[ Go to top ]

    Since spring uses APL, just fork the code. Isn't that the whole point of using APL license. You can take it and monitize it, or fork it.
  113. Re: Just fork the source[ Go to top ]

    Since spring uses APL, just fork the code. Isn't that the whole point of using APL license. You can take it and monitize it, or fork it.
    And this will probably happen, sooner or later *if* this policy should be executed literally (and probably will be). Thanks God Spring Framework is not rocket science, and we have great community around. Artur
  114. Re: Just fork the source[ Go to top ]

    Since spring uses APL, just fork the code. Isn't that the whole point of using APL license. You can take it and monitize it, or fork it.
    You have the code. You don't have the name!
  115. Re: Just fork the source[ Go to top ]

    Since spring uses APL, just fork the code. Isn't that the whole point of using APL license. You can take it and monitize it, or fork it.

    You have the code. You don't have the name!
    What good is the name? all I care about is code and being useful.
  116. Re: Just fork the source[ Go to top ]

    Since spring uses APL, just fork the code. Isn't that the whole point of using APL license. You can take it and monitize it, or fork it.

    You have the code. You don't have the name!
    Well, then let's call it "autumn", this has worked for other programs also (more -> less ;)
  117. Re: New Spring maintenance policy[ Go to top ]

    Since I work for big enterprise and we use spring framework for virtually everything, and I'm also active member of spring framework community and also work for my side projects (based on Spring) I have two standpoints: * Enterprise perspective. Virtually every enterprise requires *support* and *maintenance* for products they use. In the case of Open Source it means 'healthy community' at least. Without this we cannot use bits. Take into account Spring Framework now - after 3 months since major release, without Enterprise Subscription, I wouldn't be able to use spring. As I'm unable to use Windows NT on workstation. As simple as this. Having said that - I'm fine with the paid support/patches. But I really don't like when rules change during the match. Really. Moreover - before spring beat everything because of price/value ratio. Now, it's not so obvious - maybe WebSphere or Bea will win in the next run. I should rethink my EJB 3.0 standpoint. But, even I don't like the idea I have to maintain one more contract, I see more serious problems. We use lot of 'spring based' stuff. And don't tell me that 'OK 3 months support is enough'. See CXF or Grails as perfect example. They discover *serious* problems with Spring a Year after release. Even though I have Enterprise license - CXF guys, for example, probably won't. Should I use different versions of spring for my infrastructure and for CXF? It doesn't make sense. * Open Source perspective - is even worse than Enterprise one. How will You, for example deal with critical security hole discovered 4 months after release? I don't tell You about minor features, or minor bugs. How we could deal with bugs? Since most of the modern Web frameworks base on Spring (Struts2, Grails etc.). I still hope that I misunderstand this policy. But in the other case I see no other choice, than just... fork Spring Framework. Hopefully we have a lot of supporters available (thousands of projects on Apache, code house, some brilliant companies, lots of developers - probably Apache umbrella would be perfect choice). Well, never thought I could say this. But this may be the best choice, in this - worst - scenario... Artur
  118. Re: New Spring maintenance policy[ Go to top ]

    I have a big personal investment in Spring. If I were just a regular user, then might be thinking seriously about just dumping Spring and going for something a bit more open, even if (to begin with) it was a bit inferior. Instead, I have spent a lot of time working on a framework which extends Spring to add features that you won't find elsewhere. It's not something that I would want to throw away. The direction that Spring is going at the moment does disturb and depress me. When Spring first came out a few years ago, it really was a breath of fresh air. It's beginning to smell a bit stale for the wrong reasons. It's one thing to have value added products (tools, etc.) available on a commercial basis. It's another to have a different release policy on existing open source products, which effectively makes open source users second class citizens in its user base. My advice to Rod Johnson - stop trying so desperately hard to make money out of Spring. There are better ways of creating a billion dollar company. Instead, put more effort into retaining the values that made Spring great in the first place. Phil Zoio http://impala.googlecode.com/ - Impala dynamic modules for Spring Spring reloaded, fast and simple!
  119. This is Classic!!![ Go to top ]

    Rod, you are the man! I personally hate how this policy applies to new releases, and think it is a bad move on your part. But I have to admit I have a pretty big smile on my face right now. I love how you just gave your community the big middle finger. I like Spring, but have never liked Spring fan boys much. At lest this move will most likely shut them up. ha ha ha ha
  120. Re: This is Classic!!![ Go to top ]

    Damn it, This is so Hilarious, Specially the middle finger to the community. Bye bye Spring, It was great until last.
  121. Re: This is Classic!!![ Go to top ]

    I believed Spring framework already was a standard more than the expert group more than JCP even more than SUN, Springsource make their money with consulting and another extra to the stack but this just ruined all, This ruined Rod vision of lightweight middle-ware as standard, Maybe SpringSource now got to much ambitious. It is sad but well I have to stop believing and dreaming and go back to the real thing the standards, anyway are not bad they are based on Spring idea, thanks god. As I said, Bye bye Spring. Peace everyone.
  122. it was about time...[ Go to top ]

    to move on to something else. In my opinion too many things already depended on Spring (in many projects) - so it was about the time to do some cleanup. thanks to SpringSource
  123. Hilarious[ Go to top ]

    As Mikael and others already commented, the psychological ramifications are much greater than anything else and this has been a hilarious blunder from spring source to not to manage the discussion on the subject. Great way to give finger to the community and people who have spoken so fondly about Spring framework and made it's adoption to what it is. Great job. Really. Realistic options for people building on top of spring are either: 1) pay the subscription 2) take risk with trunk 3) keep on upgrading Spring constantly in your software and having the trouble of weeding out bugs while maintenance releases are still given, and hope that next release will come soon 4) fork Option 1 might not be a bad option, but as the licencing prices and structure are not available online it is hard to know. Can anyone here spill out the beans and tell how much the licences cost? Options 2, 3 and 4 all sound and feel crappy choises unless lots of people pool resources together and form similar structure as Centos is to Redhat EL. Many of use don't need the 3 year maintenance that enterprise customers like to have, but don't either want to be left dark and work with the unknowns as Spring Source's current plans would mean. As I've made large commitments to skills in Spring, I'm not yet about to dump it. But let's say that this has opened up our previously almost monogamous relationship status to 'Complicated' or 'Seeing someone, but looking'. Disappointment. Oh well. Times are changing.
  124. Re: Hilarious[ Go to top ]

    Option 1 might not be a bad option, but as the licencing prices and structure are not available online it is hard to know.
    I'm not sure, here. Ok, I have no problem ask my manager to pay SS maintenance fees. But, the problem is that what I get is... spring framework itself. Since Spring is infrastructure stack, it is obviously, not only used by my code. It's used by a lot o bits I do use - CXF, Grails, Struts2, WebWork, ActiveMQ and lots of other spring-based stuff. Now what? If guys from CXF will find bug in Spring - how they get it fixed, and being fixed back for them? There are a lot of cases as such in Spring JIRA: http://jira.springframework.org/browse/SPR-4584 Artur
  125. Re: Hilarious[ Go to top ]

    I'm not sure, here. Ok, I have no problem ask my manager to pay SS maintenance fees. But, the problem is that what I get is... spring framework itself. Since Spring is infrastructure stack, it is obviously, not only used by my code. It's used by a lot o bits I do use - CXF, Grails, Struts2, WebWork, ActiveMQ and lots of other spring-based stuff.
    True, it is clear that this change has great implications for lots of projects - Mule being first in mind for me as they went the spring way for version 2. But let's play a little and think about a positive scenario. Spring source releases new versions quite often, putting out new point release roughly every three months. Every release includes nice fixes and feature upgrades. Updates are most of the time designed to be as drop in replacements and most of the time we could continue with life as it was before... Except if the time between releases is more than three months and community is left in the dark. Not so positive scenario after all. There was a good suggestion in the thread about having bugfixes to the community in timely fashion untill a newer version is available. It would be fair for the community and set the commitment between SS and the community to play well with the latest and greatest, and aim for subscription in cases where you want to have the stability of one specific version for longer time. It will be fun to see what are the end results of this change - as people have made large commitments to spring and clearly will feel betrayed. I would hate to see this lead to another framework war, where things are reinvented just for the fun of it and net results is having lots of unnecessary competition that just divides the mindshare and skills. Spring's adoption is still it's greatest asset. Though many of the people responsible for it's wide adoption in real life have not made any commitments to the codebase, they have made lot of the work to bring spring into the status where it is now. It is huge misjudgement on behalf of SS to just piss on the hand that has not directly fed it, but has been opening doors and has been in vocal support of it everywhere. This change might actually not be a big deal, if new releases are done in timely fashion and life goes on normally. But as so many have already pointed out, this policychange changes the implicit contract that the community and spring source has had about the latest and greatest. Let's say that three months has passed since the latest release and a major bug is discovered within the core or let's say for example in spring security. If you were the product manager at Spring Source, wouldn't you be tempted to _not_ to push the next release out fast - but rather wait for people to hop on board with subscriptions or see people to try to patch their setups on their own. And as is said in: http://enigmastation.com/pebble/default/2008/09/21/1222008840000.html "How do we know Spring's not going to change their license again to something actually onerous, and not just annoying like this one is? Answer: we don't. Just like a man who's had an affair can never be trusted the same way again, Spring's jilting us - even in a minor way - and we can never trust them like we did. " Yep. Nicely played Spring Source!
  126. The actual change: no binaries[ Go to top ]

    Aside from the large "Let's burn the Spring logo" sentiment I understand that this whole change boils down to: "You'll get binaries only in the 3 month period after the major release." This isn't a great tragedy as it seems. Many OSS projects do not provide binaries for all platforms in the world. Do you get Windows binaries for your [insert-favourite-linux-project] by default? Usually, they are built and distributed by a passionate fan who provides them to the community. What prevents the community to follow this model? (As the source is available in the repository, the only concern is to download and build the binaries in the intermediate period and distribute them accordingly.)
  127. Re: The actual change: no binaries[ Go to top ]

    I understand that this whole change boils down to:
    "You'll get binaries only in the 3 month period after the major release."
    If you are right that would be fine. The real clarification of this is still missing. As far as I understand, fixes to a more than 3 months old version will be available publicly only in new major versions. I doubt fixes made for one of the 'subscription' clients to an older versions will be available in any public repository - binary or sources. Otherwise we would have another company compiling them and selling the subscription for less .... So the choices boil down to risking a (hopefully available) new major version with potential new bugs or buying the subscription, should a bug arise.
  128. Re: The actual change: no binaries[ Go to top ]

    Ingo
    I understand that this whole change boils down to:
    "You'll get binaries only in the 3 month period after the major release."

    If you are right that would be fine. The real clarification of this is still missing.
    You're exactly right, and such a change hardly justifies the overreaction on this thread. Both Mark Brewer and I have clearly stated that we plan to leave the source open--that message just seems to have gotten lost through folks jumping to conclusions. For example, contrary to the more far-fetched speculation, we are not contemplating any license change. What we are doing, as various posters point out, is very similar to a number of other successful projects. Rgds Rod
  129. Re: The actual change: no binaries[ Go to top ]

    Rod Sorry, you might have meant to be clear, but I'm not clear, yet. Can you categorically promise that all fixes made to the sources, incl. former versions, will be publicly available in a repository? Even if that fix has been made three months after that release. To avoid more confusion: - V 3.0 comes out - V 3.1 comes out three months later - subsequently a bug is found in 3.0 - you fix it for a subscription client - I can go into a free and open repository and retrieve source code for version 3.0 (let's call it 3.0.1) that includes the fix. Can you state the above is true?
  130. Re: The actual change: no binaries[ Go to top ]

    Ingo
    Rod Sorry, you might have meant to be clear, but I'm not clear, yet. Can you categorically promise that all fixes made to the sources, incl. former versions, will be publicly available in a repository? Even if that fix has been made three months after that release. To avoid more confusion: - V 3.0 comes out - V 3.1 comes out three months later - subsequently a bug is found in 3.0 - you fix it for a subscription client - I can go into a free and open repository and retrieve source code for version 3.0 (let's call it 3.0.1) that includes the fix. Can you state the above is true?
    Correct. We intend to continue to expose all our code to the open source community. Rgds Rod
  131. Re: The actual change: no binaries[ Go to top ]

    Rod,
    Ingo
    Rod
    Sorry, you might have meant to be clear, but I'm not clear, yet.
    Can you categorically promise that all fixes made to the sources, incl. former versions, will be publicly available in a repository? Even if that fix has been made three months after that release.
    To avoid more confusion:
    - V 3.0 comes out
    - V 3.1 comes out three months later
    - subsequently a bug is found in 3.0
    - you fix it for a subscription client
    - I can go into a free and open repository and retrieve source code for version 3.0 (let's call it 3.0.1) that includes the fix.
    Can you state the above is true?

    Correct. We intend to continue to expose all our code to the open source community.
    Rgds
    Rod
    How can this be true when the press release reads "Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software." ??? This is getting more and more confusing for every "clarification" you make. I have on my agenda to become a SS Enterprise customer next week, I sure hope the info I get then is better than this. /Magnus
  132. Re: The actual change: no binaries[ Go to top ]

    Magnus
    How can this be true when the press release reads "Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software."???
    My statement that "We intend to continue to expose all our code to the open source community" is perfectly consistent with the press release, which talks about community releases. We plan to check in bug fixes, but there will be no further maintenance releases. Rgds Rod
  133. Re: The actual change: no binaries[ Go to top ]

    Ok the clarification sounds much better. But what is the difference of bug fixes and maintenance releases?. I think this would be much better in a blog to clear more this mess. Regards.
  134. Re: The actual change: no binaries[ Go to top ]

    We plan to check in bug fixes, but there will be no further maintenance releases.
    Thank you for this clarification. This more or less clears any confusion, and will make it much more easier to justify to people to continue to invest in spring and also consider spring enterprise purchases when the need arises. If possible, I'm looking forward clarifying blog post where people could be directed to see what these changes in reality mean. Even though the press release and statement were well worded, they had the unfortunate opportunity for many of us to misunderstand the intent and what would it mean.
  135. Branches[ Go to top ]

    Rod, I've looked into the release history of 2.0.x Springframework. It was released 3.10.2006 - so if I understand the release changes correctly, the latest 2.0.x release the community would have get is 2.0.2, which was released 08.01.2007 if the release policy would have been like the new one, right? So, all the fixes from 2.0.3. - 2.0.8 would have been made to the trunk, which then would have been the trunk of 2.5.x, right? If I understand this correctly this means, that I can't just check the code out and compile it, but I've to merge the cahnges made to the "Community" trunk to get the fixes into the 2.0.x branch. Is this correct? This would mean that I have to know which classes have been changed for the fixes I need and I must be careful not to merge in changes from the 2.5.x trunk. If there are bigger changes in the branch this could also mean, that I can't merge the fix back and I would have to implement the fixes for myself. Is this correct? The other question is which version should I use if the new release is not released yet. Version 2.5 was release 11 month after 2.0.2, which would have been the last released 2.0.x version under the new policy. Does that mean an "Open Source" user would have to use the trunk builds until the release? Is the trunk stable enough? A lot of questions...would be happy to get some clarification as a Springframework user, Springframework fan and SpringSource partner. Mirko http://blog.codecentric.de
  136. Branches, merging, building[ Go to top ]

    I've looked into the release history of 2.0.x Springframework. It was released 3.10.2006 - so if I understand the release changes correctly, the latest 2.0.x release the community would have get is 2.0.2, which was released 08.01.2007 if the release policy would have been like the new one, right? So, all the fixes from 2.0.3. - 2.0.8 would have been made to the trunk, which then would have been the trunk of 2.5.x, right?

    If I understand this correctly this means, that I can't just check the code out and compile it, but I've to merge the cahnges made to the "Community" trunk to get the fixes into the 2.0.x branch. Is this correct?
    Assuming the above is true then necessity of building new release is not only issue for "Community". Main and the most important issue is need of merging changes/fixes from trunk to branch of last maintanance release for Community. Rod, am I correct?
  137. No binaries, but CVS version tags?[ Go to top ]

    Hello Rod,
    We plan to check in bug fixes, but there will be no further maintenance releases.
    An additional question. Will the Spring CVS still contain CVS version tags for maintenance releases not made available to the community? If so, we can just check-out the source code based on the version tag and and run 'build alljars' on the source tree (which I just did on Spring 2.5.5 to check out the build system used). So, if this is the case, what is the added value for the Enterprise users? Just that they don't have to checkout a CVS version and run 'build alljars'? I just don't get it anymore. This just makes it annoying for community users to retrieve the latest maintenance release, but you can still get in about 20 minutes (depending on the speed of the CVS, the build runs in under a minute).
  138. [...] I just don't get it anymore. This just makes it annoying for community users to retrieve the latest maintenance release, but you can still get in about 20 minutes (depending on the speed of the CVS, the build runs in under a minute).
    Bingo. Annoying. So why on earth do it, if the price to pay is having people out there shouting "Spring is not open any more!" in anger because you took from them something that they already had? (no.1 of the items in the things-you-should-never-do-with-oss list) Regards, Daniel Fernández.
  139. Why bother?[ Go to top ]

    [...] I just don't get it anymore. This just makes it annoying for community users to retrieve the latest maintenance release, but you can still get in about 20 minutes (depending on the speed of the CVS, the build runs in under a minute).


    Bingo. Annoying. So why on earth do it, if the price to pay is having people out there shouting "Spring is not open any more!" in anger because you took from them something that they already had? (no.1 of the items in the things-you-should-never-do-with-oss list)

    Regards,

    Daniel Fernández.
    +1. It can be hard enough to include open source code in some companies. Now instead of stating that its open source and its free to use I have to tag a "but" on the end. I generally find that once the company has adopted Spring and its in use they will then fork out for support and training. Why make its adoption harder for the sake of building a binary? (Which anyone can do!)
  140. This sounds like a good opportunity for a 3rd party support organization that sells support and services for Spring and related technologies to make a name for themselves. All they need to do is set up an automated build and reporting system (to tell what's in the builds by tying the checkins in with Spring's JIRA issues) and publish the builds to a public repository.
  141. This sounds like a good opportunity for a 3rd party support organization that sells support and services for Spring and related technologies to make a name for themselves. All they need to do is set up an automated build and reporting system (to tell what's in the builds by tying the checkins in with Spring's JIRA issues) and publish the builds to a public repository.
    Indeed. I'm glad to see that the code will be in the public repositories - definitely something I didn't get from the announcement but saw in the conversation. But... holy moly, I feel bad for maven users (again). Can you imagine the fun when someone leaves a maintenance version - available only to enterprise customers - in a pom.xml, and some unsuspecting fellow tries to build? Hmm. We should have an equivalent to "build from source" from apt in Alex...
  142. Re: No binaries, but CVS version tags?[ Go to top ]

    Duncan
    An additional question. Will the Spring CVS still contain CVS version tags for maintenance releases not made available to the community?
    Source code will be published in the source repository. After 3 months SpringSource will continue make maintenance releases as needed to support our customers. There will be no tags in the repository corresponding to those releases. Our assessment of when source is ready for a release and when a coherent set of changes should go out together is something that we offer, along with 24x7 support, to our customers, and is based on integration testing that goes beyond the testing resources available in the community. The community is free to build sources at any point. For example, people might choose to build when a bug they care about is resolved. Rgds Rod
  143. Re: No binaries, but CVS version tags?[ Go to top ]

    Why don't we switch on Grails for our common needs? Grails deliver high-productivity and has everything that their underlying framework (i.e. Spring) offers. Our friendly team at Grails can easily take care of this possible maintenance nightmare. Long live Spring under the hood of Grails. - I think this aggressive commercialization attempt will hurt the strong community. Java people do not like these kind of stuffs. Cheers, Sudhaker
  144. There will be no tags in the repository corresponding to those releases. Our assessment of when source is ready for a release and when a coherent set of changes should go out together is something that we offer, along with 24x7 support, to our customers, and is based on integration testing that goes beyond the testing resources available in the community. The community is free to build sources at any point. For example, people might choose to build when a bug they care about is resolved.

    Rgds
    Rod
    So, with this new policy, this is the scenario: 1. Spring 2.0 is released in Oct 3rd, 2006. 2. I find a bug in 2.0.2 (Jan 8th, 2007) which is important for me, and I report it. 3. Someone at SpringSource (or outside, it doesn't matter) fixes it for 2.0.3 (Mar 9th, 2007). 4. As 2.0.3 was released more than 3 months after 2.0, I cannot have binaries for it. 5. Of course, I can checkout the source repository trunk, compile, and build but... I don't have a tag, and I don't have SpringSource's "assessment" to know whether all parts will fit together, so I should consider this trunk unstable. This means, of course, that it will not go into my production systems. No bug fix for me. 6. Spring 2.5 is released on Nov 19th, 2007. More than 10 months after the last, buggy version I had the right to have (2.0.2). Translation: something I could do before, and I could rely on before, I cannot now. Oh yes, I can pay... but I didn't have to pay before for just the same! SpringSource must understand that for us the "users", those who like other people working for them (so that we have spare time to evangelize about their products and make them so famous that they can even found a successful open-source-based company ;-)), this sounds like having being used. You give users openness and freedom, users give you an almost-monopoly in exchange... then you try to make them pay for the same thing that... they gave you. Yeah, you have the right to, no doubt about that, but... tsk, tsk, tsk. Regards, Daniel Fernández.
  145. You give users openness and freedom, users give you an almost-monopoly in exchange... then you try to make them pay for the same thing that... they gave you.

    Yeah, you have the right to, no doubt about that, but... tsk, tsk, tsk.

    Regards,

    Daniel Fernández.
    Such is life. I sent my second inquery to SS about the pricing, and look forward hearing from them anytime soon! I mean this change doesn't mean that small customers would be insignificant to SS and doesn't mean that small customers would not even get price quotes as SS is busy answering questions from real customers that mean big business. Sincerely I wish that Spring source would reconsider some points said in this thread and meet in the half way by - for example providing the tags in repository. Sure, it demolishes some of the value proposition - but not for the real enterprise-market.
  146. Heimo Thanks for your post.
    I sent my second inquery to SS about the pricing, and look forward hearing from them anytime soon!
    Someone will be in touch shortly. Rest assured, we don't only care about big customers! But I really wanted to respond to an interesting point that you raised:
    Sincerely I wish that Spring source would reconsider some points said in this thread and meet in the half way by - for example providing the tags in repository. Sure, it demolishes some of the value proposition - but not for the real enterprise-market.
    I understand your point of view. We are not trying to harm the open source community, or those who work for organizations that can't afford to pay subscriptions. We are keeping the source open and I want to be as open as possible with our community. However, let's suppose that we published the tags. I'd be happy if individual developers wanted to build to those tags. However, it would open an opportunity for third party companies to try to distribute those builds for their own purposes: to make money from them or as a dumping strategy. Why would this be A Bad Thing?
    • Money that could have paid toward Spring development would contribute nothing to Spring development. A model where one company or group develops open source and another makes money from it is destructive in the medium to long term.
    • Customers who purchased support from such third parties would not be receiving quality support (as it wouldn't be backed by Spring's developers), so it wouldn't help them
    • Some obvious third parties who might be involved, who have shown their willingness to try to cash in on the open source work of others, don't need the money.
    Sure, SpringSource wants to make money. But a strong and healthy SpringSource is important to the future of Spring--and, I believe, to that of enterprise Java. I am very proud of our record of creating some of the most important and highest quality open source in enterprise Java--and I'm committed to ensuring that we contribute even more in future. Rgds Rod
  147. Rod, Why not already with this policy move more forward as for example myeclipse they have a very affordable price per developer and keep Spring source opensource just for find bugs. There could be 2 plans a subscription for just use the Framework and tools or the complete subscription with technical support and so on. If there was now in the internet website of Spring Source a place where I can buy right now the subscription I will buy it. Spring is already a standard, it made a name already, so many people will keep loyal to Spring. If there is a plan or something like that I will need not to worry and is affordable even for small business plus the Spring code is Opensource APL(Im not sure if opensource model works but it worked for Spring to make name for their self and to find bugs). But if Spring Source continue with some kind of secrecy for example I don't know now the price of the subscription and change the plans of the game everytime you announce something of course we will go with another solution, go away from Spring. That is why I don't like so much Apple they say they use open standards but they are very secrecy and use I think bad tactics. Regards.
  148. This is my stack of tools. 1.Intellij IDEA I pay for it and is affordable 2.Resin subscription professional I pay for it and is affordable 3.Spring Framework it was very affordable(gratis) but I didn't pay and that feels something is wrong so I wanna pay an affordable subscription so everything works good in here. 4.ICEfaces they don't have a subscription plan but they have a support plan but I didn't need yet that but I would like they offer some kind of affordable subscription and be happy. As you can see we the users wants to pay for their work of our tools developers and really I don't care if is opensource or not I just want something works and it is affordable, not as the Qt framework guys that for 1 license to use Qt I have to pay $3000US every year that blows a small to medium business. Regards.
  149. Re: No binaries, but CVS version tags?[ Go to top ]

    Rod I understand your frustration, seeing other parties cash in on your hard work. Firstly, however, its fair game. You publish a project as an ASF licenced project - I can do what I want with it, that's the license. That's why we all happily adopted it! If there is a business opportunity people are allowed to use it. That's what a free market is about. In respect to the steps taken, I do not think you meant bad towards the OS industry. However I strongly believe that this change backfired and the OS industry is the main looser! The lack of labels actually empowers 3rd parties to cash in on these changes. With labeled releases they have nothing to offer that any internal developer could do themselves. Without these tags they will offer so called 'tested and supported' milestone releases to customers for money (probably significantly cheaper than you as their overhead is significantly lower). Will that be the same quality than your support? Probably not - but as they will offer standby support as well, companies will be happy. The OS users however have no way to receive any tested updates (good or mediocre quality) without paying! Additionally, as this thread shows, you scared a lot of us. Even if the new scenario is still workable we all wonder what's next. I for one have concerns to propose Spring for future projects and have for the first time since its release downloaded Guice. You have a hard job ahead regaining our trust but I sincerly hope you will! Spring made a huge positive impact to the OS industry and Java world and we all have to thank you for it. I just hope it won't now do as much damage.
  150. However, it would open an opportunity for third party companies to try to distribute those builds for their own purposes: to make money from them or as a dumping strategy.

    Why would this be A Bad Thing?
    • Money that could have paid toward Spring development would contribute nothing to Spring development. A model where one company or group develops open source and another makes money from it is destructive in the medium to long term.
    • Customers who purchased support from such third parties would not be receiving quality support (as it wouldn't be backed by Spring's developers), so it wouldn't help them
    • Some obvious third parties who might be involved, who have shown their willingness to try to cash in on the open source work of others, don't need the money.
    Rod, I perfectly understand Your reasoning. Don't misunderstand me - I wish You great commercial success! I'm all with You, I love Spring, I work with it since pre 1.0 version. I made few patches, bug requests etc. I even got 'grandfahter status' in Your certification process (ah BTW. and i'm about to pass certificate). I'm also architect in really big financial institution in Europe, Your customer (though we are not paying subscription as for now). I'm responsible for making technical recommendations, including 'maintenance contracts' for development stuff. So this policy affects my stuff definitely. I, as few others in this thread asked about commercial details. Got nothing so far. Hope will get something in near future. Being frankly, I'm not comfortable with this situation. To describe my current feeling, using kind words, I feel... Uncertainty as in FUD. As Your potential client I don't feel comfortable with this and this is not the best starting position when it comes to doing business. I have no clear vision what this 'policy' is *exactly* all about. I spent my working time, monitoring this thread, changing my mind few times, getting unclear messages (like: 'Yes code will be available freely', 'no there wouldn't be tag for release' - You, as everyone around knows that code without tags means... no way to compile the given 'release' by yourself etc.) and still being puzzled. I believe that in this situation Your clear statement, in the form of blog entry should had happen Yesterday at least. The following issues, IMHO has be addressed: * What license will apply to updates available Only for Enterprise Customers (after 3m period)? * Can I, as a Enterprise Customer: a) have access to source code WITH tags as I have today? b) redistribute 'Enterprise Versions' of spring framework in any form (source, binary, etc.) - as I can today? * How do You see me, as Your Paying Customer working with 3rd party libraries relying on Spring - eg. CXF? I expect that I could continue using this great framework without harm... Same applies to Struts2, Grails and others. Artur
  151. I understand your point of view. We are not trying to harm the open source community, or those who work for organizations that can't afford to pay subscriptions.
    I believe that the open source community will be affected in a negative way. There are a lot of other open source projects that either depend on Spring or enhance it. Furthermore, with the new version policy, how will an organization combine the secret and official Spring releases with open source projects?
    However, let's suppose that we published the tags. I'd be happy if individual developers wanted to build to those tags. However, it would open an opportunity for third party companies to try to distribute those builds for their own purposes: to make money from them or as a dumping strategy.
    I believe that this is a non-existent risk. With publicly available releases from either SpringSource or an reputable open source organization, who would buy Oracle releases?
    • Customers who purchased support from such third parties would not be receiving quality support (as it wouldn't be backed by Spring's developers), so it wouldn't help them
    This implies that no other company on the face of this earth is competent or able to provide support for Spring. I'm certain that the market would decide which companies provide value and quality in supporting Spring. My opinion is that you are destroying the ecosystem around Spring instead of embracing it. Regards, Mikael
  152. Just had a very pleasant discussion with european territory manager about our needs and what spring source offers. As we really just would want to get official, tested binaries that work ( the spring enterprise edition part ) - my conclusion was that the only real option for us is to go just with the open source version and try to manage if problems arise. I really want to say that Spring source's offering has a huge amount of value for enterprises that are stacked with cash and run mission critical systems with pring. It is also clear that the offering is clearly aimed at enterprises - as the entry package's pricing starts around 16 thousand euros per year, though they can make custom smaller packages for smaller needs. In our case calculation for one server and one developer would have meant 5-6 thousand euros, per year. And yes, the name 'enterprise' in the product name should be a giveaway. What I would have expected to pay and would have been very happy to pay would have been something in the range of 300 - 500 euros per server per yer - similarly as the entry level packages are with mysql and Caucho Resin appserver. Both companies - Sun and Caucho - have also separate much more enterprisey packages and support contracts available for those who need them - as well as just the opensource versions. Spring souce has packaged more into it's offering - and hence bills also more. Unfortunately it also means that it will effectively prevent revenue streams from my kind of developers and small companies - who will now just continue to work with opensource version of Spring Framework. I continue to look forward new versions and innovations from Spring Source. I hope that these changes don't harm the ecosystem as many have feared and we can continue to develope on top of our favourite Java-framework.
  153. I know this is just a calculation but if this is true $5000 to $6000 euro per developer per year for the subscription this definitely blows away small to medium business. I was laughing that the Qt Folks charges $3000US per license, that can be every 2 years each major version plus they have upgrade discount $1500US but still blows for S/M business. As you said if they charge for example 300 per developer per year for S/M business that is affordable but not that calculation, that is insane. Maybe in Silicon Valley they have that money but not around the world is like that. If this calculation is true, I'm sorry but me, my customers and my collages we will have to abandon Spring for the Guice or JEE. I don't want the open source version, I don't trust it, and we always will suffer not to get the maintenance release that the Enterprise users enjoy to use because my business cant afford that subscription. Hope is not that way and Spring Source can make the right choice. Regards.
  154. Carlos
    I don't want the open source version, I don't trust it
    Note that it comes from the same repository. There is no "open source version"--Spring is open source. Regarding your points about pricing for small business, we will consider that. Rgds Rod
  155. Rod,
    Regarding your points about pricing for small business, we will consider that.
    That makes me happy, Thank you for your feedback :) Regards.
  156. Thanks Carlos. I have initiated a very serious discussion about this internally since my last post :-)
  157. Pricing, schedules and vibe[ Go to top ]

    I guess I should preface this by saying I very, very rarely post. However, having read "most" of the posts in this thread, I still feel very jaded and suddenly unwelcome by SpringSource. Having used various versions of Spring over the last few years, I have championed it where I currently work and have encouraged other developers to try using various features of Spring as it makes development easier. For example, the JDBC templates. The notion of DI and IOC containers can be applied from many frameworks AFAIK. One of the primary drivers behind championing Spring is it allows developers to focus on things that matter. Things like business logic, layout, integration and testing of the application being developed. Spring is "easy" to use, it removes a headache from development and makes developing more enjoyable. Whilst bug fixes will be applied to trunk, I don't find it "easy" to make sure I download at the right time to ensure I get the necessary patches, compile and then deploy to our maven repo. I also wouldn't find it "easy" to try and explain on a forum which svn version I had downloaded before posting a question and hoping someone else also had the same version as me. I also would find it near useless reading community blogs that referenced anything outside of the 3 month period. So for me, Community Spring would lose one of it's most appealing points being easy. Spring was also released early and often. I wonder how this will change. There seems to be a strong commercial justification for "holding back" some important but non-critical features/bug fixes until after the 3-month period. Why would SpringSource release often and early when they can release early then wait for 3 months of free community testing before starting to release commercial patches to their "enterprise" community. And why 3 months? Why not 2, 1, 6, 8?! Seems like a figure plucked out of the air, surely in a couple of months it will be "too much effort" to release patches within 3 months. Again, I feel Spring would lose the "early, often" appeal. Rod, you keep banging on about Guice being released in March 2007, do you have a release schedule for the next 8-12 months of major planned releases? Are they every 3 months, 12 months? As for the pricing. Sheesh. 5-6K in Euros!? That's what about 8-9K AUD! Per developer?! And why no pricing structure on the SpringSource site? Is it that sensitive? Are you embarrased by it? Going back to Spring being "easy", it's easy to justify a cost of zero to management as to why developers should use more of a framework we enjoy. I (and I'm sure I don't speak alone here) don't have the time or effort to even attempt to justify a potential cost of ~50K AUD for a dev team of 6. I think I'll find it easier to justify using a free JEE spec implementation. Rod, reading one of your blog entries http://blog.springsource.com/2008/06/25/pumping-it-dry-200-a-barrel-and-25000-per-cpu/, I feel there's a strong level of hipocrasy ... "They have the oil, and they think they have existing customers over a barrel" ... I also don't quite understand the "why"!? My understanding of the driving force behind the change in maintenance policy was because: - It's costly to maintain older major release version for free. So, I fail to see how "charging after 3 months of releases of the latest and greatest" will solve that problem? Rod, Mark, can you please explain that to me? I completely agree that people should pay for maintenance reasons of older versions as it would be costly to maintain - personally I would just stop maintaining them. It feels like you guys aren't being honest about the reasons for the change. And if you're not being honest about the reasons, why should the community trust anything else you have to say?? All in all, I feel very disappointed with the direction being taken by SpringSource. It feels dishonest, greedy and arrogant. I *hope* there's a change in policy, but I doubt it. I (no doubt along with hordes of others who aren't posting) will stop championing Spring and start looking for alternatives. Ryan
  158. Re: Pricing, schedules and vibe[ Go to top ]

    Rod without the tags you are pointing to the people that use only the DI and are not interested on the Spring Stack or Enteprise offering to use Guice. You are afraid of competition?, don't be, Spring Source already it is BIG, nobody can challenge the Spring Framework(Stack and portfolio) really. Anyway Guice is baked by Google and they use it internally, Also as you said Google have not interest in to make money with Guice they make lots of money with other business but I think that is the strong point of Guice they will keep it forever opensource and sometime Google can throw some cash to Guice so it continue its path. Now if Spring DI doesn't give the tags many people will feel is not real open so many people will go with Google Guice offering. But if you give the tags it will be as JBoss Seam, everybody that works with JBoss Seam is happy and there is not competition for them and they have worked that way like 2 or 3 years?. Also why SS didn't go from day 1 with straight GPL and now they could have the business model as MySQL dual licensing. I think for opensource projects have to think more carefully which license will use. For me the Apache license meaning is I give you for free my work and you can do whatever you want with it. GPL it is Total freedom but you can not do proprietary or even commercial it is just to share with the community so you could apply your dual licensing. Instead of this Enterprise policy I would prefer it that you announce that the Spring Framework will change their license to GPL or LGPL and offering the dual licensing. That is more Real OpenSource!.
  159. Re: No binaries, but CVS version tags?[ Go to top ]

    Hi! I am fine with the direction you go. I think a stabilizing enterprise branch would have been the better route to go (compare JBoss EAP).
    Duncan
    An additional question. Will the Spring CVS still contain CVS version tags for maintenance releases not made available to the community?

    Source code will be published in the source repository. After 3 months SpringSource will continue make maintenance releases as needed to support our customers.

    There will be no tags in the repository corresponding to those releases. ...
    Rgds
    Rod
    I'd say this could be seen as giving the middle finger to the community. Is is absolutely no extra effort for you to provide the maintenance tags in the repository. You are deliberately excluding the community from this. And you do know that no one sane would use a version that might contain a half checked in refactoring. Just to come back to JBoss again: JBoss does someting similar with the community version (jboss.org) and the EAP version (jboss.com). But even Red Hat provides all the tags for EAP, SP and CP versions in the repository. You are free to build them yourself. And JBoss is distributed as LGPL software, meaning anyone who legally received a EAP version can legally redistribute it. And still Red Hat is selling support. Perhaps you want to reconsider and "fine tune" your modell a bit. Best regards, Tobias (working with, not for, JBoss since 2000)
  160. The psychology effect to people is already harmed. Who will trust SS again even they change their mind??. As I said I will use Spring just paying an afforable subcription but me I dont comeback to the OpenSource Spring anymore, that one is dead for me. Regards. PS. I'm one of many waiting for details for the Enterprise subscription, I hope an answer soon.
  161. Duncan
    An additional question. Will the Spring CVS still contain CVS version tags for maintenance releases not made available to the community?

    Source code will be published in the source repository. After 3 months SpringSource will continue make maintenance releases as needed to support our customers.

    There will be no tags in the repository corresponding to those releases. Our assessment of when source is ready for a release and when a coherent set of changes should go out together is something that we offer, along with 24x7 support, to our customers, and is based on integration testing that goes beyond the testing resources available in the community. The community is free to build sources at any point. For example, people might choose to build when a bug they care about is resolved.

    Rgds
    Rod
    So what's stopping Spring Source charging for binaries of major releases (Not making major release tags available to the public). They don't make money of the community and apparently they don't need the community. To be honest this has put doubts in my mind about the future direction of Spring. It has shaken my trust and I was quite happy to generate revenue for Spring Source (Training and support)
  162. Michael
    So what's stopping Spring Source charging for binaries of major releases (Not making major release tags available to the public).
    We're trying to achieve a fair balance between community and enterprise users. Charging for major release builds would most certainly not do that. It would harm Spring users and the wider community, which could not benefit SpringSource or anyone else. Your logic appears to be that "if they can change a single thing, they can change anything at all". I think this is a stretch. Rgds Rod
  163. Rod, I think it's a poor choice not to put tags in the CVS/SVN repository. How can you guys even do your maintenance releases without them? How can paying customers know which version they are on? It sounds like they would receive a well-tested non-named version. I wouldn't pay for that... even if I was as rich as Voca! I don't see any other open source companies refusing to use tags. Can you point to other examples? Look at Hibernate, they have paying customers and they still put out versioned releases. It's totally understandable you want to make money, but I think it's a horrendous choice not to tag as you push builds to the paying customers. Yeah, so your argument about it otherwise diverting revenue from freeloaders is true, but it totally makes me believe you're willing to forgo good development practices to conserve income. I really hope that your paying customers demand public tags. No serious customer should accept anything less. "Spaceballs 2: The Search for More Money." A good movie title, but bad philosophy for SpringSource to adopt.
  164. How can you guys even do your maintenance releases without them?
    SS will have tags -- tags just wouldn't be available to anyone except SS employees. The whole things smells of a VC sticking their nose in where they don't understand what they're doing. The Spring guys are pretty smart. Even they know that 3 months isn't long enough after a major release to have fixed all critical bugs and produced a stable release, even for the first class experience we've all had to date with Spring. It means that there would never be a stable community release of the Spring framework again, unless the community could guess what set of files comprised a stable release. There would also be no way to describe what version you're on. e.g. spring-framework-freds-build-2am-tues-29-sep-cross-your-fingers.zip Meanwhile, we're still waiting to hear if the community gets a tagged repo...
  165. What wait? The FAQ clearly states that there will be no tags for the community after the initial 3 months have passed.
    Will SpringSource maintenance releases beyond 3 months be tagged in the public repository? Source code will be published in the source repository. After 3 months SpringSource will continue to make maintenance releases as needed to support our customers. There will be no tags in the repository corresponding to those releases. Our assessment of when source is ready for a release and when a coherent set of changes should go out together is something that we offer, along with 24x7 support, to our customers, and is based on integration testing that goes beyond the testing resources available in the community.
  166. What wait? The FAQ clearly states that there will be no tags for the community after the initial 3 months have passed.


    Will SpringSource maintenance releases beyond 3 months be tagged in the public repository?
    Source code will be published in the source repository. After 3 months SpringSource will continue to make maintenance releases as needed to support our customers. There will be no tags in the repository corresponding to those releases. Our assessment of when source is ready for a release and when a coherent set of changes should go out together is something that we offer, along with 24x7 support, to our customers, and is based on integration testing that goes beyond the testing resources available in the community.
    Why wait? Because if you've read any of the messages you'd know that Rod has *clearly stated* that its under consideration to change this -- in order to avoid the community being trashed.
  167. Paulus, just to add to Greg's post... As I've understood Rod so far: Sure, there will be the trunk and there will be branches and there will be tags. But you will only get the trunk. Imagine the Spring repo would not be CVS but SVN backed. The publicly available repo would host the folder named "trunk" and the not publicly available SpringSource repo would host the folders named "tags" and "branches". ;-) Happy release management trying to get a coherent spring package with all dependencies (and I don't mean technical dependencies) resolved that is reasonable stable! But hey, we can always build a trunk snaphot release against snapshot dependencies. If that isn't an option! Cheers A very very sad Oliver
  168. There appears to be an effort to fill the void SpringSource's new policy created. Not forking the codebase, simply providing those services that SpringSource intends to discontinue 3 months after release. http://www.freespring.org/ Is there anything definitive out there that shows SpringSource is modifying their policy to something a little less inflammatory to the community at large? If SpringSource significantly revises their policy then freespring won't even need to exist and will likely fade away. No change in policy and freespring will likely flourish.
  169. Lennard, Rod Johnson blogged just today that SpringSource are changing the policy to address many of the concerns raised. Full details: http://blog.springsource.com/2008/10/07/a-question-of-balance-tuning-the-maintenance-policy/
  170. Re: The actual change: no binaries[ Go to top ]

    Rod:
    Magnus
    How can this be true when the press release reads "Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software."???

    My statement that "We intend to continue to expose all our code to the open source community" is perfectly consistent with the press release, which talks about community releases. We plan to check in bug fixes, but there will be no further maintenance releases.

    Rgds
    Rod
    Ah, that sounds better. Then I don't have a problem. You could have saved me many angry thoughts by putting that explicitly into the press release. The press release that talks about the "trunk" and "made available in the next community release" really communicates something different imho. With this new information is don't even see this as frontpage news... There's nothing to see here, please move along.... /Magnus
  171. Re: The actual change: no binaries[ Go to top ]

    Magnus
    How can this be true when the press release reads "Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software."???

    My statement that "We intend to continue to expose all our code to the open source community" is perfectly consistent with the press release, which talks about community releases. We plan to check in bug fixes, but there will be no further maintenance releases.

    Rgds
    Rod
    This thread is becoming too emotional in both ways. Now i read people writing "wow, i am safe because the bug fixes are in the trunk !!" Well, that's not the point. I was not worried about not having access to the source code of course but i am really concerned about grounding all my software on SS (yes on SS, not on Spring because the decision is not about the quality of Spring but about the "style of life" of SS). IMHO the point is "can we still trust SS for the next years of development ? Can we rely on SS for continuing to build our intermediate infrastructures on spring ?" An approach that everyone would have welcomed with happiness is the following: "Hey guys, we added an enterprise support giving: - pushing communications for new fixes - free consultancy for 3 open cases / spring support per year - 3 free books - partecipation to one webinar a month - bla bla bla and all this just for 3000$ per year " wow !! this is interesting ! i am pushing here everybody to use spring, let's buy enterprise support ! And if SS makes money from additional services, well, they will be pushed to make a better spring. but Rod here you are trying to convince the all of us that it is too expensive for you to do a "mvn deploy" even for the community. Rod, that's an insult to people intelligence; that is ridiculous and pathetic; the real facts are that you are simply saying "i want to start making money without any additional effort, just pulling unfairly the community to the enterprise side". And that's bad, really very bad. Even Microsoft is much more fair than you are: i have been paying for years the MSDN universal subscription, happy to pay for additional services: but i did not buy the MSDN because the removed services, documentation, ... from base services to put it in the enterprise services. And I do not want to be in business with unfair companies. Regards Paolo
  172. Re: The actual change: no binaries[ Go to top ]

    And I do not want to be in business with unfair companies.
    +1
  173. Rod Thanks for your calm attemps to explain this whole situation. I have another question: In small/medium project it was always a safe bet to use e.g. Spring-2.0-RC1. Suppose the fatal 3 months passed since last stable (say 3.0) release, paying customers can use next fix release (3.0.2), but there is no sign of upcoming next stable version (3.1). Does SS plan to make available any 3.1-M1/RC1 versions? If no, who is going to test these prereleases? Suppose SS has 10000 paying customers. Even if everyone of them is so eager to test/patch/post issues concerning these prereleases, this is still <<1% of all spring users and developers worldwide... And are you sure, those clients really want to test/patch SpringFramework after they paid? Are you ready to abandon these 99+% enthusiasts checking http://sourceforge.net/projects/springframework everyday in hope a new version/milestone/RC is released? Of course, one can also test the trunk version, but where to post the JIRA issues? What to choose in "Affects Version/s" field? Thanks in advance for your next reply(ies). best regards Grzegorz
  174. Re: The actual change: no binaries[ Go to top ]

    Rod Thanks for the answer. Please ignore my latest post - i must have composed it while you answered mine ... Your answer makes me definitely happier! Thanks Ingo
  175. Re: The actual change: no binaries[ Go to top ]

    Hi Rod, Can you explain how the policy operates in the following context? A "enterprise" customer of Alfresco receives a maintenance release of the Spring core via Alfresco's own maintenance distribution. This maintenance release has not been provided to the community. The customer who has not become an enterprise spring customer has internal projects that use the same major release of Spring core. Can the customer take the jars distributed with Alfresco and packaged and deploy them with the other internal application? Can the customers code executed in the same runtime and bind to the same maintenance libraries if they have extensions built on Alfresco which leverage Spring heavily? OSGi? Basically are the maintenance releases licensed differently and forbid distribution to others? William
  176. Ingo
    Rod
    Sorry, you might have meant to be clear, but I'm not clear, yet.
    Can you categorically promise that all fixes made to the sources, incl. former versions, will be publicly available in a repository? Even if that fix has been made three months after that release.
    To avoid more confusion:
    - V 3.0 comes out
    - V 3.1 comes out three months later
    - subsequently a bug is found in 3.0
    - you fix it for a subscription client
    - I can go into a free and open repository and retrieve source code for version 3.0 (let's call it 3.0.1) that includes the fix.
    Can you state the above is true?

    Correct. We intend to continue to expose all our code to the open source community.
    Rgds
    Rod
    Does the new policy mean that main releases (3.0, 3.1, ...) will be made in every 3 months? For example: You release a major version (3.0, free). For 3 months you release minor versions as free (3.0.1, 3.0.2,...). After 3 months you release a new major version (3.1, free) but from now on minor versions for 3.0 will only be available for the customers. Is this correct?
  177. Does the new policy mean that main releases (3.0, 3.1, ...) will be made in every 3 months?
    For example:
    You release a major version (3.0, free). For 3 months you release minor versions as free (3.0.1, 3.0.2,...). After 3 months you release a new major version (3.1, free) but from now on minor versions for 3.0 will only be available for the customers. Is this correct?
    I think everythink will be clear soon. changelog.txt says, that 2.5.6 release was planned for 2008-09-22. There are 8 unresolved JIRA issues, but, what more important, there IS going to be release 2.5.6. The only question is: will it be published to sourceforge, or will we see just plain *.txt file containing the final nail to the coffin of our hopes...
  178. Re: The actual change: no binaries[ Go to top ]

    To avoid more confusion:
    - V 3.0 comes out
    - V 3.1 comes out three months later
    - subsequently a bug is found in 3.0
    - you fix it for a subscription client
    - I can go into a free and open repository and retrieve source code for version 3.0 (let's call it 3.0.1) that includes the fix.
    Can you state the above is true?
    The answer is here http://www.springsource.com/node/558 "Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software." So the answer to your question must be no afaik. /Magnus
  179. Re: The actual change: no binaries[ Go to top ]

    @Magnus Heino, Thank you for your answer, I will read it again to clear my questions. And sorry if I insulted or my comments are not comfortable for somebody. Regards.
  180. Re: The actual change: no binaries[ Go to top ]

    Magnus, thanks for a slightly clearer answer. So I guess the following scenario is true: If we take the current state: - 2.5 is out for more than 3 month - 3.0 is not even available in a repository as a preview - All the bug fixes we received in versions 2.5.1 - 2.5.5 that happened post the first three month we would have not been able in any way or shape to get our hands on under the new deal. Unless, of course, we paid for the enterprise subscription. Could you please confirm or clarify this statement? Out of interest, what is the licence of the code delivered to paying customers after the three month period?
  181. Re: The actual change: no binaries[ Go to top ]

    Aside from the large "Let's burn the Spring logo" sentiment I understand that this whole change boils down to:
    "You'll get binaries only in the 3 month period after the major release."
    The problem is - that WE HAVE to interpret things. Sorry, but we have no clear answer from SS official so far. I wouldn't pay to get binaries. I cannot imagine how such a model could even work. It would be most weird model I have seen ever. Let's assume then I'll get source together with binary distribution. Now, assume that this would be ASF licence. Now - who will stop me making diff agains 'publicly available' repo and publish it to community? If so? What's the deal besides spreading confusion? Everything we need, and - as a spring community - we deserve is clear statement - what exactly is going to be done by SS?
    Many OSS projects do not provide binaries for all platforms in the world. Do you get Windows binaries for your [insert-favourite-linux-project] by default? Usually, they are built and distributed by a passionate fan who provides them to the community.
    The problem is, that in this case - this passionate fan is gonna have Enterprise Support. As I read "policy" literally. It's not clear what and in which form will land in public repo. Artur
  182. Re: The actual change: no binaries[ Go to top ]

    Artur
    Aside from the large "Let's burn the Spring logo" sentiment I understand that this whole change boils down to:
    "You'll get binaries only in the 3 month period after the major release."


    The problem is - that WE HAVE to interpret things. Sorry, but we have no clear answer from SS official so far.
    I thought we were quite clear on this. Rgds Rod
  183. Re: The actual change: no binaries[ Go to top ]

    This is not about binaries and compile, I can do that anytime in my spare time in the evening, This is an insult to the community, it's a back stab and rules changed in the middle of the game. Spring is reusing open source projects, they grow with the community, It is retard to think this folks after this policy are doing good to the community or even open source. What about all the open source projects that depend of Spring(ex.Grails), It is RUINED people, get it?. This is hilarious, This sucks, Spring Source sucks big time!!. I'm done this thread. Bye.
  184. Re: The actual change: no binaries[ Go to top ]

    I'm done this thread. Bye.
    You mean you're finished trolling? (slow clap) - Tom
  185. Re: The actual change: no binaries[ Go to top ]

    This is the true. Why I will be trolling?, I'm furious and I will not post in this thread just for trolling around, This is serious, My Projects depend of this, This is my opinion as a user and Spring contributor. I'm not trolling around, It is the simple true that this framework is ruined, My feeling is telling me this so sorry I have to move on as many people here express. Do you contributed something in this thread? or here maybe you are the troll.
  186. Also Mr.Rod looks he ignore common users here, I asked for clarification about his intentions but I just see he respond to named people as Martin Flower, But the rest of users seems we are nothing for Mr.Rod expectations, it is sad. If there is more clear clarification as Ingo Boegemann posted: "To avoid more confusion: - V 3.0 comes out - V 3.1 comes out three months later - subsequently a bug is found in 3.0 - you fix it for a subscription client - I can go into a free and open repository and retrieve source code for version 3.0 (let's call it 3.0.1) that includes the fix. Can you state the above is true?" I would like someone from SS respond to it.
  187. Re: The actual change: no binaries[ Go to top ]

    or here maybe you are the troll.
    Yep, you got me figured out lock stock and barrel. You're certainly not trolling when your first of nine entries started off with "Fu** SpringSource!!". Give me a break. Tom
  188. Re: The actual change: no binaries[ Go to top ]

    @Thomas Fuller, Of course that was my first reaction I could not believe this. Anyway I don't need this, I give you your break. It is great that the idea of a DI is decoupled code so I'll just move to another framework and that's it. Thank you.
  189. Re: The actual change: no binaries[ Go to top ]

    or here maybe you are the troll.


    Yep, you got me figured out lock stock and barrel.

    You're certainly not trolling when your first of nine entries started off with "Fu** SpringSource!!".

    Give me a break.

    Tom
    Given the language, and hiding behind a lame pseudonym, I think "troll wannabe" might be a better classification :-). Craig
  190. I like nick names but you are right kinda lame well I just changed to my name I don't have nothing to hide. As I said that was my first reaction, sorry I was very confused but now Rod Johnson cleared this misunderstand. By the way nice work with the Tomcat spec Craig. I'm fan of Tomcat. Regards.
  191. I'm done this thread. Bye.


    You mean you're finished trolling?

    (slow clap)

    - Tom
    No, he simply understood the way to go: far away from Spring. That is the way I am taking too. (no clap)
  192. There have been many attempts at clarification, but i'm still not quite there :-(. I guess perhaps I need an example. So, from the changelog (http://static.springframework.org/spring/docs/2.5.x/changelog.txt), these are the releases I can see: version 2.5.5 (2008-06-23) version 2.5.4 (2008-04-28) version 2.5.3 (2008-04-06) version 2.5.2 (2008-02-29) version 2.5.1 (2008-01-09) version 2.5 final (2007-11-19) version 2.0.5 (2007-05-07) version 2.0.4 (2007-04-10) version 2.0.3 (2007-03-09) version 2.0.2 (2007-01-08) version 2.0.1 (23.11.2006) version 2.0 final (3.10.2006) Is it correct to understand that if the new policy had been in effect during this time, we would only have seen the following releases? version 2.5.2 (2008-02-29) version 2.5.1 (2008-01-09) version 2.5 final (2007-11-19) version 2.0.1 (23.11.2006) version 2.0 final (3.10.2006) Eirik
  193. There have been many attempts at clarification, but i'm still not quite there :-(. I guess perhaps I need an example.

    So, from the changelog (http://static.springframework.org/spring/docs/2.5.x/changelog.txt), these are the releases I can see:

    version 2.5.5 (2008-06-23)
    version 2.5.4 (2008-04-28)
    version 2.5.3 (2008-04-06)
    version 2.5.2 (2008-02-29)
    version 2.5.1 (2008-01-09)
    version 2.5 final (2007-11-19)
    version 2.0.5 (2007-05-07)
    version 2.0.4 (2007-04-10)
    version 2.0.3 (2007-03-09)
    version 2.0.2 (2007-01-08)
    version 2.0.1 (23.11.2006)
    version 2.0 final (3.10.2006)

    Is it correct to understand that if the new policy had been in effect during this time, we would only have seen the following releases?

    version 2.5.2 (2008-02-29)
    version 2.5.1 (2008-01-09)
    version 2.5 final (2007-11-19)
    version 2.0.1 (23.11.2006)
    version 2.0 final (3.10.2006)

    Eirik
    If you pay, you will receive all these releases. If you don't pay, you will receive the releases you noted. You will also have access to all the bug correction code in the public trunk and you will have to build *a* release by yourself
  194. SVN branches and tags?[ Go to top ]

    I'm more interested in whether there will be SVN tags for the "missing" releases. Rod?
  195. Childish Overreaction[ Go to top ]

    Reading this thread, the reactions of my collegues and being a longtime enterprise user of the Springframework, i simply have to shake my head in disbelieve: What have i walked into? In terms of diserability: It was long due, that SpringSource changed there licence in this respect. Entersprise maintainance and operation reality are so much different, then what i am hearing here in this thread as reaction. Many a manager is more then happy to pay for maintenance, then being "talked" into frequent upgrading by some of his Spring enthusiasts, just because of some newbies and oh yes the bug fixes.... In terms of feasibilty: The Springframework is lots, lots of code with a unbeatable ratio value per line of code. And lots of versions. Just take a look at all the downloadable versions at SourceForge. The versions go back to 0.9. It's there it can be downloaded. So where should they stop, respectively start backporting? All? Impossible. In terms of responsiblity: Spring has always been careful and spent lots of effort to garantee compatability for "older" versions of Java. Acting responsible and acting to "real" needs of enterprise computing. For me this has attitude reflected in there code has always been one the values of Spring. Yes, the new maintainance policy is also a responsible act. Making millions from it ;-/ ... come on, it's probably really just barely cowering their expences. In terms propability: I just wonder how many of my collegues here, where not only "theoretically" in the situation, affected by be new maintenance policy, but for "real". Probably the fewest, if any.... and if in that situation, without a manager willing to pay, hey, backport or fix yourself..... that's really far from "branching", that opensource. I think we really have to keep care to our "good" opensource projects and at least value what we get. Just my five cents Christoph
  196. Too busy to run build scripts?[ Go to top ]

    So after reading this entire thread it's clear to me that the real change is that SS no longer can be bothered with releasing maintenance builds to the community 3 months after a major release. But the obvious question still remains: Why? Is it too expensive in terms of time and resources to release a maintenance release or is there something else going on here? You wouldn't be trying to force people into buying subscriptions would you? This isn't the open source business model we're used to. Make money by selling additional value not by removing value from the existing open source product. I don't think it's likely we'll see a fork since that would require forking Juergen Hoeller. But perhaps someone will set up a site, let's call it DestinationSpring, that hosts a maven repository with up-to-date community maintenance builds. Then we can all bind our pom.xml's to org.destinationspring instead. But still, why should we have to? // Anonymous
  197. Apparently I've commented on TSS before. // Not so anonymous after all
  198. Fortunately JCP adopting most of the Spring's best practices and adding them to the JEE so that we don't have to lock ourselves into a single vendor :)
  199. =/[ Go to top ]

    "This policy doesn’t affect technologists who believe in open source" by Rod Johnson Of course this will affect us! This is very sad. I hope SS change her mind or maybe this could be the chance to EJB3 spec growns it's adoption. =/
  200. What about tests and build scripts?[ Go to top ]

    Rod or Mark, will *new* and *old* Spring Framework's tests and build scripts (Ant and Maven) still be in the same public repository where the fixes for Enterprise releases will be commited? Regards, Ramiro Pereira de Magalhães
  201. will *new* and *old* Spring Framework's tests and build scripts (Ant and Maven) still be in the same public repository where the fixes for Enterprise releases will be commited?
    Yes.
  202. Mr. Rod Johnson, Does the new, 3 month policy also apply for the binary minor releases of the newest major release? Attila
  203. Mr. Rod Johnson,

    Does the new, 3 month policy also apply for the binary minor releases of the newest major release?

    Attila
    Yes, for the three month period following a major release, the maintenances releases will be provided in binary form to the community and our customers.
  204. Mr. Rod Johnson,

    Does the new, 3 month policy also apply for the binary minor releases of the newest major release?

    Attila


    Yes, for the three month period following a major release, the maintenances releases will be provided in binary form to the community and our customers.
    The major sticking point then still seems to be the lack of tags available to be able to produce a coherent build. It seems (?) from reading the posts so far that Spring Source might come out relatively unscathed, reputation-wise, if the community can have access to a tagged repository. People are going to start having a serious look elsewhere without tags. Rod/Mark, Enterprise users are still going to be happy to pay for support, what about throwing your loyal community a bone and providing a tagged repository?
  205. Springsource == shaky company[ Go to top ]

    On May 01, 2008 I wrote in another thread that "I wouldn't be surprised if Springsource was bleeding money, as many of the consultants it employs are top names in the Java world and probably receive high salaries." I assumed SpringSource to be cash flow negative and that the company was burning through the VC investment. Rod Johnson dismissed my post as "pure FUD", but it was clear to me that his company has no choice but to change its licensing or get aquired by someone with more sound finances. SpringSource's latest move now proves my previous points. Obviously, SpringSource has not much choice. If they give the public free access to the CVS/SVN tags, how should they be able to generate enough cash flow to pay their expensive consultants, let alone earn a decent profit?
  206. Re: Springsource == shaky company[ Go to top ]

    Obviously, SpringSource has not much choice. If they give the public free access to the CVS/SVN tags, how should they be able to generate enough cash flow to pay their expensive consultants, let alone earn a decent profit?
    Well being a loss-leader is a valid strategy for building your market to cash on - but even still I would not concur with your analysis untill this dialogue is finished and we know what happens. For me I would be happy to get tags in the repository only for the latest major release, so that small companies and individual developers could update their software with latest and greatest releases. For businesses ability not to have to constantly upgrade their software, but get updates to their version would be of value - especially with the extended support and guaranteed response times, not to mention other tools that SS offers. However we can ask for how many customers the value in Spring source's offering is more than it's cost - compared to the opensource version. The maintenance policy in it's current form can be seen as twisting the arm of users and force them to become customers. And as discussed, for small and medium businesses and individual developers, pricing structure currently can feel unreasonable. We all know that Spring framework is great, and has been great for a long time! Spring source's conundrum is to be able to provide value through additional services and products without destroying the viable ecosystem it has created. As Spring Framework is so good already, this can be a tough challenge. Strong Spring Source - as Rod said - would be a good thing for the whole community and the future of Spring Framework - but finding a proper business model that keeps everyone happy requires more thinking and tinkering - as well as selling the idea to the market. I really don't know what would be the best model for Spring Source. Something like Mysql-model would be clearest and preferable - meaning additional features/products and better support for commercial version, and having pricing structure that works also for small businesses as large enterprises.
  207. Re: New Spring maintenance policy[ Go to top ]

    I'm afraid it's till not clear to me how things are going to work with the new policy... The three-months patch policy applies to the latest major release, or only to the older ones? for example, if spring 3.0 is out there and it's the latest major version, and a year later spring 3.1 is released, will there be nine months of no opensource updates? or the three-months-opensourceness clause applies only after another major version has been released (in this case, after 3.1 has been released)? I guess many developers could afford the risk of having to upgrade to a new major version in the case of a blatant bug after three months... IF THERE IS ANOTHER MAJOR VERSION. But, what if there's no newer version than the one currently in use and you get a bug? that would not be a very comfortable situation...
  208. Re: New Spring maintenance policy[ Go to top ]

    I'm afraid it's till not clear to me how things are going to work with the new policy...
    Whatever interpretation of new policy is, one thing is for sure, SpringSource has acted immorally in this case. The people who made Spring what it is today, users/developers who praised it, provided feedback, spread the word to their fellow colleagues are let down. You can not change rules in the middle of the game. If there were no community there would be no Spring. What prevents SpringSource from forking only commercial version of Spring except morality which is on shaky legs considering this last move? Yes, I know you have to make money, so do I, but I do not go around and mid-finger my business partners. And yes, community was your partner. Was I say...
  209. Re: New Spring maintenance policy[ Go to top ]

    Spring folks doesn't have honor to the open source and the spring community, What the hell they think we are?, stupid's or zombies to follow their desire? Wrong. This is it, Spring shot in their foot, Rod destroyed his own company and that happen in history also. I'm sorry to tell to the folks that still believe in SS, watch-out!, Spring Source and the Spring framework is RIP, Dead dead dead. Go look to another framework because this is KAPUT!.
  210. Re: New Spring maintenance policy[ Go to top ]

    I'm sorry to tell to the folks that still believe in SS, watch-out!, Spring Source and the Spring framework is RIP, Dead dead dead.

    Go look to another framework because this is KAPUT!.
    I believe in that there can be some viable middle ground where we all can be happy and work together, and such drastic measures as dumping Spring Framework are not yet necessary. It should be in our common interests to work with Spring Source and see what could be made out of this all. Dumping Spring Framework immediately is irrational - as it means that we have to suffer from switching costs even though we haven't yet seen what the situation means and how the differences in needs, wishes and requirements can be resolved. And do not forget that Spring Framework - as it is even now - is great framework and has amazing amount of features together in it's modules. It is huge amount of work to create comparable features on top of other frameworks and have such a consistent style and usability. So let's not throw out the baby with the bathwater yet.
  211. Re: New Spring maintenance policy[ Go to top ]

    Dumping Spring Framework immediately is irrational
    No one will dump it immediately, but we will see drop in Spring adoption, me included. I will neither use it in quantity I have in the past, nor I will promote and advocate it as I have done in the past. Something is fishy if we see: 1) some kind of GPL server announcement 2) bad move towards community. With my business hat on, one should not exclude more drastic moves from SpringSource in the future, not limited to commercial fork of Spring.
  212. Re: New Spring maintenance policy[ Go to top ]

    With my business hat on, one should not exclude more drastic moves from SpringSource in the future, not limited to commercial fork of Spring.
    It's a shame that Hani doesn't seem to blog anymore. This discussion sure could take a slash or two from bileblog. :-) Anyway discussions about pending doom are too soon. One of the realities of the world is that Spring Framework - even as it is now - is pretty darn good. Possibly that is also one of the reasons why Spring Source needs to cash in now if they are going low on new ideas and tieing in enterprises to their subscription plans would be even harder later on, when 85% of all the needs would already be filled. We have a great tool already, let's not forget that .-D
  213. Re: New Spring maintenance policy[ Go to top ]

    With my business hat on, one should not exclude more drastic moves from SpringSource in the future, not limited to commercial fork of Spring.


    It's a shame that Hani doesn't seem to blog anymore. This discussion sure could take a slash or two from bileblog. :-)

    Anyway discussions about pending doom are too soon. One of the realities of the world is that Spring Framework - even as it is now - is pretty darn good.

    Possibly that is also one of the reasons why Spring Source needs to cash in now if they are going low on new ideas and tieing in enterprises to their subscription plans would be even harder later on, when 85% of all the needs would already be filled.

    We have a great tool already, let's not forget that .-D
    You will get the darn good thing with JEE 6 and even Rod Johnson said it. For the people that use only the DI could use Guice and I saw a snapshot of this month 09/08 and maybe soon Guice will have momentum after this disgrace news. If you still believe in this watch-out because they will give you the finger again, They like to change the things very often.
  214. Re: New Spring maintenance policy[ Go to top ]

    For the people that use only the DI could use Guice...
    Before rushing to criticize commercial activity around open source (in the case of SpringSource, in this instance), I think a balanced view should consider the potential danger of alternative (non-corporate) models. As I pointed out earlier in this thread, there has not been a Guice release since March 2007. That's a real risk when a project doesn't have a viable economic model--and Guice is just one of many examples here. The absence of a company behind Guice (Google not really having any strategic interest in it) might produce a warm fuzzy feeling, but does it benefit the community? By contrast, consider the immense progress Spring projects have made in the last 18 months. And what about enterprises who require long-term support?
  215. Re: New Spring maintenance policy[ Go to top ]

    That's a real risk when a project doesn't have a viable economic model--and Guice is just one of many examples here. The absence of a company behind Guice (Google not really having any strategic interest in it) might produce a warm fuzzy feeling, but does it benefit the community? By contrast, consider the immense progress Spring projects have made in the last 18 months. And what about enterprises who require long-term support?
    You are spot on about the risks and also costs of thinking switching from Spring into something else - especially when there are clear unkowns and threaths also with all the alternatives. For those who see Spring as an IoC-container change would be easy, but those of us who have thought Spring as a larger platform for development there are less options. Well there is JEE and Seam ( and I predict a small spike in Manning's Seam in action ebook sales .-). Spring Source has strategic intent in Spring Framework and it's future - naturally, but excuse me for people not having the warm and fuzzy feeling about it now even though there are great chances that all this will be great change for all of us, and provides a solid economic foundation for Spring Source to continue to grow and develope great software - and everyone would benefit. The main thing for Spring Source to understand now about all this griping and moaning is that things have a logical side and emotional side, and we have gripes in both of them - but only one of them is key. On emotional side people are griping as the feeling about Spring Source has changed. You were the poster boy, you were the home of all things good and pure - and now you are BEA, except better and cooler, and you still have an open source codebase. On more logical side people are griping that adressing just _initial_ stability is just silly and yes even though you can and could get untagged changes from the repository for the latest release there are always dangers with that and. Well yeah. You know it. You don't see Sun Microsystems pushing people Glassfish that has just initial stability issues adressed and requires you to either subscribe their excellent support and additionally quality tested enterprise version. As far as I know, they have always provided - and will provide - very solid releases. Maybe this is also an emotional thing, as it _might_ be that three months is to adress the stability issues is enough - but as people have shown from examples in history that there is a doubt. And three months? What is that as an arbitrary timelimit and what do you wish to achieve with setting it as it is? What should people feel and think about it, when new release comes? "Oh great, now quickly test, test and try everything before 3 months are passed" if at the same time nothing guarantees that things spotted and reported will be fixed by then. You know, you only promised to adress the initial stability for three months - and hey thanks for the testing, our customers appreciate it and see you in the next major release which will come eventually, but if you would like to actually do something in the mean time - you can always call our sales team! I don't see the jive in that. It can be that the intention is something else, but what the wording is and how people communicate things make it sound so. How things were weren't that much different from what you will promise, but promising it in that wording makes it blatantly clear in a bad way. Previously there was this implicit assumption that there was a mutual best effort to improve the software and releases would be made when they were ready and community would help spring source engineers to adress problems by testing bugs in nightly releases etc. The explicit wording changes how things feel and so far the communication hasn't really changed it. Throw us a bone and give us the tags to repository for releases in latest version and everything is back where it was. I'm sorry for being such a pest and dick trying to educate you in things that you evidently already know. I have my vested interest in seeing Spring Framework succeed and as I don't see myself working in large financial institutions that would be purchasing subscriptions, I'm voicing my thoughts in an attemt to understand and see where the world is actually going.
  216. Re: New Spring maintenance policy[ Go to top ]

    For the people that use only the DI could use Guice...
    Before rushing to criticize commercial activity around open source (in the case of SpringSource, in this instance), I think a balanced view should consider the potential danger of alternative (non-corporate) models. As I pointed out earlier in this thread, there has not been a Guice release since March 2007. That's a real risk when a project doesn't have a viable economic model--and Guice is just one of many examples here. The absence of a company behind Guice (Google not really having any strategic interest in it) might produce a warm fuzzy feeling, but does it benefit the community? By contrast, consider the immense progress Spring projects have made in the last 18 months. And what about enterprises who require long-term support?
    Rod, a few people have asked for tags on the *latest* major version only. Is that feasible? e.g. no more tags on the 2.0 branch, continued tags on 2.5 until 3.0 comes out, then no more tags on the 2.5 branch. It seems like this would keep most people happy, and might (?) also meet Spring Source needs of extracting a decent revenue stream from Enterprises -- who may not be so quick to upgrade from 2.0 or 2.5 to 3.0 You really need to provide an explicit answer on this specific question.
  217. Re: New Spring maintenance policy[ Go to top ]

    Greg, Thanks for the suggestion, and for taking the time to set out your thoughts. As I've mentioned above, one of our concerns is tagging opening the possibility of competition from third parties who could divert revenue that would otherwise have helped fund Spring development. I'd like to think the community would see through such efforts, but I'm not sure. I'd like to provide tags--as well as source--to the community if possible. The idea of tagging the current branch until the next major release comes out is an interesting compromise, and we will consider it. I would love to have a genuinely collaborative dialog with the community on fine-tuning a fair and balanced outcome, and I'm happy that the discussion now seems to be trending that way. Rgds Rod
  218. Re: New Spring maintenance policy[ Go to top ]

    As I've mentioned above, one of our concerns is tagging opening the possibility of competition from third parties who could divert revenue that would otherwise have helped fund Spring development.
    Thank you Rod for your swift maybe answer. Here are few points to add to consideration: 1) your current pricing model with lots of value packaged into one offering opens up that competitive option 2) your current pricing model closes out many small and medium size businesses 3) if the tags would be provided for the latest release there would be no sane person trying to compete with you Effectively because of points of 1 and 2 you are: - either shunning some developers and non customers but users of the framework away - or opening a possibility for that third party to present itself and create that reasonably priced communicty packaged and tested version without any frills or thrills So from my point of view this effectively comes only down to the fact that you doubt whether you have enough leverage to twist enterprises / users in any other way to subscribe to the offering. But there is no need to cut off your nose to spite your face. There has been some punches and cheap jabs thrown here, and just like a gentleman you have returned to answer and educate us on how to see things from the different point of view. And for that I really applaud you, really well done! Thank you for continuing the dialogue and please do consider swiftly whether providing tags for the current branch would be a sane compromise.
  219. Re: New Spring maintenance policy[ Go to top ]

    Heimo
    1) your current pricing model with lots of value packaged into one offering opens up that competitive option 2) your current pricing model closes out many small and medium size businesses
    Yes, we've heard that message and are considering an offering that will fill this gap. Currently all our offerings include the additional software in SpringSource Performance Suite and comprehensive support. That delivers significant additional benefit, but makes the price point hard for us to get down. (Delivering enterprise-grade support can be an expensive business.) We are hoping to offer something simpler and cheaper for small business. Rgds Rod
  220. Re: New Spring maintenance policy[ Go to top ]

    The idea of tagging the current branch until the next major release comes out is an interesting compromise, and we will consider it.
    Rod, I am pretty sure that tagging the current branch would be seen by the community as an improvement from your first position. It still wouldn't be all that I'd desire... but I must say that I sincerely appreciate your, at least, considering this point. Anyway, I would like to elaborate on this point: if tags are provided... would there be any restriction that would stop the community from downloading and building a tagged maintenance release and then distributing it (for instance, by uploading it into a maven repository)? Regards, Daniel Fernández.
  221. Re: New Spring maintenance policy[ Go to top ]

    Anyway, I would like to elaborate on this point: if tags are provided... would there be any restriction that would stop the community from downloading and building a tagged maintenance release and then distributing it (for instance, by uploading it into a maven repository)?
    The source being Apache License, this would be possible.
  222. Re: New Spring maintenance policy[ Go to top ]

    Anyway, I would like to elaborate on this point: if tags are provided... would there be any restriction that would stop the community from downloading and building a tagged maintenance release and then distributing it (for instance, by uploading it into a maven repository)?

    The source being Apache License, this would be possible.
    Well, this would be a dramatic improvement on the initial scenario, no doubt about that. I sincerely hope you consider this as a viable alternative. Where do we sign? ;-) Thank you for your patience, Rod. Daniel Fernández.
  223. I sincerely hope you consider this as a viable alternative.

    Where do we sign? ;-)


    Thank you for your patience, Rod.

    Daniel Fernández.
    +1 This would be a great solution. If there would also be a targeted solution for small businesses and developers in the price ranges I suggested ( 300 - 500 euros per server ) I'd still consider also using those options to easily provide customers real tested binaries and to support the development. I mean we do get the troublesome economics of open source and purchase software that we want to support, when the price is right. Where do we sign?
  224. Re: New Spring maintenance policy[ Go to top ]

    Greg,

    Thanks for the suggestion, and for taking the time to set out your thoughts. As I've mentioned above, one of our concerns is tagging opening the possibility of competition from third parties who could divert revenue that would otherwise have helped fund Spring development. I'd like to think the community would see through such efforts, but I'm not sure. I'd like to provide tags--as well as source--to the community if possible.

    The idea of tagging the current branch until the next major release comes out is an interesting compromise, and we will consider it.

    I would love to have a genuinely collaborative dialog with the community on fine-tuning a fair and balanced outcome, and I'm happy that the discussion now seems to be trending that way.

    Rgds
    Rod
    I think someone has already suggested that if tags are provided then it will decrease, not increase the opportunity for 3rd parties to generate revenue -- since more people would be able to safely create coherent Spring releases. *Not* providing tags *increases* the possibility of competition from 3rd parties since it would obviously require more effort to produce a coherent/tested Spring release -- something that a far lesser degree of people would be willing/capable of doing.
  225. Re: New Spring maintenance policy[ Go to top ]

    a few people have asked for tags on the *latest* major version only.

    Is that feasible?
    I would even go as far as saying that it would be better to always have a tagged source + binary release of the latest and greatest, and don't provide fixes for older maintenance branches at all. Don't make backports public. Then you can have it all for free if you are willing to upgrade, and have to pay if you want to keep using anything else. That way people and other projects building on spring ioc and namespace support wouldn't be hurt imho. /Magnus
  226. Re: New Spring maintenance policy[ Go to top ]

    a few people have asked for tags on the *latest* major version only.

    Is that feasible?


    I would even go as far as saying that it would be better to always have a tagged source + binary release of the latest and greatest, and don't provide fixes for older maintenance branches at all. Don't make backports public.

    Then you can have it all for free if you are willing to upgrade, and have to pay if you want to keep using anything else.

    That way people and other projects building on spring ioc and namespace support wouldn't be hurt imho.

    /Magnus
    Actually I was thinking that this was the way that the new policy was going to work from the beginning:
    After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. Subsequent maintenance releases will be available to SpringSource Enterprise customers. Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software . . .
    Confirmation from SS people would be appreciated...
    Francisco A. Lozano
  227. Where is the community?[ Go to top ]

    Probably the biggest issue for me with this announcement (and the well-timed publication of the commit stats) is that it indicates that there is no real community involvement with the development of Spring. Surely if Spring was a healthy Open Source project, instead of OSILO - Open Source in License Only, it would be up to the community to make a decision like this, not a commercial entity providing support. If there are members of the community interested in continuing to publish maintenance releases after 3 months then they should be able to continue to do so on the "official" springframework.org site. However, it seems that the springframework.org site is little more than marketing for SpringSource any more, and given that almost all commits come from SpringSource employees, the development process for Spring doesn't seem very open at the moment. Perhaps allowing the community to step in and provide additional maintenance releases is something that Rod and crew will be willing to consider? All-in-all, this is just another development that make me more wary of "commercial" open source, especially proprietary ones where I can't just move to another vendor's implementation. What will happen to Spring if SpringSource implodes and there is no community around the project? Perhaps there is more of a community of developers hidden behind the commit statistics, but if one company is vetting all patches... I'm sure I'll continue to make use of Spring, but perhaps it's time to look more seriously at moving back to the JEE fold.
  228. Official FAQ[ Go to top ]

    We have now published an official FAQ.
  229. Re: Official FAQ[ Go to top ]

    So no tags... and no chance of getting the three-month-policy only applied to non-current releases... ... looks like it's time to check other IoC stuff :)
  230. RE: Other IOC Stuff[ Go to top ]

    Or perhaps this if you are just using Spring for IOC: http://www.tallsoftware.com/microspring/index.html
  231. Re: RE: Other IOC Stuff[ Go to top ]

    Actually only crucial part of Spring, at least IMO, is declarative transactions. If someone could make/fork mini declarative tx mgmt library I probably wouldn't use Spring any more.
  232. Re: New Spring maintenance policy[ Go to top ]

    I know of atleast two big projects that have now decided to drop spring and move to EJB3 + Guice although must admit it not based on technical merits but "dubious/uncertain" intentions of SS.
  233. Re: New Spring maintenance policy[ Go to top ]

    That is right, the technical merits of course we all know Spring is a great framework and portfolio but the problem here is the "dubious/uncertain" intentions of SS. I try hard to figure out the intentions of SS but I don't have a damn clue. I want to help Rod and SS but they don't let with their secrecy plans or I don't know exactly why they doing this. The Faq's doesn't say much really there are a lot of questions still. I really hope Rod come to us and give us a plain and straight answer and inspire us like he did in his first book. He was one of us that could not stand the garbage J2EE was. I don't want to comeback to JEE but he is pushing us to do it, I don't see another option. Or as the above comment's say SS can charge us license fees to use Spring framework per developer or give us the tags please or anything but don't let us in the uncertain.
  234. Re: New Spring maintenance policy[ Go to top ]

    I don't want to comeback to JEE but he is pushing us to do it, I don't see another option.
    I hate to break it to ya, but by using Spring you have been using Java EE as well. JEE without EJB that is.
  235. Re: New Spring maintenance policy[ Go to top ]

    I don't want to comeback to JEE but he is pushing us to do it, I don't see another option.


    I hate to break it to ya, but by using Spring you have been using Java EE as well. JEE without EJB that is.
    Oh Yeah I mean EJB thanks. I will miss the transactions and the JDBC Template and Spring Batch, SpringMVC( it was the coolest MVC framework to date) and well many more. Rod and SS, listen to your users please :-( (Just the tags please).
  236. Today I contacted SpringSource as someone who uses ONLY the DI + JTA transactions + JPA in GlassFish. I do not use anything else from SpringSource. Since nobody was answering me on the forums I wanted to purchase a support incident or a block of support incidents. I was shocked and horrified with what they quoted me, since I do not use their whole portfolio: http://www.ryandelaplante.com/rdelaplante/entry/the_cost_of_springsource_enterprise So if you're really stuck and have been waiting days for help, be prepared to shell out as much as a new car for support. I really think they should have pay per incident support for $100 or $200. Then people might actually be willing to pay them.
  237. $22,500
    Wow! 22k for something with no scalability/high availability features? 22k for wrapper? Also in the news: http://www.theregister.co.uk/2008/09/26/springsource_president_coo/
  238. $22,500


    Wow! 22k for something with no scalability/high availability features? 22k for wrapper?

    Also in the news:

    http://www.theregister.co.uk/2008/09/26/springsource_president_coo/
    It looks Spring now is proprietary with that article above. So Long Spring!.
  239. $22,500


    Wow! 22k for something with no scalability/high availability features? 22k for wrapper?

    Also in the news:

    http://www.theregister.co.uk/2008/09/26/springsource_president_coo/
    Well... the fact is that, this last paragraph:
    [...] The move "only affects those who are unwilling to go near source code, or update to the latest version," he said. [...]
    In fact, gives us hope that they are truly considering offering the maintenance releases for the last major version (even if it's only the tags), as Rod announced here. So, let's see if they finally announce it officially and stop the mess... Regards, Daniel Fernández
  240. I was shocked and horrified with what they quoted me, since I do not use their whole portfolio:

    http://www.ryandelaplante.com/rdelaplante/entry/the_cost_of_springsource_enterprise
    There are enterprise tools and there are tools that are of enterprise quality. Market in Java-land is in interesting state as Spring was the thing that disrupted everything previously and had put tremendous pressure to old players to prove their value. From my point of view Sun has done a great job transforming some of their offering to fit better also into lowend markets - to become great infrastructure tools anywhere - case example Glassfish and Mysql. Oracle has on the other hand been creating more offering, tools and value that can be stuck down the throath of locked in customers - and is doing quite well financially, launching itself into shopping sprees every now and then. IBM has been doing commercial opensource and other hybrids for some time, but for many developers their tools are still expensive and enterprisey. Jboss is still jboss. Opensource and also quite affordable. As you wrote, Spring's pricing puts it against the big players with real enterprise support that is expensive. But something they might not have noticed is that by having just the enterprise offering and speculation of crippeled down open source version ( 'initial stability adressed' ) they are effectively alienating their base. Only republicans can do that, but even they must now and then - before the elections - must come back to the masses, talk about boys kissing boys being abomination, get the votes and then go back to business. If you initially were the alternative to greedy bastards with superficial value proposition, it seems quite bad move to want to replace existing greedy bastards by transforming oneself into such - nevermind how good your value proposition is. Spring Source's offering is good and we all love the framework, but the packaging is stupid beyond any belief as it works well only for real enterprise customers who are used to dealing with Bea and alike. This wouldn't matter if it wouldn't be coupled with the **** you tactics of new maintenance policy - effectively putting FUD on viability of spring framework's open source version. The utter lack of empathy for people's motivation and understanding dynamics of the community is beyond any belief. As I said previously, what on earth do SS see gaining by setting the 3 months limit on new versions and then cutting the community off. The implicit contract previously was that by going with the latest and greatest was good for you and good for us. New deal might be something different. Bea and Oracle can get away with stuff like that as people have already made commitments to their platforms and paid the price (and the switching costs are in multitudes of higher than what we are speaking here). To be honest the policy itself is not that bad idea and could really well work for some company that pushes out a new product. However as others have noted and commented, Spring has got itself into the position of being integral part of Java world infrastructure and a de facto standard by being robust and open - and this feels like changing the rules in the middle of the game. Might be.. Feels like.. wtf. Yeah. We don't really know for sure what this all means for the future. As we have seen from examples that people have posted, three months in current versioning could / would mean that people would be stuck with nicely buggy versions for a long time - but we don't know what the future would be like. Could be that SS would release versions faster than previously, or not. Fear, Uncertainty and doubt. Normally this requires competitors to spread FUD on your portfolio and product line, this time the company has done it on it's own. Sun gets great community feedback for Glassfish and other projects as the opensource versions are great - and you can run them in production. Deal is clear, and it is simple - everyone is happy and everyone benefits, even enterprise customers or low key customers who still buy support for the commercial QA-tested version. Never mind the critisism and disappointments that I've here described, I do still hope that there is a sane compromise that could solve the situation. Tags for the latest release would be a great way to go and return the situation as it was on logical level. Or make a commitment that new version with patches applied will be made every three months. Rod Johnson has been really good sport on this thread and has communicated that SS tries to take these things into consideration. Hopefully we will hear soon how the thinking goes and what will the future be. If you could go back in time, I wish that I would speak to Rod & co. beforehand and help them see where the message fails. I mean I see that there is possibility that this thing could be the best thing since sliced bread in Spring world - a really good compromise between commercial and opensource needs - but there is no way to tell. And that is the key. So please Rod. Give us the tags, come back to the community and communicate the vision better. We really love spring and we want someone to have leadership, but now we are left in the dark and to interpret what things might mean. And don't fear, we don't expect you to be as inspiring and uplifting as Obama - we still dig you. You have been the man and started a great project. Don't let investors to screw up a great thing into a mess. Communicate, tell a story and inspire us to believe in Spring. From a long time fanboy, soon to be sceptic. ( Put this also to my blog: http://huima.wordpress.com/2008/09/26/spring-and-java-market/ )
  241. Heimo
    Never mind the critisism and disappointments that I've here described, I do still hope that there is a sane compromise that could solve the situation. Tags for the latest release would be a great way to go and return the situation as it was on logical level. Or make a commitment that new version with patches applied will be made every three months.
    We are very seriously considering options around tagging. We will make a decision on this early next week. In the same timeframe, we will hopefully have a lower cost offering for small business as I've mentioned. Please bear with us while we work through the issues.
    Rod Johnson has been really good sport on this thread and has communicated that SS tries to take these things into consideration. Hopefully we will hear soon how the thinking goes and what will the future be.
    Thanks, I appreciate that.
    If you could go back in time, I wish that I would speak to Rod & co. beforehand and help them see where the message fails. I mean I see that there is possibility that this thing could be the best thing since sliced bread in Spring world - a really good compromise between commercial and opensource needs - but there is no way to tell. And that is the key.
    Please feel free to drop me an email if you'd like to chat (and that goes for other posters, also.) I'm not hard to find--rod at springsource. We are seeking a "really good compromise between commercial and opensource needs" and are open to collaboration from the community. Rgds Rod
  242. Summary / TGIF[ Go to top ]

    Another attempt to understand the words being reason for such long topic... The Policy begins with: "Customers who are using SpringSource Enterprise [...]" Does this also means: Customers who are using springframework/spring-weblow/spring-batch ... ? This question gives some hope, as springframework != "SpringSource Enterprise", but wait: "After a new major version of Spring is released [...]" What is the "version of Spring" - version of framework? version of webflow? Sorry for repeating the same questions again and again, but weekend is comming and this topic is getting too long to reload... regards Grzegorz Grzybek
  243. @EJB = freedom injection[ Go to top ]

    @EJB :) and without the need of XML configuration :) goodbye Spring trap :)
  244. Re: @EJB = freedom injection[ Go to top ]

    +1 Spring is Dead!. So long Spring.
  245. Re: @EJB = freedom injection[ Go to top ]

    +1

    Spring is Dead!.

    So long Spring.
    It is time for Summer - real open source fork of Spring!
  246. Lessons learned[ Go to top ]

    Lessons learned: 1. don't give your testicles to venture capitalists, unless you really have no further need for them 2. how to stop worrying and learn to love the Oracle 3. every good thing must come to an end 4. business is business and Moses is Moses
  247. Re: Lessons learned[ Go to top ]

    Lessons learned:

    1. don't give your testicles to venture capitalists, unless you really have no further need for them

    2. how to stop worrying and learn to love the Oracle

    3. every good thing must come to an end

    4. business is business and Moses is Moses
    Nicely summed up Mikael. Moves from SS seem in this new context strange - even from sustainable business development perspective, so either VC forces have not thought things through or are playing bold game of amazing profits or fast kill. Previously Rod talked nicely about appserver market and bloatness of the offering, and appserver market took note. Glassfish is an excellent appserver and it's version 3 promises to be more modular and lightweight. Jboss started to offer their appserver and whole platform in (afaik) affordable pricing. Spring Source releases it's own appserver - based on Tomcat and Osgi. Wtf? Spring framework has become the de facto application framework for non JEE and many cases also for JEE applications, making JEE technologies fun to use. JEE specs have taken note and promise of JEE 6 and EJB3.1 seem to fix some aches that people have had, but not replacing the need for Spring altogether. People like me would have the preference to use Spring as the glue fitting pieces together, using great Spring MVC and Security on top of JPA and robustness of good JEE appserver that provides everything else from scalability and pooling of resources. However these announcements and speculation makes wonder what is the long term direction of Spring and when or where will be there a final headbutt situation that separates Spring and rest of the Java world to different paths. I really don't have clear idea anymore what Spring Source's intentions are and how they are compatible with my goals as a developer, architect or CTO. If Spring's intention is to be the enterprise stack with it's own proprietary technologies and platform ( app server move is nice example ) for tight lockin, then good luck with that. I mean who in their right mind would replace all the standards that at least in theory ease vendor lockins into huge one vendor lock in? Yeah I know that OSGi is the saviour and Tomcat is high on adoption, but I don't really get how that equates to people wanting to pay for a propietary appserver concept. After what I read from comments and ideas I believe that they do have a huge amount of good innovations there, but for f*ck's sake why would I write my application in that fashion using those innovations if there is no other runtime environment where I could _easily_ port everything into a new environment? Oh and never mind the fact that I can easily find people with grasp of JEE technologies (JPA etc.) and basic Spring understanding - which can easily overweight the suggested benefits of new innovations and forcing people to first learn about Osgi to be productive. I wish that I would understand better as with this mess I've become more frustrated and also disillusioned about putting too much faith in Spring basket. Yes Spring has been defining Java landscape for some time, but how big Spring Source think they are? Oh how Rod's writing from earlier on feel ironic: http://blog.springsource.com/2008/01/16/the-power-of-adoption-why-no-company-is-big-enough-to-deny-developers-what-they-want/ Yes. We would like to have tags in repository. For the latest release. Luckily Spring Framework works great as it is for my current needs, but if something promising with a clearer and more compatible future comes along - I'm surely now much more keener to take a look at it and jump the train. And most likely so should you too. Have a great weekend everyone, hopefully we will have soon more information from Spring Source.
  248. Re: Lessons learned[ Go to top ]

    hopefully we will have soon more information from Spring Source.
    Entire SS app server thing is highly likely doomed to fail. Not because I say so, but because all other powers-to-be, vendors who decide which direction will global market go, have taken opposite direction aka standards approach. You cant deny the power to decide/influence which comes with multi-billion dollar IT marker Sun/IBM/BEA/Oracle/RH share. SS is simply too small, and most importantly, their app server is not implementation of some formally defined specification such as Java EE. So the question is: why to invest in SS technical infrastructure?
  249. Re: Lessons learned[ Go to top ]

    Oh how Rod's writing from earlier on feel ironic: http://blog.springsource.com/2008/01/16/the-power-of-adoption-why-no-company-is-big-enough-to-deny-developers-what-they-want/
    I read this article and I ask my self what is doing Spring Source is insane, They are killing by my self. What happen to Rod, he is a bright person and suddenly this change still I don't understand and I don't want to think what comes next, This is sick.
  250. Release status determination[ Go to top ]

    It is difficult for a few people with a strong knowledge and involvement with Spring to monitor the JIRA and commit logs and declare a release? After all, every open source project has to decide when to release and it shouldn't be rocket science. If it works, then we'll have Spring Community Release x.y.z.
  251. OSGI version compatability[ Go to top ]

    Rod, I an wondering if there will be any effect on projects such as spring-dm where version dependencies play a big role. How does this all get synchronized in terms of compatible versions. Best, -- Thomas