Abby Kearns, CEO von ActiveState – Interview-Reihe

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 eines 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 Veränderungen in Cloud, Open Source und KI in eine klare Produktstrategie und Unternehmenswachstum umzusetzen.

ActiveState ist ein kanadisches Softwareunternehmen, das 1997 gegründet wurde und Unternehmenswerkzeuge 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 bei der Automatisierung der Abhängigkeitsverwaltung, der Erkennung und Behebung von Sicherheitslücken und der Erstellung sicherer, reproduzierbarer Entwicklungsumgebungen in mehreren Programmiersprachen wie Python, Perl und Tcl. Durch die Lieferung von vorkonfigurierten, überprüften Open-Source-Komponenten und ihre Integration in bestehende Workflows zielt ActiveState darauf ab, die Sicherheitsrisiken in der Software-Lieferkette zu reduzieren und gleichzeitig die Produktivität der Entwickler und die Anwendungslieferung zu verbessern.

Sie haben Ihre Karriere an der Schnittstelle von Open Source, Cloud-nativen Plattformen und Unternehmensumwandlung verbracht, von der Leitung der Cloud Foundry Foundation bis 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 es, an der Schnittstelle von Community und Infrastruktur zu arbeiten, wenn 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 die Konfigurationsverwaltung und die frühen Stadien dessen, was wir jetzt DevSecOps nennen. ActiveState ist dieser Moment für Open-Source-Governance.

Was mich hierher gezogen hat, ist ein Problem, das ich lange beobachtet habe. Jedes Unternehmen, das ich getroffen habe, läuft auf Open Source. Die meisten von ihnen können nicht mit Sicherheit sagen, welches Open Source sie verwenden, ob es gepatcht wurde oder wer für die Entscheidung verantwortlich ist, es zu verwenden. Diese Lücke zwischen der Bedeutung von Open Source und der mangelnden Sorgfalt, die die meisten Organisationen bei der Verwaltung anwenden, 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 werden, woher das Open Source für Unternehmen kommt. Nicht ein Scanner. Nicht ein Bericht. Eine vertrauenswürdige, überprüfte, kontinuierlich behobene Quelle, auf die Organisationen verweisen können, wenn Regulierungsbehörden, Vorstände oder Reaktionsteams fragen, wie sie ihre Software-Lieferkette verwaltet 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 einzuschließen.

Jede SBOM-Richtlinie, jedes SCA-Tool, jeder Vulnerabilitäts-Management-Workflow geht davon aus, dass ein Mensch in der Schleife war, der die Bibliothek ausgewählt 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 vorhanden 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 Entwicklerumfragen, die GitHub-Sterne, none dieser Bewertungsframeworks haben Sicherheit als erste Maßnahme einbezogen. Die Branche hat sich auf Geschwindigkeit und Richtigkeit optimiert und die Infrastruktur ohne zu fragen, ob die Ausgabe sicher war, ausgeliefert. Das ist kein Tooling-Fehler. Das ist ein Führungsfehler in der Entscheidungsfindung. Wir arbeiten jetzt auf einer Grundlage, die nie auf das Risiko hin bewertet wurde, das sie einführt.

Sie haben gesagt, dass unverwaltetes Open Source zu einer großen Unternehmensverwundbarkeit wird. Warum erreicht Open-Source-Governance jetzt das Board-Level, und was unterschätzen Führungskräfte noch?

Es erreicht das Board, weil die regulatorische Umgebung die Rechenschaftspflicht-Struktur geändert hat. Die EU-Cyber-Resilience-Verordnung, die SEC-Offenlegungsanforderungen, die CISA-Secure-by-Design-Richtlinie: Diese Rahmenbedingungen ändern die Frage von “Hatten Sie einen Scanner?” zu “Können Sie beweisen, dass Ihre Software bei der Quelle sicher war?” Das sind sehr unterschiedliche Fragen, und die meisten Organisationen können die zweite 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 mit dem Hinzufügen von Scanning-Tools reagieren, lösen das zugrunde liegende Problem nicht. Scanning erkennt Probleme, nachdem sie in die Umgebung gelangt sind.

