Abby Kearns, CEO van ActiveState – Interviewreeks

Abby Kearns is CEO van ActiveState en een technisch directeur met meer dan 25 jaar ervaring in het opbouwen en schalen van enterprise software-organisaties. Ze was eerder CTO van Puppet, waar ze hielp bij het leiden van een strategische transformatie die culmineerde in de overname van het bedrijf door Perforce Software. Eerder in haar carrière was ze CEO van de Cloud Foundry Foundation, waar ze de groei van een van de grootste open source cloud platform-ecosystemen in de industrie leidde. Abby zit momenteel in de raad van bestuur van Akka (voorheen Lightbend). Ze is bekend vanwege het helpen van bedrijven om grote veranderingen in cloud, open source en AI om te zetten in een duidelijke productstrategie en ondernemingsgroei.

ActiveState is een Canadese softwareonderneming opgericht in 1997 die enterprise-tools en -platforms biedt voor het bouwen, beheren en beveiligen van open source software. De kernaanbieding van het bedrijf, het ActiveState Platform, helpt ontwikkel-, DevOps- en beveiligingsteams bij het automatiseren van afhankelijkheidsbeheer, het detecteren en verhelpen van kwetsbaarheden en het creëren van beveiligde, reproduceerbare ontwikkelomgevingen voor meerdere programmeertalen zoals Python, Perl en Tcl. Door vooraf gebouwde, geverifieerde open source-componenten te leveren en deze te integreren in bestaande workflows, streeft ActiveState ernaar om beveiligingsrisico’s in de softwareleverantieketen te verminderen en de productiviteit van ontwikkelaars te verbeteren en de levering van toepassingen te versnellen.

U hebt uw carrière doorgebracht op het snijvlak van open source, cloud-native platforms en ondernemingsverandering, van het leiden van de Cloud Foundry Foundation tot het dienen als CTO bij Puppet. Wat trok u aan om de CEO-functie bij ActiveState op zich te nemen, en wat is uw visie voor het bedrijf in deze volgende groeifase?

Het doorlopende thema van mijn carrière is het opereren op het snijvlak van community en infrastructuur op momenten waarop de industrie beslissingen neemt die jarenlang zullen doorwerken. Cloud Foundry was dat moment voor cloud-native. Puppet was dat moment voor configuratiebeheer en de vroege stadia van wat we nu DevSecOps noemen. ActiveState is dat moment voor open source governance.

Wat me hierheen trok, is een probleem dat ik al lang heb zien opbouwen. Elk bedrijf dat ik ben tegengekomen, draait op open source. De meesten van hen kunnen niet met vertrouwen zeggen welke open source ze gebruiken, of deze is gepatcht, of wie verantwoordelijk is voor de beslissing om het te gebruiken. Die kloof, tussen hoe fundamenteel open source is geworden en hoe weinig rigor de meeste organisaties toepassen op het beheersen ervan, is waar de industrie risico’s accumuleert. ActiveState heeft twintig jaar besteed aan het opbouwen van de infrastructuur om die kloof te dichten. Mijn taak is ervoor te zorgen dat de markt begrijpt waarom het dichten ervan dringend is.

De visie voor deze volgende fase is duidelijk: ActiveState wordt het standaardantwoord op de vraag waar enterprise open source vandaan komt. Niet een scanner. Niet een rapport. Een vertrouwd, geverifieerd, continu hersteld bron waar organisaties naar kunnen verwijzen wanneer regulators, raden of incidentresponders vragen hoe ze hun softwareleverantieketen hebben beheerd.

ActiveState positioneert zichzelf als een kritische laag in het beveiligen van de softwareleverantieketen op een moment waarop AI codegeneratie versnelt. Hoe verandert AI fundamenteel het risicoprofiel van open source software?

AI-geassisteerde ontwikkeling doorbreekt een fundamentele veronderstelling waarop de hele open source governance-toolchain is gebouwd: dat een ontwikkelaar een bewuste beslissing nam om een afhankelijkheid op te nemen.

Elke SBOM-mandaat, elke SCA-tool, elke kwetsbaarheidsbeheerworkflow veronderstelt dat er een mens in de lus zat die die bibliotheek trok. Wanneer AI code genereert, komen afhankelijkheden in productie terecht die niemand heeft geselecteerd, beoordeeld of in veel gevallen zelfs weet dat ze er zijn. De governance-tooling zoekt naar beslissingen. AI maakt productiewijzigingen die de beslissing volledig omzeilen.

