Robocorp verlässt Robot Framework — Kein Qualitätsurteil

TL;DR: Robocorp war Hauptsponsor der Robot Framework Foundation. Im Januar 2024 wurde das Unternehmen vom KI-Startup Sema4.ai übernommen und erklärte RF für deprecated — Begründung: Python sei für KI-Agenten besser geeignet. Der Schritt war ein strategischer Pivot von RPA zu KI-Agenten, kein Qualitätsurteil über RF als Test-Framework. Die RF Foundation hat den Verlust überstanden und ist mit über 60 Mitgliedsorganisationen breiter aufgestellt als zuvor.

Lesedauer ca. 10 Min · Stand: 2026-04

Anfang 2024 hat Robocorp Robot Framework auf seiner Plattform für deprecated erklärt. Für Enterprise-Teams, die RF als Testautomatisierungs-Framework einsetzen, stellte sich die Frage: Wenn der Hauptsponsor abspringt, wie tragfähig ist das Ökosystem dann noch? Die Antwort verlangt eine Trennung zwischen Robocorps Geschäftsentscheidung und der Substanz des Frameworks.

Chronologie des Abgangs

Am 29. Januar 2024 gab Robocorp die Übernahme durch das neu gegründete KI-Startup Sema4.ai bekannt. Rob Bearden, zuvor CEO von Cloudera, führte das neue Unternehmen. Zwei Wochen später, am 15. Februar 2024, veröffentlichte Robocorp eine Deprecation-Seite unter dem Titel «Embracing Python for Automation-as-Code». Robot Framework wurde auf der Robocorp-Plattform offiziell für deprecated erklärt. Im ersten Quartal 2024 folgte das Rebranding: VS Code Extension und Action Server liefen unter dem neuen Namen Sema4.ai. Die Domain robocorp.com leitet heute auf sema4.ai weiter.

Datum	Ereignis
01/2024	Übernahme durch Sema4.ai
02/2024	RF-Deprecation auf Robocorp-Plattform
Q1 2024	Rebranding VS Code Extension → Sema4.ai
06/2024	Weitere 25 Mio. USD Finanzierung (u.a. Snowflake Ventures)
2025	robocorp.com leitet auf sema4.ai weiter

Robocorp war seit 2020 Hauptsponsor der RF Foundation und damit der grösste kommerzielle Akteur im RF-Ökosystem. Der Weggang betraf nicht nur finanzielle Unterstützung, sondern auch zentrale Tooling-Infrastruktur.

Robocorps Begründung im Detail

Die Deprecation-Seite nannte vier Argumente für den Wechsel zu reinem Python.

Pythons Ökosystem. Das Package-Ökosystem von Python sei dem von RF an Breite und Entwicklungsgeschwindigkeit überlegen. Jede Python-Library stehe direkt zur Verfügung, ohne den Umweg über eine RF-Keyword-Library.

LLM-Kompatibilität. LLMs wie ChatGPT verstünden Python besser als RF-Syntax. Das beschleunige die KI-gestützte Entwicklung von Automatisierungen.

Abstraktionsschicht entfällt. RF sei ein «unnötiger Wrapper» über Python. Die zusätzliche Abstraktionsschicht erzeuge Overhead ohne konkreten Nutzen.

Entwickler-Verfügbarkeit. Python-Entwickler seien um ein Vielfaches zahlreicher als RF-Spezialisten. Für Unternehmen erleichtere das die Skalierung von Automatisierungsteams.

CEO Antti Karjalainen positionierte Python als Sprache der Wahl für KI-Agenten-Entwicklung.

Was diese Argumente treffen und was nicht

Die Argumente sind im Kontext von Robocorps neuem Geschäftsmodell nachvollziehbar. Sema4.ai baut Enterprise-KI-Agenten, keine Testautomatisierung. Für KI-Agenten ist Python die natürliche Wahl. Die RF-Abstraktionsschicht erzeugt dort tatsächlich Overhead.

