OSGi – Feast or Famine?

I want to be careful here, but also very clear – I advocate OSGi and modularity, though am concerned about its future. In some circles, OSGi is hailed as a disruptive technology; in others, it lives in relative obscurity. There are some indications that adoption is growing, and possibly at some point, it’ll catch like wildfire. But right now, OSGi is the most widely acclaimed technology that nobody is using.

Maybe I’m too harsh. Or too impatient. Maybe I need to give it more time. I know some will argue that people are using OSGi, and they’re right. Some are. But of the more than 6 million Java developers worldwide, those using OSGi and designing modular applications is only a very small fraction.

So what’s the problem? What’s needed to drive adoption? How will OSGi and modularity succeed?

What’s In a Name?

One of the greatest inhibitors to adoption has been platform support. Until recently, few platforms exposed the virtues of OSGi to the enterprise developer. That’s beginning to change, and should help drive adoption. Another obstacle is tooling, which I discussed a while back when lamenting that one of the biggest barriers to adoption is no migration path. With better tools, we’re beginning to overcome that challenge.

But will it be enough? Will platform support and great tools help drive adoption? Sadly, possibly not. And part of the problem, I believe, has very little to do with the technology, and much more to do with its image.

So, what’s in a name?

OSGi is the dynamic module system for Java!

Modularity – Old and Stodgy

Recently, I commented on a recent conversation I had with a conference organizer and his reluctance to accept my speaking proposal on modularity. The general sentiment was that it’s an old, boring concept that can be traced back 40 years! He was interested in my talk on agility, but I explained that given the choice, I’d prefer to speak on modularity.

Currently, I’m participating in a similar conversation with the organizers of the Agile 2010 conference on a few sessions I’ve proposed on modularity. And now, Peter writes about a similar experience. This sends an important message to the OSGi community, and highlights an important challenge surrounding modularity. The message: Modularity is boring! The problem: The importance of modularity, and its support as a first class citizen on the Java platform, is not well communicated nor understood.

Not a Technology Problem

This is a serious problem that requires attention. In his post, Peter suggested that micro-services may be a more apt term for OSGi services, so as not to confuse the term with web services. He even hints at proposing a new JSR that would introduce the idea of micro-services as a new primitive on the Java platform. This is a good start, and micro-services isn’t a bad idea, but more needs to be done. The problem is not that OSGi isn’t a great technology with real benefits, the problem is that nobody cares about modularity.

Possibly it isn’t that they don’t care, but instead that modularity won’t sell. Nobody wants to buy a 40 year old technology, they want to buy the next great thing. And without question, developing modular software is not a new idea. But in general, the ideas surrounding SOA were not new either. Yet, without question, SOA has garnered significantly more attention than OSGi over the past decade. SOA has had its day in the sun; OSGi and modularity have not.

This is not a technology problem. The real problem is that OSGi doesn’t have a clearly articulated identity that explains why an organization must be using it, and organizations will adopt OSGi only if its adoption can be tied to real business benefits. Just like object-orientation in the 1990’s and SOA in the 2000’s, each were sold with a wonderful accompaniment of benefits that would reduce cost, speed delivery, model the real world, blah, blah, and blah. Whether they did or did not help organizations realize these benefits is arguable. Whether each were widely adopted is not!

Crossing the Chasm

OSGi has the potential to be this decade’s most disruptive technology. Unfortunately, the virtues of OSGi run the very real risk of never coming to fruition if it’s unable to cross the chasm. And sadly, it can never cross the chasm unless we find an effective way to sell, or reinvent, modularity.

Foremost, OSGi, modularity, and micro-services do not represent the paradigm shift that’s necessary. Too often, we talk about OSGi in terms of its technical merits alone. Unfortunately, that’s not enough. If OSGi is to cross the chasm, it is going to require something different. Something that people can really latch onto. Something that gets them excited. Modularity isn’t enough. Nor is plug-in architecture. Nor any other technically superior thing that OSGi is.

Naturally, this is only my perspective. My opinion. But OSGi has been a widely acclaimed technology for several years, and it has achieved very little enterprise adoption. While the move by SpringSource to donate dm Server to the Eclipse Foundation was hailed as a great contribution to open source, it’s also a clear indication that adoption of dm Server was gaining little traction.

