OSGi Evangelist

We had an OSGi board meeting in Chicago last week. One of the interesting outcomes of this meeting was my new position. From now on I am the OSGi Evangelist. My new task is to make OSGi a better known option for Java developers.

The key issue I want to focus on is to make more clear what we really try to achieve.

The original goal in 1998 of the OSGi was to create a brand new market for managed home gateways so that our members could take advantage of Metcalfe's law. By providing a standard application environment for these new devices we could enable developers to create applications for a wide array of devices and not just for a single brand. By having many applications, it becomes interesting to manufacture devices. Unfortunately, the home gateways never happened due to the Internet bubble and complexity. However, despite the lack of commercial success, we achieved our technical goals to provide a unique computing environment and deployment standard. That is, we had a good solution but we lost the problem.

The OSGi Alliance would have withered away was it not for the fact that other industries recognized the value of a standardized application environment. An environment that focuses on service orientation, collaboration, dynamics, and security. Vehicles, mobiles, telematics, any device that is networked is a potential candidate for the OSGi specifications.

However, this interest is so far not sufficient; the OSGi Alliance is still on the wrong end of the hockey stick. Though we provide many immediate development benefits (see the adoption by Eclipse and Apache), we have not yet a compelling case commercially due to lack of adoption. This is partly inherent in Metcalfe's law; developers are not interested until there are lots of devices, manufacturers are not interested until there is an abundance of applications.

So we are planning to address this issue more serious now in the coming year. First, in Release 4 we have made more vertical profiles that address the problem that the OSGi Service Platform is too fuzzy. The previous specifications provided well defined services, but never defined which services had to be present. Also, we allowed the OSGi to be used on any JCP profile that was a superset of our minimum execution environment. This allowed for great flexibility by the manufacturer but made it hard for application developers to target a broad range of devices.

Second, we intend to create a bundle (=application) repository from the OSGi web site so that it will become visible how many bundles already exist. We will work with the OSGi vendors like ProSyst, IBM, Espial but also with the open source organizations like Oscar, Eclipse, Apache, Knopflerfish and others to provide a single access point for OSGi based applications.

Third, we need to provide more support for developers. Here, the open source plays a pivotal role. Apache has extended their Maven and Ant tools to handle the OSGi idiosyncrasies. Eclipse plugins are bundles and they have promised to make as much as possible of their efforts real bundles that also run outside Eclipse. Oscar has the Oscar Bundle Repository (OBR) that is gaining traction. Nokia is said to be working hard on toolkits for the next generation mobile phones which will have OSGi frameworks.

However, in the end the onus is on vendors and operators; besides the end users, they stand the chance to profit most of an open unified networked services market. They need to share the vision of a huge market for devices that run off the shelf applications. A market that is not dictated by a single company. I will be working very hard in the next years to bring this vision closer to reality, but we cannot do it alone. Let us know what it takes to make your company become an OSGi member. Let us know if you can help in other ways.

  Peter Kriens

posted by Peter @ Tuesday, September 20, 2005