Abby Kearns, CEO av ActiveState – Intervju-serie

Abby Kearns er CEO av ActiveState og en teknologileder med mer enn 25 års erfaring med å bygge og skala bedriftsprogramvareorganisasjoner. Hun tjenestegjorde tidligere som CTO i Puppet, der hun hjalp til å lede en strategisk transformasjon som kulminerte i selskapets oppkjøp av Perforce Software. Tidligere i sin karriere var hun CEO av Cloud Foundry Foundation, hvor hun ledet veksten av en av bransjens største åpne kildekode-molnplattformer. Abby sitter for tiden i styret for Akka (tidligere Lightbend). Hun er kjent for å hjelpe selskaper å oversette store endringer i sky, åpen kildekode og AI til tydelig produktstrategi og bedriftsvekst.

ActiveState er et canadisk programvareselskap etablert i 1997 som tilbyr bedriftsverktøy og plattformer for å bygge, håndtere og sikre åpen kildekode-programvare. 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 kildekodekomponenter og integrere dem i eksisterende arbeidsflyter, har ActiveState som mål å redusere sikkerhetsrisikoer i programvareforsyningskjeden samtidig som utviklerproduktiviteten og levering av programmer forbedres.

Du har brukt karrieren din på skjæringspunktet mellom åpen kildekode, skybaserte plattformer og bedriftstransformasjon, fra å lede Cloud Foundry Foundation til å være CTO i Puppet. Hva trakk deg til å ta på deg CEO-rollen i ActiveState, og hva er din visjon for selskapet i denne neste vekstfasen?

Gjennomgangen av min karriere har vært å operere på skjæringspunktet mellom samfunn og infrastruktur på tidspunkter når bransjen tar avgjørelser som vil ha effekt i mange år. Cloud Foundry var det øyeblikket for skybaserte plattformer. Puppet var det øyeblikket for konfigurasjonsstyring og de tidlige fasene av det vi nå kaller DevSecOps. ActiveState er det øyeblikket for åpen kildekode-styring.

Hva som trakk meg hit, er et problem jeg har sett bygge opp over lang tid. Hvert enkelt bedrift jeg har møtt, kjører på åpen kildekode. De fleste av dem kan ikke si med sikkerhet hva slags åpen kildekode de kjører, om den har blitt fikset, eller hvem som er ansvarlig for avgjørelsen om å bruke den. Denne gapen, mellom hvor grunnleggende åpen kildekode har blitt og hvor lite disiplin de fleste organisasjoner anvender for å styre den, er der 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 er presserende.

Visjonen for denne neste fasen er tydelig: ActiveState blir standard svaret på spørsmålet om hvor bedriftens åpen kildekode kommer fra. Ikke en skanner. Ikke en rapport. En pålitelig, verifisert, kontinuerlig fikset kilde som organisasjoner kan peke på når regulatorer, styre eller hendelsesrespondenter spør hvordan de styrte sin programvareforsyningskjede.

ActiveState stiller seg som et kritisk lag i å sikre programvareforsyningskjeden på et tidspunkt når AI akselerer kodegenerering. Hvordan endrer AI i grunnleggende risikoprofilen for åpen kildekode-programvare?

AI-assistert utvikling bryter en grunnleggende antakelse som hele åpen kildekode-styringsverktø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 menneskelig faktor som valgte å trekke den biblioteket. Når AI genererer kode, ankommer avhengigheter i produksjon som ingen valgte, gjennomgikk eller i mange tilfeller visste var der. Styringsverktøyet ser etter avgjørelser. AI tar produksjonsendringer som går forbi avgjørelsen helt og holdent.

Det er et annet lag til dette. Kodeverktøyene som drev AI-tilpasning, produktivitetsbenchmarks, utviklerundersøkelser, GitHub-stjerner, inkluderte ikke sikkerhet som en førsteklasses målestokk. Bransjen optimerte for hastighet og riktighet og leverte infrastrukturen uten å spørre om utgangen var trygg. Det er ikke et verktøysvigt. Det er et ledelsesvigt i hvordan tilpasningsavgjørelser ble tatt. Vi opererer nå i skala på en basis som aldri ble evaluert for risikoen det introduserte.

Du har sagt at ustyrte åpne kildekoder blir en stor bedriftssårbarhet. Hvorfor når åpen kildekode-styring nå opp til styrenivå, og hva underskattes fortsatt av ledere?

Det når styrenivået fordi det regulerende miljøet har endret ansvarstrukturen. EU sitt cybersikkerhetslov, SEC sitt krav til åpenhet, CISA sitt sikre design-veiledning: disse rammevirkningene endrer spørsmålet fra “Har du en skanner?” til “Kan du bevise at programvaren din var sikker ved opphavet?” 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 åpen kildekode-risiko ved å legge til flere skanningsverktøy, løser ikke det underliggende problemet. Skanning detekterer problemer etter at de har kommet inn i miljøet ditt.

Når alt er merket, prioriteres ingenting, 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 åpen kildekode som kommer inn i deres miljø, og hvem som er ansvarlig for disse avgjørelsene.

Med åpen kildekode nå innbygget i de fleste bedriftsprogramvarestabler, hvordan bør organisasjoner omtenke åpen kildekode som infrastruktur fremfor bare en utviklingsmessig behagelighet?

