Znuny vs OFORK: Etablierter OTRS-Nachfolger oder neuer Fork?

Die Entscheidung für einen Nachfolger der OTRS Community Edition ist für viele IT-Organisationen eine Frage der langfristigen Stabilität und des Vertrauens in die Projektführung. Während Znuny seit 2021 als direkte Fortführung etabliert ist und von einem kommerziellen Dienstleister gesteuert wird, positioniert sich OFORK (auch O-Fork) als eine Alternative, deren öffentliches Repository in der vorliegenden Form seit Oktober 2025 besteht. Beide Systeme teilen die technologische Wurzel in der Programmiersprache Perl und setzen auf das bewährte .opm-Paketformat. Dennoch ergeben sich bei der Analyse der Governance-Strukturen, der Release-Zyklen und der Ökosystem-Anbindung signifikante Unterschiede, die für die Betriebssicherheit und die Wartbarkeit in professionellen Umgebungen ausschlaggebend sind.

Governance und Projektstruktur: Vendor-led vs. Maintainer-led

Ein zentrales Kriterium für technische Entscheider ist die Frage, wer hinter der Entwicklung steht und wie Entscheidungen getroffen werden. Znuny wird von der Znuny GmbH geführt. Dieses Modell der „Vendor-led open-source development“ bedeutet, dass ein kommerzielles Unternehmen die primäre Verantwortung für die Codebasis, die Security-Advisories und die Roadmap trägt. Dies bietet für Unternehmen oft eine greifbare Anlaufstelle, erfordert aber auch Vertrauen in die Strategie des Herstellers.

Im Gegensatz dazu wird OFORK als Projekt-Maintainer-geführt beschrieben. Die Governance liegt hier bei den individuellen Maintainern des Projekts. Laut Datenpaket ist für OFORK kein expliziter kommerzieller Backer hinterlegt. Während dies eine hohe Unabhängigkeit suggeriert, fehlen im Vergleich zu Znuny etablierte Strukturen wie ein öffentliches Forum für den Austausch zwischen Anwendern. Die Identität von OFORK ist eng mit der OTRS-Familie verknüpft, wobei das Projekt eine Historie bis ins Jahr 2018 angibt, die öffentliche Sichtbarkeit im aktuellen Repository jedoch deutlich jüngeren Datums ist (Oktober 2025).

Wartbarkeit und Release-Strategie

Für Administratoren ist die Vorhersagbarkeit von Updates und die Verfügbarkeit von Sicherheitskorrekturen essenziell. Znuny verfolgt eine zweigleisige Strategie: Es gibt eine aktive Feature-Linie (aktuell Version 7.3) und einen Long-Term Support (LTS) Zweig (Version 6.5). Diese LTS-Version ermöglicht es Organisationen, über einen längeren Zeitraum auf einer stabilen Basis zu bleiben, ohne funktionale Änderungen am User Interface oder den Kernprozessen mitgehen zu müssen. Sicherheitsrelevante Abhängigkeiten werden laut den vorliegenden Security Advisories https://www.znuny.org/en/advisories/security-advisories regelmäßig adressiert, wie der Patch 7.3.5 vom Juli 2026 belegt.

OFORK wird aktuell in der Version 12.0.3 geführt. Eine explizite LTS-Zusage oder eine dokumentierte Update-Policy ist für dieses Projekt im Datenpaket nicht hinterlegt. Ein technisches Detail in der Wartbarkeit betrifft die Datenbankunterstützung: Während Znuny moderne Versionen von MySQL, MariaDB und PostgreSQL unterstützt, wird für OFORK explizit MySQL in Versionen kleiner als 8.0 aufgeführt. Dies kann für Admins, die auf aktuelle Betriebssystem-Distributionen mit neueren Datenbank-Standards setzen, eine Hürde in der Infrastrukturplanung darstellen. PostgreSQL wird ab Version 9.2 und Oracle ab 10g unterstützt.

Ökosystem, Erweiterbarkeit und Schnittstellen

Die Stärke der OTRS-basierten Systeme lag historisch in ihrer Modularität. Znuny kann auf ein gewachsenes Ökosystem zurückgreifen. Mit 115 im Hub registrierten Paketen und einem eigenen Package Manager https://addons.znuny.com bietet es eine hohe Flexibilität für ITSM-Prozesse und Integrationen. Die Anbindung an Drittsysteme erfolgt über das „Generic Interface“ per REST oder SOAP, was eine tiefe Integration in bestehende IT-Landschaften ermöglicht.

