Abby Kearns, CEO von ActiveState – Interview-Serie

Abby Kearns ist CEO von ActiveState und eine Technologie-Executive mit mehr als 25 Jahren Erfahrung im Aufbau und Skalieren von Unternehmenssoftware-Organisationen. Zuvor war sie CTO von Puppet, wo sie half, eine strategische Transformation zu leiten, die in der Übernahme des Unternehmens durch Perforce Software gipfelte. Früher in ihrer Karriere war sie CEO der Cloud Foundry Foundation, wo sie das Wachstum einer der größten Open-Source-Cloud-Plattform-Ökosysteme der Branche leitete. Abby ist derzeit Mitglied des Vorstands von Akka (früher Lightbend). Sie ist bekannt dafür, Unternehmen dabei zu helfen, große Verschiebungen in Cloud, Open Source und KI in klare Produktstrategie und Unternehmenswachstum umzusetzen.

ActiveState ist ein kanadisches Software-Unternehmen, das 1997 gegründet wurde und Unternehmens-Tools und -Plattformen für den Bau, die Verwaltung und die Sicherung von Open-Source-Software bereitstellt. Sein Kernangebot, die ActiveState-Plattform, hilft Entwicklung-, DevOps- und Sicherheitsteams dabei, Abhängigkeitsverwaltung zu automatisieren, Schwachstellen zu erkennen und zu beheben sowie sichere, reproduzierbare Entwicklungsumgebungen über mehrere Programmiersprachen wie Python, Perl und Tcl hinweg zu erstellen. Durch die Bereitstellung von vorab erstellten, verifizierten Open-Source-Komponenten und deren Integration in bestehende Workflows zielt ActiveState darauf ab, Sicherheitsrisiken in der Software-Lieferkette zu reduzieren und gleichzeitig die Produktivität von Entwicklern und die Anwendungs-Entwicklung zu beschleunigen.

Sie haben Ihre Karriere an der Schnittstelle von Open Source, Cloud-nativen Plattformen und Unternehmens-Transformation verbracht, von der Leitung der Cloud Foundry Foundation bis hin zur Position als CTO bei Puppet. Was hat Sie dazu bewogen, die Position des CEO bei ActiveState zu übernehmen, und was ist Ihre Vision für das Unternehmen in dieser nächsten Wachstumsphase?

Der rote Faden meiner Karriere war das Arbeiten an der Schnittstelle zwischen Community und Infrastruktur in Momenten, in denen die Branche Entscheidungen trifft, die sich über Jahre hinweg auswirken. Cloud Foundry war dieser Moment für Cloud-nativen. Puppet war dieser Moment für Konfigurationsverwaltung und die frühen Stadien dessen, was wir heute als DevSecOps bezeichnen. ActiveState ist dieser Moment für Open-Source-Governance.

Was mich hierher gezogen hat, ist ein Problem, das ich über eine lange Zeit hinweg beobachtet habe. Jedes Unternehmen, mit dem ich zu tun hatte, läuft auf Open Source. Die meisten von ihnen können nicht mit Sicherheit sagen, welche Open-Source-Software sie verwenden, ob sie gepatcht wurde oder wer für die Entscheidung verantwortlich ist, sie zu verwenden. Diese Lücke zwischen der Bedeutung von Open Source und der mangelnden Sorgfalt, mit der die meisten Organisationen Open Source regieren, ist der Ort, an dem sich das Risiko der Branche ansammelt. ActiveState hat zwanzig Jahre damit verbracht, die Infrastruktur aufzubauen, um diese Lücke zu schließen. Meine Aufgabe ist es, sicherzustellen, dass der Markt versteht, warum das Schließen dieser Lücke dringend ist.

Die Vision für diese nächste Phase ist klar: ActiveState wird zur Standardantwort auf die Frage, woher Unternehmens-Open-Source stammt. Nicht ein Scanner. Nicht ein Bericht. Eine vertrauenswürdige, verifizierte, kontinuierlich behandelte Quelle, auf die Organisationen verweisen können, wenn Regulierungsbehörden, Vorstände oder Reaktionsteams fragen, wie sie ihre Software-Lieferkette regiert haben.

