The OSGi Alliance was founded in March 1999 in order to provide a modular component-based runtime for Java, back when Java 1.2 was released. It was specified as JSR 8, which was the equivalent version of Java's enhancement proposals (JEPs) at the time, before Java was opened in the form of OpenJDK.
As an independent foundation, backed by a number of members including Adobe, IBM, Bosch and others, the OSGi Alliance foundation acted as the intellectual property repository for the OSGi specification and hosted the expert groups that created them. By collaborating together on a single vendor-neutral organisation, it was possible to define an open standard that could be implemented by a number of open-source and commercial providers, and plays a part in a number of commercial technologies by those companies today.
One of the biggest users of OSGi turned out to be another open-source project kicked off by IBM, called Eclipse. The first version of the IDE was released in 2001, a couple of years after the OSGi Alliance was created, although it wouldn't be until Eclipse 3 in 2004 that the runtime moved over to use OSGi. The Eclipse Foundation was also created in 2004 (with many of the same members as the OSGi Alliance) as the IP depository for the Eclipse codebase, and has since outgrown its IDE roots – providing web-based tools, integration into the Internet of Things, and has recently taken over the evolution of the JavaEE specification (now JakartaEE).
These changes have resulted in a significant overlap in interest between the OSGi Alliance and the Eclipse Foundation, so after discussions earlier in the year it was decided that the OSGi Alliance should merge its IP into the Eclipse Foundation, and establish the Eclipse OSGi Working Group. Once up and running, the first task the working group will do is complete and then approve the OSGi R8 Compendium specification, which has been worked on up to this point. The OSGi R8 Core specification will be approved by the OSGi Alliance but subsequently published by the Eclipse Foundation; it is likely, therefore, that the OSGi R8 specification and an Equinox based implementation will be available early next year.
InfoQ caught up with Dan Bandera, president of the OSGi Alliance, to find out more about the move, and started off by asking why the move to the Eclipse Foundation, and whether or not other foundations were considered:
Dan Bandera:The OSGi Alliance was founded in an era which was very different; the Apache Foundation [which started in 1999 as well] had only just got off the ground, and the Eclipse Foundation wasn't started for another five years. However, we took the decision that the costs of running a foundation for a specific set of use cases wasn't an efficient use of resources, which is why we started looking at other foundations.
We looked at Apache, the Linux Foundation, OASIS – but what drew us to Eclipse was twofold. Firstly, the majority of the members of the OSGi Alliance are also members of the Eclipse Foundation already, but secondly, the Eclipse Foundation has evolved from working on only open source software releases to also working with specifications. This work has been done as part of the donation of the JavaEE (now JakartaEE) specification and ongoing future work happening at Eclipse.
The standardisation process is important to OSGi, because although there are several open-source implementations, there are also commercial implementations used by others, and it's important that there be a specification that can be used to verify compatibility between implementations.
InfoQ: How are the specifications going to evolve?
Bandera: That's going to be the job of the OSGi Working group when it starts. Its first item of business will be to approve the working group charter which will govern how it acts in the future, and thereafter the specifications will evolve as the working group sees fit.
The work towards the OSGi Core Release 8 specification has largely been done at this point, and the IP associated with that work will be transferred to the Eclipse Foundation, which will allow the OSGi Working Group at Eclipse to produce the release. Historically, the OSGi releases have been published at www.osgi.org, but it's up to the working group to decide where and how to publish OSGi specifications going forwards.
The work on the OSGi Compendium Release 8 is a work-in-progress, and won't be finished until the OSGi working group is running. Typically both sets of specifications have been a collection of references to versioned specifications, such as Declarative Service 1.4. Whether the working group chooses to continue to publish things in a compendium release or release the services individually over time is something the working group will have to decide.
It's extremely likely that the working group will strongly recommend that future specifications be released under the Eclipse Specification License, although older releases will continue to be available under their original licenses.
InfoQ: One of the important things about specifications is that they have a compatibility suite that allows implementors to declare that they meet the specification, like Java's TCK. What's happening with that?
Bandera: Compliance testing is a vital part of the specification process. The OSGi Alliance will provide the compliance test suite to the Eclipse Foundation as part of the transfer, and implementations will be able to access the open source suite. To use the logo and claim compliance, the compliance tests must be run and the results published, as well as being a member of the working group.
This means that the open-source projects, like Apache Felix and Knoplerfish, will have access to the same compliance tests as commercial implementations, and the reference implementation at Eclipse Equinox will be tested as well. Those members of the working group will be able to ensure that the open source versions are also certified in the same way that they've been before.
InfoQ: What advantages are there for the existing or new OSGi Alliance members with the transfer?
Bandera: Firstly, the majority of members of the OSGi Alliance members are also Eclipse members, which means that those companies who are members of both will see a reduction in membership fees.
For new members, the OSGi Alliance had an almost flat fee for each of its membership tiers, whereas the Eclipse Foundation has a graduated membership based on the turnover of your organisation. That means it's more efficient for smaller new members to join because they'll have a lower cost, which we hope will drive new membership of the working group.
InfoQ: How can people get involved with the future of OSGi?
Bandera: Those who are already members of the Eclipse Foundation can join in the newly formed OSGi working group. For those who aren't members of the Eclipse Foundation, you can find out more by visiting the Eclipse membership page.
Those interested in participating can send a mail to the https://accounts.eclipse.org/mailing-list/osgi-wg list, and it is expected that the working group will be up and running within a few weeks.