Now, it is possible that an 800 pound gorilla could throw their weight behind OSGi and modularity that will help drive enterprise adoption. Maybe IBM’s move to expose the virtues of OSGi to the enterprise will be enough. With other vendors following suit, and up and coming vendors such as Paremus on the rise, that just might be enough. But if it is enough, I still believe the enterprise isn’t going to buy OSGi and modularity for the reasons we believe they should, they’ll buy something else very trendy in which OSGi and modularity plays a central role. Something new. Something fashionable. Because as I recall Ivar Jacobson alluding to at a keynote a couple of years ago,

The software industry is more driven by fashion than the fashion industry.

Sad. But true! And hopefully when it happens it won’t dilute the value of OSGi and modularity.

Ignore my Rant if You Want

OSGi is a great technology solution. But we also recognize that technologically superior solutions often fail to win. One of the most popular stories is of the video tape format wars. So my little pontification here should in no way be interpreted as questioning whether OSGi is capable, but instead whether OSGi will.

You can choose to ignore me if you’d like, scoff at me, or call this a rant. Maybe I’m just impatient. Either way, I’ll still continue to proclaim the virtues of OSGi and modularity. I believe in it…firmly! But the nagging feeling I have surrounding its ability to cement its place in the world of enterprise software development will continue to tug at me. And I wonder…will it ever succeed? And if so, how? And…when?

What do you think?

