Abby Kearns, administrerende direktør for ActiveState – Interviewserie

Abby Kearns er administrerende direktør for ActiveState og en teknologiuddannelsesleder med mere end 25 års erfaring i opbygning og skaleringsentreprise softwareorganisationer. Hun har tidligere fungeret som teknologiuddannelsesleder for Puppet, hvor hun hjalp med at lede en strategisk transformation, der kulminerede i virksomhedens overtagelse af Perforce Software. Tidligere i sin karriere var hun administrerende direktør for Cloud Foundry Foundation, hvor hun vejledte væksten af en af branchens største åbne kildekode cloud-platformsøkosystemer. Abby sidder i øjeblikket i bestyrelsen for Akka (tidligere Lightbend). Hun er kendt for at hjælpe virksomheder med at oversætte store ændringer i cloud, åben kildekode og kunstig intelligens til klare produktstrategier og virksomheds vækst.

ActiveState er et canadisk softwarefirma grundlagt i 1997, der tilbyder virksomhedsredskaber og -platforme til opbygning, ledelse og sikring af åben kildekode software. Dets kerneydelse, ActiveState Platform, hjælper udviklings-, DevOps- og sikkerhedshold med at automatisere afhængighedsstyring, opdage og afhjælpe sårbarheder og oprette sikre, reproducerbare udviklingsmiljøer på tværs af flere programmeringssprog som Python, Perl og Tcl. Ved at levere forudbyggede, verificerede åbne kildekods komponenter og integrere dem i eksisterende arbejdsgange, sigter ActiveState på at reducere sikkerhedsrisici i softwareforsyningskæden, samtidig med at udviklerproduktiviteten og applikationsleveringen accelereres.

Du har tilbragt din karriere ved skæringen af åben kildekode, cloud-native platforme og virksomhedsomvandling, fra at lede Cloud Foundry Foundation til at fungere som teknologiuddannelsesleder i Puppet. Hvad fik dig til at påtage dig rollen som administrerende direktør i ActiveState, og hvilken er din vision for virksomheden i denne næste vækstfase?

Det gennemgående tema i min karriere har været at fungere ved skæringen af fællesskab og infrastruktur på tidspunkter, hvor branchen træffer beslutninger, der vil have konsekvenser i mange år. Cloud Foundry var det øjeblik for cloud-native. Puppet var det øjeblik for konfigurationsstyring og de tidlige faser af, hvad vi nu kalder DevSecOps. ActiveState er det øjeblik for åben kildekode styre.

Hvad fik mig til at komme hertil, er et problem, jeg har set bygge op over lang tid. Hver virksomhed, jeg har mødt, kører på åben kildekode. De fleste af dem kan ikke fortælle med sikkerhed, hvilken åben kildekode de kører, om den er blevet rettet, eller hvem der er ansvarlig for beslutningen om at bruge den. Den lukke, mellem hvor grundlæggende åben kildekode er blevet, og hvor lidt disciplin de fleste organisationer anvender til at styre den, er, hvor branchens risiko akkumulerer sig. ActiveState har brugt tyve år på at bygge infrastrukturen til at lukke den lukke. Mit job er at sikre, at markedet forstår, hvorfor lukningen er presserende.

Visonen for denne næste fase er klar: ActiveState bliver det standard svar på spørgsmålet om, hvor virksomheds åben kildekode kommer fra. Ikke en scanner. Ikke en rapport. En pålidelig, verificeret, kontinuerligt afhjulpet kilde, som organisationer kan pege på, når regulatorer, bestyrelser eller reaktionsteam beder om at vide, hvordan de styrede deres softwareforsyningskæde.

ActiveState positionerer sig selv som et kritisk lag i sikring af softwareforsyningskæden på et tidspunkt, hvor kunstig intelligens accelererer kodegenerering. Hvordan ændrer kunstig intelligens fundamentalt risikoprofilen for åben kildekode software?

Kunstig intelligens-baseret udvikling bryder en grundlæggende antagelse, som hele den åbne kildekode styre-værktøjskæde er bygget på: at en udvikler har truffet en bevidst beslutning om at inkludere en afhængighed.

