According the announcement from Adrian Colyer, CTO of SpringSource:
For a mainstream development team though, who just want to build an enterprise application as quickly as possible, and with as little hassle as possible, the costs currently associated with adopting enterprise OSGi can outweigh the short-term benefits. This situation needs to be addressed before enterprise OSGi can become the de-facto approach for mainstream enterprise application development.While SpringSource will no doubt continue to support OSGi, the extent to which it will continue to provide resources to the donated projects is far from certain. What is more clear, though, is it will no longer be wielding it's own considerable influence within the industry to shepherd its user base en masse towards OSGi.
This is a good thing. Firstly, the obsession with OSGi has distracted the community away from practical efforts which could work more comfortably within the existing enterprise Java model. Hopefully that obsession will go away, or at least be limited to those already converted to the OSGi way. Secondly, from a purely selfish, egotistical point of view, I feel vindicated. For years, I have been saying that OSGi is too complex for the Java mainstream. For years, I have been beaten over the head by a small group of hardcore OSGi evangelists who have persistently used the argument that if SpringSource is betting on OSGi, then it must be a good thing for everyone else, and that any alternative approach does not warrant any consideration. The bet has failed, and this argument has now fallen rather flat. If SpringSource, with all the credibility it has generated through the Spring Framework, all its intellectual and marketing muscle, and all the effort and expense it has incurred, cannot make work OSGi for mainstream enterprise Java, then no one else can.
But all of this is also points to a real missed opportunity. The fact remains that Spring users still need a modularity solution. They need a way of being able to take advantage of the best of what dynamic modularity has to offer - dynamically composable software with genuine decoupling between parts of the application, and rapid build/deploy/test cycles during development - without having to take on all the complexity of the full-blown OSGi approach. This need still exists, and will not go away. As Adrian suggests, this need will not be served by OSGi without some fundamental simplifications, something I could not imagine happening any time soon.
In the meantime, I have invited SpringSource to engage more with Impala. While they have flirted with the idea in the last few months, perhaps even seriously, they have backed away from it for now. In view of recent history, it is not that surprising. Imagine the uproar that would ensue among the OSGi zealots if SpringSource were to go down that route. It doesn't bear thinking about.
7 comments:
Phil, I'm sorry you think I've been beating you over the head. I've really only pointed out your most egregious errors and called you out on your FUD. If you equate those things with physical violence, then you'd better put a helmet on now...
There is nothing in SpringSource's announcement to suggest that SpringSource no longer believes in OSGi or that it will be scaling back its commitment to OSGi in any way. Yes, they are "donating" their code to Eclipse, which really means they are changing it from one open source license (GPL) to another (EPL) and moving its code repository to a more open and popular one (eclipse.org). Remember when IBM "donated" Eclipse to the independent Eclipse Foundation in 2004? Have they scaled back their commitment to it? Are IBM no longer betting on Eclipse?
One things that you might have noticed is that SpringSource were acquired by VMware recently; that changed the equation for the dm Server product substantially. When they were independent and VC-funded, SpringSource needed to monetize dm Server directly through licensing, so the GPL made perfect sense for them. For VMware though, it is more important to grow the community of enterprise developers using OSGi, and that is easier to do when the code is licensed more liberally and hosted at an independent foundation. And, it's working! VMware's competitors such as Oracle and SAP are already providing material resources to enhance the new Virgo project, along with its closely-related Gemini project (no, I don't know where this obsession with Zodiacal names comes from...)
You're right that Spring users (in fact all Java users) still need a modularity solution. That solution is and will remain OSGi. We're not going away. What we ARE going to do is keep making our tools better so that people can better manage the inevitable complexity that arises from *any* true modularity solution.
Neil,
Correction - FUD is your speciality. Your willingness to repeatedly dismiss Impala with only a really poor understanding of its merits and limitations (based apparently on one presentation over two years ago) really astounds me. Have you actually even tried it out?
Personally, I've nothing against OSGi - but as I state again and again, it is just not right or necessary for every project, and approaches such as that of Impala have merit for practical reasons.
But I don't suppose there is any point me ever expecting you to concede that.
Your interpretation of the implications of SpringSource's "donation" of OSGi to Eclipse is predictably generous for OSGi, but you can't walk away from the fact that even SpringSource no longer thinks that OSGi (as it is right now, as least) is the right choice for the mainstream of enterprise Java, a view which has now been stated publically.
Phil
FWIW, from http://jaxenter.com/Adrian-Colyer-Why-dm-Server-Is-Moving-To-Eclipse-10106.html
JAXenter: What does the migration mean for the development process of the dm Server (i.e. Virgo)? Is SpringSource abandoning the project ?
Adrian Colyer: Beyond the 2.0 release which we just put out, ongoing development of the dm Server will happen as part of the Virgo project at Eclipse.org. The full set of SpringSource developers currently working on the dm Server will become committers at Eclipse.org. The aim is to put out a baseline release from the Virgo project as quickly as possible, and ultimately to join the Eclipse release train to coordinate Virgo releases with Equinox and other Eclipse component releases. We already have indication from other interested parties that they would like to contribute to Virgo development too, so the project has a healthy future ahead of it.
Which doesn't sound to me like they're backing away from Spring-DM...
Anyway I need a modularity solution that works across various dependency frameworks, not just Spring, so for me personally that's still OSGi. For others it may be something else, but please let's get back to facts not FUD.
Phil,
"you can't walk away from the fact that even SpringSource no longer thinks that OSGi (as it is right now, as least) is the right choice for the mainstream of enterprise Java"
Of course I dispute that, because it's simply not what they are saying. Going back to the quote: "this situation needs to be addressed before enterprise OSGi can become [...] mainstream". You have interpreted this as "OSGi will never become mainstream". The correct interpretation is "we [SS] are addressing this situation to help OSGi become mainstream".
Adrian did acknowledge that OSGi carries a short-term cost which must be paid before you can start deriving benefit from it. I acknowledge that too. Guess what, so does every framework, including Impala.
Finally I think you have no basis to accuse me of FUD against Impala. I only comment on your blog when you write rubbish about OSGi, and then only to correct you. On my own blog, I never discuss Impala.
Neil,
For examples of spreading you FUD about Impala, take the drivel you wrote in StackOverflow and in dzone.
Talking about whether OSGi will become mainstream for enterprise Java, I certainly did not use the word "never" (another example of you twisting my words). However, in spite of all the effort and hype of the last three years, it's still a long way from becoming a reality, and further still, now that SpringSource are politely absolving themselves from the responsibility of making this happen.
Phil
Again, Phil, they are not backing away from OSGi nor are they absolving responsibility -- see the quote that Stuart posted where they state they are committing the same number of developers to dm Server now as they were previously. Or Glynn Normington's blog, in which he described SpringSource's deep involvement in the OSGi standardisation process.
I'm tickled by your whine on StackOverflow that I spend much of my time smearing Impala. I would have no need to talk about Impala at all if not for your ongoing one-man anti-OSGi campaign, in blog post after ignorant blog post.
Well, I'm signing off this thread for now. I do wish you luck with continuing to enhance Impala, and I suggest that that might be a more productive activity than these very (very, very) premature declarations of victory ;-)
Neil,
As I repeatedly state, I am not anti-OSGi - I am just anti the notion that it's approach to modularity is appropriate for every project which can benefit from modularity in an application. I am also certainly very much opposed to your attack dog tactics for trying to browbeat people into OSGi acceptance, something I noticed on many occasions in blog postings and comments.
By the way, I am not ignorant of OSGi - I actually have a pretty good understanding of how it works, something which certainly cannot be said for you about Impala.
Phil
Post a Comment