Why OSGi Technology is Strategic
2007-04-27
The recent interest in OSGi Alliance from the server folks has been very nice. We recently welcomed several new companies that are major players in this market. Big players like JBoss/Redhat, IONA, BEA, and others. We also had some companies join that are smaller but highly innovative like Paremus, Jayway, Interface21, and Luminis. Other companies, already long time members, like IBM and Oracle have put extra people on the specification work. The EEG meeting after JavaOne at Oracle in Redwood looks to be very interesting. So overall, things are looking pretty good.
However, I recently noticed the difference between the original membership and how the membership is shaping up now. The newcomers are quite different from the people that originally founded the OSGi Alliance in 1999. At that time, there was a clear vision about a potentially huge home automation market. Technical people like me were dragged in by business people to create the required technology. Member meetings at that time were mostly crowded with business developers and account managers. We attracted a lot of companies that were hoping to sell products to the operators and service providers. Similar effects happened when Nokia and Motorola initiated the OSGi Mobile Specification and BMW and Acunia the Vehicle Specification.
That picture has quite dramatically changed over the last few years. Today the OSGi Alliance is mostly focused on providing a dynamic module system to Java, with the vision to create a universal middleware standard. The need that we found in the home automation market in 1999 turned out to have a very generic solution, useful for many other industries.
However happy I am about reaching the developers today, and their enthusiasm for the specifications, I think we still fail to convey the importance of the OSGi Alliance to the strategic management of companies that invest significantly in software, or almost any larger company. As a very technically focused club we have won the minds of many developers but we fail to bring the message to CIOs and CEOs. And we need to reach them, their companies are bound to gain most when OSGi technologies are widely adopted.
I understand the lack of their attention because it is a complex world out there. From a high level many specifications, products, and open source projects, look very similar and are in general: overwhelming. Even I, as an expert in the field and strong desire to know what is going on, feels lost lately with the immense amount of components where one can choose from. Maven repositories are said to hold over 20.000 artifacts! And I am already restricting myself to Java related solutions, it is a vast field.
So why does the OSGi Alliance require any different treatment than the Apache Foundation, Microsoft, Codehaus, Objectweb, IBM, or any other of the hundreds of thousands of software component producers? Why specific attention to the OSGi Alliance over the sea of other products? Why should developers choose the technologies based on technical merits, but should OSGi technology demand strategic attention?
The answer is simple, the OSGi Alliance is about managing this overwhelming sea of components and their interaction. It is about being in control of the thousands of dependencies that software has to internal and external artifacts. It is a framework that addresses the heart of the software development process. It is about managing the software development, deployment and the, most expensive one, the maintenance process.
Not by prescribing an agile or heavy development process, but by defining a solid specification for the artifacts that are being produced, deployed, and maintained. Anybody that is familiar with a software development process is intricately aware of the myriad of problems that occur due to the lack well defined dependencies and countless hours are wasted solving problems that could have been prevented. The OSGi technology addresses this complicated and messy problem. Even companies that think that they manage their software dependencies well, often find out to their surprise they did not after starting to use OSGi technologies.
Superficially, the Java platform looks like it is providing this kind of control. However, though the Java platform clearly provides a tremendous value to our industry, there are two big flaws: one technical and one commercial.
First the technical flaw. The Java platform does not standardize a dependency and deployment model. There have been several attempts but non of these attempts is as comprehensive and complete as what the OSGi specifications offer today. The result is that many problems in a development process show up in the final stages, the time when they are the most expensive. There is no roadmap in the Java platform to create a modular system where robust applications can be reliably and quickly build from internal and external components. Integrating external components is difficult and hard work, often creating interactions that are unwanted. It is hard to overestimate the costs associated with this lack of modularity.
The OSGi specifications clearly address this area. The solid specifications define the format of the artifact and their dependencies. These artifacts can be used by OSGi frameworks to manage the components in a robust, secure, and reliable way. In conjunction with a repository, missing dependencies can be downloaded on demand. There is a tremendous amount of technical detail necessary to create such a platform, but once it is there, it is easy to use for developers and very suited to build applications with small, large, and very large teams. Obviously the most visible use case is the Eclipse IDE, based on the OSGi specifications. Eclipse with its thousands of components clearly proves that the specifications are solid. The success of OSGi technology in the mobile phone and embedded market show it is applicable for small systems as well. This is a standard that is clearly cross industry, trying to create a universal middleware layer.
The second flaw in the Java world is not technical, it is commercial. Sun has developed the Java language with the help of many, many companies. Around 2000 they started the Java Community Process (JCP) to formalize the specification process of the Java languages and its libraries. Some very solid work has been performed under this umbrella. However, the process is not neutral because there is no separate organization: the JCP is Sun, there is no separation. For example, participating in the JCP requires one to sign a contract with Sun. In the end, Sun has the final say. This is not a healthy process; the sad story of two OSGi technology related specifications (JSR 277 and JSR 294) show that despite quite heavy industry pressure, Sun can decide to develop a new technology that already has a de facto industry standard solution.
The OSGi Alliance and its specifications have strategic importance because it corrects the aforementioned flaws. The specifications provide a solid foundation to integrate the myriad of external components that are being used in software development today. The organization provides a neutral platform for standardizing components, both cross industry and specific for vertical markets.
The potential gains of using OSGi technology in the development process are large. Most organizations that produce and use software can have tremendous savings if they adopt the OSGi specifications. However, we are not there yet because the value of a standard like OSGi is largely based on the network effect. We need more members, not only to help us expand the specifications to foster an industry wide component market, but we also need new members to make the specifications more attractive for others. The grass-root adoption by the developers that we are seeing today proves that the technical foundation is solid. Any CIO or CEO that recognizes the potential can be sure that the technology works.
Today we are at a stage that you can ask what the specifications can do for you and get a welcome answer. However, we are also at a stage that you should ask what you can do for the OSGi Alliance to increase the rewards for our complete industry. Why not join and make it happen?
Peter Kriens
P.S. Hope to see you on JavaOne or the OSGi community event in Munich June 26-27
However, I recently noticed the difference between the original membership and how the membership is shaping up now. The newcomers are quite different from the people that originally founded the OSGi Alliance in 1999. At that time, there was a clear vision about a potentially huge home automation market. Technical people like me were dragged in by business people to create the required technology. Member meetings at that time were mostly crowded with business developers and account managers. We attracted a lot of companies that were hoping to sell products to the operators and service providers. Similar effects happened when Nokia and Motorola initiated the OSGi Mobile Specification and BMW and Acunia the Vehicle Specification.
That picture has quite dramatically changed over the last few years. Today the OSGi Alliance is mostly focused on providing a dynamic module system to Java, with the vision to create a universal middleware standard. The need that we found in the home automation market in 1999 turned out to have a very generic solution, useful for many other industries.
However happy I am about reaching the developers today, and their enthusiasm for the specifications, I think we still fail to convey the importance of the OSGi Alliance to the strategic management of companies that invest significantly in software, or almost any larger company. As a very technically focused club we have won the minds of many developers but we fail to bring the message to CIOs and CEOs. And we need to reach them, their companies are bound to gain most when OSGi technologies are widely adopted.
I understand the lack of their attention because it is a complex world out there. From a high level many specifications, products, and open source projects, look very similar and are in general: overwhelming. Even I, as an expert in the field and strong desire to know what is going on, feels lost lately with the immense amount of components where one can choose from. Maven repositories are said to hold over 20.000 artifacts! And I am already restricting myself to Java related solutions, it is a vast field.
So why does the OSGi Alliance require any different treatment than the Apache Foundation, Microsoft, Codehaus, Objectweb, IBM, or any other of the hundreds of thousands of software component producers? Why specific attention to the OSGi Alliance over the sea of other products? Why should developers choose the technologies based on technical merits, but should OSGi technology demand strategic attention?
The answer is simple, the OSGi Alliance is about managing this overwhelming sea of components and their interaction. It is about being in control of the thousands of dependencies that software has to internal and external artifacts. It is a framework that addresses the heart of the software development process. It is about managing the software development, deployment and the, most expensive one, the maintenance process.
Not by prescribing an agile or heavy development process, but by defining a solid specification for the artifacts that are being produced, deployed, and maintained. Anybody that is familiar with a software development process is intricately aware of the myriad of problems that occur due to the lack well defined dependencies and countless hours are wasted solving problems that could have been prevented. The OSGi technology addresses this complicated and messy problem. Even companies that think that they manage their software dependencies well, often find out to their surprise they did not after starting to use OSGi technologies.
Superficially, the Java platform looks like it is providing this kind of control. However, though the Java platform clearly provides a tremendous value to our industry, there are two big flaws: one technical and one commercial.
First the technical flaw. The Java platform does not standardize a dependency and deployment model. There have been several attempts but non of these attempts is as comprehensive and complete as what the OSGi specifications offer today. The result is that many problems in a development process show up in the final stages, the time when they are the most expensive. There is no roadmap in the Java platform to create a modular system where robust applications can be reliably and quickly build from internal and external components. Integrating external components is difficult and hard work, often creating interactions that are unwanted. It is hard to overestimate the costs associated with this lack of modularity.
The OSGi specifications clearly address this area. The solid specifications define the format of the artifact and their dependencies. These artifacts can be used by OSGi frameworks to manage the components in a robust, secure, and reliable way. In conjunction with a repository, missing dependencies can be downloaded on demand. There is a tremendous amount of technical detail necessary to create such a platform, but once it is there, it is easy to use for developers and very suited to build applications with small, large, and very large teams. Obviously the most visible use case is the Eclipse IDE, based on the OSGi specifications. Eclipse with its thousands of components clearly proves that the specifications are solid. The success of OSGi technology in the mobile phone and embedded market show it is applicable for small systems as well. This is a standard that is clearly cross industry, trying to create a universal middleware layer.
The second flaw in the Java world is not technical, it is commercial. Sun has developed the Java language with the help of many, many companies. Around 2000 they started the Java Community Process (JCP) to formalize the specification process of the Java languages and its libraries. Some very solid work has been performed under this umbrella. However, the process is not neutral because there is no separate organization: the JCP is Sun, there is no separation. For example, participating in the JCP requires one to sign a contract with Sun. In the end, Sun has the final say. This is not a healthy process; the sad story of two OSGi technology related specifications (JSR 277 and JSR 294) show that despite quite heavy industry pressure, Sun can decide to develop a new technology that already has a de facto industry standard solution.
The OSGi Alliance and its specifications have strategic importance because it corrects the aforementioned flaws. The specifications provide a solid foundation to integrate the myriad of external components that are being used in software development today. The organization provides a neutral platform for standardizing components, both cross industry and specific for vertical markets.
The potential gains of using OSGi technology in the development process are large. Most organizations that produce and use software can have tremendous savings if they adopt the OSGi specifications. However, we are not there yet because the value of a standard like OSGi is largely based on the network effect. We need more members, not only to help us expand the specifications to foster an industry wide component market, but we also need new members to make the specifications more attractive for others. The grass-root adoption by the developers that we are seeing today proves that the technical foundation is solid. Any CIO or CEO that recognizes the potential can be sure that the technology works.
Today we are at a stage that you can ask what the specifications can do for you and get a welcome answer. However, we are also at a stage that you should ask what you can do for the OSGi Alliance to increase the rewards for our complete industry. Why not join and make it happen?
Peter Kriens
P.S. Hope to see you on JavaOne or the OSGi community event in Munich June 26-27
Labels: eclipse osgi
Twenty THOUSAND dollars. That's why not!
;-)
Great post Peter, but a simple three-word answer to your question at the end ("why not join?").
Twenty THOUSAND dollars. That's why not!
;-)
+1. It would be nice if there was a cheaper option for smaller companies - startups in particular, which are more likely to build their entire software platform on OSGi (as opposed to larger existing companies that may dabble a little in OSGi here and there).
For the members, I think that the $20k/€15k membership is the least amount, it can cost quite some employee time to participate in the EGs. We are trying to create a high quality specification and that means there are some serious costs involved. The OSGi Alliance is a non-profit organization.
Peter Kriens
So the development of this technology is reserved for big companies, not for small ones !