OpenUI5

SAP ships the UI5 framework in two deliveries. OpenUI5 is the open-source one; SAPUI5 is the one integrated into SAP products such as SAP BTP and the ABAP platform. The main difference is the license, not the programming model.

Three facts follow from that shared origin:

1. Same core. The runtime, data binding, routing and the most common control libraries, for example sap.m, sap.ui.layout and sap.ui.unified, are identical in both deliveries.
2. Same technical names. Control names, library names and APIs match, so code written against OpenUI5 keeps working when the runtime is switched to SAPUI5.
3. Aligned versions. Both deliveries follow the same release line, although SAP notes that version numbers can differ at patch level. The technical information dialog (Ctrl+Alt+Shift+P) shows which version an app actually loaded.

SAPUI5 is therefore a superset: everything in OpenUI5 plus additional SAP-specific libraries. OpenUI5 is the open-source subset of SAPUI5, not a separate framework.

A comparison of the library lists published for release 1.154 shows that every OpenUI5 library is also part of SAPUI5, while SAPUI5 adds several dozen more. The gaps that matter most in SAP projects:

OpenUI5 still contains a broad set: sap.m, sap.f, the object page layout in sap.uxap, sap.ui.table, the metadata-driven controls in sap.ui.mdc, the flexibility libraries sap.ui.fl and sap.ui.rta, integration cards and the SAP Horizon theme library. The list changes between releases, so check it for the version you target. OpenUI5 covers the building blocks of a full web app, but not the SAP layers that generate or host SAP Fiori apps.

Use this decision criterion: if the app depends on an SAP product's runtime or on an SAP-only library, use SAPUI5; otherwise OpenUI5 is a valid choice.

OpenUI5 fits when:

• the app runs outside SAP products, for example a public web portal or an internal tool on a non-SAP backend;
• the project is itself open source, such as a UI5 tool, sample or custom control library, and must not depend on SAP-licensed code;
• a team is learning UI5 and wants a freely available runtime and documentation set.

SAPUI5 fits when:

• the app runs in the SAP Fiori Launchpad or SAP Build Work Zone, which load the SAPUI5 runtime anyway;
• the app uses SAP Fiori elements, smart controls or SAP charts;
• the app is delivered on the ABAP platform or SAP BTP, where SAPUI5 is part of the product.

For Alder Manufacturing, a supplier self-registration page for Cedar Office Supply on a non-SAP web server is an OpenUI5 candidate; a purchase order list report in the launchpad is not. OpenUI5 is the right choice when independence from SAP product licensing matters more than SAP-specific libraries.

• No generated floorplans. Without SAP Fiori elements, list reports and object pages must be built by hand with standard controls, so the effort profile matches freestyle SAPUI5, not annotation-driven development.
• No launchpad runtime of its own. Apps that should run in the SAP Fiori Launchpad run on the launchpad's SAPUI5 runtime, not on OpenUI5. In practice, an OpenUI5 app that moves into an SAP landscape becomes an SAPUI5 app.
• Persistence for flexibility is external. The flexibility libraries are included, but storing key user and end-user changes productively needs a backend: the layered repository of an ABAP system or SAP BTP services. The browser-storage connectors are meant for testing.
• Support model. OpenUI5 bugs and feature requests are raised publicly as GitHub issues; whether an SAP support contract covers a given OpenUI5 use depends on its terms.

These limits follow from the split itself: OpenUI5 is the framework, while SAPUI5 adds what SAP's own products need on top.

1. Starting on OpenUI5 and discovering a dependency late. A project that later needs smart controls, SAP Fiori elements or spreadsheet export has to switch to SAPUI5. Fix: list required libraries before choosing the delivery.
2. Equating OpenUI5 with SAP Fiori compliance. OpenUI5 controls follow the SAP Fiori design, but layout, navigation and wording decide whether an app follows the SAP Fiori Design Guidelines. Fix: review the app against the guidelines, not just the controls.
3. Mixing deliveries in one landscape. Bootstrapping some apps from the OpenUI5 content delivery network and others from the SAPUI5 one makes version comparisons and troubleshooting harder. Fix: use one delivery per app and document it.
4. Ignoring patch-level differences. OpenUI5 and SAPUI5 version numbers can diverge at patch level. Fix: check the technical information dialog when a bug appears in one delivery but not the other.

Most OpenUI5 problems are scoping decisions made too early, not defects in the framework.