© theartofphoto, 123RF

Er wollte Helfern helfen: Linux-Magazin-Autor Stefan Wintermeyer hat bei Suse “Stefans Trouble Ticket System” (STTS) eingeführt. Aus ihm entstand mit den Jahren das Ticketsystem OTRS.

Vor 20 Jahren – im Oktober 1998 – zog ich von Neuwied am Rhein nach Nürnberg und nahm eine Stelle bei der S.u.S.E. in Nürnberg an. Das Unternehmen schrieb sich damals noch mit Punkten zwischen den Buchstaben, weniger als 50 Mitarbeiter arbeiteten dort.

Galt ich in Neuwied als Linux-Fachmann, startete ich bei Suse [1] – verglichen mit den anderen – als absoluter Anfänger. Umgeben von Kernelhackern und Programmiergurus fing ich im Support an. Jeder Käufer einer Suse-Box (bestehend aus Installations-CDs und Handbuch) erhielt mit dieser auch das Anrecht auf E-Mail-Support, was Telefonanrufe an zwei Tagen pro Woche einschloss.

Linux war damals noch weit weniger benutzerfreundlich als heute, entsprechend trudelten reichlich Support-Anfragen ein. Die E-Mails wanderten zunächst zu einem alle zwei Wochen wechselnden Dispatcher – einer Person! Deren Aufgabe war es, eingehende E-Mails an die Spezialisten zu verteilen. Qualitätsmanagement nach heutigen Standards war noch unbekannt. Wurde ein Bug gemeldet, wurde er gefixt. Es gab keine Testsuiten oder gar A-B-Tests. Jeder Programmierer musste damals auch Support leisten (was zur Verbesserung der Codequalität beitrug). Einfache Anfragen beantwortete der Dispatcher auch selbst.

Dispatcher eigneten sich schnell ein sehr breites Wissen an. Am Tag landeten zwischen 200 und 500 neue E-Mails in der Support-Inbox. Da wurden die Tage schon mal länger. Richtig Pech hatte, wer eine übervolle Inbox mit alten Anfragen der Vorwoche übernehmen musste, weil der vorherige Dispatcher eher wenig Lust auf diese Arbeit verspürt hatte.

Support gab es nur in einem bestimmten Zeitfenster nach der Veröffentlichung einer Distribution und auch nur für die Käufer der Box. Das Anrecht auf Support erkauften sich die Kunden mit einem bei jedem Kauf einzigartigen Lizenzschlüssel, einem zufälligen mehrstelligen Buchstabencode.

Alle Codes landeten zusammen mit der Softwareversion in einer internen SQL-Datenbank. Ein Supporter öffnete die E-Mail und suchte nach dem Code, um ihn dann in einem zusätzlichen Tool zu überprüfen. Dieser Prozess dauerte im besten Fall 30 Sekunden. Kleinvieh macht auch Mist: Bei 400 E-Mails prüfte ein Dispatcher an einem Tag gut drei Stunden lang nur Lizenzcodes.

Reine Zeitverschwendung

Leitete er dann die E-Mail an einen Spezialisten weiter, wiederholte sich dieser Vorgang oft nochmals. Ich war verblüfft, dass dies in einer Firma voller Software-Wunderkinder niemanden störte. Auf meine wiederholten Fragen kam stets die Antwort, dass sich das unmöglich automatisieren lasse. Man könne ja die Lizenzcodes nicht rausfiltern, weil es sich um Zufallswerte handelte, die ein Regex nicht erkennen könne. Mir wurde sogar explizit verboten mit so einer “blöden Idee” Zeit zu verschwenden.

Unter einem Vorwand verschaffte ich mir trotzdem Leserechte zur SQL-Datenbank und arbeitete heimlich weiter an dem Problem. In meiner ».procmailrc« [2] leitete ich alle E-Mails an ein Perl-Skript, das per Regular Expression aus dem E-Mail-Body alle Zeichenketten mit fünf Buchstaben herausfilterte und als Anfrage an die Lizenzschlüssel-Datenbank schickte. Dieser Brute-force-Ansatz war wenig elegant, aber sehr effektiv.

