Apollon as an integration target: stable contract or extension points?

[FelixTJDietrich]

Context

A few projects now build on Apollon. Artemis is the main one, and the BESSER team's web modeling editor is another. They forked Apollon to power their low-code platform, adding their own diagram types, an AI modeling assistant, code generation, and a Python backend. It is genuinely nice to see Apollon used this way, and their fork has taught us a lot about how people want to integrate with us.

It also surfaced a question worth talking through openly before we commit to anything.

The pattern we noticed

When someone needs to customize Apollon beyond what the library exposes (new diagram types, custom rendering, display options), the only real option today is to fork the editor. The BESSER team did exactly that. The downside of forking is that they are now on an older Apollon engine and cannot easily pick up our newer work, and we cannot easily pick up theirs. Everyone loses a little.

The question

How far do we want to go in supporting projects that build on Apollon?

1. Stabilize the contract only. Publish and version the model JSON (Publish and version the diagram model JSON as a stable, documented contract #748), expose a small set of display options (Expose view-only display options through the public editor API #749), and accept that deep customizers will still fork. Low cost, covers the common cases.
2. Invest in real extension points. Let integrators add diagram types, elements, and rendering from outside the library without forking. Much more powerful, and a much larger and longer commitment.

A reasonable middle path: do (1) now, and treat (2) as demand-driven, for example once there is a second serious integrator who would use it. We would rather build extension APIs for real needs than guess at them.

Related

• Publish and version the diagram model JSON as a stable, documented contract #748 (model schema contract)
• Expose view-only display options through the public editor API #749 (display options)
• The companion discussion on a plugin API for diagram types: Should Apollon have a plugin API for custom diagram types? #753

Curious what others think, especially anyone who has integrated Apollon or seriously considered it.

We already have evidence of this friction

A couple of open issues are concrete examples of the papercuts that make building on Apollon harder than it should be, independent of any big extension work:

• [BUG] Library bundles React — duplicate React instances for consumers #603 — the library bundles React, which breaks consumers that already use React
• [BUG] Legacy @ls1intum/apollon npm package is not deprecated #605 — the legacy @ls1intum/apollon npm package is not deprecated

Fixing these is part of being a good integration target regardless of which direction above we choose.