The OSGi Needs You!

More than 20 years ago Brad Cox promoted his Software ICs. In those 20 years, Object Oriented technologies have solved many problems and during this time frame it has become a tremendous success, Java could not have existed without OO. However, so far we did not succeed in creating the component market that Brad Cox once envisioned. The key reason that it never worked out is that software is the wrong name for what we are producing; brittleware would have been a better name. Despite the improvements in tools and knowledge, component oriented systems turned out to be very difficult to engineer. What are the reasons that this attractive idea is so hard to achieve?

The following is my list of requirements that must be satisfied for a successful component model:

• Portability – The model must be supported on virtually any device, or critical market size will not be achieved.


• Deployment & Management – Today’s devices are all networked. This will require remote management and deployment of components.


• Loosely coupled – Objects never made it as components because they were too tightly coupled to their environment. Components should be allowed to mix and match.


• Security – A component model for networked devices requires security to prevent the system against viruses, malicious code, and erroneous code.


• Dynamic – Component updates should not cause the system to shut down completely. Change is an integral part of today’s computing world.


• Non Intrusive – The programming model should not overly restrict the programmer or create unnecessary intrusions in plain old java code.

This is clearly not a list that a single company can develop as a product. It is also clearly more than just the Java environment, though Java provides a big chunk. A cross industry component model requires the cooperation of large number of companies to create the required eco system. This is exactly what the OSGi Alliance has done. Over the past 7 years they developed a component framework that satisfies all these technical requirements, and more.

We seem to have achieved our technical goal as is proven by the large number of applications building upon OSGi technology. However, to achieve our long term vision of “components roaming freely”, we need more, much more. To achieve adoption in the mainstream software shops we need to cross a chasm; a chasm that any new technology must cross. This is a difficult passage because most people resist change.

To resist the change, people currently use the following arguments against OSGi based solutions:

• Too expensive or too slow


• Hard to test


• Unproven

Hardware cost? We have been telling people that the cost issue will go away and today I am glad to tell you, it really did go away. OK, kidding, but with flash going for 1 cent per MByte the hardware cost issues is really on its way of becoming moot. There is of course the extra processor capacity required and the VM can be a significant cost but more and more vendors are providing good alternatives to SUN’s VMs for reasonable cost. The OSGi component model simplifies the use of alternative VMs so much that the Apache Harmony VM (free!) has chosen OSGi at its foundation.

Testing is another problem. Mainstream developers, project managers, and general managers are skeptical that anything dynamic in their software configuration can really work. Most seasoned developers have lived through nightmarish situations with late and buggy software. To manage their processes, they have installed safeguards and measures to ensure that the product that goes out the door is actually working in at least one context. Often these safeguards require a frozen system when it is tested; something that is very much at odds with a component model where the components each have a different life cycle.

This fear of change in itself is at odds with where the mainstream of computing is heading. Devices are networked and must survive in a continuously changing world. As an industry we must evolve to a model where software is less brittle and more robust. Freezing the world during testing, as so many do, just means that many, many errors will be found by the users in the real world where time tends not to be frozen. Facing the problems up front is the better solution.

Unproven? Type in OSGi in Google and browse … Should the US National Guard order a system to detect bio terror attacks on an unproven technology? Would Eclipse knowingly put unproven technology under the hood knowing that their IDE will be downloaded millions of times? Don’t think so, the OSGi specifications have already clearly proven themselves over and over, in many different situations.

I am convinced that the OSGi Alliance provides a crucial function to achieve this ubiquitous computing model we have trying to achieve for so many years. We have the technology, we have the enthusiastic early adopters, and we have the ears of many in the mainstream markets, among them some of the largest software companies in the world like IBM, Siemens, and Nokia. However, to continue, we also need your help as well. To achieve the credibility needed to cross the chasm, the OSGi Alliance needs many more mainstream companies to use and help promote the OSGi specifications. You can do this for the pay off, which can be big: a cross industry component market will be gigantic. You can do this because a unified component market will simplify your development and reduce its cost. You can do it because you share our vision and want to help it come true. Or you can do this because you believe this is the right way to go. Whatever your motives, the OSGi Alliance needs your support as a member, as an adopter associate, or if you cannot afford the fee, as an enthusiastic user.

Hope to see you on the next OSGi member meeting!

Peter Kriens