ActiveState positioniert sich als kritische Schicht bei der Sicherung der Software-Lieferkette zu einer Zeit, in der KI die Code-Generierung beschleunigt. Wie verändert KI grundlegend das Risikoprofil von Open-Source-Software?

KI-gestützte Entwicklung bricht eine grundlegende Annahme, auf der die gesamte Open-Source-Governance-Toolkette aufbaut: dass ein Entwickler eine bewusste Entscheidung getroffen hat, eine Abhängigkeit einzubeziehen.

Jede SBOM-Richtlinie, jedes SCA-Tool, jedes Vulnerabilitäts-Management-Workflow geht davon aus, dass ein Mensch in der Schleife war, der diese Bibliothek gezogen hat. Wenn KI Code generiert, kommen Abhängigkeiten in die Produktion, die niemand ausgewählt, überprüft oder in vielen Fällen sogar weiß, dass sie dort sind. Die Governance-Tooling sucht nach Entscheidungen. KI macht Produktionsänderungen, die die Entscheidung vollständig umgehen.

Es gibt eine zweite Ebene dazu. Die Codierungstools, die die KI-Adoption vorangetrieben haben, die Produktivitätsbenchmarks, die Entwickler-Umfragen, die GitHub-Sterne, keines dieser Bewertungsframeworks hat Sicherheit als erste Maßnahme einbezogen. Die Branche hat sich auf Geschwindigkeit und Richtigkeit optimiert und die Infrastruktur ohne Sicherheitsabfrage ausgeliefert. Das ist kein Tooling-Fehler. Es ist ein Führungsfehler in der Entscheidungsfindung. Wir arbeiten jetzt im großen Maßstab auf einer Grundlage, die nie auf das Risiko hin bewertet wurde, das sie einführt.

Sie haben gesagt, dass unregulierte Open-Source-Software zu einer großen Unternehmens-Schwachstelle wird. Warum steigt Open-Source-Governance jetzt auf die Vorstandsebene, und was unterschätzen Führungskräfte noch?

Es erreicht den Vorstand, weil die regulatorische Umgebung die Rechenschaftspflicht-Struktur geändert hat. Die EU-Cyber-Resilience-Verordnung, die Offenlegungsanforderungen der SEC, die Secure-by-Design-Richtlinie von CISA: Diese Rahmenwerke verschieben die Frage von “Hatten Sie einen Scanner?” zu “Können Sie beweisen, dass Ihre Software sicher war, als sie ursprünglich erstellt wurde?” Das sind sehr unterschiedliche Fragen, und die meisten Organisationen können die zweite Frage nicht beantworten.

Was Führungskräfte noch unterschätzen, ist, dass dies ein strukturelles Problem ist, kein Ressourcenproblem. Die Organisationen, die auf Open-Source-Risiken reagieren, indem sie mehr Scanning-Tools hinzufügen, lösen das zugrunde liegende Problem nicht. Scanning erkennt Probleme, nachdem sie in die Umgebung eingetreten sind.

Wenn alles gekennzeichnet ist, wird nichts priorisiert, und der Umfang der Warnungen wird zu einer eigenen operativen Dysfunktion. Die Organisationen, die dies erfolgreich meistern, sind nicht diejenigen, die mehr Tools kaufen. Sie sind diejenigen, die ändern, wie sie Entscheidungen über Open Source treffen, das in ihre Umgebung eintritt, und wer für diese Entscheidungen verantwortlich ist.

Wie sollten Organisationen Open Source als Infrastruktur und nicht nur als Entwicklungskomfort neu denken, da Open Source nun in den meisten Unternehmens-Software-Stacks eingebettet ist?

