Abby Kearns, VD för ActiveState – Intervju-serie

Abby Kearns är VD för ActiveState och en teknisk chef med mer än 25 års erfarenhet av att bygga och skala företagsprogramvaruorganisationer. Hon har tidigare varit CTO för Puppet, där hon hjälpte till att leda en strategisk omvandling som kulminerade i företagets förvärv av Perforce Software. Tidigare i sin karriär var hon VD för Cloud Foundry Foundation, där hon ledde tillväxten av en av branschens största öppen källkods molnplattformsekosystem. Abby sitter för närvarande i styrelsen för Akka (tidigare Lightbend). Hon är känd för att hjälpa företag att översätta stora förändringar i moln, öppen källkod och AI till tydlig produktstrategi och företagsväxt.

ActiveState är ett kanadensiskt programvaruföretag som grundades 1997 och som tillhandahåller företagsverktyg och plattformar för att bygga, hantera och säkra öppen källkodsprogramvara. Företagets kärnerbjudande, ActiveState-plattformen, hjälper utvecklings-, DevOps- och säkerhetsteam att automatisera beroendehantering, upptäcka och åtgärda sårbarheter och skapa säkra, reproducerbara utvecklingsmiljöer över flera programmeringsspråk som Python, Perl och Tcl. Genom att leverera förbyggda, verifierade öppna källkodskomponenter och integrera dem i befintliga arbetsflöden syftar ActiveState till att minska säkerhetsrisker i programvaruförsörjningskedjan samtidigt som utvecklingsproduktiviteten och programvaruleveransen påskyndas.

Du har tillbringat din karriär vid skärningspunkten mellan öppen källkod, molnbaserade plattformar och företagstransformation, från att leda Cloud Foundry Foundation till att vara CTO på Puppet. Vad lockade dig att ta på dig VD-rollen på ActiveState, och vad är din vision för företaget i denna nästa tillväxtfas?

Det gemensamma temat i min karriär har varit att verka vid skärningspunkten mellan samhälle och infrastruktur när branschen fattar beslut som kommer att påverka under många år. Cloud Foundry var den punkten för molnbaserade. Puppet var den punkten för konfigurationshantering och de tidiga stadierna av vad vi nu kallar DevSecOps. ActiveState är den punkten för öppen källkodsstyrning.

Det som lockade mig hit är ett problem som jag har sett växa under lång tid. Varje företag som jag har mött körs på öppen källkod. De flesta av dem kan inte med säkerhet säga vilken öppen källkod de kör, om den har patchats eller vem som är ansvarig för beslutet att använda den. Gapet mellan hur grundläggande öppen källkod har blivit och hur liten stränghet de flesta organisationer tillämpar för att styra den är där branschens risk ackumuleras. ActiveState har tillbringat tjugo år med att bygga infrastrukturen för att stänga detta gap. Mitt jobb är att se till att marknaden förstår varför det är brådskande att stänga det.

VISIONEN för denna nästa tillväxtfas är tydlig: ActiveState blir standardsvaret på frågan om var företagsöppen källkod kommer ifrån. Inte en skanner. Inte en rapport. En betrodd, verifierad, kontinuerligt åtgärdad källa som organisationer kan peka på när tillsynsmyndigheter, styrelser eller incidenthanterare frågar hur de styrde sin programvaruförsörjningskedja.

ActiveState positionerar sig som en kritisk lager i att säkra programvaruförsörjningskedjan vid en tidpunkt då AI påskyndar kodgenerering. Hur förändrar AI i grunden riskprofilen för öppen källkodsprogramvara?

AI-assisterad utveckling bryter en grundläggande antagande som hela öppen källkodsstyrningsverktygskedjan byggdes på: att en utvecklare fattade ett medvetet beslut att inkludera ett beroende.

Varje SBOM-mandat, varje SCA-verktyg, varje sårbarhets hanteringsarbetsflöde antar att det fanns en människa i loopen som valde att dra in biblioteket. När AI genererar kod anländer beroenden till produktion som ingen valde, granskade eller i många fall ens känner till att de finns. Styrningsverktygen letar efter beslut. AI gör produktionsändringar som kringgår beslutet helt och hållet.

Det finns ett andra lager till detta. De kodningsverktyg som drev AI-antagande, produktivitetsmåtten, utvecklarundersökningarna, GitHub-stjärnorna, inga av dessa utvärderingsramar inkluderade säkerhet som en första ordningens mått. Branschen optimerade för hastighet och korrekthet och levererade infrastrukturen utan att fråga om utdata var säkert. Det är inte ett verktygsfel. Det är ett ledarskapsfel i hur antagandebeslut fattades. Vi verkar nu i stor skala på en grund som aldrig utvärderades för den risk det introducerade.

Du har sagt att ohanterad öppen källkod blir en stor företagsvulnerabilitet. Varför stiger öppen källkodsstyrning nu till styrelsenivå, och vad underskattar chefer fortfarande?

