Complete

Every time when a new industry joins OSGi there is a lot of new people entering the specification work. These people, inevitably, bring their their own culture. Mixing cultures is not always without its problems. Having lived and worked in Holland, Sweden, and France I learned the hard way that moving to another culture can be a tricky thing; it does take some time before you realize that your absolute truth is not really shared by your new countrymen.

So the Enterprise experts bring their prevailing culture. With respect to standards, this culture is heavily influenced by JCP, specifically JEE, and the way things work in the open source world. This is not always aligned with the way OSGi has been run so far. Previous OSGi specs have always been rather rather thoroughly reviewed and picked apart. A running joke in the Alliance is that we start with a telegraph pole but we we end up with a tooth pick. But what a tooth pick!

One of the key things I always liked about the final OSGi specs is that they are complete. Virtually all service specifications and framework specification thoroughly specify edge cases, are fully introspective and provide relevant events to track what is happening inside the service. In JEE vendors have much more freedom. For example, in JEE the deployment aspects are left as an implementation detail. This completeness of OSGi specs is demonstrated by the fact that (so far) all our specs were able to run from a single test framework while only requiring vendors to have their to be tested bundles installed. It is possible to define do the test setup in the test case because the specifications are sufficiently complete. For example, we can deploy a bundle in a framework without having to know the vendor of that framework.

However, some of the EEG members complain we're too specific and do not allow enough space for implementations to do it their way. By giving more leeway to implementations, you allow more innovation and vendors can more easily fit existing products under a specification. These are not invalid arguments.

So I am struggling a bit with this issue. One of my primary roles in the OSGi Alliance is to guard the consistency between the specifications. This causes me sometimes to feel that I am fighting the whole group to guard this consistency. Despite the fact that I am really trying to run the fine line between being conservative and enabling new groups to do it their way. However, the hardest part is that I continuously have to challenge my own beliefs to try to see their point of view. Well, that is what mixing cultures does to you ...

Peter Kriens