Das mentale Modell, mit dem die meisten Organisationen arbeiten, ist zehn Jahre alt. Open Source begann als Entwicklungskomfort. Entwickler konnten Bibliotheken ziehen, schneller vorankommen und grundlegende Komponenten nicht neu erfinden. Diese Rahmenbedingung machte Sinn, als Open Source optional und ergänzend war.

Diese Realität ist nicht mehr gegeben. Open Source ist die Grundlage moderner Software. 96 Prozent der Anwendungen enthalten Open-Source-Komponenten. Es ist kein Komfortlayer auf top von proprietärer Infrastruktur. Es ist die Infrastruktur. Und Infrastruktur muss wie Infrastruktur regiert werden, mit expliziten Richtlinien darüber, was in die Umgebung eintritt, definiertem Eigentum für Wartung und Behebung und Verantwortlichkeit, die auf der richtigen Ebene der Organisation sitzt.

Die Organisationen, die auf diesem Gebiet vorne liegen, haben eine bewusste Verschiebung vorgenommen: Open-Source-Konsum ist eine strategische Entscheidung mit Sicherheits- und finanziellen Konsequenzen, nicht eine Standard-Einstellung, die Entwickler individuell verwalten. Diese Verschiebung erfordert Richtlinien, operative Prozesse und klare Vorstands-Verantwortlichkeit. Die meisten Organisationen haben diese Verschiebung noch nicht vorgenommen.

Sie haben Organisationen durch mehrere Technologiewellen geführt. Wie vergleicht sich die aktuelle KI-getriebene Verschiebung mit früheren Übergängen wie Cloud und DevOps in Bezug auf Geschwindigkeit und Störung?

Die aktuelle KI-getriebene Bewegung ist sehr ähnlich wie frühere technologische Verschiebungen. Als Cloud als Liefermodell auftrat, machten die Organisationen, die es als reine Technologieentscheidung behandelten, sehr unterschiedliche Fehler als die Organisationen, die es als architektonische und operative Verschiebung erkannten. Diejenigen, die den Governance-Übergang nicht vollzogen, zahlten dafür über Jahre hinweg mit Schatten-IT, Kostenüberschreitungen und Sicherheits- und technischer Schulden.

Was anders ist an der aktuellen KI-getriebenen Verschiebung, ist die Geschwindigkeit und die Unsichtbarkeit. Cloud-Adoption war sichtbar. Man wusste, wenn die Organisation Workloads von On-Premises in die Cloud verlagerte. DevOps war sichtbar: Organisationen restrukturierten Teams, änderten Deployment-Pipelines und schrieben Prozesse neu. KI-Coding-Tools werden von Entwickler zu Entwickler, von Tool zu Tool, adoptiert, und das Risiko sammelt sich in der Codebasis, bevor die meisten Organisationen registriert haben, dass eine Governance-Entscheidung getroffen wurde.

Die Störung ist auch asymmetrisch auf eine Weise, die Cloud und DevOps nicht waren. Diese Übergänge schufen neue Kategorien von Risiken, aber bewahrten im Wesentlichen die Annahme, dass ein Mensch für den Code verantwortlich war, der ausgeliefert wurde. KI untergräbt diese Annahme an dem Punkt, an dem es am schwersten zu erkennen ist. Das macht diesen Übergang unterschiedlich. Die Exposition ist unsichtbar, bis sie es nicht mehr ist.

Viele Unternehmen kämpfen darum, Open-Source-Adoption in ein nachhaltiges Geschäftsmodell umzuwandeln. Was unterscheidet Unternehmen, die erfolgreich sind, von denen, die scheitern?

Die Organisationen, die nachhaltige Geschäfte auf Open Source aufgebaut haben, teilen eine Eigenschaft: Sie sind diszipliniert darin, was sie tatsächlich verkaufen. Sie verkaufen nicht die Open-Source-Software, die kostenlos ist. Sie verkaufen die Expertise, den operativen Support, die Governance-Infrastruktur oder den Managed-Service, der die kostenlose Software auf Unternehmens-Niveau tragbar macht.

