Reactions to Licensing, OSGi, and Technical Aspects of the SpringSource Application Platform

Excuse my naievete.

As someone developing a large enterprisey system with a fair number of (strictly managed) dependencies, what does porting my application (an EAR + WAR) from <conventional app server> to SAP do for me?

This nifty technology around provisioning dependencies sounds.. nifty, but shouldn't your application be explicit about defining and providing its dependencies?

Why do I need to delegate 'go get my servlet JAR' to the app server? What benefit does this give to a typical enterprise app with a long lifetime and strictly controlled dependencies?

What are the other benefits that would convince me to move platforms? I realise that there's support for hotswapping components, but if, again like a typical enterprise app, my upgrades are strictly controlled and scheduled - what am I gaining here?

What are the real life gains I can expect from going through an effort to 'port' to OSGi? Real benefits please, that you've seen from a real life deployment, not bullet points from a marketing brochure.

Neil,



I'm not going to reveal the exact size of the development effort for the SpringSource Application Platform, but let me at least say it took several person-years of some very smart people to get to this stage. That's not the kind of sizing that a lightweight integration takes. Making OSGi work for enterprise application development, and with existing enterprise application libraries was a lot of work. Plus even forgetting the end-user OSGi support, the dm-kernel itself provides for an excellent server platform with a lot of attention to detail paid to things like efficient threading models, deadlock detection, per-application trace logs etc..



-- Regards, Adrian.

Adrian,

Who cares if it took several man years of "very" smart people to create this box around OSGi? What people do care about is the business value a product brings, ease of development, standards availibility of talent, ROI and vendor-lockin..the list can go on. Unfortunately Raher than focusing on these issues , only thing Spring is using to promot S2AP all the time is
- OSGi and it's integration
- FUD (about JEE)

I am not sure if this is going to win you many friends in the community that has started to question the "real" value of spring.

Good luck to you (and your investors)!

Neil



Let me first deal with your comments about VC funding. The fact that SpringSource is a rapidly growing company is immensely positive for Spring. Look at the huge amount of quality Spring releases that are resulting: Spring 2.5, Spring Web Flow 2.0, Spring Security 2.0, Spring Web Services 1.5, Spring Batch 1.0... All deliver real benefits from users, and we've never been able to deliver this much code in such a short space of time. The growth and success of our business is good for Spring and good for those who build and run Spring applications.



Demonization of VC-funded companies is lame and superficial. Nearly every great software company has been VC funded. VCs and strong businesses are a necessary part of the software landscape. Take some leading enterprise Java solutions--Spring/Eclipse/Hibernate/Tomcat: all have benefited from either investment of large companies, or VC funding. At some point your buddies at Paremus will either get funded, acquired or fail to be able to realize their technology vision, and let all their users and customers down. They've got more chance of getting where they want to from an engineering perspetive if they go down the first route.



There has been no change of direction at SpringSource: merely progressive execution of our plan to be take a leading position in enterprise Java. As for "Spring will no longer feel like "our" product - but SpringSource's": the people behind Spring are the people behind SpringSource.



We chose in late 2006 to raise money in order to build the next-generation stack. We're proud we've accomplished that. Our company had been running for 3 years when we raised funding. We were already a real company with real technology. We had a choice of investors who wanted to buy into our vision. Anyone who has observed me over the years--whether they agreed with me or not--should be in little doubt that I am not likely to be an investors' puppet.



Enterprise Java needs a transformation. We've helped to drive that with Spring and our longstanding thought leadership. There's further to go and we're proud that we're continuing along the route.


Rgds

Rod

Michael, this is a great question and deserves a thorough answer. I started on the answer but it turned out to be longer than can comfortably fit in a comment. When I finish writing it up I'll post it on the SpringSource blog and put a link here...

Adrian,

Who cares if it took several man years of "very" smart people to create this box around OSGi? What people do care about is the business value a product brings, ease of development, standards availibility of talent, ROI and vendor-lockin..

the list can go on. Unfortunately Raher than focusing on these issues , only thing Spring is using to promot S2AP all the time is
- OSGi and it's integration
- FUD (about JEE)

Good luck to you (and your investors)!