Hver SBOM-mandat, hver SCA-værktøj, hver sårbarhedsstyringsarbejdsgang antager, at der var en menneskelig faktor i løkken, der valgte at trække biblioteket. Når kunstig intelligens genererer kode, ankommer afhængigheder til produktion, som ingen har valgt, gennemgået eller i mange tilfælde endda ved, er der. Styre-værktøjet ser efter beslutninger. Kunstig intelligens foretager produktionsændringer, der omgår beslutningen helt.

Der er et andet lag til dette. De kodningsværktøjer, der drev kunstig intelligens-adoption, produktivitetsbenchmarks, udviklersundersøgelser, GitHub-stjerner, inkluderede ingen af disse vurderingsrammer sikkerhed som en førsteprioritetsmåling. Branchen optimerede for hastighed og korrekthed og leverede infrastrukturen uden at spørge, om outputtet var sikkert. Det er ikke et værktøjsfejl. Det er et ledelsesfejl i, hvordan adoptionsbeslutninger blev truffet. Vi opererer nu i stor målestok på en grundlag, der aldrig blev vurderet for den risiko, det indførte.

Du har sagt, at ustyrret åben kildekode bliver en stor virksomheds-sårbarhed. Hvordan kommer åben kildekode styre til at stige til bestyrelsesniveau, og hvad undervurderer eksklusive stadig?

Det når bestyrelsesniveau, fordi den regulerende ramme har ændret ansvarlighedsstrukturen. EU’s cybersikkerhedslov, SEC’s offentliggørelseskrav, CISA’s Sikkerhed ved design-retningslinjer: disse rammer ændrer spørgsmålet fra “Havde du en scanner?” til “Kan du bevise, at din software var sikker på tidspunktet for oprindelse?” Det er to meget forskellige spørgsmål, og de fleste organisationer kan ikke besvare det andet.

Hvad eksklusive stadig undervurderer, er, at dette er et strukturelt problem, ikke et ressourceproblem. Organisationerne, jeg ser, der reagerer på åben kildekode-risiko ved at tilføje flere scanningværktøjer, løser ikke det underliggende problem. Scanning detekterer problemer efter, at de er kommet ind i jeres miljø.

Når alt er markeret, prioriteres intet, og volumen af alerts bliver sin egen operationsfejl. Organisationerne, der vil navigere dette succesfuldt, er ikke dem, der køber mere værktøjer. De er dem, der ændrer, hvordan de træffer beslutninger om, hvilken åben kildekode der kommer ind i deres miljø, og hvem der er ansvarlig for disse beslutninger.

Med åben kildekode nu integreret på tværs af de fleste virksomhedssoftware-stakke, hvordan bør organisationer omdefinere åben kildekode som infrastruktur snarere end blot en udviklingsbevægelse?

Tankemodellen, de fleste organisationer arbejder fra, er ti år forældet. Åben kildekode startede som en udviklingsbevægelse. Udviklere kunne trække biblioteker, flytte hurtigt og undgå at genopfinde grundlæggende komponenter. Denne ramme gjorde mening, da åben kildekode var valgfri og supplerende.

Det er ikke den nuværende realitet. Åben kildekode er grundlaget for moderne software. 96% af applikationer inkluderer åben kildekode-komponenter. Det er ikke et convenience-lag på toppen af proprietær infrastruktur. Det er infrastrukturen. Og infrastruktur skal styres som infrastruktur, med eksplisitte politikker om, hvad der kommer ind i miljøet, defineret ejerskab for vedligeholdelse og afhjælpning, og ansvar, der sidder på det rette niveau i organisationen.

Organisationerne, der er foran på dette, har gjort en bevidst skift: åben kildekode-forbrug er en strategisk beslutning med sikkerheds- og finansielle konsekvenser, ikke en standardindstilling, som udviklere styrer individuelt. Denne skift kræver politik, operationsprocesser og klart eksklusivt ansvar. De fleste organisationer har endnu ikke gjort denne skift.

Du har ledet organisationer gennem mange teknologiske bølger. Hvordan ligner den nuværende kunstig intelligens-drevne skift sig i forhold til tidligere overgange som cloud og DevOps i forhold til hastighed og forstyrrelse?

