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?
Ian Skerrett 
I agree that executives don’t get modularity, but they do get *cost* and ultimately that’s what developers are attempting to drive down by creating modular systems. (And by insisting on other quality attributes such intention revealing code, loose coupling, high cohesion, etc.)
We create mechanisms to make our lives easier, but really it’s all about cost. In necessarily complex systems, modularity will drive down cost and by implication increase profitability.
But things are moving quickly now – I am seeing customers come to me who have already made the decision to go to OSGi and need guidance. They see the major vendors going that way, and feel it’s now safe for them to do the same.
I also agree that OSGi is too hard to get into. There are many reasons for this, but I think the increased adoption that I believe is currently happening will help – people will write and blog more about it and in turn this will help guide more adopters. Success, as ever, will breed success.
Something else. All tutorials, as a matter of course, should point developers away from the spec and API and towards the friendlier abstractions such as the Blueprint services, almost as a first port of call. For the vast majority of developers, these abstractions, a good IDE/PDE and a simple build environment are all that’s needed.
The German Eclipse Magazine is always looking for success stories about EclipseRT technologies – which could also be published in English at jaxenter.com. There will be a number of sessions on OSGi success stories at the JAX 2010 conference – such as the migration of German health insurance providers TK, to OSGi.
@tara Thanks for your insight. I agree cost is a consideration but I think we need to more clear how it reduces costs. Everyone will say ‘reduce cost’ as a value proposition so how is OSGi different?
I do agree with your optimism on people starting to move towards OSGi. Now we have to make sure they are successful. 🙂
@hartmustscholsser JAX is a great supporter of Eclipse and OSGi. It is wonderful to see you are getting some very compelling case studies. This will be a big help.
Ian, your response to Tara hits the nail on the head. All the benefits we can list for OSGi — reduced cost, better reusability, isolation of risk — have been touted before by others. The problem is, they failed to deliver.
CxOs are rightly skeptical of such claims, and our response of “ah but this time it really works!” just sounds lame. We need data, data and more data.