"A", my only point in mentioning the development effort involved is that it should clearly indicate there is something more substantial going on than a mere surface integration of the technologies involved. Michael (above) asks a great question: (paraphrasing) ignoring the hype about OSGi, what benefits should I expect to see from moving a traditional JEE application to OSGi? I intend to answer that question fully in a separate posting.



You seem confused about the relationship between "Spring", "SpringSource" and "S2AP".



"Spring" (as in the Spring Framework) is an open source Apache-licensed project, which together with a number of other "Spring xxx" projects (e.g. Spring Security, Spring Web Flow, Spring Web Services, ...) is made freely available from springframework.org. "Spring" cannot promote S2AP, and the Spring Framework remains unchanged by this announcement. It is still exactly as it was, and will run happily in a wide range of Java environments.



"SpringSource" is the company behind the Spring Framework, and the entity that has developed and is promoting the SpringSource Application Platform (S2AP).



"S2AP" is an open source product developed and released by SpringSource, and made available from springsource.com. The availability of S2AP in no way changes the 'real' value of Spring (perhaps you can make a case it increases it, because now there is a new deployment option...). Anyone who wants to is free to deploy Spring-based applications on S2AP, and they are equally free to deploy them to any other platform.

Neil



"Buddies" is not offensive. At least here in the US. You're jumping to conclusions. As for Paremus, I wish them luck and wasn't attacking them or you. And I stand by my conclusion that the best thing they could do for their business and their technology is to raise funding, and that attacking us for doing likewise is unreasonable.


As for "comments I did not make". Let me quote from what you wrote:

It just seems the inevitable effect of VC funding (more marketing - no more innovation) is kicking in

Neil,

I don't doubt the considerable effort that has gone into the Spring Framework

Newton is a distributed component framework in which the components can be simple POJOs or wrappers around components based on other models.

Neil


I didn't mean to offend you, and on re-reading I see that "demonization" was stronger than I intended. I apologize.

it just seems the inevitable effect of VC funding (more marketing - no more innovation) is kicking in

Here is the reply I promised earlier.

Let's be clear, I'm not hitting in at some marketing angle, I'm genuinely disappointed at the rate _all_ application server development is happening at. Writing distributed applications today is not much simpler than it was 7-8 years ago and that sucks, doesn't it? I suppose I'm just frustrated that people like yourselves who are in a such good position to push that envelope don't appear to be doing so right now.

As is Newton, the fact that it can do things that S2AP can't doesn't infer that it can't do things S2AP can. Newton is perfectly capable of acting as an OSGi application server that is a simple but valid use and it certainly can deploy applications "of the kind being deployed today on servers such as Tomcat, JBoss, GlassFish, WebLogic, and WebSphere".

But really it's not about S2AS vs. Newton or Spring vs WebLogic etc. - I'm sure you guys will make a darn good job of S2AP; what I'm interested in is solving the real and tough problems we have today in distributed enterprise environments. For the 80% of people who need to worry mostly about Hibernate and web apps they're pretty sorted already - it's those of us who keep finding ourselves in the last 20% (or even less) who need just a little more help :-)

• Newton - has excellent support for distributed computing. I have no information available if Newton also takes some effort to make Spring-contracts work in OSGi environment.


• S2AP - has support for making Spring-contracts work in OSGi environment (load-time weaving, etc). But the part of making the whole solution work in a distributed manner is still left on the shoulders of the application developer.
  

• question to Neil (as the best Newton expert available on this thread) - does Newton do some magic (similar to S2AP) to make Spring-contracts work in OSGi environment? For specific description of that magic you can refer to the blog post that Adrian posted above.


• question to Adrian - as both Newton and S2AP are based on OSGi, I could "just" combine those two products, right? Maybe you even have plans for doing something like this (borrow stuff from Newton) in S2AP roadmap? Can you predict the amount of engineering required to make this work?

Neeme,



I'd just like to jump in and answer the specific questions you raised.




Question to Neil:

Not quite sure what you mean by "Spring-Contracts", but I can comment on Load Time Weaving.




Newton fully supports Spring-DM. Spring-DM (I believe) doesn't support load-time weaving; this a current OSGi limitation. The reason for this is as follows:




1. OSGi bundles are limited to using code from packages they import, as defined at compile time.


2. Load-time weaving potentially changes the code a bundle uses, making it necessary to use code from packages that aren't imported.