Den nuværende kunstig intelligens-drevne bevægelse ligner meget tidligere teknologiske skift. Når cloud opstod som en leveringsmodel, gjorde organisationerne, der behandlede det som et rent teknologisk valg, meget forskellige fejl end organisationerne, der erkendte det som en arkitektonisk og operationsmæssig skift. Dem, der fejlede med at gøre styre-skiftet, betalte for det i mange år i skygge-IT, omkostningsoverskridelser og sikkerheds- og tekniske gæld.

Hvad der er forskelligt ved den nuværende kunstig intelligens-drevne skift, er hastigheden og usynligheden. Cloud-adoption var synlig. Du vidste, når din organisation migrerede arbejdsbyrde fra on-prem til cloud. DevOps var synlig: organisationer omstrukturerede hold, ændrede installationsrørledninger og gen skrev processer. Kunstig intelligens-kodningsværktøjer bliver adopteret udvikler for udvikler, værktøjskald for værktøjskald, og risikoen akkumulerer sig i kodebasen, før de fleste organisationer har registreret, at en styre-beslutning blev truffet.

Forstyrrelsen er også asymmetrisk på en måde, som cloud og DevOps ikke var. Disse overgange skabte nye kategorier af risiko, men bevarede i stor udstrækning antagelsen af, at et menneske var ansvarlig for den kode, der blev leveret. Kunstig intelligens undergraver denne antagelse på det punkt, hvor det er sværest at registrere. Det er, hvad gør denne overgang forskellig. Udsættelsen er usynlig, indtil det ikke er.

Mange virksomheder kæmper med at omdanne åben kildekode-adoption til en bæredygtig forretningsmodel. Hvad adskiller virksomheder, der lykkes, fra dem, der fejler?

Organisationerne, der har bygget bæredygtige forretningsmodeller på åben kildekode, deler en karakteristik: de er disciplinerede omkring, hvilket produkt de faktisk sælger. De sælger ikke åben kildekode software, som er gratis. De sælger ekspertisen, operationsstøtten, styre-infrastrukturen eller den administrerede tjeneste, der gør den gratis software livskraftig i virksomhedsskala.

Ombyt, organisationer, der fejler, tenderer til at forveksle fællesskabsadoption med kommerciel trækkraft. De er ikke det samme. En høj GitHub-stjernetal eller en stor fællesskab signalerer, at udviklere finder projektet nyttigt. Det signalerer ikke, at købere vil betale for det, eller at det, udviklere finder nyttigt, er det, organisationer faktisk har brug for. Oversættelsen fra udvikler-adoption til virksomheds-værdi kræver bygning af noget ud over åben kildekode selv, og organisationerne, der fejler at gøre denne forskel klart i deres positionering, produkt og salgsbevægelse, tenderer ikke til at overleve skiftet til skala.

Fra din erfaring med at skale udvikler-først-virksomheder, hvad er de største ledelsesudfordringer, når man går fra produkt-ledt vækst til virksomhedsskala-operations?

Den største udfordring er, at de færdigheder og instinkter, der gjorde dig succesfuld i produkt-ledt vækst, arbejder imod dig på virksomhedsskala. Produkt-ledt vækst belønner hurtig bevægelse, iteration i offentligheden, optimering for udvikleroplevelse og lader adoption føre den kommercielle bevægelse. Virksomhedssalg belønner bevidst proces, eksklusivt forhold, lange cykler og evnen til at kortlægge dit produkt til resultater, der betyder noget for købere, der ikke er udviklere.

Ledelsesfejlen, jeg ser oftest, er at antage, at skiftet primært er et salgsbevægelsesproblem. Det er det ikke. Det er et organisationsdesign-problem. Holdet, der byggede produktet, positioneringen og de tidlige kunde-forhold, er ofte ikke holdet, der kan udføre virksomhedssalgsbevægelsen. At erkende dette uden at miste, hvad der gjorde produktet værd at købe, er virkelig svært. De ledere, der gør det godt, er dem, der er ærlige om, hvilke dele af organisationen skal udvikle sig, og som bygger de nye kapaciteter uden at demontere den kultur, der skabte produktet.

Du har arbejdet omhyggeligt ved skæringen af sikkerhed og udviklerproduktivitet. Hvordan kan virksomheder balancere hastighed og innovation med det voksende behov for sikre, pålidelige software-komponenter?

