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.
