Als ich vor fast zehn Jahren bei der ATIX AG anfing, war orcharhino noch weit von dem Produkt entfernt, das es heute ist. Damals bestand orcharhino im Wesentlichen aus zwei Projekten: einem „orcharhino“ für die Verwaltung RPM-basierter Systeme und „Tiki“ für Debian. Tiki basierte zu dieser Zeit noch auf Spacewalk.
Vieles musste von Hand zusammengebaut werden. Es gab zwar eine ausführliche Dokumentation, aber trotzdem gehörten viele manuelle Schritte ganz selbstverständlich zum Alltag. Heute ist das kaum noch vorstellbar. Damals war es einfach die Art, wie wir gearbeitet haben.
Mit mir fingen zwei weitere Kollegen an. Gemeinsam mit den beiden bereits bestehenden Entwicklern und den Consultants machten wir uns daran, aus dem damaligen Projekt Schritt für Schritt ein verlässliches Produkt zu bauen. Am Anfang war vieles noch sehr direkt: Wir entwickelten Funktionen, packten Releases, schrieben Dokumentation und kümmerten uns oft auch selbst darum, dass die Neuerungen ihren Weg zu den Nutzern fanden.
Von manuellen Prozessen zur Automatisierung
Aus den manuellen Schritten zum Erstellen der orcharhino-Pakete entstand mit der Zeit ein vollständig automatisierter Packaging-Prozess. Mit „snapshot_management“ wurde das erste Plugin in orcharhino aufgenommen. Gleichzeitig arbeiteten wir bereits an der nächsten Erweiterung, um die Anbindung von SUSE Linux Enterprise zu verbessern.
Ein großes Thema war damals auch die Installation von Foreman und Katello. Beide Open-Source-Projekte bilden wichtige technische Grundlagen von orcharhino, waren zu dieser Zeit aber häufig nicht einfach zu installieren und zu betreiben. Mit Ansible und einem leichtgewichtigen webbasierten Installer wollten wir unseren Consultants das Leben leichter machen und gleichzeitig für reproduzierbarere Installationen sorgen.
Genau an solchen Stellen wurde für mich immer deutlicher, worin die eigentliche Produktarbeit besteht. Es reicht nicht, einzelne Open-Source-Komponenten zusammenzustellen. Sie müssen integriert, getestet, dokumentiert und über längere Zeit verlässlich gepflegt werden. Dazu kommen eigene Erweiterungen, definierte Releases und ein Support, der im Problemfall Verantwortung übernimmt.
Der Durchbruch beim Debian-Support
Eine der schwierigsten Baustellen blieb zunächst der Debian-Support. „orcharhino Tiki“ war eine separate Lösung, während im eigentlichen orcharhino die Unterstützung für Debian-Pakete fehlte. Gerade diese Lücke hat uns aber motiviert, bestehende Ansätze immer wieder zu hinterfragen.
Mit orcharhino 3.0 und dem Debian-Paket-Support sowie Version 4.0 mit Debian-Errata-Support gelang schließlich der Durchbruch. Damit konnten wir RPM- und Debian-basierte Systeme erstmals über eine gemeinsame Plattform verwalten.
Für uns war das mehr als nur ein weiteres Feature. Es war ein wichtiger Schritt hin zu dem, was orcharhino heute ausmacht: ein herstellerunabhängiges System für das Lifecycle Management unterschiedlicher Linux-Enterprise-Distributionen.
Von einzelnen Distributionen zur breiten Plattform
In den folgenden Jahren ging diese Entwicklung weiter. Wir integrierten den Salt-Support und übernahmen später auch die Pflege des Puppet-Plugins. Wir ergänzten neue Integrationen und erweiterten orcharhino um Enterprise-Funktionen, beispielsweise die Nutzung von Proxmox als Compute Resource.
Mit dem wachsenden Kundenstamm kamen immer neue Anforderungen hinzu. Aus der Unterstützung RPM-basierter Systeme und Debian wurde nach und nach eine Plattform für SUSE, Red Hat, Debian, Ubuntu, AlmaLinux, Oracle Linux und Rocky Linux. Für einige Betriebssysteme unterstützen wir inzwischen auch ARM64 und PPC64.
Gerade diese Breite schätzen viele unserer Kunden. Sie können unterschiedliche Distributionen und Architekturen über ein gemeinsames System verwalten, ohne sich beim Lifecycle Management vollständig an einen einzelnen Betriebssystemhersteller zu binden.
Mit orcharhino ist auch das Team gewachsen
Auch unser Team hat sich stark verändert. Aus anfänglich drei Mitarbeitern und einigen Consultants, die ebenfalls an orcharhino arbeiteten, ist das Engineering-Team heute das größte Team innerhalb der ATIX.
In den ersten Jahren waren die Rollen noch deutlich weniger getrennt. Wir schrieben Code, bauten Pakete, pflegten die Dokumentation, formulierten Release Notes und verfassten manchmal auch die Tweets selbst. Heute gibt es spezialisierte Teams für Marketing, Kommunikation und Außendarstellung.
Für mich ist genau das ein schönes Zeichen dafür, wie sehr orcharhino und die ATIX gewachsen sind. Viele Dinge, die früher nebenbei erledigt wurden, sind heute Teil professioneller und klar definierter Prozesse.
Trotzdem ist unsere Arbeit im Engineering-Team bis heute sehr vielseitig geblieben. Ganz im Sinne von DevOps kümmern wir uns nicht nur um klassische Entwicklung. Wir arbeiten auch an der von vielen Kunden geschätzten Dokumentation, betreiben verschiedene, teilweise vollständig automatisierte Testinfrastrukturen und sind am Betrieb des orcharhino-Auslieferungssystems beteiligt.
Dieses Auslieferungssystem läuft natürlich ebenfalls auf orcharhino.
Ohne Automatisierung mit Ansible, OpenTofu und orcharhino selbst könnten wir diese Vielzahl an Aufgaben kaum bewältigen. Automatisierung war für uns nie nur ein technisches Ziel. Sie war immer auch die Voraussetzung dafür, mehr Plattformen zu unterstützen, häufiger und verlässlicher auszuliefern und als Team weiter wachsen zu können.
Zehn Jahre Open Source und Community
Über all die Jahre waren und sind wir Teil der Foreman Community. Viele Diskussionen im Forum und im Chat, gemeinsames Arbeiten an Pull Requests auf GitHub und zahlreiche Begegnungen auf Konferenzen haben unsere Arbeit geprägt.
Die Zusammenarbeit mit der Community war dabei nie nur ein abstrakter Teil der Open-Source-Welt. Oft ging es um sehr konkrete Fragen: Warum verhält sich eine Komponente so? Wie lässt sich ein Fehler sauber beheben? Ist eine Änderung auch für andere Nutzer sinnvoll? Und wie kann eine Lösung so gestaltet werden, dass sie langfristig wartbar bleibt?
Ohne die Community wäre orcharhino heute nicht das Produkt, das es ist. Für jeden Codebeitrag, jedes konstruktive und manchmal auch kritische Review, jede Diskussion und jede Unterstützung bei schwierigen Problemen möchte ich mich herzlich bedanken.
Gleichzeitig haben wir über die Jahre viel Arbeit investiert, um aus diesen Open-Source-Grundlagen ein eigenständiges Enterprise-Produkt zu machen. Dazu gehört nicht nur unsere eigenen Entwicklungsleistung, sondern auch Release Engineering, Packaging, Qualitätssicherung, Dokumentation, und professioneller Support.
Gerade diese unsichtbaren Arbeiten machen aus technischer Funktionalität ein Produkt, auf das sich Kunden im täglichen Betrieb verlassen können.
Vom mitfinanzierten Projekt zum Kernprodukt
Anfangs wurde die Entwicklung von orcharhino durch das Consulting-Geschäft der ATIX mitfinanziert. Heute ist orcharhino das Kernprodukt des Unternehmens.
Diese Geschichte haben wir in den vergangenen zehn Jahren als Team gemeinsam geschrieben: mit den vielen langjährigen Entwicklern im Engineering, mit den Kollegen im Support, die jeden Tag ihr Bestes geben, um unsere Kunden zu unterstützen, und mit Marketing, Vertrieb und Consulting, die neue Anforderungen oft sehr früh erkennen und an uns herantragen.
Und natürlich auch mit Mark und Thomas, die uns in der Entwicklung mit so mancher Herausforderung dazu gebracht haben, eine Lösung noch einmal zu hinterfragen und besser zu machen.
Wenn ich heute auf die vergangenen Jahre zurückblicke, denke ich nicht nur an einzelne Releases oder Funktionen. Ich denke vor allem an viele kleine und große technische Entscheidungen, an lange Fehlersuchen, an Diskussionen über Architektur, an Pull Requests, die mehr Runden brauchten als erwartet, und an den Moment, wenn eine Lösung schließlich zuverlässig funktionierte.
Genau aus diesen vielen Schritten ist orcharhino zu dem geworden, was es heute ist.
Wie geht es weiter?
Mit der Unterstützung von OpenTofu für Compute Ressourcen und der Erweiterung um den Ansible Director haben wir neue Wege eingeschlagen. Beide Projekte haben viel Potenzial, und es bleibt spannend zu sehen, welchen Impact diese noch haben werden.
Auch digitale Souveränität, Containerisierung und künstliche Intelligenz werden orcharhino in Zukunft verändern. Für uns Entwickler bedeutet das, neue Technologien zu bewerten, bestehende Konzepte weiterzuentwickeln und dabei nicht aus den Augen zu verlieren, was Kunden im produktiven Betrieb wirklich benötigen.
Wahrscheinlich werden wir darüber bald auf einem Community-Event, beim nächsten orcharhino Summit oder spätestens zum 20. Geburtstag von orcharhino berichten.
Happy Birthday, orcharhino!
