Abby Kearns, VD för ActiveState – Intervjuserie

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ällkodsplattformsekosystem. 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 avhjälpa 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ällkomponenter och integrera dem i befintliga arbetsflöden syftar ActiveState till att minska säkerhetsrisker i programvaruleverantörskedjan samtidigt som utvecklarens produktivitet förbättras och programvarudistributionen 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 drog dig till att ta på dig rollen som VD på ActiveState, och vad är din vision för företaget i denna nästa fas av tillväxt?

Genomgående i min karriär har varit att verka vid skärningspunkten mellan samhälle och infrastruktur vid tillfällen då branschen fattar beslut som kommer att ackumuleras under många år. Cloud Foundry var det ögonblicket för molnbaserade. Puppet var det ögonblicket för konfigurationshantering och de tidiga stadierna av vad vi nu kallar DevSecOps. ActiveState är det ögonblicket för öppen källkodshantering.

Det som drog 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 säga med säkerhet vilken öppen källkod de kör, om den har patchats eller vem som är ansvarig för beslutet att använda den. Det gap som finns 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 det gapet. Min uppgift ä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 fas ä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 pålitlig, verifierad, kontinuerligt åtgärdad källa som organisationer kan peka på när tillsynsmyndigheter, styrelser eller incidenthanterare frågar hur de styrde sin programvaruleverantörskedja.

ActiveState positionerar sig som en kritisk lager i att säkra programvaruleverantörskedjan vid en tidpunkt då AI påskyndar kodgenerering. Hur förändrar AI på ett grundläggande sätt riskprofilen för öppen källkodsprogramvara?

AI-assisterad utveckling bryter en grundläggande antagande som hela öppen källkodshanteringens verktygskedja byggdes på: att en utvecklare medvetet valde 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. Hanteringsverktygen 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-antagandet, 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 skickade infrastrukturen utan att fråga om utmatningen var säker. Det är inte ett verktygsfel. Det är ett ledarskapsfel i hur antagningsbeslut 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öretagssårbarhet. Varför når öppen källkodshantering nu styrelsenivå, och vad underskattar chefer fortfarande?

Det når styrelsenivå eftersom den regulatoriska miljön har ändrat ansvarsstrukturen. EU:s cybersäkerhetslag, SEC:s krav på offentliggörande, CISA:s vägledning om säkerhet från början: dessa ramverk förändrar frågan från “Hade du en skanner?” till “Kan du bevisa att din programvara var säker vid källan?” Det är två mycket olika frågor, och de flesta organisationer kan inte svara på den andra.

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

När allt är flaggat, prioriteras ingenting, och volymen av varningar 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 ändrar hur de fattar beslut om vilken öppen källkod som kommer in i miljön från början, 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 utvecklingsbequemlighet?

Den mentala modell som de flesta organisationer arbetar från är tio år gammal. Öppen källkod började som en utvecklingsbequemlighet. Utvecklare kunde dra in bibliotek, flytta snabbare och undvika att återskapa grundläggande komponenter. Den ramen fungerade 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ällkomponenter. Det är inte ett bekvämlighetslager ovanpå proprietär infrastruktur. Det är infrastrukturen. Och infrastruktur måste styras som infrastruktur, med uttryckliga policyer om vad som kommer in i miljön, definierad ägandeskap för underhåll och avhjälpande, och ansvar som sitter på rätt nivå i organisationen.

Organisationerna som är före på det här området har gjort en medveten förändring: öppen källkodsanvändning ä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 när det gäller hastighet och störning?

Den nuvarande AI-drivna rörelsen är mycket lik tidigare tekniska förändringar. När molnet uppstod som en leveransmodell, gjorde organisationerna som behandlade det som ett rent tekniskt val mycket olika misstag än organisationerna som insåg att det var en arkitektonisk och operativ förändring. De som misslyckades med att göra den styrningsförändringen 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 från tidigare ä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 skrev om 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.

Störningen är också asymmetrisk på ett sätt som moln och DevOps inte var. Dessa övergångar skapade nya kategorier av risk, men behöll i stor utsträckning antagandet att en människa var ansvarig för den kod som skickades. AI urholkar det antagandet vid den punkt där det är svårast att upptäcka. Det är vad som gör denna övergång annorlunda. Exponeringen är osynlig tills den inte är det.

Många företag kämpar för att omvandla ö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 vad produkten de faktiskt säljer. De säljer inte den öppna källkodsprogramvaran, som är gratis. De säljer expertisen, den operativa supporten, hanteringsinfrastrukturen eller den hanterade tjänsten som gör den fria programvaran livskraftig på företagsnivå.

I motsats till detta tenderar organisationer som misslyckas att förväxla communityantagande med kommersiell dragkraft. De är inte samma sak. Ett högt GitHub-stjärntal eller en stor community signalerar att utvecklare finner projektet användbart. Det signalerar inte att köpare kommer att betala för det, eller att det som utvecklare finner 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 själv, och organisationerna som inte gör den distinktionen tydligt i sin positionering, produkt och 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öretagsskalig verksamhet?

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 medveten process, chefsrelationer, långa cykler och förmågan att kartlägga produkten till resultat som är viktiga för köpare som inte är utvecklare.

Ledarskapsfelet jag ser oftast är att anta att övergången främst är ett försäljningsproblem. Det är det inte. Det är ett organisationsdesignproblem. Teamet som byggde produkten, positioneringen och de tidiga kundrelationerna är ofta inte det team som kan utföra företagsrörelsen. Att erkänna det utan att förlora det som gjorde produkten värd att köpa från början är genuint svårt. De ledare 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, pålitliga programvarukomponenter?

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

De som har löst den spänningen har gjort det genom att flytta var säkerheten 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 pålitlig, ä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 hanteringsinfrastrukturen, 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 pålitliga öppna källkods ekosystemens utveckling under de närmaste åren?

Den kuraterade, pålitliga ö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 2026 års landskap är det alltmer ett lagkrav att kunna demonstrera programvaruursprung. Styrelser och tillsynsmyndigheter ställer frågor som organisationer inte kan besvara om de drar direkt från offentliga register.

Det andra är AI-utvecklingens hastighet. När AI-verktyg genererar mer kod och drar in fler beroenden, kommer volymen av ovärderade komponenter som kommer in i produktion att överstiga varje organisations förmåga att granska dem manuellt. Organisationerna som har etablerat en kuraterad, policystyrda 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 infrastrukturlösningen på ett problem som AI-utveckling har gjort oundvikligt.

Som en av de få kvinnliga VD:arna i den öppna källkods- och infrastruktursektorn, 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 gått förbi den performativa mångfaldsdeklarationsfasen och som gör strukturella förändringar, och fler modeller för vad ledarskap i det här området kan se ut.

Affärsfallet för att stänga det återstående gapet är inte abstrakt. De problem som branschen arbetar med nu, programvaruleverantörskedjorisken, AI-styrningen, 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 det direkt. Organisationerna som har gjort verklig framsteg i fråga om 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 detsamma som att ha sin synpunkt genuint vägd. Den distinktionen är där nästa fas av framsteg behöver hända.

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