Meet the OSGi Working Group

The OSGi Working Group was formed in 2020 as part of the asset and mission transfer of the former OSGi Alliance to the Eclipse Foundation. It was formed to drive the evolution and broad adoption of software technologies derived from or related to the OSGi Specification Project. The OSGi Specification Project is an open source initiative to create software specifications, compatible implementations, and TCKs that enable development, deployment, and management of embedded, server-side, and cloud native applications.

Since joining the Eclipse Foundation, the OSGi Working Group released its first set of specifications, Compendium R8, in December 2021. 

We spoke with Project Lead BJ Hargrave to find out what OSGi is, why it joined the Eclipse Foundation, and what the working group’s plans are in the open source community. 

What does the OSGi Working Group do?

OSGi was all about microservices before microservices came along. The working group’s mission is about modularity in the Java space. Programming has come a long way from punching machine code into the fronts of computers. We’ve gone to procedural models, like C, through to object-oriented models like C++ or Java. Each time, we’ve increased the encapsulation, so the programmer has fewer nitty-gritty details to worry about. So now, it’s not just classes that are encapsulating details but actual modules. OSGi calls them bundles.

OSGi has a service-oriented programming model that uses a broker: a module can provide an API implementation and another module can simply look it up in the broker and use it. 

And we have built numerous other service specifications that sit on top of the core framework. We’ve released several over the years, including our most recent release of Compendium R8 last year. 

How did we go from the OSGi Alliance to the OSGi Working Group?

The OSGi Alliance started in 1999. Its mission was simple: to make standards. Open source was around, but not particularly prominent. So, the OSGi Alliance was created to host the intellectual property and provide a forum for various companies to join and participate. As a not-for-profit corporation, there was administrative work we had to do as well. We had to have accountants certifying the books, people collecting money, that sort of thing. 

A few years ago, it was starting to become obvious that we needed to transition the governance to a better home rather than continuing to be standalone. The Eclipse Foundation was well-established, and we had a pre-existing relationship with it. The Eclipse Foundation is also a long-time user of OSGi technology, in the form of the Eclipse Equinox project. 

How has joining the Eclipse Foundation changed things for OSGi? 

The main value from joining the Eclipse Foundation was for its governance model. Because we were no longer a legal entity, working within the Foundation’s governance framework vastly reduced our overhead. By shedding our corporate shell and becoming part of a larger organization, we could simplify our governance significantly. 

Originally, we were a very closed-door organization. If you wanted to see how the sausage was made, so to speak, you had to pay money. Over the years we slowly opened that window a bit. Now, the window is gone. Working in open source has brought us much closer to the community and, of course, the big players in the Java ecosystem. 

As far as our release process, it’s become a bit more complex. We had reference implementations as part of our old release process. At the Eclipse Foundation, because it’s a larger community, we call them compatible implementations. We typically look to other open source projects to provide these compatible implementations.

At the former OSGi Alliance, we worked in stages: we could publish the APIs, and the project could complete the implementation afterwards. At the Eclipse Foundation, everything has to be completed at once. So, it’s a bit more challenging, and requires more cooperation and coordination with these open source projects. 

Let’s talk about your first release as part of the Eclipse Foundation, Compendium R8. What are some of the highlights?

In the OSGi space, we sometimes use the word specification when we really mean a collection of specifications, which is what Compendium R8 is. As part of coming to the Eclipse Foundation, we decided to streamline how we publish specifications. Previously, we’d released some in themed anthologies. We decided to collapse them into one, which is the Compendium. 

As part of that process, we also enhanced many of the existing specifications. For example, the Declarative Services Specification. A typical Eclipse IDE might be running 150-200 bundles, which can create coordination issues. How do I know when my dependencies are present? What happens when they go away? 

To deal with that, we defined a declarative model. You can write some Java annotations and basically declare what you want to say. Declarative Services does all the hard work for you after that. We also updated it with a few new features: now there’s a mechanism where you can ask for untyped services. And we added a mechanism called conditions, where you can establish conditions and condition chains that govern when certain services become available.

What’s next for the OSGi Working Group?

We recently raised our base Java language level to Java 8. We had many customers that were still running old versions, but we decided to finally cut the cord and move to Java 8. But there’s a lot to react to in the changing Java ecosystem: Oracle has stated its intention to remove its security manager from Java, and Jakarta EE renamed all its APIs from javax to jakarta. We have several specifications that use Enterprise Java APIs. So, we have a whole bunch of work ahead of us to react to these changes. 

Going forward, we want to start working more with some of our peer working groups at the Eclipse Foundation, like Jakarta EE and MicroProfile, to make sure their artifacts are OSGi-ready. One of the pressing things coming up now is reacting to Jakarta EE 9 because we have some specifications in the Compendium that are built on Enterprise Java APIs. All of those need to be updated for the new Jakarta version. 

How can the community get more involved?

If we could get more people to help us do the work transitioning our projects onto the new namespace, that would help a lot. 

If you want to join our GitHub, there’s always stuff to do there. We also have bi-weekly calls for the project, which are open to everyone. 

For more info on the OSGi Working Group, visit OSGi.org.