---
title: "OSGi at Adobe: New School technology"
date: 2011-06-15T19:18:52Z
modified: 2011-06-15T19:18:52Z
permalink: "https://redmonk.com/jgovernor/osgi-at-adobe-new-school-technology/"
type: post
status: publish
excerpt: ""
wpid: 3395
categories:
  - developers
tags:
  - developers
  - Adobe
  - Day
  - OSGi
timestamp: 2011-06-15T19:18:52Z
---

\[insert image here. i need to find a good one ;-)\]

i am at an Adobe event in San Jose for the analyst unveiling of the company’s Customer Experience Management platform and strategy.

Rather than focusing on CEM for this post, which I talked to indepth already [here](http://www.redmonk.com/jgovernor/2011/05/20/software-services-and-the-office-of-the-cmo/), I thought I would nerd out a little bit and talk about Adobe’s approach to what I call [the Stackless Stack](http://www.redmonk.com/jgovernor/2008/02/05/osgi-and-the-rise-of-the-stackless-stack-just-in-time/).

I asked David Neuscheler, CTO of Adobe CEM – who joined the firm as part of its Day Software acquisition, whether OSGi was something customers do, and should, care about.

The question is a live one – there is currently quite a debate going on about the value of OSGi – led by voices such as [Ross Mason of Mulesoft](http://blogs.mulesoft.org/osgi-no-thanks/).

I see both Adobe and Dell using OSGi in new toolsets, so its certainly relevant to vendors. But what about users?

Neuscheler said OSGi was more relevant to people running apps than building them.

“OSGi gives us the power to modularise our solution. its a java spec that allows you to deal with java in a 24×7 environment – with no need to bring down the app for updates. that modularisation puts a burden on the developer – they need to think more about modularity.”

\[note- OSGi is a Java spec, but not in the JSR sense. OSGi is a separate standardisation stream – in the [multipolar Java world](http://www.redmonk.com/jgovernor/2010/10/01/java-the-unipolar-moment-on-distributed-governance-for-distributed-software/)\].

“Usually OSGi comes with maven, continuum etc for continuous integration.

But there are 2 classes of developers- those that love tooling – the more complex, and automated, the better they like it- I call them class 2 developers.

i am not one of them. i don’t like to spend three days installing a development environment. i like to just get going, we’re scripting types, more agile.

However, _once 100 people are using it_, it needs to be hardened for osgi containers etc.

Makes sense. Build Agile, deploy Modular. Don’t optimise prematurely.

Kevin Cochrane, VP of marketing, CEM at Adobe then jumped in.

There are 3 OSGi use cases relevant to customers:

> 1\. updates. ie bug fixes to customer production systems. there is no need to bring them down.
> 2\. extending new services. you might have 12 services, and a huge user community – you can still roll out extensions with no downtime.
> 3\. discovery of new services. find a pre-packaged piece of code. browse, integrate and deploy.

Arguably that’s two use cases- hot swappability and reuse. But those are very important use cases, and could be foundational.

Adobe is going to move to appstore like offerings going forward; like every other software vendor it needs to deliver more and more services as a service, for its own apps and those of partners.

The use cases Adobe describes chime pretty well in my thoughts on the Stackless Stack from February 2008.

> SOA is one of the most hyped terms of the recent few years in IT, but the story has largely focused on design time, rather than runtime flexibility. What would a SOA for middleware deployment look like? Like OSGi.

In conclusion: OSGi certainly shouldn’t be exposed to end users, or even all developers, but it can have significant value in large Java development shops serving big user populations.

Any disclosure to make? I am one of the founders of the OSGi UK user group, the OSGi Alliance is a client, as is Adobe.