Abby Kearns, CEO av ActiveState – Intervju-serie

Abby Kearns er CEO av ActiveState og en teknologi-ekspert med mer enn 25 års erfaring med å bygge og skale opp bedriftsprogramvareorganisasjoner. Hun har tidligere vært CTO i Puppet, der hun hjalp til å lede en strategisk transformasjon som kulminerte i selskapets overtakelse av Perforce Software. Tidligere i sin karriere var hun CEO i Cloud Foundry Foundation, der hun ledet veksten av en av bransjens største åpne kildekode-skytjenesteprogramvareøkosystemer. Abby sitter for tiden i styret i Akka (tidligere Lightbend). Hun er kjent for å hjelpe selskaper med å oversette store endringer i skytjenester, åpne kildekoder og kunstig intelligens til klare produktstrategier og bedriftsvekst.

ActiveState er et canadisk programvareselskap grunnlagt i 1997 som tilbyr bedriftsverktøy og plattformer for å bygge, forvalte og sikre åpne kildekodesoftware. Deres kjerneprodukt, ActiveState-plattformen, hjelper utviklings-, DevOps- og sikkerhetsteam med å automatisere avhengighetsstyring, oppdage og rette opp sårbarheter, og lage sikre, reproduserbare utviklingsmiljøer på tvers av flere programmeringsspråk som Python, Perl og Tcl. Ved å levere forhåndsbygde, verifiserte åpne kildekodeskomponenter og integrere dem i eksisterende arbeidsflyter, har ActiveState som mål å redusere sikkerhetsrisikoer i programvareforsyningskjeden samtidig som utviklerproduktiviteten og applikasjonsleveringen påskyndes.

Du har tilbragt din karriere i skjæringspunktet mellom åpne kildekoder, skytjenester og bedriftstransformasjon, fra å lede Cloud Foundry Foundation til å være CTO i Puppet. Hva var det som førte deg til å påta deg CEO-rollen i ActiveState, og hva er din visjon for selskapet i denne neste vekstfasen?

Det gjennomgående temaet i min karriere har vært å operere i skjæringspunktet mellom samfunn og infrastruktur på tidspunkter når bransjen tar avgjørelser som vil ha konsekvenser i mange år. Cloud Foundry var det øyeblikket for skytjenester. Puppet var det øyeblikket for konfigurasjonsstyring og de tidlige fasene av hva vi nå kaller DevSecOps. ActiveState er det øyeblikket for åpne kildekodesstyring.

Dette problemet har jeg sett bygge seg opp over lang tid. Hver bedrift jeg har møtt, kjører på åpne kildekoder. De fleste av dem kan ikke si med sikkerhet hva slags åpne kildekoder de kjører, om de er oppdatert eller hvem som er ansvarlig for avgjørelsen om å bruke dem. Denne gapen, mellom hvor grunnleggende åpne kildekoder har blitt og hvor lite disiplin de fleste organisasjoner anvender for å styre dem, er hvor bransjens risiko akkumulerer. ActiveState har brukt tjue år på å bygge infrastrukturen for å lukke denne gapen. Min jobb er å sikre at markedet forstår hvorfor lukkingen av denne gapen er nødvendig.

Visjonen for denne neste fasen er klar: ActiveState blir standardsvaret på spørsmålet om hvor bedriftens åpne kildekoder kommer fra. Ikke en skanner. Ikke en rapport. En pålitelig, verifisert, kontinuerlig rettet kilde som organisasjoner kan peke på når regulatorer, styre eller hendelsesrespondere spør hvordan de styrte sin programvareforsyningskjede.

ActiveState stiller seg selv som et kritisk lag i å sikre programvareforsyningskjeden på et tidspunkt når kunstig intelligens akselererer kodegenerering. Hvordan endrer kunstig intelligens risikoprofilen for åpne kildekodesoftware?

Kunstig intelligens-basert utvikling bryter en grunnleggende antakelse som hele åpne kildekodesstyringsverktøykjeden var bygget på: at en utvikler tok en bevisst avgjørelse om å inkludere en avhengighet.

