Is the Ω problem really a problem

At the OSGi Community event last week (and on a blog post[1]) Alex Blewitt outlines "the Ω problem". The basic thesis of this problem is that Enterprise OSGi adoption is being hindered because all the relevant projects have unintelligible names based on "greek letters and astrological". He quotes Apache Aries, Eclipse Libra, and Apache [Felix] Gogo as examples. As a committer on Apache Aries and as someone involved in Enterprise OSGi I take some small exception to being singled out like this.

What's in a name? That which we call a rose
By any other name would smell as sweet.

I spend far too much of my life arguing over names. The trouble with names is the barrier of entry to the debate is so low everyone can engage and voice an opinion. So are names important? The answer is I think yes and no. In a (slightly tetchy) twitter exchange (which was all my fault) I asked Alex how he would like to fix the problem, how to apply the fix to the Apache Aries JNDI module. His suggestion was:

• Apache Naming for OSGi
• Apache JNDI for OSGi [2]

There are a few potential issues with this proposal. These complicate the matter rather than prevent the names being used, but they need to be considered:

1. OSGi is a registered trademark of the OSGi Alliance. While it is valid to use OSGi in product or project names in some cases you need a lawyer to know what they are. As a result putting OSGi in a name is somewhat tricky. (I hate to bring lawyers into this, but it is worth mentioning)
2. The Apache Aries JNDI module does not provide a Naming Service which could be implied by the former name. I've had many conversations with people who assume Apache Aries JNDI provides a name service. When I point out that the response is typically "oh yes, that makes sense".
3. It doesn't really fit with the Apache way of doing things. The ASF is a federation of projects this means that you can have multiple projects doing the exact same thing. While this might sound odd there are several potentially competing projects; Apache CXF and Apache Axis2 for example are both Web services stacks. This means it is completely valid to have multiple implementations of the OSGi JNDI specification. This might seem odd, but it is possible that the Apache Felix project and Apache Aries might both choose to implement the same specification. This then becomes a problem using names like those suggested because there are two things in Apache that should have the same name. I can't speak for Eclipse, but it could easily be the same thing there.

All this really highlights is the problems associated with naming. The most likely best improvement based on Alex's suggestion is "Apache Aries JNDI for OSGi" which isn't a huge improvement. This leads me onto a second observation.

In Alex's blog he identifies Spring Data, Spring Web services, Apache Commons Lang as good names, and Apache Aries as bad, but this isn't comparing like with like. If we deconstruct the good names they follow this pattern:

   <brand> <function>

The "brand" in the names is "Spring" and "Apache Commons"; the function is "Data", "Web services", "Lang". If we look at two items from the bad list (and I'm choosing the two I have some familiarity with) the quoted names are the brand and do not denote the function. The two I'll quote from are Apache Aries and Eclipse Gemini. Both these projects have the following:

• Apache Aries Blueprint
• Apache Aries JNDI
• Eclipse Gemini Blueprint
• Eclipse Gemini Naming

The project or brand is Apache Aries, the function is Blueprint and JNDI.

So back to the original title of my blog post. "Is the Ω problem really a problem". For me the answer is no. Naming is hard, and I am sure we haven't got it right, but the names of things aren't the problem. I think there are some real problems here that need to be addressed, but we need to focus on those rather than deciding that naming a project Apache Aries, or Eclipse Gemini is weird (or by implication of not being good, bad).

Before I sign off I think some of the problems we have to address for adoption of Enterprise OSGi:

• Explain to people the benefits
• Better integration into more Application Servers.
  In fact since WebSphere Application Server,  Apache Geronimo, Glassfish and JBoss OSGi are all doing this perhaps it is making people aware of what is out there.
• Better support for the a la carte model familiar to many experience OSGi people.
  I think there is a debate to be had around this. In the enterprise world a la carte is more complex than in previous OSGi arenas. You can certainly have an a la carte model for an application that uses Servlets, JPA, transactions and Blueprint (we have a sample in apache aries that builds its own runtime like this) in reality once you have done this you have pretty much built your own application server at which point you should be looking to reuse what others have done.

Alasdair

[1]http://alblue.bandlem.com/2011/09/omega-problem.html
[2]https://twitter.com/#!/alblue/status/118763089289158656

P.S. I'm too anal not to point out the following minor errors in the list of names in Alex's blog:

• Apache RegExp is really called Apache Jakarta RegExp (this is retired and in the Apache Attic)
• Apache Gogo is really Apache Felix Gogo
• Apache Sigil is really Apache Felix Sigil