Natürlich waren die meisten fünfstelligen Zeichenketten normale Wörter und hatten deshalb keinen Treffer, aber die Lizenzschlüssel wurden korrekt erkannt. Procmail schrieb diese dann zusammen mit der Versionsnummer der Distribution als X-Header in die E-Mail. Alle Supporter konfigurierten ihr E-Mail-Programm so um, dass im Kopf der Inhalt dieses X-Headers erschien.

Das kleine Perl-Programm sparte uns viel Zeit, daher fing ich an, weitere automatische Tools zu bauen. Zum Beispiel brachte jede Distributionsversion typische Fehler mit, die regelmäßig im Support aufschlugen. Suchmaschinen waren noch sehr ineffektiv, Endanwender fanden nur schwer selber Lösungen.

Diese Supportanfragen enthielten oft bestimmte Schlüsselwörter, etwa die Namen von Konfigurationsdateien. Bald hatte ich ein Toolset entwickelt, das mir aufgrund der Schlüsselwörter dafür passende Textbausteine herauspickte. Natürlich passten die Treffer nicht immer, aber ein 80-Prozent-Lösung war schon eine Hilfe. Der Einsatz der X-Header bewährte sich später in STTS, OTRS und Zammad als praktischer Mechanismus.

Neues System, neue Sorgen

1999 stellte Suse den Ablauf im Support um, er skalierte nicht mehr. Also schaffte die Firma ein kommerzielles Trouble-Ticketsystem an. Die Zeiten der zentralen Inbox und der Dispatcher waren vorbei, nur die Brute-force-Lizenzcode-Suche überlebte den Umstieg.

Das neue System ließ sich katastrophal schlecht bedienen. Zwar konnten erstmals mehrere Personen an der zentralen Inbox arbeiten und dort Anfragen locken, aber der Java-Client erwies sich als schrecklich langsam und kompliziert. Das Backlog wuchs unaufhörlich, die Stimmung im Support kippte und der Service verschlechterte sich.

Stefans System

An einem Freitag Nachmittag hatte ich genug und fing an, ein eigenes Trouble-Ticketsystem zu programmieren, das STTS (Stefans Trouble Ticket System). Es war einer dieser ein Wochenende andauernden Programmier-Marathons, die sich nur in jungen Jahren und ohne Familie leisten lassen. Am Montag saß ich übermüdet und ungeduscht vor dem rudimentären Prototyp. Da der Begriff STTS bereits häufig im Code auftauchte und mir die Zeit für Alternativen fehlte, benannte ich das System einfach in Suses Trouble Ticket System um.

Das STTS war ein gruseliger Perl-Monolith mit einem Webinterface aus purem HTML – kein CSS, kein Javascript. Dazu muss man wissen: Die IT-Welt sah damals noch anders aus. Das Encoding von Zeichen, das heute UTF-8 macht, war mühselig (von Perl zur MySQL-Datenbank). An Git war nicht zu denken, SVN das Maximum technischer Möglichkeiten. Zwar war die agile Entwicklung noch nicht erfunden, doch arbeiteten wir sehr agil, ohne es zu wissen.

Doch der Hauptunterschied im Stack bestand in Javascript, ohne das heutige Webanwendung undenkbar wären. Damals fand alles auf dem Server statt, der Webclient stellte nur HTML dar.

STTS ließ sich schneller und einfacher bedienen als das gerade eingeführte kommerzielle System. Alle E-Mails landeten erst in einer zentralen Queue und ließen sich dort von den Supportern zur Bearbeitung reservieren (“locken” genannt). Anfangs konnte sich jeder Supporter das Ticket per E-Mail schicken lassen, um es dann mit dem Client seiner Wahl zu beantworten. Später bot STTS auch die Möglichkeit, E-Mails direkt im Web-GUI zu schreiben (Abbildung 1, [4]).

