The OTRS Community Edition lives on in three active forks—Znuny, OTOBO, and KIX. Which one is right for your team depends on the feature set, AI strategy, and migration path. Other sources examine these questions in great detail (links at the end of this article). From the perspective of a vendor-neutral plugin directory, however, a very different and often underestimated question arises:
How portable is the shared .opm ecosystem really—and can I simply take a package found for OTRS or Znuny and install it in OTOBO or KIX?
Let's take a closer look. For the preliminary system selection, check out the separate, data-driven comparison OTRS Forks and Zammad 2026 as well as all direct system comparisons.
A Shared Root, a Shared Package Format
All three forks descend from the OTRS Community Edition and therefore share the same basic building blocks for extensions:
.opmas a package format—an XML-based container format that bundles code, database changes, and configuration.SOPMas a manifest—the source file of a package declares, among other things, its name, version, and—crucially—the compatible framework version.- The Generic Interface—the REST/SOAP web service layer used to connect integrations.
- Dynamic Fields, ACLs, process management—conceptually familiar across all forks.
On paper, this looks like perfect interchangeability. In practice, however, portability is a spectrum—and that is precisely what makes a well-maintained directory valuable.
Package Sources Across the Three Forks
Each fork maintains its own distribution channel. We aggregate these sources in our package sources overview:
| Fork | Official Package Source | Format |
|---|---|---|
| Znuny | addons.znuny.com | .opm |
| OTOBO | ftp.otobo.org/pub/otobo/packages/ | .opm |
| KIX (Classic) | kixdesk.com / Repos | .opm |
Because the same file extension is used, it easily gives the impression that a single package runs everywhere. In reality, compatibility is tied to the respective framework version and internal API assumptions.
Portability in Practice: Four Pitfalls
1. The Declared Framework Version
In the SOPM/OPM file, a package specifies which framework versions it is compatible with (e.g., 6.x, 10.x, 11.x). A package that only declares <Framework>6.0.x</Framework> cannot be easily installed on a modern OTOBO 11—the package manager will block it or issue a warning. Znuny packages close to the OTRS 6 baseline are therefore not automatically runnable in OTOBO 11.
2. Diverging Internal APIs
Even if the format is identical, OTOBO and KIX have modernized parts of their core. Calls to internal Perl modules, modified method signatures, or new caching layers (e.g., OTOBO relies on Redis/Elasticsearch) can cause a syntactically installable package to throw runtime errors.
3. Template and Frontend Differences
Skins and frontend extensions are particularly sensitive. An agent skin built for the classic OTRS/Znuny interface rarely fits OTOBO 1:1—and certainly not the reimagined frontend of KIX 18, which is architecturally the furthest removed from the original.
4. Dependencies Between Packages
Many extensions require other .opm packages or Perl modules. If a declared dependency is missing in the target system or only exists in an incompatible version, the installation fails, regardless of the fork.
Rule of thumb: The closer a package stays to pure business logic (Dynamic Fields, ACLs, Generic Interface mappings), the more portable it is. The deeper it digs into the frontend or internal core APIs, the more likely it needs a fork-specific variant.
Special Case KIX 18: Same Heritage, Different World
KIX maintains a classic Perl line and the newer KIX 18 in parallel. KIX 18 is a largely rewritten development featuring a REST API-centric architecture and its own frontend. For plugin portability, this means that classic .opm add-ons from the OTRS world are the hardest to adopt directly here. In return, the API-first architecture opens up alternative integration paths—such as through external services rather than embedded .opm modules.
How an Open Directory Helps
This is precisely where the Open ITSM Hub comes in: Instead of merely listing packages, we capture compatibility metadata—showing which package is intended for which system and versions. This allows you to see at a glance whether an extension fits your installation before testing it in a staging environment.
Browse by system:
- Znuny Plugins
- OTOBO Plugins
- Zammad Plugins
- Complete overview of all ITSM Plugins and Packages
Digging Deeper: Comparison, Migration & AI
This article deliberately does not answer the question "Which fork is the best?"—there are already excellent, detailed sources for that. If you are interested in selection, migration, or the AI perspective, continue reading at:
Fork Selection & Feature/AI Comparison:
- OTOBO vs. Znuny vs. Zammad – The AI Comparison (softoft.de)
- Open-Source AI Ticket System: Best Options 2026 (openticketai.com)
- What OTOBO 11 Brings (softoft.de)
Migration from OTRS:
AI Automation on These Systems:
- Solution pages for OTOBO, Znuny, and KIX at Open Ticket AI
- Practical guides: Automation in Znuny and OTOBO Ticket Automation
- Python SDKs for OTOBO and Znuny
Conclusion
The shared .opm heritage of the OTRS forks is a blessing for the community, but it is no guarantee of blind interchangeability. The portability of an extension depends on the declared framework version, internal APIs, frontend interventions, and dependencies. Anyone using third-party packages should always verify declared compatibility and test in a staging environment.
Which fork—Znuny, OTOBO, or KIX—is ultimately the right one is answered by the comparison and migration articles linked above. Our task is to make the surrounding ecosystem visible and comparable. You can find further classifications in the blog overview.
This article is a neutral Open ITSM Hub summary on the plugin ecosystem. For binding compatibility and version specifications, please consult the official documentation of the respective project.