Around 37:00 into the talk, he had a slide "Some things we got wrong at SpringSource" and it contained bullets about the over investment in OSGi for 2 years, which I quote below:
Its interesting to note that about an year back, Ross Mason of MuleSource blogged about using OSGi in the Mule ESB in the post OSGi? No Thanks and said:
- Seduced by technology in search of a problem
- Clever technology but didn't solve most pressing customer problems
"Classic example of falling in love with a technology without considering the business implications.
We significantly over invested in OSGi and our dm-server technology for a couple of years. It wasn't a bad technology. Unfortunately, it simply solved a set of problems that a very small number of customers had., and yeah, we should have spent more time listening to the pressing problems our potential customers actually had.
That ultimately was something that we worked around, but we spent millions of dollars that we could have spent elsewhere."
OSGi is a great specification for middleware vendors, but a terrible specification for the end user. This is because OSGi was never build for application developer consumption
1 comment:
This is absolutely true. Currently I have to do configuration for a particular product of particular company which uses OSGI largely and I am very frustrated about that it does not give admin console even if one back end 3rd party web service down.
Post a Comment