Rammesætning af hastighed versus sikkerhed er et falsk valg, der har bestået, fordi værktøjet har forstærket det. Når sikkerhed implementeres som en gennemgangsporte ved udviklingsprocessens slutning, er det en flaskehals. Når det implementeres som en styret kilde af pålidelige komponenter, som udviklere trækker fra i udviklingsprocessens begyndelse, langsommere intet.

Dem, der har løst denne spænding, har gjort det ved at ændre, hvor sikkerhed sker. Ikke gennemgang af kode efter, at den er skrevet. Ikke scanning af artefakter efter, at de er bygget. Styre, hvad der kommer ind i kataloget, som udviklere og kunstig intelligens-værktøjer trækker fra. Hvis kilden er pålidelig, er hastigheden ikke begrænset af sikkerheds-gennemgangen, fordi sikkerhedsarbejdet skete upstream. Det er en arkitektonisk beslutning, ikke en kulturel. Det kræver investering i styre-infrastrukturen, men det kræver ikke at vælge mellem at flytte hurtigt og levere sikkert.

Da kunstig intelligens-værktøjer i stigende grad genererer kode og afhængigheder, hvordan ser du på udviklingen af kuraterede eller pålidelige åben kildekode-økosystemer i de næste få år?

Rollen af kuraterede, pålidelige åben kildekode-kilder vil skifte fra en bedste praksis til en baseline-krav. Denne skift bliver drevet af to ting, der ikke vil omvende.

Det første er den regulerende ramme. I 2026-landskabet er det at kunne demonstrere software-proveniens en juridisk krav, ikke en frivillig standard. Bestyrelser og regulatorer stiller spørgsmål, som organisationer ikke kan besvare.

Det andet er kunstig intelligens-udviklingshastighed. Da kunstig intelligens-værktøjer genererer mere kode og trækker mere afhængigheder, vil volumen af ikke-vurderede komponenter, der kommer ind i produktion, overstige enhver organisations kapacitet til at gennemgå dem manuelt. Organisationerne, der har etableret en kurateret, politik-styret katalog som standardkilde for deres udviklere og kunstig intelligens-værktøjer, vil kunne matche kunstig intelligens-hastighed med passende sikkerhedsstyre. Organisationerne, der stadig afhænger af offentlige registre og manuel gennemgang, vil opleve en vækstende lukke mellem, hvor hurtigt kode bliver genereret, og hvor grundigt den bliver vurderet.

Kuraterede økosystemer er infrastruktur-svaret på et problem, som kunstig intelligens-udvikling har gjort uundgåeligt.

Da en af de få kvindelige administrerende direktører i åben kildekode- og infrastruktur-branchen, hvad ændringer har du set i ledelsesdiversitet over årene, og hvad skal der stadig forbedres?

Der har været reel ændring. Da jeg startede min karriere, var repræsentationen af kvinder i eksklusivt roller i åben kildekode og infrastruktur lav nok til, at undtagelserne var bemærkelsesværdige. Det er mindre sandt nu. Der er flere kvinder i senior tekniske og eksklusivt roller, flere organisationer, der er gået videre fra den performative diversitets-erklæring-fase og har gjort strukturelle ændringer, og flere modeller for, hvad ledelse i denne branche kan se ud som.

Forretningsfaldet for at lukke den resterende lukke er ikke abstrakt. Problemerne, denne branche arbejder på nu, software-forsyningskæde-risiko, kunstig intelligens-styre, de organisationsændringer, der kræves for at gøre sikkerhed en førsteprioritetspraksis, er hårde problemer. Diverse hold producerer bedre resultater på hårde problemer. Ikke som en sag af aspiration, men som en sag af, hvordan forskellige perspektiver afslører antagelser, som homogene hold misser. Jeg har set dette direkte. Organisationerne, der har gjort reel fremgang på tilhørsforhold, ikke kun repræsentation, er dem, hvor denne operationsfordel viser sig i arbejdet.

Tilhørsforhold er stadig urent i branchen. At være i rummet er ikke det samme som at have din perspektiv ærligt vurderet. Denne forskel er, hvor den næste fase af fremgang skal ske.

Tak for det store interview, læsere, der ønsker at lære mere, skal besøge ActiveState.