Wenn alles gekennzeichnet ist, wird nichts priorisiert, und der Umfang der Warnungen wird zu einer eigenen operativen Dysfunktion. Die Organisationen, die dies erfolgreich bewältigen, sind nicht diejenigen, die mehr Tools kaufen. Sie sind diejenigen, die ändern, wie sie Entscheidungen über das Open Source treffen, das in ihre Umgebung gelangt, 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 Unternehmenssoftware-Stacks eingebettet ist?

Das geistige 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 Ausrichtung machte Sinn, als Open Source optional und ergänzend war.

Das ist nicht die aktuelle Realität. Open Source ist die Grundlage moderner Software. Sechsundneunzig Prozent der Anwendungen enthalten Open-Source-Komponenten. Es ist keine Komfortschicht auf top proprietärer Infrastruktur. Es ist die Infrastruktur. Und Infrastruktur muss wie Infrastruktur verwaltet werden, mit expliziten Richtlinien darüber, was in die Umgebung gelangt, definiertem Eigentum für Wartung und Behebung und Verantwortung, die auf der richtigen Ebene der Organisation sitzt.

Die Organisationen, die hier vorne liegen, haben einen bewussten Schritt gemacht: Open-Source-Verbrauch ist eine strategische Entscheidung mit Sicherheits- und Finanzfolgen, nicht eine Standard-Einstellung, die Entwickler individuell verwalten. Dieser Schritt erfordert Richtlinien, operative Prozesse und klare Führungskräfte-Verantwortung. Die meisten Organisationen haben diesen Schritt noch nicht gemacht.

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

Die aktuelle KI-gestützte Bewegung ist sehr ähnlich wie frühere technologische Verschiebungen. Als Cloud als Liefermodell aufkam, 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 geschafft haben, haben jahrelang unter Schatten-IT, Kostenüberschreitungen und Sicherheits- und technischem Schulden gelitten.

Was anders ist an der aktuellen KI-gestützten Verschiebung, ist die Geschwindigkeit und die Unsichtbarkeit. Cloud-Adoption war sichtbar. Sie wussten, wenn Ihre Organisation Workloads von On-Premises in die Cloud verlagerte. DevOps war sichtbar: Organisationen strukturierten Teams um, änderten Deployments-Pipelines und schrieben Prozesse neu. KI-Coding-Tools werden von Entwickler zu Entwickler, Tool-Aufruf zu Tool-Aufruf, adoptiert, und das Risiko kumuliert im 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 sie 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 ist, was diesen Übergang anders macht. Die Belastung 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, was das Produkt angeht, das sie tatsächlich verkaufen. Sie verkaufen nicht die Open-Source-Software, die kostenlos ist. Sie verkaufen die Expertise, die operative Unterstützung, die Governance-Infrastruktur oder den Managed-Service, der die kostenlose Software auf Unternehmensskala tragbar macht.

Im Gegensatz dazu neigen Organisationen, die scheitern, dazu, Community-Adoption mit kommerziellem Zug 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 Unternehmenswert erfordert den Aufbau von etwas, das über die Open-Source-Software hinausgeht, und die Organisationen, die diese Unterscheidung nicht klar in ihrer Positionierung, ihrem Produkt und ihrem Vertriebsprozess 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ührungskräfte-Herausforderungen beim Übergang von produktgeführtem Wachstum zu Unternehmensskala-Betrieb?