Tankemodellen de fleste organisasjoner jobber fra, er ti år gammel. Åpen kildekode startet som en utviklingsmessig behagelighet. Utviklere kunne trekke biblioteker, flytte raskere og unngå å gjøre om grunnleggende komponenter. Denne rammen gjorde mening når åpen kildekode var valgfri og supplementær.

Det er ikke den nåværende realiteten. Åpen kildekode er grunnlaget for moderne programvare. 96 prosent av applikasjonene inkluderer åpne kildekodemoduler. 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 fiksing, og ansvar som sitter på riktig nivå i organisasjonen.

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

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

Den nåværende AI-drevne bevegelsen er svært lik tidligere teknologiske skift. Når sky oppstod som en leveringsmodell, gjorde organisasjonene som behandlet det som et rent teknologisk valg, svært forskjellige feil enn organisasjonene som erkjente det som en arkitektonisk og operasjonell skift. De som feilet i å gjøre styringsovergangen, betalte for det i årevis i skygget IT, kostnadsoverskridelser og sikkerhets- og teknisk gjeld.

Hva som er forskjellig med den nåværende AI-drevne skiftet, er hastigheten og usynligheten. Sky-tilpasning var synlig. Du visste når din organisasjon migrerte arbeidsbyrde fra lokale til sky. DevOps var synlig: organisasjoner omstrukturerte team, endret deploy-pipelines og skrev om prosesser. AI-kodeverktøy blir tatt i bruk 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.

Forstyrrelsen er også asymmetrisk på en måte som sky og DevOps ikke var. Disse overgangene skapte nye kategorier av risiko, men beholdt i stor grad antakelsen om at et menneske var ansvarlig for koden som ble levert. AI eroderer denne antakelsen på det punktet hvor det er hardest å detektere. Det er hva som gjør denne overgangen forskjellig. Eksposen er usynlig til den ikke er.

Mange selskaper sliter med å omdanne åpen kildekode-tilpasning til en bærekraftig forretningsmodell. Hva skiller selskaper som lykkes fra de som feiler?

Organisasjonene som har bygget bærekraftige forretninger på åpen kildekode, deler én karakteristikk: de er disiplinerte om hva produktet de faktisk selger. De selger ikke åpen kildekode-programvaren, som er gratis. De selger ekspertisen, den operasjonelle støtten, styringsinfrastrukturen eller den administrerte tjenesten som gjør den gratis programvaren livskraftig på bedriftsnivå.

Ombyt, organisasjoner som feiler, tenderer til å forveksle samfunnsadopsjon med kommersiell trekkraft. De er ikke det samme. Høy GitHub-stjernetall eller et stort samfunn 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 åpen kildekode selv, og organisasjonene som feiler i å gjøre denne distinksjonen tydelig i deres posisjonering, produkt og salgsbevegelse, tenderer til ikke å overleve overgangen til skala.

Fra din erfaring med å skala utvikler-styrte organisasjoner, hva er de største ledelsesutfordringene når man går over fra produkt-ledet vekst til bedrifts-skala operasjoner?

Den største utfordringen er at ferdighetene og instinktene som gjorde deg suksessfull i produkt-ledet vekst, arbeider mot deg på bedriftsnivå. Produkt-ledet vekst belønner rask bevegelse, itererer i offentligheten, optimaliserer for utvikleropplevelse og lar adopsjon lede den kommersielle bevegelsen. Bedriftssalg belønner bevisst prosess, eksekutivrelasjoner, 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 det ikke. Det er et organisatorisk designproblem. Teamet som bygde produktet, posisjonen 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 bygge nye evner uten å demontere kulturen som skapte produktet.

Du har arbeidet omfattende på skjæringspunktet mellom sikkerhet og utviklerproduktivitet. Hvordan kan selskaper balansere hastighet og innovasjon med den voksende behovet for sikre, pålitelige programvarekomponenter?

Rammingen av 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 starten av prosessen, bremser det ikke noe ned.

De som har løst denne spenningen, har gjort det ved å flytte hvor sikkerheten 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 AI-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 AI-verktøy stadig genererer kode og avhengigheter, hvordan ser du på utviklingen av kurerte eller pålitelige åpne kildekode-økosystemer de neste årene?

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

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

Det andre er AI-utviklingshastighet. Ettersom AI-verktøy genererer mer kode og trekker mer 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 AI-verktøy, vil kunne matche AI sin 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 AI-utvikling har gjort uunngåelig.

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

Det har vært reelle endringer. Når jeg startet karrieren min, var representasjonen av kvinner i ledelsesroller i åpen kildekode og infrastruktur lav nok til at unntakene var merkbare. Det er mindre sant nå. Det er flere kvinner i senior tekniske og ledelsesstillinger, flere organisasjoner som har flyttet seg forbi den performative mangfoldsutviklingsfasen og gjort strukturelle endringer, og flere modeller for hva ledelse i denne bransjen kan se ut som.

Forretningscasen for å lukke den gjenværende gapet, er ikke abstrakt. Problemene denne bransjen jobber med nå, programvareforsyningskjede-risiko, AI-styring, de organisatoriske endringene som kreves for å gjøre sikkerhet en førsteklasses praksis, er vanskelige problemer. Mangfoldige team produserer bedre resultater på vanskelige problemer. Ikke som en sak om aspirasjon, men som en sak 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 over bransjen. Å være i rommet er ikke det samme som å ha perspektivet ditt virkelig vurdert. Denne distinksjonen er der den neste fasen av fremgang må skje.

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