Er is een tweede laag aan dit. De codingsgereedschappen die AI-adoptie aandreven, de productiviteitsbenchmarks, de ontwikkelaaronderzoeken, de GitHub-sterren, geen van deze evaluatiekaders omvatte beveiliging als een eerste-orde maatstaf. De industrie optimaliseerde voor snelheid en correctheid en leverde de infrastructuur zonder te vragen of de uitvoer veilig was. Dat is geen tooling-fout. Het is een leiderschapsfout in hoe adoptiebeslissingen werden genomen. We opereren nu op schaal op een fundament dat nooit is geëvalueerd op het risico dat het introduceerde.

U hebt gezegd dat onbeheerd open source een grote ondernemingskwetsbaarheid wordt. Waarom stijgt open source governance nu naar het niveau van de raad van bestuur, en wat onderschatten executives nog steeds?

Het bereikt de raad van bestuur omdat de regelgevingsomgeving de verantwoordingsstructuur heeft veranderd. De EU Cyber Resilience Act, SEC-disclosuurvereisten, CISA’s Secure by Design-guidance: deze kaders veranderen de vraag van “Hadden jullie een scanner?” naar “Kun je aantonen dat je software veilig was op het moment van oorsprong?” Die zijn heel verschillende vragen, en de meeste organisaties kunnen de tweede niet beantwoorden.

Wat executives nog steeds onderschatten, is dat dit een structureel probleem is, geen resourcemprobleem. De organisaties die reageren op open source-risico’s door meer scanningsgereedschappen toe te voegen, lossen het onderliggende probleem niet op. Scannen detecteert problemen nadat ze al in uw omgeving zijn binnengekomen.

Wanneer alles wordt gemarkeerd, wordt niets geprioriteerd, en wordt het volume van waarschuwingen een operationele disfunctie op zich. De organisaties die dit succesvol zullen navigeren, zijn niet degene die meer gereedschappen kopen. Ze zijn degene die veranderen hoe ze beslissingen nemen over welke open source hun omgeving binnenkomt en wie verantwoordelijk is voor die beslissingen.

Met open source nu ingebed in de meeste enterprise software-stacks, hoe moeten organisaties open source opnieuw overwegen als infrastructuur in plaats van alleen een ontwikkelingsgemak?

Het mentale model waar de meeste organisaties van uitgaan, is tien jaar verouderd. Open source begon als een ontwikkelingsgemak. Ontwikkelaars konden bibliotheken trekken, sneller verplaatsen en fundamentele componenten niet opnieuw uitvinden. Die kadering had zin toen open source optioneel en supplementair was.

Dat is de huidige realiteit niet. Open source is de basis van moderne software. Zesennegentig procent van de toepassingen bevat open source-componenten. Het is geen gemaklaag bovenop propriëtaire infrastructuur. Het is de infrastructuur. En infrastructuur moet worden beheerd als infrastructuur, met expliciete beleidsregels over wat de omgeving binnenkomt, gedefinieerd eigendom voor onderhoud en herstel, en verantwoordelijkheid die op het juiste niveau van de organisatie zit.

De organisaties die hierop vooruit liggen, hebben een bewuste verschuiving gemaakt: open source-consumptie is een strategische beslissing met beveiligings- en financiële gevolgen, niet een standaardinstelling die ontwikkelaars individueel beheren. Die verschuiving vereist beleid, operationeel proces en duidelijke executive-verantwoordelijkheid. De meeste organisaties hebben die verschuiving nog niet gemaakt.

U hebt organisaties door meerdere technologiegolven heen geleid. Hoe vergelijkt de huidige AI-gedreven verschuiving met eerdere overgangen zoals cloud en DevOps in termen van snelheid en verstoring?

De huidige AI-gedreven beweging is zeer vergelijkbaar met eerdere technologische verschuivingen. Toen cloud opkwam als een leveringsmodel, maakten de organisaties die het als een zuivere technologiekeuze behandelde, heel andere fouten dan de organisaties die het herkenden als een architectonische en operationele verschuiving. Degenen die faalden om de governance-overgang te maken, betaalden ervoor gedurende jaren in schaduw-IT, kostenoverschrijdingen en beveiligings- en technische schulden.