Hver SBOM-mandat, hver SCA-verktøy, hver sårbarhetsstyringsarbeidsflyt antar at det var en menneske i løkken som valgte å trekke inn biblioteket. Når kunstig intelligens genererer kode, kommer avhengigheter inn i produksjon som ingen valgte, gjennomgikk eller i mange tilfeller visste var der. Styringsverktøyene ser etter avgjørelser. Kunstig intelligens gjør endringer i produksjon som går forbi avgjørelsen helt og holdent.

Det er et annet lag til dette. De kodeverktøyene som drev kunstig intelligens-tilpasning, produktivitetsbenchmarks, utviklerundersøkelser, GitHub-stjerner, inkluderte ikke sikkerhet som en førsteprioritetsmål. Bransjen optimerte for hastighet og korrekthet og leverte infrastrukturen uten å spørre om utgangen var trygg. Det er ikke et verktøysvigt. Det er et ledelsessvigt i hvordan tilpasningsavgjørelser ble tatt. Vi opererer nå i stor skala på en basis som aldri ble evaluert for risikoen den innførte.

Du har sagt at ustyrte åpne kildekoder blir en stor bedriftssårbarhet. Hvorfor stiger åpne kildekodesstyring nå til styretnivå, og hva underskattes fortsatt av ledere?

Det når styrenivået fordi det regulerende miljøet har endret ansvarstrukturen. EU-sikkerhetsloven, SEC-krav, CISA-sikkerhetsveiledning: disse rammevilkårene endrer spørsmålet fra “Hadde du en skanner?” til “Kan du bevise at programvaren din var sikker ved opphavsstedet?” Disse er svært forskjellige spørsmål, og de fleste organisasjoner kan ikke svare på det siste.

Hva ledere fortsatt underskattes er at dette er et strukturelt problem, ikke et ressursproblem. Organisasjonene jeg ser responderer til åpne kildekoderisiko ved å legge til flere skanningsverktøy, løser ikke det underliggende problemet. Skanning detekterer problemer etter at de har kommet inn i miljøet.

Når alt blir markert, blir ingenting prioritet, og volumet av varsler blir sin egen operasjonelle dysfunksjon. Organisasjonene som vil navigere dette suksessfullt, er ikke de som kjøper flere verktøy. De er de som endrer hvordan de tar avgjørelser om hva slags åpne kildekoder som kommer inn i miljøet deres fra første sted, og hvem som er ansvarlig for disse avgjørelsene.

Med åpne kildekoder nå innbygget i de fleste bedriftsprogramvarestabler, hvordan bør organisasjoner omtenke åpne kildekoder som infrastruktur i stedet for bare en utviklingshensikt?

Tankemodellen de fleste organisasjoner jobber fra, er ti år gammel. Åpne kildekoder startet som en utviklingshensikt. Utviklere kunne trekke inn biblioteker, flytte raskere og unngå å gjøre grunnleggende komponenter på nytt. Denne rammen gjorde mening når åpne kildekoder var valgfrie og supplerende.

Dette er ikke den nåværende virkeligheten. Åpne kildekoder er grunnlaget for moderne programvare. 96 prosent av applikasjonene inkluderer åpne kildekodeskomponenter. Det er ikke et komfortlag på toppen av proprietær infrastruktur. Det er infrastrukturen. Og infrastruktur må styrers som infrastruktur, med eksplisitte politikker om hva som kommer inn i miljøet, definert eierskap for vedlikehold og retting, og ansvar som sitter på riktig nivå i organisasjonen.

Organisasjonene som er foran på dette, har gjort en bevisst skifte: åpne kildekodesforbruk er en strategisk avgjørelse med sikkerhets- og finansielle konsekvenser, ikke en standardinnstilling som utviklere håndterer individuelt. Denne skiftet krever politikk, operasjonell prosess og tydelig ledelsesansvar. De fleste organisasjoner har ennå ikke gjort denne skiftet.

Du har ledet organisasjoner gjennom flere teknologiske bølger. Hvordan sammenligner den nåværende kunstig intelligens-drevne skiftet med tidligere overganger som skytjenester og DevOps når det gjelder hastighet og forstyrrelse?

