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 softwareorganisaties. Ze was eerder CTO van Puppet, waar ze hielp bij 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 cloudplatformecosystemen in de industrie leidde. Abby zit momenteel in de raad van bestuur van Akka (voorheen Lightbend). Ze is bekend met het helpen van bedrijven om grote veranderingen in cloud, open source en AI om te zetten in 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. Het kernaanbod van het bedrijf, het ActiveState Platform, helpt ontwikkel-, DevOps- en beveiligingsteams bij het automatiseren van afhankelijkheidsbeheer, het detecteren en herstellen 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 de beveiligingsrisico’s in de softwareleverantieketen te verminderen en tegelijkertijd 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 ondernemings transformatie, 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 fase van groei?

Het doorlopende thema van mijn carrière is het opereren op het snijvlak van gemeenschap en infrastructuur op momenten waarop de industrie beslissingen neemt die voor jaren zullen compileren. 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 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 discipline de meeste organisaties toepassen bij het beheren 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 van die kloof 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 betrouwbaar, 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 omvatten beveiliging als een eerste-orde maatstaf. De industrie optimaliseerde voor snelheid en correctheid en leverde de infrastructuur zonder te vragen of de output veilig was. Dat is geen toolingfout. Het is een leiderschapsfout in hoe adoptiebeslissingen werden genomen. We opereren nu op grote 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, de SEC-disclosuvereisten, de CISA Secure by Design-richtlijnen: deze kaders veranderen de vraag van “Hadden jullie een scanner?” naar “Kunnen jullie bewijzen dat jullie software veilig was op het punt van oorsprong?” Dat zijn heel andere vragen, en de meeste organisaties kunnen het tweede antwoord niet geven.

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. Scanning 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. Het 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 bewegen en fundamentele componenten niet opnieuw uitvinden. Die kadering had zin toen open source optioneel en aanvullend was.

Dat is de huidige realiteit niet. Open source is de basis van moderne software. Zesennegentig procent van de applicaties 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 voorop lopen hierin, 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 geleid door meerdere technologische golven. Hoe vergelijkt de huidige AI-gedreven verschuiving met eerdere transities zoals cloud en DevOps in termen van snelheid en disruptie?

De huidige AI-gedreven beweging is erg 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 erkenden als een architecturale en operationele verschuiving. Degene die faalden om de governance-transitie te maken, betaalden daarvoor jarenlang in schaduw-IT, kostenoverschrijdingen en beveiligings- en technische schulden.

Wat anders is aan de huidige AI-gedreven verschuiving, is de snelheid en de onzichtbaarheid. Cloudadoptie 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 aangenomen door ontwikkelaar, door ontwikkelaar, en het risico accumuleert in de codebasis voordat de meeste organisaties hebben geregistreerd dat een governancebeslissing werd genomen.

De disruptie is ook asymmetrisch op een manier die cloud en DevOps niet waren. Die transities creëerden nieuwe categorieën risico, 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 transformatie anders maakt. De blootstelling is onzichtbaar totdat het dat niet meer is.

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

De organisaties die duurzame bedrijven 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 de gemeenschapsadoptie verwarren met commerciële tractie. Ze zijn niet hetzelfde. Een hoge GitHub-sterrentelling of een grote gemeenschap 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 echt nodig hebben. De vertaling van ontwikkelaarsadoptie naar ondernemingswaarde vereist het opbouwen van iets buiten de open source zelf, en de organisaties die falen om dat onderscheid duidelijk te maken in hun positionering, product en verkoopbeweging, hebben de neiging om de overgang naar schaal niet te overleven.

Uit uw ervaring met het schalen van developer-first organisaties, wat zijn de grootste leiderschapsuitdagingen bij de overgang van productgeleide groei naar ondernemingsgrote operaties?

De grootste uitdaging is dat de vaardigheden en instincten die u succesvol maakten in productgeleide groei, tegen u werken op ondernemingsniveau. Productgeleide groei beloont het snel bewegen, itereren in het openbaar, optimaliseren voor ontwikkelaarservaring en het laten leiden van de commerciële beweging door adoptie. Ondernemingsverkopen beloont een bewuste procedure, executive-relaties, lange cycli en de capaciteit 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 primair een verkoopmotionprobleem is. Het is geen verkoopmotionprobleem. Het is een organisatorisch ontwerpprobleem. Het team dat het product, de positionering en de vroege klantrelaties bouwde, is vaak niet het team dat de ondernemingsbeweging kan uitvoeren. 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 die het product creëerde, af te breken.

U hebt uitgebreid gewerkt op het snijvlak van beveiliging en ontwikkelaarsproductiviteit. Hoe kunnen bedrijven snelheid en innovatie in evenwicht brengen met de groeiende behoefte aan beveiligde, betrouwbare softwarecomponenten?

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 betrouwbare componenten die ontwikkelaars aan het begin van het proces trekken, vertraagt het niets.

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

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

De rol van gecureerde, betrouwbare open source bronnen zal verschuiven van een beste praktijk naar een basisvereiste. Die verschuiving wordt aangedreven door twee dingen die niet zullen omdraaien.

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

Het tweede is de AI-ontwikkelingsvelocity. Naarmate AI-gereedschappen meer code en afhankelijkheden genereren, zal het volume van ongeverifieerde componenten dat in productie binnenkomt, elke organisatie overschrijden die handmatig kan controleren. De organisaties die een gecureerde, policy-gestuurde catalogus hebben ingesteld als de standaardbron voor hun ontwikkelaars en AI-gereedschappen, zullen in staat zijn om AI’s velocity te combineren 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.

Gecureerde ecosystemen zijn het infrastructuurantwoord 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 der jaren, en wat moet nog steeds verbeterd worden?

Er is echte verandering. Toen ik mijn carrière begon, was de vertegenwoordiging van vrouwen in uitvoerende rollen in open source en infrastructuur laag genoeg dat de uitzonderingen opvielen. Dat is minder waar nu. Er zijn meer vrouwen in senior technische en uitvoerende posities, meer organisaties die verder zijn gegaan dan de performative diversiteitsverklaringen en structurele veranderingen aan het maken zijn, 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, softwareleverantieketenrisico, AI-governance, de organisatorische veranderingen die nodig zijn om beveiliging een eerste-ordepraktijk te maken, zijn moeilijke problemen. Diverse teams produceren betere resultaten bij 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 ActiveState bezoeken.