Wat anders is aan de huidige AI-gedreven verschuiving, is de snelheid en de onzichtbaarheid. Cloud-adoptie was zichtbaar. U wist wanneer uw organisatie workloads van on-prem naar de cloud migreerde. DevOps was zichtbaar: organisaties waren teams aan het herschikken, implementatiepijplijnen aan het veranderen en processen aan het herschrijven. AI-codingsgereedschappen worden ontwikkelaar per ontwikkelaar, toolcall per toolcall geadopteerd, en het risico accumuleert in de codebase voordat de meeste organisaties hebben geregistreerd dat een governance-beslissing was genomen.

De verstoring is ook asymmetrisch op een manier die cloud en DevOps niet waren. Die overgangen creëerden nieuwe categorieën risico’s, maar behielden grotendeels de veronderstelling dat een mens verantwoordelijk was voor de code die werd verzonden. AI ondermijnt die veronderstelling op het punt waar het het moeilijkst is om te detecteren. Dat is wat deze overgang anders maakt. De blootstelling is onzichtbaar totdat het niet meer is.

Veel bedrijven worstelen om open source-adoptie om te zetten in een duurzaam bedrijfsmodel. Wat onderscheidt bedrijven die slagen van die welke falen?

De organisaties die een duurzaam bedrijf hebben opgebouwd op open source, delen één kenmerk: ze zijn gedisciplineerd over wat product ze eigenlijk verkopen. Ze verkopen de open source software niet, die is gratis. Ze verkopen de expertise, de operationele ondersteuning, de governance-infrastructuur of de beheerde service die de gratis software levensvatbaar maakt op enterprise-schaal.

Omgekeerd falen organisaties die open source-verkoop verwarren met commerciële tractie. Ze zijn niet hetzelfde. Een hoge GitHub-sterrenscore of een grote community signaleert dat ontwikkelaars het project nuttig vinden. Het signaleert niet dat kopers ervoor zullen betalen, of dat het ding dat ontwikkelaars nuttig vinden, het ding is dat organisaties eigenlijk nodig hebben. De vertaling van ontwikkelaar-adoptie naar ondernemingswaarde vereist het opbouwen van iets buiten de open source zelf, en de organisaties die die onderscheidingslijn niet duidelijk maken in hun positionering, product en verkoopbeweging, hebben de neiging het overgangsproces naar schaal niet te overleven.

Uit uw ervaring met het schalen van developer-first-organisaties, wat zijn de grootste leiderschapsuitdagingen bij de overgang van product-gedreven groei naar enterprise-schaaloperaties?

De grootste uitdaging is dat de vaardigheden en instincten die u succesvol maakten in product-gedreven groei, tegen u werken op enterprise-schaal. Product-gedreven groei beloont het snel verplaatsen, itereren in het openbaar, optimaliseren voor ontwikkelaar-ervaring en het laten leiden van adoptie door de commerciële beweging. Enterprise-verkoop beloont een bewuste procedure, executive-relaties, lange cycli en de mogelijkheid om uw product te koppelen aan resultaten die belangrijk zijn voor kopers die geen ontwikkelaars zijn.

De leiderschapsfout die ik het meest zie, is het aannemen dat de overgang voornamelijk een verkoopbewegingsprobleem is. Het is geen verkoopbewegingsprobleem. Het is een organisatorisch ontwerpprobleem. Het team dat het product, de positionering en de vroege klantrelaties bouwde, is vaak niet het team dat de enterprise-beweging kan uitvoeren. Het erkennen dat zonder te verliezen wat het product de moeite waard maakte om te kopen, is echt moeilijk. De leiders die het goed doen, zijn degene die eerlijk zijn over welke delen van de organisatie moeten evolueren en die de nieuwe capaciteiten opbouwen zonder de cultuur te ontmantelen die het product creëerde.

U hebt uitgebreid gewerkt op het snijvlak van beveiliging en ontwikkelaar-productiviteit. Hoe kunnen bedrijven snelheid en innovatie in evenwicht brengen met de groeiende behoefte aan beveiligde, vertrouwde software-componenten?