Den nåværende kunstig intelligens-drevne bevegelsen er svært lik tidligere teknologiske skift. Når skytjenester oppstod som en leveringsmodell, gjorde organisasjoner som behandlet det som et rent teknologisk valg, svært forskjellige feil enn organisasjoner som erkjente det som en arkitektonisk og operasjonell skifte. De som ikke klarte å gjøre styringsovergangen, betalte for det i mange år med skygge-IT, kostnadsoverskridelser og sikkerhets- og teknisk gjeld.

Hva som er forskjellig med den nåværende kunstig intelligens-drevne skiftet, er hastigheten og usynligheten. Skytjenesteadopsjon var synlig. Du visste når din organisasjon migrerte arbeidsbyrde fra lokal til skyen. DevOps var synlig: organisasjoner omstrukturerte team, endret deploy-pipelines og skrev om prosesser. Kunstig intelligens-kodeverktøy blir adoptert utvikler for utvikler, verktøyskall for verktøyskall, og risikoen akkumulerer i kodebasen før de fleste organisasjoner har registrert at en styringsavgjørelse ble tatt.

Mange selskaper sliter med å omdanne åpne kildekodetilpasning til en bærekraftig forretningsmodell. Hva skiller selskaper som lykkes fra de som feiler?

Organisasjonene som har bygget bærekraftige forretninger på åpne kildekoder, deler en karakteristikk: de er disiplinerte når det gjelder hva produktet de faktisk selger. De selger ikke åpne kildekodesoftwaren, som er gratis. De selger ekspertisen, operasjonell støtte, styringsinfrastrukturen eller den administrerte tjenesten som gjør den gratis programvaren levedyktig på bedriftsnivå.

Om vendt, organisasjoner som feiler, tenderer til å forveksle samfunnsadopsjon med kommersiell trekkraft. De er ikke det samme. Høy GitHub-stjernetall eller stor samfunnet signaliserer at utviklere finner prosjektet nyttig. Det signaliserer ikke at kjøpere vil betale for det, eller at det utviklerne finner nyttig, er det samme som organisasjoner faktisk trenger. Oversettelsen fra utvikleradopsjon til bedriftsverdi krever bygging av noe utover åpne kildekoden selv, og organisasjoner som ikke klarer å gjøre denne distinksjonen tydelig i posisjonering, produkt og salgsbevegelse, tenderer ikke å overleve overgangen til skala.

Fra din erfaring med å skale utvikler-først-organisasjoner, hva er de største ledelsesutfordringene når man går over fra produkt-led vekst til bedrifts-skala drift?

Den største utfordringen er at ferdighetene og instinktene som gjorde deg suksessfull i produkt-led vekst, arbeider mot deg på bedriftsnivå. Produkt-led vekst belønner rask bevegelse, itererer offentlig, optimaliserer for utvikleropplevelse og lar adopsjon lede kommersiell bevegelse. Bedriftssalg belønner bevisst prosess, eksekutiv-relasjoner, lange sykluser og evnen til å kartlegge produktet til resultater som betyr noe for kjøpere som ikke er utviklere.

Ledelsesfeilen jeg ser oftest, er å anta at overgangen primært er et salgsbevegelsesproblem. Det er ikke. Det er et organisatorisk designproblem. Teamet som bygde produktet, posisjoneringen og de tidlige kunde-relasjonene, er ofte ikke teamet som kan utføre bedriftsbevegelsen. Å erkjenne dette uten å tape det som gjorde produktet verd å kjøpe, er virkelig vanskelig. Ledere som gjør det bra, er de som er ærlige om hvilke deler av organisasjonen som må utvikle seg og som bygger nye evner uten å demontere kulturen som skapte produktet.

Du har arbeidet utstrakt på skjæringspunktet mellom sikkerhet og utviklerproduktivitet. Hvordan kan selskaper balansere hastighet og innovasjon med det økende behovet for sikre, pålitelige programvarekomponenter?