11 thoughts on “OSGi – Feast or Famine?

  1. We (Paremus) are seeing rapidly build traction / interest.

    Perhaps we have a special viewpoint?

    Perhaps it takes the fuses of two paradigm shifts the set the world alight? OSGi & Cloud concepts. Modularity and Resource abstraction?

    The Paremus Service Fabric usually receives interest – not necessarily because it supports OSGi, not because it is built from OSGi – but because of the speed organisations can deploy and roll back complex composite systems across an arbitrary set of compute resource.

    OSGi is a major enabler in our story – but like all good magic – the more it is invisible (courtesy on Nimble) – the better/ the more compelling / OSGi becomes ??

  2. Having just authored a book on OSGi recently, I can assure you that I (and my co-authors also) share your opinion. I am a pragmatist. OSGi solves a problem for me. But it is certainly no magic wand to achieve modularity. Modularity is indeed boring. But it’s critical. For years now, Jeff and I have been trying to speak (and write) about how modularity is the real goal. OSGi is just one feasible tool to use toward that end. At EclipseCon last month, I was encouraged to hear the boring old modularity message loud and clear. So while I share your opinion, maybe I share only a fraction of your pessimism.

  3. As developers, I certainly understand why we can get excited about OSGi and modularity. Especially for those that have experienced the benefits of modular architecture. But I can’t help but think that modularity is going to be a tough sell, OSGi of itself even more difficult, and that it’s popularity will only truly skyrocket when attached to the next technology trend or fad. However sad or wrong it may be!

    I believe Richard makes a valid point in his comment. It’s not the technology that garners the attention. It’s what the technology enables. While OSGi enables and enforces modular architecture, modularity isn’t trendy enough to sell. We must sell that which modularity enables. And that which modularity enables must be trendy enough to garner such interest.

  4. It is very very hard to find opinions of what might be “not so great” about OSGi, or reasons that hinder it’s adoption. It’s even harder to find that kind of info from insiders who truly know OSGi by heart.

    Most criticism is received with flames, so most times it isn’t even worth it to comment on critical posts, attracting flamers.

    As a thank you for your article I want to live you this comment from a complete ousider to OSGi, who has been keeping it under watch for 2 years now. Perhaps you might find it somehow useful, o rperhaps you might give me some more insight on the value that I’m missing:

    The reasons why I’ve passed on adopting OSGi as the core for developing software at my software company, are:

    First of all, we are a software company that develops, deplyos and supports software as solutions, for telcos.

    To us, modularity is not a goal on it’s own. It’s a means to an end. ¿what end? The technical benefits achieved by it, you know them. So at least for my company the issue is that the extent to which we might need those benefits afforded by OSGi’s modularuty (like being able to deploy and kill individual runtime components, downsize or grow footprint, etc) is not large enough for us to want to pay for it’s full price (more on the price later).

    For isolation from other solution provider’s systems we just reside on our own JVM, in its own server. For provisioning of resources, said server can be virtual. To integrate with third parties, SOA does the deal without putting us all in the same bed (JVM). And this is not for a technical reason but a business reason: ¿coexisting with oter vendor’s software on the same JVM? ¿Having to demonstrate to the customer that OutOfMemory Exceptions or excessive CPU consumption is due to that other vendor?. It’s not an attractive proposition unless we could charge lot for that feature, but the customer won’t pay more for it, and they probably already payed VMWare to solve that kind of problems. Of course there is also “internal” isolation of our own modules from each other. However, as an architect I don’t see isolation “beyond what can be done with packages” as something I want whithin my own product. I don’t want people reinventing wheels, nor pointing fingers at each other. I want a collaborative culture, and a framework that forces isolation within my product into isles is not something I really want. I am an agilist, and thus a believer in not applying technical fixes to cultural problems.

    About the feature of restarting individual components, we already deal with it, since redundant servers (needed by HA) allow us to make said restarts without much detriment to end users, and our customers are OK with it. OSGi could make us more dynamic on this, yes, and more fine-grained, but we are “just fine” as is. I reckon many other software developers don’t have this luxury and could profit from OSGi, just not us.

    About managing the complexity of dependencies, our software is in the thousands of classes and 40 MB in libraries, yet for us, Java’s own classloader is still enough to deal with dependencies, and this -as I see it- is because the whole set of “what goes into the classpath” is under our control as the Software vendor with on-site support of the app in production, so we can just apply a tried-and-true-and-cheap way to keep a system that uses a lot of dependencies stable: stay with the versions of the libraries that are known to work, and not update any until we need a feature in the newer version that is worth the cost of spending time to evaluate that newer version and change our code to support it. This approach just works. We can stay a whole year with an old version of a library, yet the customer is happy, and it’s not hard to keep the versions of libraries synchronized between our dev servers and the customers test and production servers. I belive in this regard that OSGi is a great technology that would make much more sense as a core for an IT department that needs to integrate software that it subcontracts from various providers (such as small companies and/or freelancers), or by company with a really really huge project.

    OSGi could allow us to be more dynamic in handling dependencies, but for us, the co$t of the “issue of dependency management of third party libraries” gravitates more around analyzing, reading, testing, experimenting, and being sure the whole system will still work, which are labor-intensive areas in which OSGi does not provide significant savings. Testing frameworks and JUnit provide the value we need here. And regarding dependency management inside our own software, continuous integration and automated testing provides the kind of confidence we need in the “working solution”. I see some value on OSGi here but not enough for the price.

    So there are good things to be had with OSGi. It’s just that once you have invested in solutions for the issues OSGi solves, your existing solutions might be technologically inferior, but they appear as free. OSGi, on the other hand appears with an apparent price of a “steep learning curve”, stone age Java language (some OSGi advocates dare say “in very few cases are the features of java 5 useful”, no comments), and a need for an app-wide migration, which I fear I wont be able to sell to management, given how hard it is to sell them refactoring efforts (for quality and maintainability).

    If I was just comming to the business of software in 2010, OSGi would be my choice. But given what I currently already have, It’s a business proposal thats not that bad, but not good enough for me to bet company money and/or carreer prospect on it.

    please remember that I’m trying to criticize or denigrate from OSGi. I’m just trying to express why guys like me run away scared.

  5. I wholeheartedly agree with Vladimir’s comments. Companies ask what the compelling BUSINESS case is, and the benefit has to outweigh the cost. I am a big believer of OSGi, but that is the battle I fight every day.

    Another big hurdle (coming from a large scale enterprise) is the cost of migration. If we were to start from scratch, OSGi would be a MUCH easier choice. However, in most cases, we don’t start from scratch when OSGi is adopted. We migrate. First, the cost of migration is truly steep. Take an example of dynamic classloading (Class.forName). It’s easy to say you shouldn’t do dynamic classloading. However, if you already have hundreds of dynamic classloading points going on in your system, that’s easier said than done. And the list goes on.

    What I look to OSGi leaders for is proven and REALISTIC migration path suggestions that will ease a system into an OSGi ready state with a reasonable amount of cost. IMO, we need to focus more on practical issues of migration, and I think there lies the key to enterprise adoption.

    Just my 2 cents.

  6. The name “OSGI” is not cool, looks like a boring and nerdy acronym.
    Someone could consider this as a minor problem, but it isn’t.
    Nobody would buy an IPhone if his name was “Apple Smart Communication Device”, ASCD.

    Remember this absulute true statement: “The software industry is more driven by fashion than the fashion industry”.

Leave a Reply

Your email address will not be published.