OSGi has been introduced many times in the past few years and will still require some in the future1. With so many introductions, one might be inclined to think that this is a new technology. To the contrary, OSGi is a good 14 year old technology started in 1999!
So why does such an old technology still require an introduction? Is it because it is not yet popular and not reached mainstream yet? Even after 14 years! There are more than 3 implementations of the OSGi specification. Glassfish and Websphere uses it. JBoss supports it. Apache Geronimo provides it. Eclipse is built on it. Netbeans supports it. Spring dmServer and Oracle JDeveloper is built on it. As you can see, most of the middleware servers and the top IDEs are either built on OSGi or has support for it. So, popular it is! But mainstream? That is debatable.
The applications mentioned above are middleware or tooling products. You can use any of these products without knowing anything about OSGi. This is good as well as bad. Good because it helps adoption, as unlike other frameworks, OSGi does not come in the developers' way. Bad because developers tend not to follow the OSGi principles while developing applications. Besides, middleware and tooling product developers are far less compared to general java developers. There have been few attempts to make OSGi available for general purpose development like Spring dmServer (now Eclipse Virgo). But it did not gain much traction. So, why is OSGi not mainstream yet in spite of all the benefits that it provides? Here, I summarize some of my personal observations behind the reasons of OSGi's non-adopt-ability:
The OSGi group looks like an elitist club with minimal public engagement up until recently. Only big companies seem to be part of it. There is no open-source-community-like engagement with the general public or at least it appears so.
The name (OSGi Alliance) itself sounds very technical and non-mainstream. I agree that OSGi started in a niche area and now have expanded to general purpose usage. But since the context has changed, so should the engagement. I think, a name like `OSGi Foundation` will make it less intimidating (`OSGi` itself cannot be dropped because of brand value and historical reasons).
The group should allow individual technical contributors without corporate affiliations to be part of the top membership. A similar model like the current Java Community Process (JCP) or Spring community will make it look more open. I know many will disagree that the JCP is an open community. But it does allow individual membership and is becoming more open.
The OSGi specification is full of jargon. Names like blueprint and compendium, for example, sounds complex although they have simpler names. The use of `Specification` instead of `API` to describe a standard makes it sound too technical like the CORBA specification. Yes, I know that OSGi IS a `Specification`.
Can't we have a specification without calling it a specification? I think `API` is a much simpler term to use just like how the JCP uses it. All JCP APIs are standard specifications. But for marketing purpose, API sounds more appealing to the general masses. Similarly, call it dependency injection container or CDI container instead of blueprint container to make it sound familiar with JavaEE CDI concepts.
Lots of FUD (Fear, Uncertainty, Doubt) has been generated regarding OSGi. Read this and this and this and this and that. Some of those opinions have been presented with the sole intention to garner page hits. The title do not match the contents. Some of these has been addressed while some may not. Some are genuine concerns. When a new developer reads such articles, they become very skeptical about adopting it. When people like Rod Johnson says it is complex, people(developer, architect, project manager, IT department) tend to believe it.
http://jaxenter.com/jax-magazine/JTJ-2011-04
LinkedIn's use of OSGi
http://javadepend.wordpress.com/2012/10/11/the-osgi-puzzle/
http://soupinadeli.com/pdfs/a-year-with-osgi.pdf
http://branchandbound.net/blog/java/2013/07/java-modularity-story/
The OSGi site does not provide an official reference implementation of all the specifications. Individual specifications/API are implemented by different project groups mostly from the Apache stable. Core implementation is provided by Eclipse Equinox project. Some of the enterprise APIs are provided by Apache Aries, Apache CXF and other projects. This means a developer has to pull together different parts from various sources to meet his needs. This can be overwhelming sometimes.
Similar to how JavaEE provides an official reference implementation and complete product (Glassfish), OSGi should provide a reference implementation together with every specification release. OSGi R5 has been released in 2012 but still there is no complete R5 implementation after one year. This implementation need not be a new project. One of the main two projects, Equinox or Felix, should be made the centralized implementation of all core and compendium specifications.
A concurrent implementation release with every new specification release will allow users to start 'playing' with the new features. This will create more buzz as people will start blogging, tweeting and pinning their experiences.
In fact, a core product similar to OpenJDK project, would be more appealing. The core can be maintained by all parties interested (Equinox, Felix, Knoplerfish, JBoss) while individually they can differentiate by additional components or integration with their products.
The OSGi blog seems to be the personal blog of Peter Kriens. There are no other contributors to the blog. Don't misunderstand me. His posts are always very informative and insightful and a Body of Knowledge by itself. I always look forward to his posts. But, only one person speaking about OSGi in a community that boasts of hundreds of members does not correctly reflect the diversity of the community. On the other hand, the OSGi wiki is non existent. It is hardly being maintained.
Blogs from different community members should be published in the official blog area and not just as RSS feed. This will complement the efforts to counter the FUD mentioned earlier.
The wiki should also be maintained more regularly with up-to-date information. More tutorials, code snippets, design rationale, etc. should be provided.
The applications mentioned above are middleware or tooling products. You can use any of these products without knowing anything about OSGi. This is good as well as bad. Good because it helps adoption, as unlike other frameworks, OSGi does not come in the developers' way. Bad because developers tend not to follow the OSGi principles while developing applications. Besides, middleware and tooling product developers are far less compared to general java developers. There have been few attempts to make OSGi available for general purpose development like Spring dmServer (now Eclipse Virgo). But it did not gain much traction. So, why is OSGi not mainstream yet in spite of all the benefits that it provides? Here, I summarize some of my personal observations behind the reasons of OSGi's non-adopt-ability:
Observation One: Elitist
The OSGi group looks like an elitist club with minimal public engagement up until recently. Only big companies seem to be part of it. There is no open-source-community-like engagement with the general public or at least it appears so.
Solution
The name (OSGi Alliance) itself sounds very technical and non-mainstream. I agree that OSGi started in a niche area and now have expanded to general purpose usage. But since the context has changed, so should the engagement. I think, a name like `OSGi Foundation` will make it less intimidating (`OSGi` itself cannot be dropped because of brand value and historical reasons).
The group should allow individual technical contributors without corporate affiliations to be part of the top membership. A similar model like the current Java Community Process (JCP) or Spring community will make it look more open. I know many will disagree that the JCP is an open community. But it does allow individual membership and is becoming more open.
Observation Two: Too many jargon
The OSGi specification is full of jargon. Names like blueprint and compendium, for example, sounds complex although they have simpler names. The use of `Specification` instead of `API` to describe a standard makes it sound too technical like the CORBA specification. Yes, I know that OSGi IS a `Specification`.
Solution
Can't we have a specification without calling it a specification? I think `API` is a much simpler term to use just like how the JCP uses it. All JCP APIs are standard specifications. But for marketing purpose, API sounds more appealing to the general masses. Similarly, call it dependency injection container or CDI container instead of blueprint container to make it sound familiar with JavaEE CDI concepts.
Observation Three: FUD
Lots of FUD (Fear, Uncertainty, Doubt) has been generated regarding OSGi. Read this and this and this and this and that. Some of those opinions have been presented with the sole intention to garner page hits. The title do not match the contents. Some of these has been addressed while some may not. Some are genuine concerns. When a new developer reads such articles, they become very skeptical about adopting it. When people like Rod Johnson says it is complex, people(developer, architect, project manager, IT department) tend to believe it.
Solution
To counter these FUDs, more and more real life examples of successful projects should be published. Additionally, architecture, design patterns, anti-patterns, best practices, etc. should be published frequently. Some of these are available but they have become dated. Fresh information on latest technologies will create the buzz around OSGi. The following links addresses the strength of OSGi:
http://jaxenter.com/jax-magazine/JTJ-2011-04
LinkedIn's use of OSGi
http://javadepend.wordpress.com/2012/10/11/the-osgi-puzzle/
http://soupinadeli.com/pdfs/a-year-with-osgi.pdf
http://branchandbound.net/blog/java/2013/07/java-modularity-story/
Observation Four: No centralized implementation
The OSGi site does not provide an official reference implementation of all the specifications. Individual specifications/API are implemented by different project groups mostly from the Apache stable. Core implementation is provided by Eclipse Equinox project. Some of the enterprise APIs are provided by Apache Aries, Apache CXF and other projects. This means a developer has to pull together different parts from various sources to meet his needs. This can be overwhelming sometimes.
Solution
Similar to how JavaEE provides an official reference implementation and complete product (Glassfish), OSGi should provide a reference implementation together with every specification release. OSGi R5 has been released in 2012 but still there is no complete R5 implementation after one year. This implementation need not be a new project. One of the main two projects, Equinox or Felix, should be made the centralized implementation of all core and compendium specifications.
A concurrent implementation release with every new specification release will allow users to start 'playing' with the new features. This will create more buzz as people will start blogging, tweeting and pinning their experiences.
In fact, a core product similar to OpenJDK project, would be more appealing. The core can be maintained by all parties interested (Equinox, Felix, Knoplerfish, JBoss) while individually they can differentiate by additional components or integration with their products.
Observation Five: Community, community
The OSGi blog seems to be the personal blog of Peter Kriens. There are no other contributors to the blog. Don't misunderstand me. His posts are always very informative and insightful and a Body of Knowledge by itself. I always look forward to his posts. But, only one person speaking about OSGi in a community that boasts of hundreds of members does not correctly reflect the diversity of the community. On the other hand, the OSGi wiki is non existent. It is hardly being maintained.
Solution
Blogs from different community members should be published in the official blog area and not just as RSS feed. This will complement the efforts to counter the FUD mentioned earlier.
The wiki should also be maintained more regularly with up-to-date information. More tutorials, code snippets, design rationale, etc. should be provided.
General Observations
- The OSGi site design is dated. A modern theme should be applied to make it more appealing.
- Community engagement must be made a priority. Programs similar to Adopt a JSR should be adopted to encourage community participation.
1 This will become a past event after the scheduled date.↩