Für Testautomatisierung tragen die Argumente weniger. Die «unnötige Abstraktionsschicht» ist genau das, was RF als Testbeschreibungsformat wertvoll macht: die Trennung von fachlicher Testbeschreibung und technischer Implementierung. Die LLM-Kompatibilität von Python bezieht sich auf Code-Verständnis, nicht auf fachliche Semantik. Und die Entwickler-Verfügbarkeit ist irrelevant, wenn Fachtester die Tests schreiben und nur die Keyword-Libraries Python-Kenntnisse erfordern.

Was Sema4.ai heute macht

Das Unternehmen fokussiert Enterprise-KI-Agenten für Finanzworkflows, SAP-Automatisierung und wissensbasierte Arbeit. Die Finanzierung beläuft sich auf 30,5 Mio. USD (Benchmark, Mayfield, Canvas Ventures) plus weitere 25 Mio. USD im Juni 2024, darunter Snowflake Ventures.

Der Pivot war fundamental: weg von RPA (Robotic Process Automation), hin zu autonomen KI-Agenten. In diesem Geschäftsmodell ist RF tatsächlich fehl am Platz. KI-Agenten brauchen maximale programmatische Flexibilität, nicht keyword-getriebene Testbeschreibung. Die Entscheidung gegen RF war eine Entscheidung für ein anderes Geschäftsfeld, nicht gegen ein Test-Framework.

Konsequenzen für das RF-Ökosystem

Robot Framework Language Server