OFORK nutzt ebenfalls das .opm-Format für Erweiterungen, verfügt jedoch zum Stand der Datenaufnahme über keine registrierten Pakete im zentralen Hub. Die Integrationsmöglichkeiten werden primär über E-Mail und Web-Services angegeben. Für technische Entscheider bedeutet dies, dass bei OFORK eventuell mehr Eigenleistung bei der Entwicklung oder Portierung von Erweiterungen notwendig ist, da die Auswahl an fertigen Community-Modulen im Vergleich zu Znuny geringer ausfällt. Beide Systeme unterstützen jedoch den Import von Paketen, was die technologische Verwandtschaft unterstreicht.

Community-Vertrauen und Dokumentation

Vertrauen in Open-Source-Software lässt sich oft an Metriken der Zusammenarbeit ablesen. Znuny weist mit 582 Stars und 119 Forks im GitHub-Repository eine breite Basis an öffentlicher Interaktion auf. Die Dokumentation ist unter https://doc.znuny.org umfangreich für verschiedene Versionen aufbereitet, inklusive Anleitungen für Backup und Restore.

OFORK zeigt mit 4 Stars und einem Fork eine deutlich geringere öffentliche Resonanz im Repository. Auch die Dokumentation ist weniger differenziert; sie wird primär über die Projektwebsite https://o-fork.de/ bereitgestellt. Das Fehlen eines Community-Forums erschwert den informellen Wissensaustausch zwischen Administratoren. Für Organisationen, die auf eine starke Community-Basis für das Troubleshooting angewiesen sind, stellt dies einen relevanten Faktor in der Risikobewertung dar.

Deployment und technischer Stack

In der operativen Umsetzung bieten beide Systeme die klassische Source-Installation auf Linux-Basis unter Verwendung von Apache und mod_perl an. Znuny bietet darüber hinaus offizielle Docker-Unterstützung und Linux-Pakete an, was den Deployment-Prozess in modernen Infrastrukturen vereinfachen kann. Für OFORK sind im Datenpaket keine nativen Container-Optionen oder Kubernetes-Operatoren vermerkt.

Beide Systeme sind als LAMP-Stack (bzw. Varianten davon) konzipiert. Znuny nutzt für die Suche die Volltextsuche der Datenbank, bietet aber auch Caching-Optionen via Redis an. Bei OFORK sind spezifische Angaben zu Such-Engines oder erweiterten Caching-Mechanismen nicht im Datenpaket enthalten. Die Mindestanforderung für Perl liegt bei Znuny (Version 7.3) bei 5.24, während für OFORK keine spezifische Mindestversion von Perl dokumentiert ist.

Für wen passt welches System?

Die Wahl zwischen Znuny und OFORK hängt stark von der individuellen Risikotoleranz und dem Bedarf an professionellen Supportstrukturen ab.

Znuny ist eher geeignet für:

• Organisationen, die von der OTRS Community Edition migrieren und einen direkten, dokumentierten Pfad suchen.
• Umgebungen, die auf Long-Term Support (LTS) angewiesen sind, um Wartungsfenster planbar zu halten.
• Teams, die eine breite Auswahl an fertigen Zusatzmodulen (.opm) benötigen.
• Unternehmen, die Wert auf eine herstellergestützte Entwicklung mit klaren Security-Prozessen legen.

OFORK kommt in Betracht für:

• Nutzer, die ein schlankes System im OTRS-Stil suchen und keine Abhängigkeit von einem größeren kommerziellen Vendor wünschen.
• Administratoren, die bereit sind, die Weiterentwicklung eines jüngeren Projekts aktiv zu begleiten und eventuell fehlende Dokumentation oder Pakete selbst zu kompensieren.
• Szenarien, in denen spezifische ältere Datenbankversionen (wie MySQL < 8.0) zwingend beibehalten werden müssen.

Datenstand und Grenzen des Vergleichs

Dieser Vergleich basiert auf den Daten vom 30.07.2026. Es ist zu beachten, dass sich insbesondere junge Projekte wie OFORK dynamisch entwickeln können. Die Angaben zu Repository-Stars und Paket-Anzahlen sind Momentaufnahmen. Aussagen zur Stabilität oder Performance können nicht allein aus den Versionsnummern (Znuny 7.3 vs. OFORK 12.0) abgeleitet werden, da die Nummerierungsschemata der Projekte unterschiedlichen Logiken folgen.

Fazit

Znuny und OFORK repräsentieren unterschiedliche Ansätze in der Fortführung der OTRS-Tradition. Während Znuny durch ein breites Ökosystem, eine klare LTS-Strategie und eine hohe Community-Sichtbarkeit punktet, bietet OFORK eine Alternative für Anwender, die abseits der etablierten Pfade agieren möchten. Für eine detaillierte technische Prüfung der Features und Anforderungen empfiehlt sich die Nutzung der interaktiven Vergleichstabelle, um die Systeme gegen weitere Alternativen wie OTOBO oder Zammad zu prüfen.