Det når styrelsenivå eftersom den regulatoriska miljön har förändrat ansvarsstrukturen. EU:s cybersäkerhetslag, SEC:s offentliggörandekrav, CISA:s säkerhetsriktlinjer för design: dessa ramverk förändrar frågan från “Hade du en skanner?” till “Kan du bevisa att din programvara var säker vid ursprunget?” Det är mycket olika frågor, och de flesta organisationer kan inte svara på den senare.

Vad chefer fortfarande underskattar är att detta är ett strukturellt problem, inte ett resursproblem. Organisationerna jag ser som svarar på öppen källkodsrisken genom att lägga till fler skanningsverktyg löser inte det underliggande problemet. Skanningsverktyg upptäcker problem efter att de har kommit in i er miljö.

När allt flaggas, prioriteras ingenting, och volymen av larm blir sin egen operativa dysfunktion. Organisationerna som kommer att navigera detta framgångsrikt är inte de som köper fler verktyg. De är de som förändrar hur de fattar beslut om vilken öppen källkod som kommer in i deras miljö, och vem som är ansvarig för dessa beslut.

Med öppen källkod nu inbäddad i de flesta företagsprogramvarustaplar, hur bör organisationer omdefiniera öppen källkod som infrastruktur snarare än bara en utvecklingsbequemhet?

Tankemodellen som de flesta organisationer arbetar från är tio år gammal. Öppen källkod började som en utvecklingsbequemhet. Utvecklare kunde dra in bibliotek, flytta snabbare och undvika att återskapa grundläggande komponenter. Den ramningen gjorde sig när öppen källkod var valfri och supplementär.

Det är inte den nuvarande verkligheten. Öppen källkod är grunden för modern programvara. 96 procent av applikationerna innehåller öppna källkods komponenter. Det är inte ett bekvämlighetslager ovanpå proprietär infrastruktur. Det är infrastrukturen. Och infrastruktur måste styras som infrastruktur, med uttryckliga policys om vad som kommer in i miljön, definierad ägandeskap för underhåll och åtgärd, och ansvar som sitter på rätt nivå i organisationen.

Organisationerna som är före på detta har gjort en medveten förändring: öppen källkods konsumtion är ett strategiskt beslut med säkerhets- och finansiella konsekvenser, inte en standardinställning som utvecklare hanterar individuellt. Den förändringen kräver policy, operativa processer och tydligt chefsansvar. De flesta organisationer har ännu inte gjort den förändringen.

Du har lett organisationer genom flera tekniska vågor. Hur jämför den nuvarande AI-drivna förändringen med tidigare övergångar som moln och DevOps i termer av hastighet och störning?

Den nuvarande AI-drivna rörelsen är mycket lik tidigare tekniska skiften. När molnet uppstod som en leveransmodell gjorde organisationerna som behandlade det som ett rent tekniskt val mycket olika misstag än organisationerna som erkände det som ett arkitektoniskt och operativt skifte. De som misslyckades med att göra styrningstransitionen betalade för det under många år i form av skugg-IT, kostnadskörningar och säkerhets- och teknisk skuld.

Vad som skiljer den nuvarande AI-drivna förändringen är hastigheten och osynligheten. Molntillämpning var synlig. Du visste när din organisation migrerade arbetsbelastningar från lokalt till molnet. DevOps var synlig: organisationer omstrukturerade team, ändrade distributionspipeliner och om skrev processer. AI-kodningsverktyg antas utvecklare för utvecklare, verktygsanrop för verktygsanrop, och risken ackumuleras i kodbasen innan de flesta organisationer har registrerat att ett styrningsbeslut fattades.

Många företag kämpar för att göra öppen källkodsantagande till en hållbar affärsmodell. Vad skiljer företag som lyckas från de som misslyckas?

Organisationerna som har byggt hållbara affärer på öppen källkod delar en egenskap: de är disciplinerade när det gäller vilket produkt de faktiskt säljer. De säljer inte öppen källkodsprogramvara, som är gratis. De säljer expertis, operativt stöd, styrningsinfrastruktur eller den hanterade tjänst som gör den gratis programvaran livskraftig i företagsstorlek.

TVÄRTOM tenderar organisationer som misslyckas att sammanblanda communityantagande med kommersiell dragkraft. De är inte samma sak. En hög GitHub-stjärntäthet eller en stor community signalerar att utvecklare tycker att projektet är användbart. Det signalerar inte att köpare kommer att betala för det, eller att det som utvecklare tycker är användbart är det som organisationer faktiskt behöver. Översättningen från utvecklarantagande till företagsvärde kräver att bygga något utöver den öppna källkoden i sig, och organisationerna som misslyckas med att göra den distinktionen tydligt i sin positionering, sitt produkt och sin försäljningsrörelse tenderar inte att överleva övergången till skala.

Från din erfarenhet av att skala utvecklarledda organisationer, vad är de största ledarskapsutmaningarna när man övergår från produktlett tillväxt till företagsstorlek?

