Wie Osiris tatsächlich entsteht
Osiris entsteht durch einen einzelnen Entwickler mit KI-Unterstützung, in einer automatisierten Umsetzen-Prüfen-Korrigieren-Schleife, die läuft, bis Tests und eine schriftliche Spezifikation beide bestehen, nicht in einem Schuss generiert.
Osiris wird von Lucas Flores gebaut, einem IT-Systemtechniker und Inhaber eines kleinen Managed Service Providers bei Köln, kein Berufsentwickler. Der Code entsteht mit KI-Unterstützung (Claude), mit seinem eigenen Verständnis von Exchange, Graph und Speichersystemen, und mit einer Testdisziplin, die bei einem Backup-Werkzeug nicht verhandelbar ist. Wenn Sie das lesen und denken, das klingt nach einem Risiko, liegen Sie damit richtig; diese Seite ist der Beleg dafür, warum wir es für ein handhabbares Risiko halten. Kein Grund, blind zu vertrauen.
Ingenieure lassen sich nicht davon abbringen zu fragen, wie Software tatsächlich entsteht, und sie sollten auch nicht das Wort einer Marketingseite dafür nehmen müssen. Hier ist also der Prozess, mit echten Zahlen aus der aktuellen Beta, nicht die allgemeine Aussage, dass „KI uns hilft, schneller zu bauen“.
Die Loop, konkret
Jede Funktion durchläuft dieselbe Abfolge, und das ist kein Ein-Schuss-Verfahren: ein Agent implementiert sie gegen eine schriftliche Spezifikation, und ein separater Review-Durchgang prüft das Ergebnis gegen diese Spezifikation und gegen die automatisierte Testsuite (Lint, Typprüfung, und die Tests, tatsächlich gegen eine PostgreSQL-Datenbank ausgeführt, nicht gemockt). Schlägt eine Prüfung fehl, geht die Arbeit für eine weitere Runde zurück. Es gibt keine feste Rundenzahl; es wiederholt sich, bis die Prüfungen bestehen oder ein Mensch stoppt.
Konkret, aus dem jüngsten abgeschlossenen Durchgang über die Beta (intern „Iteration 1“): 12 Funktionen wurden gebaut und angenommen, und 13 separate, vom Review-Schritt aufgeworfene Probleme wurden vor der Veröffentlichung behoben: nicht 13 trotzdem ausgelieferte fehlerhafte Funktionen, sondern 13 Runden „das trägt noch nicht, beheben“, bevor das Tag hinausging. Die vollständige automatisierte Suite, die vor jedem Release grün bestehen muss, umfasst zum aktuellen Release (0.303.0): 4.168 Tests insgesamt, darunter 536 dedizierte PostgreSQL-Integrationstests über 45 Testdateien, die echtes Datenbankverhalten prüfen (Row-Level-Security, Migrationen, nebenläufige Jobs), das eine gemockte Datenbank verdecken würde. Diese Zahlen ändern sich mit jedem Release: Hier steht der Stand der letzten Aktualisierung dieser Seite, keine feste Behauptung. Der Produktions-Build wird zudem beim tatsächlichen Start in einem echten Browser geprüft, nicht nur angenommen, weil der Entwicklungsserver funktioniert.
Was ein Mensch tatsächlich tut
Die Loop entscheidet nicht allein, was gebaut oder ausgeliefert wird. Lucas setzt Prioritäten, genehmigt alles, was die Architektur, die Lizenzierung oder rechtliche Formulierungen des Produkts ändert, bevor es gebaut wird (nicht danach), und kann eine ganze Iteration anhalten, bis er zugestimmt hat. Zum Zeitpunkt der letzten Aktualisierung dieser Seite ist die nächste Iteration pausiert und startet planmäßig, nachdem das aktuelle Release erschienen ist. Entscheidungen mit rechtlichem oder finanziellem Gewicht (Preise, Lizenzbedingungen, was eine Funktion über GoBD-Konformität behaupten darf) sind seine Entscheidungen, protokolliert und datiert, nicht etwas, das ein Agent ableitet.
Wenn trotzdem etwas schiefgeht
Das ist passiert. Ein datiertes Beispiel, denn „wir testen alles“ ist ohne eines nicht viel wert: ein früher Beta-Release lieferte einen Produktions-Build aus, der in einem echten Browser eine leere Seite anzeigte, verursacht durch eine zirkuläre Abhängigkeit zwischen JavaScript-Chunks, die der Entwicklungsserver nie zutage förderte. Es wurde entdeckt, und ein Hotfix-Release noch am selben Tag behob sowohl den unmittelbaren Fehler als auch den Build-Prozess selbst, sodass er künftig bei einem zirkulären Chunk laut fehlschlägt, statt still wieder einen auszuliefern. Das ist der Maßstab, an dem wir uns messen: wenn etwas durchrutscht, gehört zur Behebung, dass genau dieser Fehler künftig nicht mehr still passieren kann.
Warum das bei einem Backup-Werkzeug mehr zählt als bei den meisten Programmen
Ein Fehler in einem Backup-Produkt verhält sich nicht nur falsch: Er kann bedeuten, dass Daten, die Sie für sicher hielten, es nicht sind. Deshalb behandelt Osiris „Restore tatsächlich getestet“ als das Produkt, nicht als Feature: ein Backup, das nie über den Restore-Pfad zurückgelesen wurde, wird als unbewiesen angezeigt, nicht als erledigt. Das Projekt definiert eine Release-Checkliste, die über die eigenen Tests der Build-Loop hinausgeht: Migrationen sowohl gegen ein Upgrade als auch gegen eine Neuinstallation, Health- Endpunkte, ein vollständiger Backup-und-Restore-Lauf mit Byte-für-Byte-Hash-Vergleich gegen einen echten Microsoft-365-Mandanten und einen echten IMAP-Server, ein Restore, nachweislich mit dem eigenständigen Restore-Werkzeug ganz ohne laufenden Osiris-Server geprüft, jedes unterstützte Speicherziel beschrieben, gelesen und gescrubbt, sowie ein Container-Schwachstellen-Scan. Stand 0.303.0 laufen davon nur die Abhängigkeitsprüfung und die PostgreSQL-Testsuiten automatisch in der CI; die Prüfungen gegen echten Mandanten, echten IMAP-Server, das eigenständige Restore-Werkzeug, die Speicherziele und den Image-Scan sind noch nicht automatisiert, und noch kein Release wurde gegen einen echten Microsoft-365-Mandanten getestet. Bisher liefen Tests gegen simulierte Graph-/IMAP-Server. Der Abschnitt „Verification“ im Changelog jedes Releases nennt genau, was für dieses Release tatsächlich gelaufen ist, nicht, was die Checkliste irgendwann abdecken soll.
Open Source, damit Sie uns nichts davon glauben müssen
Der Kern (Backup, Restore, das Audit-Log) ist AGPL-3.0 (mit Plugin-Ausnahme); die Module für Business und Service Provider sind als eigenständiger, proprietärer Code geplant, der per Lizenzschlüssel freigeschaltet wird, kein anderes Offenheitsversprechen für dieselbe Sache. Das Repository untergithub.com/lcsfls/osirisenthält heute die Lizenz und die Projektbeschreibung; der Quellcode selbst erscheint mit dem ersten öffentlichen Release, bis dahin läuft die Entwicklung in einem privaten Repository. Das wird hier klar gesagt, statt etwas anderes durch einen Link nahezulegen, der weiter fortgeschritten wirkt, als er ist. Sobald es öffentlich ist, können Sie die oben beschriebenen Tests, die Restore-Nachweise und das Speicherformat selbst prüfen, statt dieser Seite zu vertrauen. Siehe Open Source für die Lizenzdetails, einschließlich der Begründung, warum der Schlüssel der bezahlten Editionen ein Fair-Play-Mechanismus ist und kein DRM.
Sehen Sie, was dieser Prozess bisher tatsächlich ausgeliefert hat →