Im Gegensatz dazu neigen Organisationen, die scheitern, dazu, Community-Adoption mit kommerziellem Zugriff zu verwechseln. Sie sind nicht dasselbe. Eine hohe GitHub-Sterne-Zahl oder eine große Community signalisiert, dass Entwickler das Projekt nützlich finden. Es signalisiert nicht, dass Käufer dafür bezahlen werden oder dass das, was Entwickler nützlich finden, das ist, was Organisationen tatsächlich benötigen. Die Übersetzung von Entwickler-Adoption in Unternehmens-Wert erfordert das Aufbauen von etwas, das über die Open-Source-Software selbst hinausgeht, und die Organisationen, die diese Unterscheidung nicht klar in ihrer Positionierung, ihrem Produkt und ihrer Vertriebsbewegung treffen, neigen dazu, den Übergang zum Maßstab nicht zu überleben.

Aus Ihrer Erfahrung mit der Skalierung von Entwickler-erster Organisationen, was sind die größten Führungs-Herausforderungen beim Übergang von Produkt-geführtem Wachstum zu Unternehmens-Operationen im großen Maßstab?

Die größte Herausforderung ist, dass die Fähigkeiten und Instinkte, die zum Erfolg im Produkt-geführten Wachstum geführt haben, gegen Sie arbeiten, wenn es um Unternehmens-Operationen im großen Maßstab geht. Produkt-geführtes Wachstum belohnt schnelles Handeln, Iteration im öffentlichen Raum, Optimierung für Entwickler-Erfahrung und das Zulassen, dass Adoption die kommerzielle Bewegung leitet. Unternehmens-Verkäufe belohnen bewussten Prozess, exekutive Beziehungen, lange Zyklen und die Fähigkeit, Ihr Produkt auf Ergebnisse zu kartieren, die für Käufer zählen, die keine Entwickler sind.

Der Führungsfehler, den ich am häufigsten sehe, ist die Annahme, dass der Übergang in erster Linie ein Vertriebs-Problemm ist. Es ist kein Vertriebs-Problemm. Es ist ein Organisations-Design-Problemm. Das Team, das das Produkt, die Positionierung und die frühen Kundenbeziehungen aufgebaut hat, ist oft nicht das Team, das den Unternehmens-Übergang ausführen kann. Das Erkennen dessen, ohne zu verlieren, was das Produkt wertvoll gemacht hat, ist wirklich schwierig. Die Führungskräfte, die es gut machen, sind diejenigen, die ehrlich darüber sind, welche Teile der Organisation evolvieren müssen, und die neue Fähigkeiten aufbauen, ohne die Kultur zu demontieren, die das Produkt erschuf.

Sie haben umfassend an der Schnittstelle von Sicherheit und Entwickler-Produktivität gearbeitet. Wie können Unternehmen Geschwindigkeit und Innovation mit der wachsenden Notwendigkeit von sicherer, vertrauenswürdiger Software ausgleichen?

Die Darstellung von Geschwindigkeit versus Sicherheit ist eine falsche Wahl, die wegen der Tooling aufrechterhalten wurde. Wenn Sicherheit als Überprüfungstor am Ende des Entwicklungsprozesses implementiert wird, ist es ein Flaschenhals. Wenn es als regierte Quelle von vertrauenswürdigen Komponenten implementiert wird, die Entwickler am Anfang des Prozesses ziehen, verlangsamt es nichts.

Diejenigen, die diese Spannung aufgelöst haben, haben es getan, indem sie den Ort verändert, an dem Sicherheit passiert. Nicht Code überprüfen, nachdem er geschrieben wurde. Nicht Artefakte scannen, nachdem sie gebaut wurden. Regieren, was in den Katalog kommt, den Entwickler und KI-Tools ziehen. Wenn die Quelle vertrauenswürdig ist, ist die Geschwindigkeit nicht durch die Sicherheitsüberprüfung eingeschränkt, weil die Sicherheitsarbeit stromaufwärts passierte. Das ist eine architektonische Entscheidung, keine kulturelle. Es erfordert Investitionen in die Governance-Infrastruktur, aber es erfordert nicht, zwischen schnellem Handeln und sicheren Auslieferungen zu wählen.

