Nach OTRS: wie Teams ein Open-Source-Ticketsystem wählen

Lange hieß „Open-Source-Ticketsystem“ im DACH-Raum eine Codebasis. Organisationen betrieben die OTRS Community Edition, kauften Support, wenn sie ihn brauchten, und schulten Agenten auf einer Perl-Anwendung mit Queues, Rollen und Kundenportal. Diese eine Linie endete, als der Hersteller die Community Edition einstellte und das Produkt als kommerzielles OTRS weiterführte.

Was folgte, war nicht ein Nachfolger. Es war eine Spaltung, plus eine Reihe unabhängiger Projekte, die auf einer Beschaffungsfolie nur ähnlich aussehen.

Die Familie mit gemeinsamer Vergangenheit

Znuny und OTOBO führen beide die Linie der Community Edition fort. Agenten, die OTRS gelernt haben, erkennen die Agentenoberfläche, das Queue-Modell, dynamische Felder und das Generic Interface. Eine Migration von einer alten Community-Installation ist ein Projekt, keine Fantasie. Das Datenmodell ist absichtlich vertraut.

Es ist nicht dasselbe Projekt.

• Znuny ist der Fork, den das Team weiterträgt, das die Community Edition gepflegt hatte. Betreiber, die die Kontinuität dieser Linie wollen, und einen Hersteller, der das Open-Source-Produkt unter dem Namen Znuny veröffentlicht, fangen hier an.
• OTOBO ist die Linie, die mit Rother OSS gepflegt wird. Teams, die diesen Release-Zug, seine Paketierung und seine ITSM-Erweiterungen wollen, fangen hier an. OTOBO 11 ist die Generation, die gemeint ist, wenn von überarbeiteter CMDB, dynamischen Formularen und containerfreundlichem Betrieb die Rede ist.

Das kommerzielle OTRS der OTRS AG ist ein anderer Vertrag. Es ist nicht die Community Edition mit neuem Logo. Ein Team, das noch sagt „wir fahren OTRS“, kann auf einer bezahlten aktuellen Version sitzen, auf einer eingefrorenen Community-Version oder auf einem Fork, den niemand im Gespräch umbenannt hat. Die erste Aufgabe jeder Auswahl ist, das System zu benennen, das tatsächlich installiert ist.

Die Systeme, die keine Forks sind

Zammad steht oft auf derselben Shortlist und ist kein OTRS-Fork. Es ist ein eigenes Open-Source-Helpdesk, mit eigener Oberfläche und eigener Art, Kunden und Kanäle zu modellieren. Es gehört in einen Vergleich, wenn die Anforderung „ein modernes Open-Source-Desk“ lautet. Es gehört nicht in einen Vergleich, dessen Anforderung „unsere OTRS-Prozesse, ACLs und Generic-Interface-Anbindungen behalten“ lautet.

Gehostete Suiten — ServiceNow, Jira Service Management, Freshdesk und der Rest — lösen ein anderes Problem: ein Anbieter betreibt die Plattform. Sie sind die richtige Antwort, wenn die Organisation genau dieses Betriebsmodell will. Sie sind ein Kategorienfehler, wenn die Anforderung eine On-Prem-Prozessmaschine ist, die das interne Team schon zu patchen weiß.

Die Fragen, die eine Shortlist sortieren

Feature-Matrizen verdecken die Entscheidung. Fünf Fragen sortieren schneller.

1. Gibt es eine lebende Community-Edition-Datenbank, die umziehen muss? Wenn ja, sind Znuny und OTOBO das relevante Paar. Wenn nein, kommen Zammad und die gehosteten Suiten wieder auf die Liste.
2. Wer darf es betreiben? Ein Zwei-Personen-IT-Team, das Perl, Elasticsearch und ein Mail-Gateway nicht betreiben wird, sollte das nicht behaupten. Software kann Open Source sein und trotzdem einen Betreiber brauchen.
3. Welche Integrationen tragen Last? Ein Generic-Interface-Webservice, der Tickets aus dem Monitoring anlegt, ist eine Migrationsbedingung. Ein Logo im Kundenportal ist keine.
4. Was muss im Netz bleiben? Wenn Tickettext, Anhänge oder CMDB-Daten nicht in einer Anbieter-Cloud verarbeitet werden dürfen, gehört das vor jede KI-Demo gesagt.
5. Wer antwortet, wenn ein Security-Release kommt? Community-Code ohne benannten Pflegepfad ist ein anderes Risiko als ein Fork mit einer Firma hinter dem Release.

Nichts davon ist ein Ranking. Eine Kommune, ein Klinikverbund und ein Softwarehersteller können diese Fragen entgegengesetzt beantworten und alle recht haben.

Was sich in der Arbeit geändert hat, nicht im Logo

Die tägliche Arbeit auf diesen Systemen sind weiter Queues, Rollen, SLAs und die Kante, an der Mail zum Ticket wird. Die neue Arbeit, wo es sie gibt, sitzt daneben: eine CMDB, die jemand wirklich pflegt, Formulare, die zu einem Prozess passen, und — in manchen Desks — ein lokaler Klassifikator, der eine Queue vorschlägt, ohne das Ticket zu exportieren.

Dieser letzte Teil ist optional. Ein sauberes Queue-Modell und ein funktionierender Mailpfad wiegen mehr als ein Modell. Die Desks, die aus Klassifikation etwas ziehen, sind die, die schon wissen, welche Queues echt sind.

Wo der Vergleich steht

Ein strukturierter Vergleich der OTRS-Forks und von Zammad liegt auf dem Open ITSM Hub, getrennt von diesem Artikel. Die eigene Arbeit von Softoft ist Umsetzung auf OTOBO und Znuny — Installation, Integration, On-Prem-Automatisierung — nicht die Behauptung, ein Fork gewinne für jeden Leser.

Wer auswählt, sollte aufschreiben, welches System heute läuft, welche Integrationen nicht wegfallen dürfen, und ob der Tickettext das Haus verlassen darf. Danach ist die Shortlist kurz.