Abbildung 1: Suses Trouble Ticket System in Aktion: Tickets ließen sich unter anderem locken, beantworten und weiterleiten.

Mit der Zeit erhielt STTS ein besseres Warteschlangensystem mit automatischen Filtern und Eskalationsprozessen. Fertige und Queue-abhängige Textbausteine erleichterten die Arbeit und verbesserten die Qualität der Antworten. Mit STTS ließen sich mehr E-Mails in kürzerer Zeit beantworten. Für “Stammkunden” ließ sich auf alte Anfragen und Antworten zugreifen. Nur die Trouble-Ticket-Nummer war unglücklich gewählt (siehe Kasten “Zahlensalat”).

STTS entwickelte sich zum Kern des Supports und ersetzte das erst kurz zuvor eingerichtete kommerzielle System. Doch zusammen mit Suse wuchsen auch die Anforderungen an STTS. Ein Zwei-Mann-Team erweiterte und verbesserte den ursprünglichen Hack. Zu ihm gehörte der Programmierer Martin Edenhofer, der weiter unten noch eine Rolle spielen soll.

Money to burn

Mich ernannte der Vorstand derweilen zum Vice President Support, ich sollte einen weltweiten Linux-Support aufbauen. Es war Dotcom-Boom-Zeit. Meine Frage, ob wir wirklich einen globalen 24/7-Support mit Callcentern auf mehreren Kontinenten brauchen, bügelte der Vorstand mit einem “Stefan, mach dir mal um das Geld keine Sorgen. Frisches Geld bekommen wir immer!” als eher kleinkariert ab. Geld wurde am Ende mit vollen Händen ausgegeben, auch von mir.

Weil der Chef von Suse Amerika mit der US-typischen Zwei-Wochen-Frist kündigte, musste ich ein paar Monate in Oakland (Kalifornien) als Interims-Chef aushelfen. Parallel dazu lief der Aufbau der 24/7-Business-Support-Infrastruktur. Es war eine sehr stressige Zeit.

Nachdem das Suse-Supportcenter in Bremen mit über 100 Supportern in den Rund-um-die-Uhr-Betrieb ging, kümmerte ich mich Ende 2000 um den Aufbau des nächsten in Miami, Florida. Um es schnell zu starten, flog Suse ein kleines Kernteam von deutschen Supportern aus Bremen nach Miami.

Die Sache mit dem Geld

In der Woche vor Weihnachten bekam ich in Florida einen Anruf vom Vorstand. Die Sache mit dem frischen Geld entpuppte sich plötzlich doch als Problem. Die Dotcom-Blase begann zu platzen, die Geldquellen versiegten plötzlich [5].

In Miami versammelte ich bei schönstem Wetter das gerade frisch eingeflogene Team und verkündete die für alle traurige Nachricht. Das war bis heute das schwierigste Meeting, das ich jemals geleitet habe. In den nächsten zwei Wochen flogen alle nach Deutschland zurück. Einige im Team hatten dort bereits ihre Wohnungen gekündigt und ihre Autos verkauft.

Anfang 2001 eskalierte die Situation weiter. Es wurde gespart, es gab Kündigungen. Auf einer stand auch mein Name. Das war nicht gerade angenehm, aber da ich selbst mit dem Gedanken der Kündigung gespielt hatte, für mich wegen der Abfindung im Endeffekt praktisch. Um runterzukommen, ging ich auf eine dreimonatige Weltreise. Die in dieser Zeit besuchten Strände landeten übrigens später als Release-Namen in OTRS.

Zurück zur Old Economy