Wie sehen Sie die Rolle von kuratierten oder vertrauenswürdigen Open-Source-Ökosystemen in den nächsten Jahren, da KI-Tools immer mehr Code und Abhängigkeiten generieren?

Die Rolle von kuratierten, vertrauenswürdigen Open-Source-Quellen wird von einer bewährten Praxis zu einer Grundanforderung wechseln. Dieser Wechsel wird durch zwei Dinge getrieben, die nicht umkehrbar sind.

Das erste ist die regulatorische Umgebung. Im Landschaftsbild von 2026 ist es zunehmend eine gesetzliche Anforderung, Software-Herkunft nachweisen zu können, nicht ein freiwilliger Standard. Vorstände und Regulierungsbehörden stellen Fragen, die Organisationen nicht beantworten können.

Das zweite ist die KI-Entwicklungs-Geschwindigkeit. Wenn KI-Tools mehr Code und Abhängigkeiten generieren, wird der Umfang von unüberprüften Komponenten, die in die Produktion gelangen, die Fähigkeit jeder Organisation übersteigen, sie manuell zu überprüfen. Die Organisationen, die eine kuratierte, politik-gesteuerte Sammlung als Standard-Quelle für ihre Entwickler und KI-Tools eingerichtet haben, werden in der Lage sein, die Geschwindigkeit von KI mit angemessener Sicherheits-Governance zu kombinieren. Die Organisationen, die immer noch auf öffentliche Registrierungen und manuelle Überprüfung angewiesen sind, werden eine wachsende Lücke zwischen der Geschwindigkeit, mit der Code generiert wird, und der Gründlichkeit, mit der er bewertet wird, erleben.

Curatierte Ökosysteme sind die Infrastruktur-Antwort auf ein Problem, das KI-Entwicklung unvermeidlich gemacht hat.

Als eine der wenigen weiblichen CEOs im Open-Source- und Infrastruktur-Bereich, welche Veränderungen haben Sie im Laufe der Jahre in der Führungs-Diversität gesehen, und was muss noch verbessert werden?

Es gab echte Veränderungen. Als ich meine Karriere begann, war die Repräsentation von Frauen in Führungspositionen im Open-Source- und Infrastruktur-Bereich so gering, dass die Ausnahmen bemerkenswert waren. Das ist jetzt weniger der Fall. Es gibt mehr Frauen in leitenden technischen und Führungspositionen, mehr Organisationen, die über die Phase der Diversity-Statements hinausgegangen sind und strukturelle Veränderungen vornehmen, und mehr Modelle dafür, wie Führung in diesem Bereich aussehen kann.

Der Geschäftsfall für das Schließen der verbleibenden Lücke ist nicht abstrakt. Die Probleme, an denen diese Branche derzeit arbeitet, Software-Lieferkettensicherheitsrisiko, KI-Governance, die organisatorischen Veränderungen, die erforderlich sind, um Sicherheit zu einer ersten Praxis zu machen, sind schwierige Probleme. Diverse Teams produzieren bessere Ergebnisse bei schwierigen Problemen. Nicht als eine Frage des Strebens, sondern als eine Frage davon, wie unterschiedliche Perspektiven Annahmen ans Licht bringen, die homogene Teams verpassen. Ich habe dies direkt gesehen. Die Organisationen, die echte Fortschritte bei Zugehörigkeit, nicht nur Repräsentation, gemacht haben, sind diejenigen, bei denen dieser betriebliche Vorteil in der Arbeit sichtbar wird.

Zugehörigkeit ist immer noch ungleichmäßig in der Branche verteilt. Im Raum zu sein ist nicht dasselbe wie eine echte Berücksichtigung der Perspektive. Diese Unterscheidung ist der Ort, an dem die nächste Phase des Fortschritts stattfinden muss.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten ActiveState besuchen ActiveState.