Die größte Herausforderung ist, dass die Fähigkeiten und Instinkte, die Sie zum Erfolg bei produktgeführtem Wachstum geführt haben, gegen Sie arbeiten, wenn Sie auf Unternehmensskala operieren. Produktgeführtes Wachstum belohnt schnelles Handeln, Iteration im öffentlichen Raum, Optimierung für Entwicklererfahrung und die Kommerzialisierung, die der Adoption folgt. Unternehmensverkäufe belohnt absichtliche Prozesse, Führungskräfte-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 hauptsächlich ein Vertriebsprozess-Problem ist. Es ist nicht. Es ist ein Organisationsdesign-Problem. Das Team, das das Produkt, die Positionierung und die frühen Kundenbeziehungen aufgebaut hat, ist oft nicht das Team, das den Unternehmensprozess ausführen kann. Die Anerkennung dessen, ohne das 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 geschaffen hat.

Sie haben umfassend an der Schnittstelle von Sicherheit und Entwickler-Produktivität gearbeitet. Wie können Unternehmen Geschwindigkeit und Innovation mit dem wachsenden Bedürfnis nach sicheren, vertrauenswürdigen Software-Komponenten in Einklang bringen?

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 verwaltete Quelle vertrauenswürdiger 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üfung nach dem Schreiben. Nicht Scanning von Artefakten nach dem Bau. Verwaltung dessen, was in den Katalog gelangt, 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 stattgefunden hat. Das ist eine architektonische Entscheidung, keine kulturelle. Es erfordert Investitionen in die Governance-Infrastruktur, aber es erfordert nicht die Wahl zwischen schnellem Handeln und sicheren Auslieferungen.

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

Die Rolle von kuratierten, vertrauenswürdigen Open-Source-Quellen wird von einer Best-Practice zu einer Baseline-Anforderung wechseln. Dieser Wechsel wird durch zwei Dinge getrieben, die nicht umkehrbar sind.

Das erste ist die regulatorische Umgebung. Im Jahr 2026-Landschaft ist es zunehmend eine gesetzliche Anforderung, Software-Provenienz nachweisen zu können, nicht ein freiwilliger Standard. Boards und Regulierungsbehörden stellen Fragen, die Organisationen nicht beantworten können, wenn sie direkt aus öffentlichen Registern ziehen.

Das zweite ist die KI-Entwicklungs-Geschwindigkeit. Wenn KI-Tools mehr Code und Abhängigkeiten generieren, wird der Umfang der unüberprüften Komponenten, die in die Produktion gelangen, die Fähigkeit jeder Organisation übersteigen, sie manuell zu überprüfen. Die Organisationen, die einen kuratierten, politikgesteuerten Katalog als Standard-Quelle für ihre Entwickler und KI-Tools eingerichtet haben, werden in der Lage sein, die KI-Geschwindigkeit mit angemessener Sicherheits-Governance zu kombinieren. Die Organisationen, die 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.

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

Als eine der wenigen weiblichen CEOs im Open-Source- und Infrastrukturbereich: Welche Veränderungen haben Sie im Laufe der Jahre in Bezug auf Führungsdiversitä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 Infrastrukturbereich so gering, dass die Ausnahmen bemerkenswert waren. Das ist weniger wahr heute. Es gibt mehr Frauen in senior-technischen und Führungspositionen, mehr Organisationen, die über die Phase der diversity-Statement-Perfomance hinausgegangen sind und strukturelle Veränderungen vornehmen, und mehr Modelle dafür, was Führung in diesem Bereich aussehen kann.

Der Geschäftsfall für die Schließung der verbleibenden Lücke ist nicht abstrakt. Die Probleme, an denen diese Branche derzeit arbeitet, Software-Lieferketten-Risiko, KI-Governance, die organisatorischen Ä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 der Aspiration, sondern als eine Frage davon, wie unterschiedliche Perspektiven Annahmen ans Licht bringen, die homogene Teams verpassen. Ich habe dies direkt gesehen. Die Organisationen, die echten Fortschritt bei Zugehörigkeit, nicht nur Repräsentation, gemacht haben, sind diejenigen, bei denen dieser operativen Vorteil in der Arbeit sichtbar wird.

Zugehörigkeit ist jedoch immer noch ungleichmäßig in der Branche verteilt. Im Raum zu sein ist nicht dasselbe wie eine Perspektive, die wirklich berücksichtigt wird. 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.