Die grösste technische Konsequenz betrifft das IDE-Tooling. Robocorp hatte den RF Language Server für VS Code entwickelt und gepflegt. Dieser wurde auf RF-6-Stand eingefroren. RF 7 wird nicht unterstützt (GitHub Issue #1051). Neue Syntax-Konstrukte wie VAR, GROUP oder Secret Variables erhalten keine IDE-Unterstützung im Robocorp-LSP.

Die Community ist auf RobotCode umgestiegen, eine Alternative von Daniel Biehl. RobotCode unterstützt RF 7.x und wird aktiv weiterentwickelt. Der Wechsel war für die meisten Teams unkompliziert, erforderte aber eine bewusste Entscheidung und Migration.

Community-Reaktion

Die Reaktionen in der Community waren gemischt. Auf Hacker News fanden sich kritische Stimmen, die RF grundsätzlich als «unnötige Abstraktionsschicht» infrage stellten. Ein vielzitierter Kommentar bringt es auf den Punkt: Am Ende wäre es einfacher gewesen, die Tests direkt in einer Programmiersprache zu schreiben, statt eine Abstraktionsschicht zu verwenden, die keinem Zweck diente. Im RF-Forum war die Reaktion überwiegend pragmatisch: Fokus auf Alternativen zum Robocorp-Tooling, Unterstützung für RobotCode, Bestätigung der Foundation-Finanzierung.

Die Kritik an der RF-Abstraktionsschicht spiegelt eine Position wider, die vor allem bei reinen Entwicklerteams ohne Fachtester auftritt. In diesen Teams schreiben Entwickler sowohl den Produktionscode als auch die Tests. Eine zusätzliche DSL über Python erzeugt dort tatsächlich Overhead, weil alle Beteiligten Python beherrschen. In Teams, in denen Fachtester oder Business-Analysten Tests lesen und mitgestalten, ist die Abstraktionsschicht dagegen der zentrale Nutzen.

Auswirkungen auf die Werkzeugkette

Neben dem Language Server betraf der Abgang weitere Teile der Werkzeugkette. Die Robocorp-Cloud-Plattform für die Orchestrierung von RF-basierten RPA-Bots fiel weg. Robocorps Python-Packages (rpaframework, robocorp) wurden auf Wartungsmodus gesetzt. Teams, die Robocorps Tooling im RPA-Kontext nutzten, mussten auf Alternativen umsteigen.

Für Teams, die RF als Testautomatisierungs-Framework einsetzen (nicht als RPA-Plattform), waren die Auswirkungen überschaubar. Die Kern-RF-Packages (robotframework, robotframework-seleniumlibrary, robotframework-requests etc.) werden unabhängig von Robocorp/Sema4.ai gepflegt. RobotCode als IDE-Extension deckt den Language-Server-Bedarf ab. Die Testausführung erfolgt über die RF-Engine, die von der Foundation finanziert und von Pekka Klärck entwickelt wird.

Die RF Foundation nach Robocorp

Die Robot Framework Foundation hat den Verlust des Hauptsponsors nicht nur überstanden, sondern sich konsolidiert. Über 60 Mitgliedsorganisationen tragen die Finanzierung, darunter KONE, Cisco, Finnair, Deutsche Post, DB Schenker, Capgemini und Eficode. Der Slack-Workspace hat über 33’000 Mitglieder. Die RFCP-Zertifizierung (Robot Framework Certified Professional) etabliert einen formalen Qualifikationsnachweis. Jährliche RoboCon-Konferenzen fanden 2024, 2025 und 2026 in Helsinki statt.

Pekka Klärck bleibt als von der Foundation finanzierter Lead-Entwickler die zentrale Figur. Executive Director Miikka Solmela formulierte im Juli 2025: Die Foundation sei gewachsen und habe sich als Beispiel für nachhaltige Open-Source-Finanzierung bewährt, ohne den Kern zu verkaufen.

Die breite Mitgliederbasis ist ein Vorteil gegenüber der früheren Konstellation mit einem dominanten Sponsor. Kein einzelnes Unternehmen kann durch seinen Abgang das gesamte Ökosystem destabilisieren. Die Finanzierung verteilt sich auf Mitgliedsbeiträge, Sponsoring der RoboCon-Konferenz und Schulungslizenzen für die RFCP-Zertifizierung.

Die RoboCon 2026 zeigt die inhaltliche Ausrichtung: Der Ecosystem-Track fokussiert auf IBM MQ, DatabaseLibrary-Updates und Performance-Testing. Backend-Szenarien, die in der öffentlichen Community-Diskussion bisher kaum sichtbar waren, rücken in den Vordergrund. Ein eigener Track widmet sich der Integration von KI in RF-basierte Testautomatisierung, darunter KI-gestützte SAP-Automatisierung bei einer deutschen Grossbank (Accenture-Vortrag).

RF-Roadmap: Version 7.x und der Weg zu 8.0

Robot Framework befindet sich in einer produktiven Phase. Seit Januar 2024 wurden sechs Feature-Releases veröffentlicht (7.0 bis 7.4.2), etwa ein Release alle sechs Monate.

Neue Features in der 7.x-Reihe

Die wichtigsten Neuerungen umfassen die native VAR-Syntax (7.0), ein überarbeitetes Listener-Interface (7.0), JSON als Ausgabeformat (7.0/7.2), die GROUP-Syntax zum Gruppieren von Keywords (7.2), Variable Type Conversion (7.3), Secret Variables (7.4) und offizielle Python-3.14-Kompatibilität (7.3). Python 3.6 und 3.7 wurden mit RF 7.0 abgekündigt.

Status von Set Variable und VAR

Set Variable, Set Suite Variable, Set Test Variable und Set Global Variable sind «weich deprecated». Der BuiltIn-Library-Quellcode verweist auf die VAR-Syntax als empfohlene Alternative. Der Robocop-Linter warnt mit Regel DEPR05. Eine formale Entfernung ist nicht angekündigt. Alle vier Keywords funktionieren in RF 7.4.2 unverändert.

Für Teams, die RF als reines Testbeschreibungsformat einsetzen, bleibt Set Variable eine valide Option. Der Wechsel zu VAR bietet Vorteile (Performance, Typkonvertierung, konsistentere Syntax), ist aber nicht erzwungen.

RF 8.0

Für die nächste Major-Version sind bisher bestätigt: Entfernung des [Return]-Settings (ersetzt durch RETURN-Statement seit RF 7.0), Entfernung von Force Tags/Default Tags, JSON-Output während der Testausführung und Änderungen am Any-Typ-Verhalten. Ein fester Releasetermin existiert nicht. Die Foundation hat RF 8.0 zugunsten weiterer 7.x-Feature-Releases verschoben.

Die Verschiebung zeigt eine bewusste Priorität: Stabilität und inkrementelle Verbesserungen vor grossen Breaking Changes. Für Enterprise-Teams, die auf langfristige API-Stabilität angewiesen sind, ist das ein positives Signal. Die 7.x-Linie liefert Funktionalität, ohne bestehende Test-Suiten zu brechen.

Einordnung für Enterprise-Entscheider

Die Frage, die in Entscheidungsgremien gestellt wird: Wenn der Hauptsponsor abspringt, ist das Framework dann noch zukunftsfähig?

Drei Faktoren sprechen dafür, dass der Robocorp-Abgang das RF-Ökosystem nicht gefährdet.

Die Foundation ist diversifiziert: über 60 Mitglieder aus sieben Ländern. Keine Einzelabhängigkeit mehr. KONE, Cisco, Deutsche Post, Capgemini und dutzende weitere Unternehmen tragen die Entwicklung. Die Finanzierung ist breiter aufgestellt als vor Robocorps Abgang.

Die Entwicklung läuft aktiv. Sechs Releases in zwei Jahren. Python-3.14-Support. JSON-Output. Secret Variables. Pekka Klärck arbeitet vollzeit an RF, finanziert durch die Foundation. Das ist kein Wartungsmodus, sondern aktive Weiterentwicklung.

Der Abgangsgrund betrifft ein anderes Geschäftsfeld. Robocorp/Sema4.ai baut KI-Agenten, nicht Testautomatisierung. Die Entscheidung gegen RF war eine Entscheidung für ein Produkt, in dem ein Test-Framework keinen Platz hat. Wer RF als Test-Framework einsetzt, ist von diesem Pivot nicht betroffen.

Die eigentliche Lehre

Robocorps Kritik an der «unnötigen Abstraktionsschicht» enthält einen Kern, der ernst genommen werden sollte. Wer RF als Programmiersprache missbraucht (mit IF/ELSE, Schleifen und Inline-Python auf Testfallebene), erzeugt tatsächlich eine unnötige Abstraktionsschicht über Python. In diesem Fall ist reines Python die bessere Wahl. Das war im Wesentlichen Robocorps Erfahrung im RPA-Kontext: Die RF-Syntax stand zwischen den Automatisierern und der Aufgabe.

Wer RF dagegen konsequent als Testbeschreibungsformat nutzt, mit Keywords und Variablen auf Testfallebene und aller Logik in Python-Libraries, nutzt genau den Vorteil, den kein reines Python-Framework bietet: fachlich lesbare Tests, die Tester, Product Owner und Entwickler gleichermassen verstehen.

Die Frage ist also nicht «Robot Framework oder Python». Die Frage ist: Wie wird RF eingesetzt? Als Programmiersprache scheitert es an Python. Als Testbeschreibungsformat ist es Python überlegen. Robocorps Abgang bestätigt die erste Hälfte dieser Aussage. Die zweite Hälfte bestätigen Enterprise-Teams, die RF seit über einem Jahrzehnt für genau diesen Zweck einsetzen.

Risikobewertung für laufende Projekte

Für Teams, die RF bereits im Einsatz haben, ergibt sich folgendes Risikoprofil:

Geringes Risiko: RF als Testautomatisierungs-Framework mit Python-Keywords. Die Foundation finanziert die Entwicklung, Pekka Klärck arbeitet vollzeit, die Release-Kadenz liegt bei zwei bis drei Releases pro Jahr. Python-Kompatibilität wird aktiv sichergestellt (3.14-Support in RF 7.3).

Mittleres Risiko: RF mit Robocorp-spezifischem Tooling (Robocorp Lab, Robocorp Cloud, rpaframework). Diese Werkzeuge werden nicht mehr aktiv weiterentwickelt. Migration auf Community-Alternativen (RobotCode, eigene CI/CD-Integration) ist nötig.

Hohes Risiko: RF als Programmiersprache ohne Python-Unterbau in komplexen Szenarien. Genau das Szenario, das Robocorp als problematisch identifiziert hat. Hier lohnt sich die Frage, ob eine Architekturbereinigung (Python-Libraries für Logik, RF nur auf Testfallebene) oder ein Wechsel zu reinem Python die bessere Investition ist.

Der Unterschied liegt nicht im Framework. Er liegt in der Architektur.

Quellen

Sie überprüfen RF in einem laufenden Projekt nach dem Robocorp-Abgang? Im UTAA-Workshop bewerten wir Architektur, Tooling und Migrations-Pfad projektspezifisch. Mehr zur Methode oder direkt anfragen.