Is OSGi Crossing the Chasm?
Is OSGi Crossing the Chasm?
Join the DZone community and get the full member experience.Join For Free
FlexNet Code Aware, a free scan tool for developers. Scan Java, NuGet, and NPM packages for open source security and open source license compliance issues.
Crossing the Chasm is one of the classic technology business books that describe how new technology is adopted (or not adopted) by the mainstream. The main thesis is that new technology is first adopted by technology innovators and visionaries but for it to be adopted by the pragmatist in the mainstream the technology needs to meet very different expectations. In fact, if a technology does not meet these expectations it won’t cross the chasm and be adopted by the mainstream. Two recent blog post by Tony Baer of Ovum and Kirk Knoernschild of Burton Group which aren’t too flattering towards OSGi made me think that maybe OSGi is in the midst of crossing the chasm?
Over the last two years OSGi has been embraced by the alpha-geek community, especially in the Eclipse and Java community. OSGi is well establish as the foundation for the next generation of Java application servers. The EclipseRT community is taking hold and creating a wide portfolio of runtime components, based on OSGi, that will benefit enterprise users. There are lots of examples of success stories from organizations that use technology as a competitive advantage. OSGi has won the hearts and minds of the technology innovators and visionaries.
Now what are we going to do for the mainstream early majority? I’d like to suggest a few things:
1. OSGi needs a better value proposition. Kirk is correct: modularity is boring and old. Mainstream IT executives could care less about modularity. The guys at Parmeus are focused on speed and agility; this seems to ring true to me. They even have a product called Nimble. I am not sure if it is the right value proposition but I know we need something more than modularity.
2. Easier on ramp for OSGi. OSGi is too hard for the average developer to learn. The one thing I admire about the Ruby-on-Rails community is the ease of which people can get immediate results. We need the same thing for an OSGi or EclipseRT solution. A developer should be able to download, install and instantly have a running demo application. We also need more and better OSGi tutorials and books. The new OSGi/Equinox book is a great start but we need more.
3. Case studies showing success. If you have had success using OSGi, especially in an enterprise application, we need you to tell your story. Write a blog post, present at a conference, write a case study for Javalobby, leave a comment on this blog, do something to let the world know about your success. We have created a number of success stories about organizations using EclipseRT but we need more. The early majority will look to what their peers are doing, so we need to get the word out.
4. A solution approach. A critical factor in crossing the chasm is that an technology adopts a more total solution approach towards customer engagements. These customers want a solution for their problem, not a set of technology. This means having the consulting, training, tools and long-term support required by early majority organizations. Companies like VMWare Springsource, Eclipsesource, Parmeus, Prosyst and I know many others provide this total solution for their customers. I am also encouraged IBM Websphere is doing more OSGi related outbound evangelism and I am sure IBM will offer a solutions approach.
Will OSGi cross the chasm? Yes but it will take some time, since this technology is at the heart of the IT infrastructure stack. Will people start to predict OSGi is dead in the next 12 months? Of course, since that is the natural hype-cycle of the IT industry. However, they will be wrong. OSGi is hear to stay but it is still unknown how prevalent it will be in the next 5 years.
What else do we need to do to take OSGi across the chasm?From http://ianskerrett.wordpress.com/2010/04/13/is-osgi-crossing-the-chasm/
Opinions expressed by DZone contributors are their own.