Den största utmaningen är att de färdigheter och instinkter som gjorde dig framgångsrik i produktlett tillväxt fungerar mot dig på företagsnivå. Produktlett tillväxt belönar snabb rörelse, iteration i offentligheten, optimering för utvecklarupplevelse och låter antagande leda den kommersiella rörelsen. Företagsförsäljning belönar avsiktlig process, chefsrelationer, långa cykler och förmågan att kartlägga din produkt till resultat som är viktiga för köpare som inte är utvecklare.

LEDARSKAPSMISSTAGET jag ser oftast är att anta att övergången primärt är ett försäljningsrörelseproblem. Det är inte. Det är ett organisationsdesignproblem. Teamet som byggde produkten, positioneringen och de tidiga kundrelationerna är ofta inte teamet som kan utföra företagsrörelsen. Att erkänna det utan att förlora det som gjorde produkten värd att köpa i första hand är genuint svårt. Cheferna som gör det bra är de som är ärliga om vilka delar av organisationen som behöver utvecklas och som bygger de nya förmågorna utan att demontera kulturen som skapade produkten.

Du har arbetat omfattande vid skärningspunkten mellan säkerhet och utvecklarproduktivitet. Hur kan företag balansera hastighet och innovation med det växande behovet av säkra, betrodda programvarukomponenter?

RAMEN för hastighet kontra säkerhet är ett falskt val som har bestått eftersom verktygen har förstärkt det. När säkerhet implementeras som en granskningsgrind i slutet av utvecklingsprocessen är det en flaskhals. När det implementeras som en styrkt källa till betrodda komponenter som utvecklare drar från i början av processen, bromsar det inte någonting.

De som har löst denna spänning har gjort det genom att förändra var säkerhet sker. Inte granska kod efter att den är skriven. Inte skanna artefakter efter att de är byggda. Styra vad som kommer in i katalogen som utvecklare och AI-verktyg drar från. Om källan är betrodd, är hastigheten inte begränsad av säkerhetsgranskningen eftersom säkerhetsarbetet skedde uppströms. Det är ett arkitektoniskt beslut, inte ett kulturellt. Det kräver investeringar i styrningsinfrastrukturen, men det kräver inte att välja mellan att flytta snabbt och leverera säkert.

Som AI-verktyg alltmer genererar kod och beroenden, hur ser du på den kuraterade eller betrodda öppna källkodsekosystemens roll under de kommande åren?

Den kuraterade, betrodda öppna källkods källans roll kommer att förändras från en bästa praxis till en baslinjekrav. Den förändringen drivs av två saker som inte kommer att vända.

Det första är den regulatoriska miljön. I landskapet 2026 är det alltmer ett lagkrav att kunna demonstrera programvaruursprung, inte en frivillig standard. Styrelser och tillsynsmyndigheter ställer frågor som organisationer inte kan besvara.

Det andra är AI-utvecklingshastighet. När AI-verktyg genererar mer kod och drar in fler beroenden kommer volymen av otestade komponenter som kommer in i produktion att överstiga varje organisations förmåga att granska dem manuellt. Organisationerna som har etablerat en kuraterad, policy-styrd katalog som standardkälla för sina utvecklare och AI-verktyg kommer att kunna matcha AI:s hastighet med lämplig säkerhetsstyrning. Organisationerna som fortfarande förlitar sig på offentliga register och manuell granskning kommer att möta ett växande gap mellan hur snabbt kod genereras och hur noggrant den utvärderas.

Kuraterade ekosystem är infrastruktursvaret på ett problem som AI-utveckling har gjort oundvikligt.

Som en av de få kvinnliga VD:arna i den öppna källkoden och infrastrukturbranschen, vilka förändringar har du sett i ledarskapsdiversitet över åren, och vad behöver fortfarande förbättras?

Det har skett en verklig förändring. När jag började min karriär var representationen av kvinnor i chefsroller i öppen källkod och infrastruktur tillräckligt låg för att undantagen skulle vara noterbara. Det är mindre sant nu. Det finns fler kvinnor i seniora tekniska och chefsroller, fler organisationer som har flyttat beyond den performativa mångfaldsfasen och som gör strukturella förändringar, och fler modeller för vad ledarskap i den här branschen kan se ut som.

Det affärsmässiga fallet för att stänga den återstående klyftan är inte abstrakt. De problem som den här branschen arbetar med nu, programvaruförsörjningskedjerisk, AI-styrning, de organisationsförändringar som krävs för att göra säkerhet till en första ordningens praxis, är svåra problem. Mångfaldiga team producerar bättre resultat på svåra problem. Inte som en fråga om aspiration, utan som en fråga om hur olika perspektiv ytor antaganden som homogena team missar. Jag har sett detta direkt. Organisationerna som har gjort verklig framsteg på tillhörighet, inte bara representation, är de där den operativa fördelen visar sig i arbetet.

Tillhörighet är fortfarande ojämn över branschen. Att vara i rummet är inte samma sak som att ha din perspektiv genuint vägd. Den distinktionen är där den nästa fasen av framsteg behöver hända.

Tack för den underbara intervjun, läsare som vill lära sig mer kan besöka ActiveState.