Der Abschied von Suse fiel mir sehr schwer, die Firma war etwas Besonderes. Sie fehlte mir. Andererseits hatte ich von der New Economy die Schnauze voll, suchte das andere Extrem und fing als Projektleiter bei der Lufthansa an – damals noch ein Old-Economy-Dinosaurier. Mein Auftrag: Ich sollte ein Web-basiertes E-Mail-System für die 60000 Mitarbeiter als günstigere Alternative zum eingesetzten Microsoft-Exchange-System entwickeln – quasi Google Mail, bevor es Google Mail gab.

Abbildung 2: Das STTS-Team bei Suse im Jahr 2001. Vordere Reihe von links: Martin Edenhofer, Carsten Groß, Dirk Lerner und Sebastian Wormser.

Das Arbeiten in der Old Economy fiel mir nicht leicht. Die Geschwindigkeit des Dinosauriers erwies sich als viel geringer und der Overhead als wesentlich größer – kein Vergleich mit der New Economy. Für mich war die einfachste Lösung, ehemalige Suse-Kollegen anzuwerben, darunter auch Martin Edenhofer aus dem STTS-Team (Abbildung 2, ganz links).

STTS Reloaded

So arbeiteten wir also zusammen die nächsten Jahre bei der Lufthansa in Frankfurt. Da wir in einer WG wohnten, kamen wir natürlich auch immer wieder auf das STTS zu sprechen. Es waren Tagträume, denn der Sourcecode gehörte Suse und war nicht offen.

Nach mehreren Monaten solcher “Was-man-aus-dem-STTS-noch-alles-machen-könnte”-Gespräche fing Martin in seiner Freizeit an, ein neues Ticketsystem aus dem Boden zu stampfen (Abbildung 3). Der Name OTRS (Open Ticket Request System, [6]) gefiel mir allerdings nie und war vor allem dem Umstand geschuldet, dass diese Vier-Buchstaben-Domain noch frei war.

Abbildung 3: “So we decided to start a new project”: Webseite des OTRS-Projekts vom November 2002.

Auf der grünen Wiese entstanden, ließen sich viele Architekturschwächen des OTRS von Anfang an vermeiden. Die Grundidee blieb die gleiche, Perl die Programmiersprache der Wahl, aber der Code und die Datenbankstruktur wurden besser. Die GPL als Lizenz zu wählen war kein Diskussionspunkt. Die MIT-Lizenz war damals noch wenig verbreitet, und wir machten uns über die Feinheiten der Open-Source-Lizenzen auch nicht viele Gedanken.

Martin arbeitete weiterhin bei der Lufthansa. Ich wurde 2003 von einem indisch-amerikanisch-deutschen Joint-Venture-Unternehmen für Offshore-Programmierung abgeworben und verbrachte meine Zeit vorwiegend damit, das Konzept der Offshore-Programmierung hassen zu lernen. Mir war zwar bewusst, dass sich mit OTRS Geld verdienen ließ. Allerdings war mir auch klar, dass der Anfang eine finanziell anstrengende Phase werden würde.

OTRS entsteht

Ich sprach mit Martin über die Idee, eine OTRS GmbH zu gründen, die Consulting und Support rund um das OTRS anbietet. Er war von der Idee logischerweise begeistert, es fehlte lediglich das Startkapital, um komfortabel die erste, finanziell trockene Phase zu überbrücken. Ich fand zwei Investoren (einer der beiden war der Suse-Mitgründer Burchhard Steinbild) und wir gründeten zu viert eine GmbH. Martin programmierte, ich war Geschäftsführer und kümmerte mich um neue Kunden.

Bei jedem Softwareprojekt ist Sichtbarkeit das Wichtigste. Selbst die beste Software hat wenig Chancen, wenn sie keiner kennt. Also bestand eine meiner Hauptaufgaben darin, auf Konferenzen Vorträge über Trouble-Ticketsysteme zu halten und die allgemeine PR-Arbeit zu leisten. In dieser Zeit verwechselten viele Interessenten Trouble-Ticketsysteme noch mit Bugtrackern. Und in den USA kannten die meisten Leute nur RT (Request Tracker, [7]).