Rammeverket hastighet versus sikkerhet er et feilvalg som har bestått fordi verktøyet har forsterket det. Når sikkerhet implementeres som en gjennomgangsportal ved slutten av utviklingsprosessen, er det en flaskehals. Når det implementeres som en styrt, pålitelig kilde som utviklere trekker fra ved begynnelsen av prosessen, bremser det ingenting ned.

De som har løst denne spenningen, har gjort det ved å flytte hvor sikkerhet skjer. Ikke gjennomgang av kode etter at den er skrevet. Ikke skanning av artefakter etter at de er bygget. Styring av hva som kommer inn i katalogen som utviklere og kunstig intelligens-verktøy trekker fra. Hvis kilden er pålitelig, er hastigheten ikke begrenset av sikkerhetsgjennomgangen fordi sikkerhetsarbeidet skjedde oppstrøms. Det er en arkitektonisk avgjørelse, ikke en kulturell. Det krever investering i styringsinfrastrukturen, men det krever ikke å velge mellom å flytte raskt og levere trygt.

Ettersom kunstig intelligens-verktøy stadig genererer kode og avhengigheter, hvordan ser du på utviklingen av kurerte eller pålitelige åpne kildekodesystemer de neste årene?

Rollen til kurerte, pålitelige åpne kildekilder vil skifte fra en beste praksis til en grunnleggende krav. Denne skiftet drives av to ting som ikke vil reversere.

Det første er det regulerende miljøet. I 2026-landskapet, er det å kunne demonstrere programvare-proveniens, stadig mer et lovkrav, ikke en frivillig standard. Styre og regulatorer spør spørsmål som organisasjoner ikke kan svare på.

Det andre er kunstig intelligens-utviklingshastighet. Ettersom kunstig intelligens-verktøy genererer mer kode og trekker inn flere avhengigheter, vil volumet av uverifiserte komponenter som kommer inn i produksjon, overstige enhver organisasjons evne til å gjennomgå dem manuelt. Organisasjonene som har etablert en kurert, policy-styrt katalog som standardkilden for utviklere og kunstig intelligens-verktøy, vil kunne matche kunstig intelligens-hastighet med passende sikkerhetsstyring. Organisasjonene som fortsatt avhenger av offentlige registre og manuell gjennomgang, vil møte en økende gap mellom hvor raskt kode genereres og hvor grundig den blir evaluert.

Kurerte økosystemer er infrastruktur-svaret på et problem som kunstig intelligens-utvikling har gjort uunngåelig.

Som en av de få kvinnelige CEO-er i åpne kildekoder og infrastruktur, hva slags endringer har du sett i ledelsesmangfold over årene, og hva må fortsatt forbedres?

Det har vært reelle endringer. Da jeg startet min karriere, var representasjonen av kvinner i ledende roller i åpne kildekoder og infrastruktur lav nok til at unntakene var merkbare. Det er mindre sant nå. Det er flere kvinner i senior tekniske og ledende stillinger, flere organisasjoner som har flyttet seg forbi den performative mangfoldsutviklingen og gjort strukturelle endringer, og flere modeller for hva ledelse i denne bransjen kan se ut som.

Forretningscasen for å lukke den gjenværende gapen, er ikke abstrakt. Problemene denne bransjen jobber med nå, programvareforsyningskjederisiko, kunstig intelligens-styring, de organisatoriske endringene som kreves for å gjøre sikkerhet en førsteprioritetspraksis, er vanskelige. Mangfoldige team produserer bedre resultater på vanskelige problemer. Ikke som et spørsmål om aspirasjon, men som et spørsmål om hvordan forskjellige perspektiver avdekker antakelser som homogene team glemmer. Jeg har sett dette direkte. Organisasjonene som har gjort virkelig fremgang på tilhørighet, ikke bare representasjon, er de hvor denne operasjonelle fordelen viser seg i arbeidet.

Tilhørighet er fortsatt ujevn fordelt over bransjen. Å være i rommet er ikke det samme som å ha din perspektiv virkelig vurdert. Denne distinksjonen er hvor den neste fasen av fremgang må skje.

Takk for det flotte intervjuet, lesere som ønsker å lære mer, kan besøke ActiveState.