De kadering van snelheid versus beveiliging is een valse keuze die heeft standgehouden omdat de tooling het heeft versterkt. Wanneer beveiliging wordt geïmplementeerd als een reviewpoort aan het einde van het ontwikkelingsproces, is het een bottleneck. Wanneer het wordt geïmplementeerd als een beheerd bron van vertrouwde componenten die ontwikkelaars aan het begin van het proces trekken, vertraagt het niets.

Degenen die deze spanning hebben opgelost, hebben dat gedaan door te verschuiven waar beveiliging gebeurt. Niet code herzien nadat het is geschreven. Niet artefacten scannen nadat ze zijn gebouwd. Beheersen wat de catalogus binnenkomt die ontwikkelaars en AI-gereedschappen trekken. Als de bron vertrouwd is, wordt de snelheid niet beperkt door de beveiligingsreview omdat het beveiligingswerk stroomopwaarts is gebeurd. Dat is een architectonische beslissing, geen culturele. Het vereist investeringen in de governance-infrastructuur, maar het vereist niet het kiezen tussen snel verplaatsen en veilig verzenden.

Naarmate AI-gereedschappen steeds meer code en afhankelijkheden genereren, hoe ziet u de rol van gecurateerde of vertrouwde open source-ecosystemen evolueren in de komende jaren?

De rol van gecurateerde, vertrouwde open source-bronnen zal verschuiven van een best practice naar een basisvereiste. Die verschuiving wordt gedreven door twee dingen die niet zullen omkeren.

Het eerste is de regelgevingsomgeving. In het landschap van 2026 is het aantonen van software-provenantie steeds vaker een wettelijke vereiste, niet een vrijwillige standaard. Raden en regulators stellen vragen die organisaties niet kunnen beantwoorden door rechtstreeks uit openbare registers te trekken.

Het tweede is de AI-ontwikkelingsvelocity. Naarmate AI-gereedschappen meer code genereren en meer afhankelijkheden trekken, zal het volume van ongeverifieerde componenten dat de productie binnenkomt, elke organisatie overschrijden die handmatig kan controleren. De organisaties die een gecurateerde, policy-gereguleerde catalogus hebben ingesteld als de standaardbron voor hun ontwikkelaars en AI-gereedschappen, zullen in staat zijn om AI’s velocity te matchen met passende beveiligingsgovernance. De organisaties die nog steeds afhankelijk zijn van openbare registers en handmatige review, zullen een groeiende kloof ervaren tussen hoe snel code wordt gegenereerd en hoe grondig het wordt geëvalueerd.

Gecurateerde ecosystemen zijn het infrastructuur-antwoord op een probleem dat AI-ontwikkeling onvermijdelijk heeft gemaakt.

Als een van de weinige vrouwelijke CEO’s in de open source- en infrastructuurruimte, welke veranderingen hebt u gezien in leiderschapsdiversiteit in de loop van de jaren, en wat moet nog worden verbeterd?

Er is echte verandering. Toen ik mijn carrière begon, was de vertegenwoordiging van vrouwen in senior technische en executive-posities laag genoeg dat de uitzonderingen opvielen. Dat is minder waar nu. Er zijn meer vrouwen in senior technische en executive-posities, meer organisaties die zijn verhuisd van de performante diversiteitsverklaring naar het maken van structurele veranderingen, en meer modellen voor wat leiderschap in deze ruimte kan lijken.

De businesscase voor het sluiten van de resterende kloof is niet abstract. De problemen waar deze industrie nu aan werkt, softwareleverantieketen-risico’s, AI-governance, de organisatorische veranderingen die nodig zijn om beveiliging een eerste-orde-praktijk te maken, zijn moeilijke problemen. Diverse teams produceren betere resultaten op moeilijke problemen. Niet als een kwestie van aspiratie, maar als een kwestie van hoe verschillende perspectieven aannamen naar boven brengen die homogene teams missen. Ik heb dit rechtstreeks gezien. De organisaties die echte vooruitgang hebben geboekt op het gebied van behoren, niet alleen vertegenwoordiging, zijn degene waar dat operationele voordeel zichtbaar wordt in het werk.

Behoren is nog steeds onevenwichtig in de industrie. In de kamer zijn is niet hetzelfde als het hebben van uw perspectief echt gewogen. Dat onderscheid is waar de volgende fase van vooruitgang moet gebeuren.

Bedankt voor het geweldige interview, lezers die meer willen leren, moeten bezoeken ActiveState.