Internationale Sichtbarkeit erlangten wir mit einer OTRS-Installation bei der Nasa. Eine kleine Abteilung innerhalb der riesigen Nasa benutze OTRS mit einer Handvoll Leute. Wir bekamen durch eine Supportanfrage Wind davon, sprachen mit dem Team und veröffentlichten eine PR-Story. Dabei ließ ich großzügig die genaue Abteilungsgröße unter den Tisch fallen. Es hieß immer nur, dass auch die Nasa jetzt OTRS einsetze.

Der Ritterschlag in Deutschland kam vom BSI (Bundesamt für Sicherheit in der Informationstechnik, [8]). Wir sollten für das Cert-Bund ein OTRS installieren und anpassen, ein umfangreiches Projekt. Etwas Besseres als ein BSI-Projekt kann einem deutschen Open-Source-Projekt kaum passieren.

Zu schreiben, dass das Supportgeschäft in dieser Zeit sehr zähflüssig lief, wäre noch untertrieben – es war fast nicht existent. Die meisten Firmen hielten es für selbstverständlich, für kostenlose Open-Source-Software auch gratis Support zu erhalten. Wir lebten vom Projektgeschäft, konnten damit aber dennoch stetig wachsen und das Team erweitern.

“Dann macht es halt selber”

Nach zwei erfolgreichen Jahren kam es dann zu einem filmreifen Treffen aller Gründer in einem Hotel am Frankfurter Flughafen. Es ging um die Zukunft der Firma. Die Sitzanordnung und der eher untypische Kleidungsstil hätten sich schon als erstes Indiz für drohendes Unheil deuten lassen. Martin saß auf der Seite der zwei anderen Gründer und nicht wie sonst immer auf meiner.

Es wurde schnell klar, dass er sich im Vorfeld mit beiden abgesprochen hatte. Offenbar herrschte Unmut über meine Art der Geschäftsführung. Aus heutiger Sicht war es lächerlich und ein klarer Fall von mangelnder Transparenz meiner Seite. Damals fühlte ich mich allerdings mit dem Rücken an der Wand und empfand es als persönlichen Affront, dass Martin sich auf die Seite der beiden anderen Gründer schlug. Bis dahin hatten wir stets zusammengehalten.

Nach zwei sehr erfolgreichen Jahren wollte ich mich für nichts rechtfertigen und dachte mir aus Trotz: “Dann macht es halt selber.” Unter einer fadenscheinigen Ausrede zog ich mich aus der Affäre und bot den anderen meine Firmenanteile zum Kauf an. Das alles geschah in nicht einmal einer Stunde. Peng!

Das Leben geht weiter

Innerhalb weniger Wochen übergab ich die Geschäftsführung und verkaufte meine Anteile an die anderen Gründer. Ich machte mich alleine selbstständig und startete mit der VoIP-Telefonanlage Gemeinschaft [9] mein nächstes Open-Source-Projekt.

Die OTRS GmbH und später AG wuchs zu einer großen Firma. OTRS wurde in diesem Zuge in Open Technology Real Services umbenannt (ein ebenso blöder Name).

Martin schied Jahre später ebenfalls aus der OTRS AG aus, auch seinen Namen nennt die ORTS-Webseite heute nicht mehr. Nach einer einjährigen Pause gründete er das sehr erfolgreiche quelloffene Trouble-Ticketsystem Zammad [10] – diesmal auf Ruby-on-Rails-Basis. Auch hier half der Start auf der grünen Wiese, ein besseres System zu erzeugen.

Miteinander gesprochen haben wir seit den Ereignissen damals nicht mehr. Dennoch muss ich heute schmunzeln, wenn ich auf eine E-Mail-Anfrage an eine Firma eine automatische Antwort mit der STTS-OTRS-typischen langen Trouble-Ticket-Nummer in der Betreffzeile zurückbekomme.