3. They can't -> Bang The OSGi Alliance are well aware of this problem and currently working on a standards based solution.




Paremus will fully support these capabilities once standardized by the OSGi Alliance.






Question to Adrian: Any third party "borrowing stuff" from the Newton would need to comply with Newton's AGPL licensed and Paremus copyright, i.e. all derivative works must be AGPL; including services hosted from a derivative platform. Parties wishing to avoid these AGPL obligations, perhaps wanting to build a commercial product built up, or service run hosted upon a Newton derived platform, need to engage in commercial dialogue with Paremus; this also allowing access to the much more powerful Infiniflow platform.





On the larger debate, I'll only make one comment. I believe that GPL license model is an excellent open-source license model. The backlash against companies that use the GPL license is quite frequently driven by self-interest.




Remember free as in Freedom, not "free beer"!




Regards Richard

I didn't for one minute say that VC funding is evil - this is how you read that bit Rod, and if I was unclear in my comment let me now be more clear - from what I see, and have seen, it does inevitably slow down innovation in open source technology projects, however, (...)

I think you are only looking at one side of the coin here.

Working for a startup without funding is, as you put it, pushing the envelope. You have to. If you don't, you won't get paid, and you won't succeed.

Generally, what goes along with "pushing the envelope" is also a fair bit of waste. Shortcuts get taken, dumb decisions get made in order to meet whatever needs it is perceived the market has. That is also part of what being a startup is all about. Most startups fail. Those who don't generally rewrite their code a number of times before getting it right.

Now, before Rod comes and takes my head off - I am not talking about Springsource. I am talking about my own experiences working for startups, and the Spring framework seems to suffer less from this affliction than the products put out by many other startups.

So yes, the speed may go down. You also don't get the same amount of waste. I can't see anything wrong with that.

I really, really don't agree with you that distributed applications look the same now as 7-8 years ago. From my hilltop I can see extreme changes. Stuff gets tested (and Spring is a major part of making that possible), there are at least attempts at developing systems in a more agile way, there are other platform options beside EJB 1.0. I really can't see your point of view at all. Stuff is vastly different than they were in 2000, and mostly for the better.

I could also wish for faster change. There are some technologies I have not tried to introduce because there are nobody out there who knows them. Getting people who know their way around AOP is non-trivial around here. OSGi? Perhaps in a while.

I hope Springsource keeps up the good work. I like what they have been doing so far. I haven't used S2AP yet, so I won't comment on that. Yet.

Geir

Number one, I don' believe that standard OSGi is an end user/application developer construct. Its not something that should be consumed by app developers which instead should be focused on writing POJOs and/or EJBs. It provides really no benefits during development and primarily shows its value add in application development within production deployments.

Second, the reason I want OSGi to become prevalent is so that we have a standardized kernel that the industry is using. I wish Java EE from the beginning defined a kernel, then all its services second. This would have made it much much easier to have standalone specifications that could be implemented a la carte by different vendors and open source organizations. So, really, IMO, OSGi is really something that is going to benefit vendors and framework developers from a software development perspective.

Third, unless Spring Source standardizes its OSGi innovations, including DI integration, it pretty much isn't very interesting, because most of us want to unify under a standard, not a proprietary, GPL based solution that is going to lock us into one vendor. This is what standards are for and I am continually disappointed (but not surprised) that Rod and Co. have little interest in beefing up standards.

Fourth, if you dig up some of Marc Fleury's old talks on the JBoss Microkernel you see a lot of similar features, arguments, and marketing talk that folks like Glassfish and SS are touting now. Just replace JMX with OSGi and u see what I mean. I'm not saying this to say "We were here first :p", but more to expand on the argument that there is no innovation here. OSGi is just a standarization of what many of us have been doing for years. And this is a *good* thing. We need the standardization, we just don't need the proprietary aspect of it.

@Neil, you have a point about VC's, business, and innovation. The thing is, most companies do not want a product that is changing every other month. They want something stable, productized, clean, and smooth. What I've experienced at the last few companies I've worked at is that productization of a project is at least an order of magnitude more work that creating the project (and an order of magnitude more monotonous and tedious). IMO, Spring Source is at this productization phase and you will naturally see a slow down in innovation. This is because productization is actually more important than innovation at times.

--
Bill Burke
JBoss, a division of Red Hat
bill.burkecentral.com