Plugins zwischen Znuny, OTOBO & KIX: Wie portabel ist das .opm-Ökosystem?

Die OTRS-Community-Edition lebt in drei aktiven Forks weiter – Znuny, OTOBO und KIX. Welcher davon für Ihr Team der richtige ist, hängt von Feature-Set, KI-Strategie und Migrationsweg ab. Diese Fragen beleuchten andere bereits sehr gründlich (Links dazu am Ende des Artikels). Aus der Perspektive eines herstellerneutralen Plugin-Verzeichnisses stellt sich aber eine ganz andere, oft unterschätzte Frage:

Wie portabel ist eigentlich das gemeinsame .opm-Ökosystem – und kann ich ein Paket, das ich für OTRS oder Znuny finde, einfach in OTOBO oder KIX installieren?

Genau das schauen wir uns hier an, statt erneut einen "Welcher Fork ist besser?"-Vergleich aufzumachen.

Eine gemeinsame Wurzel, ein gemeinsames Paketformat

Alle drei Forks stammen von der OTRS Community Edition ab und teilen sich deshalb dieselben Grundbausteine für Erweiterungen:

.opm als Paketformat – ein XML-basiertes Containerformat, das Code, Datenbankänderungen und Konfiguration bündelt.
SOPM als Manifest – die Quelldatei eines Pakets deklariert u. a. Name, Version und – entscheidend – die kompatible Framework-Version.
Das Generic Interface – die REST/SOAP-Webservice-Schicht, über die Integrationen angebunden werden.
Dynamic Fields, ACLs, Prozessmanagement – konzeptionell forkübergreifend vertraut.

Auf dem Papier sieht das nach perfekter Austauschbarkeit aus. In der Praxis ist die Portabilität jedoch ein Spektrum – und genau das macht ein gepflegtes Verzeichnis wertvoll.

Die Paket-Quellen der drei Forks

Jeder Fork pflegt seinen eigenen Auslieferungskanal. Wir aggregieren diese Quellen in unserer Paket-Quellen-Übersicht:

Fork	Offizielle Paket-Quelle	Format
Znuny	`addons.znuny.com`	`.opm`
OTOBO	`ftp.otobo.org/pub/otobo/packages/`	`.opm`
KIX (klassisch)	`kixdesk.com` / Repos	`.opm`

Weil dieselbe Dateiendung verwendet wird, entsteht schnell der Eindruck, ein einziges Paket laufe überall. Tatsächlich ist die Kompatibilität an die jeweilige Framework-Version und an interne API-Annahmen gebunden.

Portabilität in der Praxis: vier Stolperfallen

1. Die deklarierte Framework-Version

In der SOPM/OPM-Datei legt ein Paket fest, mit welchen Framework-Versionen es kompatibel ist (z. B. 6.x, 10.x, 11.x). Ein Paket, das nur <Framework>6.0.x</Framework> deklariert, lässt sich auf einem modernen OTOBO 11 nicht ohne Weiteres installieren – der Paketmanager verweigert oder warnt. Znuny-Pakete, die nahe am OTRS-6-Stand liegen, sind daher nicht automatisch in OTOBO 11 lauffähig.

2. Abweichende interne APIs

Auch wenn das Format identisch ist: OTOBO und KIX haben Teile des Kerns modernisiert. Aufrufe interner Perl-Module, geänderte Methodensignaturen oder neue Caching-Schichten (OTOBO setzt z. B. auf Redis/Elasticsearch) können dazu führen, dass ein syntaktisch installierbares Paket zur Laufzeit Fehler wirft.

3. Template- und Frontend-Unterschiede

Skins und Frontend-Erweiterungen sind besonders empfindlich. Ein Agent-Skin, der für die klassische OTRS/Znuny-Oberfläche gebaut wurde, passt optisch selten 1:1 auf OTOBO – und schon gar nicht auf das neu gedachte Frontend von KIX 18, das architektonisch am weitesten vom Original entfernt ist.

4. Abhängigkeiten zwischen Paketen

Viele Erweiterungen setzen andere .opm-Pakete oder Perl-Module voraus. Fehlt eine deklarierte Abhängigkeit im Zielsystem oder existiert sie dort nur in inkompatibler Version, scheitert die Installation – unabhängig vom Fork.

Faustregel: Je näher ein Paket an reiner Geschäftslogik (Dynamic Fields, ACLs, Generic-Interface-Mappings) bleibt, desto portabler ist es. Je tiefer es ins Frontend oder in interne Core-APIs eingreift, desto wahrscheinlicher braucht es eine fork-spezifische Variante.

Sonderfall KIX 18: gleiches Erbe, eigene Welt

KIX führt eine klassische Perl-Linie und das neuere KIX 18 parallel. KIX 18 ist eine weitgehende Neuentwicklung mit einer REST-API-zentrierten Architektur und eigenem Frontend. Für die Plugin-Portabilität heißt das: Klassische .opm-Add-ons aus der OTRS-Welt lassen sich hier am wenigsten direkt übernehmen. Dafür eröffnet die API-first-Architektur andere Integrationswege – etwa über externe Dienste statt über eingebettete .opm-Module.

Wie ein offenes Verzeichnis hier hilft

Genau an dieser Stelle setzt der Open ITSM Hub an: Statt nur Pakete aufzulisten, erfassen wir Kompatibilitäts-Metadaten – welches Paket für welches System und welche Versionen gedacht ist. So sehen Sie auf einen Blick, ob eine Erweiterung zu Ihrer Installation passt, bevor Sie sie in einer Staging-Umgebung testen.

Stöbern Sie nach System getrennt:

Znuny-Plugins
OTOBO-Plugins
Zammad-Plugins
Gesamtübersicht aller ITSM-Plugins und Pakete

Tiefer einsteigen: Vergleich, Migration & KI

Dieser Artikel beantwortet bewusst nicht die Frage "Welcher Fork ist der beste?" – dafür gibt es bereits exzellente, ausführliche Quellen. Wenn Sie an der Auswahl-, Migrations- oder KI-Perspektive interessiert sind, lesen Sie weiter bei:

Fork-Auswahl & Feature-/KI-Vergleich:

Migration von OTRS:

OTRS Migration Path 2026 (softoft.de)

KI-Automatisierung auf diesen Systemen:

Lösungsseiten für OTOBO, Znuny und KIX bei Open Ticket AI
Praxis-Guides: Automatisierung in Znuny und OTOBO Ticket-Automation
Python-SDKs für OTOBO und Znuny

Fazit

Das gemeinsame .opm-Erbe der OTRS-Forks ist ein Segen für die Community – aber kein Garant für blinde Austauschbarkeit. Die Portabilität einer Erweiterung hängt von der deklarierten Framework-Version, internen APIs, Frontend-Eingriffen und Abhängigkeiten ab. Wer fremde Pakete einsetzt, sollte immer die deklarierte Kompatibilität prüfen und in einer Staging-Umgebung testen.

Welcher Fork – Znuny, OTOBO oder KIX – am Ende der richtige ist, beantworten die oben verlinkten Vergleichs- und Migrationsartikel. Unsere Aufgabe ist es, das Ökosystem darum herum sichtbar und vergleichbar zu machen. Weitere Einordnungen finden Sie in der Blog-Übersicht.

Dieser Artikel ist ein neutrales Open-ITSM-Hub-Summary zum Plugin-Ökosystem. Für verbindliche Kompatibilitäts- und Versionsangaben konsultieren Sie bitte die offizielle Dokumentation des jeweiligen Projekts.