The OSGi ecosystem roadmap

OSGi is Java's mature dynamic module and service system. It gives every module a precise public boundary, resolves dependencies before code runs, and lets services appear or disappear while the process stays alive.

Explain it like I am five

Imagine a city made of Lego buildings:

• a bundle is one building;
• an exported package is a public door;
• an imported package is a door another building needs;
• a service is a job advertised in the town square;
• the framework is city hall: it checks doors, starts buildings, and keeps the town-square registry accurate.

A bundle cannot secretly see every other bundle. That rule is the source of OSGi's power—and of most beginner confusion.

Current baseline, August 2026

Felix subprojects have independent versions. For example, HTTP, SCR, Configuration Admin, Gogo, and Web Console do not inherit the Framework version. Always pin and verify each component rather than writing “Felix 7” for the whole stack.

The stack in one picture

Java VM → OSGi Framework → bundles + service registry → component model → runtime distribution → application

Felix and Equinox implement the Framework. Declarative Services (DS) implements a component model on top. Karaf packages a framework plus shell, features, configuration, logging, provisioning, and operations.

When OSGi fits

OSGi is strong when independently versioned modules, long-lived runtimes, plugins, device/edge software, in-process isolation, or controlled live reconfiguration matter. It is not automatically better than a plain Java application. Dynamic behavior has an operational cost.

Feynman check

Explain the difference between specification, framework implementation, component model, build tool, and runtime distribution without using their product names.