Abby Kearns, CEO di ActiveState – Serie di interviste

Abby Kearns è CEO di ActiveState e un’esecutiva tecnologica con oltre 25 anni di esperienza nella costruzione e nella gestione di organizzazioni software aziendali. In precedenza, ha ricoperto il ruolo di CTO di Puppet, dove ha contribuito a guidare una trasformazione strategica che ha portato all’acquisizione dell’azienda da parte di Perforce Software. In precedenza, è stata CEO della Cloud Foundry Foundation, guidando la crescita di una delle più grandi piattaforme cloud open source dell’industria. Abby attualmente fa parte del consiglio di amministrazione di Akka (in precedenza Lightbend). È conosciuta per aver aiutato le aziende a tradurre i principali cambiamenti nel cloud, nell’open source e nell’AI in una chiara strategia di prodotto e crescita aziendale.

ActiveState è un’azienda canadese di software fondata nel 1997 che fornisce strumenti e piattaforme aziendali per la costruzione, la gestione e la sicurezza del software open source. La sua offerta principale, la piattaforma ActiveState, aiuta i team di sviluppo, DevOps e sicurezza ad automatizzare la gestione delle dipendenze, rilevare e rimediare alle vulnerabilità e creare ambienti di sviluppo sicuri e riproducibili in più linguaggi di programmazione come Python, Perl e Tcl. Fornendo componenti open source precompilate e verificate e integrandole nei flussi di lavoro esistenti, ActiveState mira a ridurre i rischi di sicurezza nella catena di approvvigionamento del software, migliorando al contempo la produttività degli sviluppatori e accelerando la consegna delle applicazioni.

Ha trascorso la sua carriera all’intersezione di open source, piattaforme cloud-native e trasformazione aziendale, dalla guida della Cloud Foundry Foundation al ruolo di CTO in Puppet. Cosa l’ha portata ad assumere il ruolo di CEO di ActiveState e qual è la sua visione per l’azienda in questa fase di crescita?

Il filo conduttore della mia carriera è stato operare all’intersezione di comunità e infrastrutture nei momenti in cui l’industria prende decisioni che si accumuleranno per anni. Cloud Foundry è stato quel momento per il cloud-native. Puppet è stato quel momento per la gestione della configurazione e le prime fasi di ciò che ora chiamiamo DevSecOps. ActiveState è quel momento per la governance dell’open source.

Ciò che mi ha portata qui è un problema che ho osservato costruirsi nel tempo. Ogni azienda che ho incontrato si basa sull’open source. La maggior parte di loro non può dire con certezza quale open source stanno utilizzando, se è stato patchato o chi è responsabile della decisione di utilizzarlo. Quella lacuna, tra quanto l’open source sia diventato fondamentale e quanto poca rigore la maggior parte delle organizzazioni applichi alla governance, è dove il rischio dell’industria si sta accumulando. ActiveState ha trascorso vent’anni a costruire le infrastrutture per colmare quella lacuna. Il mio lavoro è assicurarmi che il mercato capisca perché chiudere quella lacuna è urgente.

La visione per questa prossima fase è chiara: ActiveState diventa la risposta predefinita alla domanda su dove proviene l’open source aziendale. Non uno scanner. Non un report. Una fonte verificata, continua e rimediata che le organizzazioni possono indicare quando i regolatori, i consigli di amministrazione o i team di risposta agli incidenti chiedono come hanno governato la catena di approvvigionamento del software.

ActiveState si sta posizionando come un livello critico nella sicurezza della catena di approvvigionamento del software in un momento in cui l’AI sta accelerando la generazione di codice. Come l’AI modifica fondamentalmente il profilo di rischio del software open source?

Lo sviluppo assistito dall’AI rompe un’ipotesi fondamentale su cui è stata costruita l’intera catena di strumenti di governance dell’open source: che uno sviluppatore abbia preso una decisione deliberata di includere una dipendenza.

Ogni mandato SBOM, ogni strumento SCA, ogni flusso di lavoro di gestione delle vulnerabilità presuppone che ci sia stato un essere umano nel loop che abbia scelto di estrarre quella libreria. Quando l’AI genera codice, le dipendenze arrivano in produzione che nessuno ha selezionato, esaminato o, in molti casi, neanche sa che ci sono. La strumentazione di governance sta cercando decisioni. L’AI sta apportando modifiche alla produzione che bypassano completamente la decisione.

C’è un secondo livello in questo. Gli strumenti di codifica che hanno guidato l’adozione dell’AI, i benchmark di produttività, le indagini sugli sviluppatori, le stelle di GitHub, nessuno di questi framework di valutazione includeva la sicurezza come misura di primo ordine. L’industria ha ottimizzato per velocità e correttezza e ha spedito l’infrastruttura senza chiedersi se l’output fosse sicuro. Questo non è un fallimento degli strumenti. È un fallimento di leadership nelle decisioni di adozione. Stiamo ora operando su larga scala su una base che non è mai stata valutata per il rischio che stava introducendo.

Ha detto che l’open source non gestito sta diventando una vulnerabilità aziendale importante. Perché la governance dell’open source sta diventando una questione di livello aziendale e cosa i dirigenti stanno ancora sottovalutando?

Sta raggiungendo il consiglio di amministrazione perché l’ambiente regolatorio ha cambiato la struttura di responsabilità. L’Atto di resilienza informatica dell’UE, i requisiti di divulgazione della SEC, la guida “Progettato per la sicurezza” di CISA: questi framework stanno spostando la domanda da “Avevi uno scanner?” a “Puoi dimostrare che il tuo software era sicuro al punto di origine?” Queste sono domande molto diverse e la maggior parte delle organizzazioni non può rispondere alla seconda.

Ciò che i dirigenti stanno ancora sottovalutando è che questo è un problema strutturale, non un problema di risorse. Le organizzazioni che rispondono al rischio dell’open source aggiungendo più strumenti di scansione non stanno risolvendo il problema sottostante. La scansione rileva problemi dopo che sono entrati nel loro ambiente.

Quando tutto è segnalato, nulla viene prioritizzato e il volume degli avvisi diventa una disfunzione operativa di per sé. Le organizzazioni che navigheranno con successo in questo non sono quelle che acquistano più strumenti. Sono quelle che stanno cambiando il modo in cui prendono decisioni su quale open source entra nel loro ambiente e chi è responsabile di quelle decisioni.

Con l’open source ormai integrato nella maggior parte degli stack software aziendali, come le organizzazioni dovrebbero ripensare l’open source come infrastruttura e non solo come comodità di sviluppo?

Il modello mentale con cui la maggior parte delle organizzazioni sta lavorando è datato di un decennio. L’open source è iniziato come comodità di sviluppo. Gli sviluppatori potevano estrarre librerie, muoversi più velocemente e evitare di reinventare componenti fondamentali. Quella cornice aveva senso quando l’open source era opzionale e supplementare.

Questa non è più la realtà attuale. L’open source è la base del software moderno. Il 96% delle applicazioni include componenti open source. Non è un livello di comodità sopra l’infrastruttura proprietaria. È l’infrastruttura. E l’infrastruttura deve essere governata come infrastruttura, con politiche esplicite su cosa entra nell’ambiente, proprietà definita per la manutenzione e la rimozione e responsabilità che siede al livello giusto dell’organizzazione.

Le organizzazioni che sono in vantaggio su questo hanno fatto un cambio deliberato: il consumo di open source è una decisione strategica con conseguenze di sicurezza e finanziarie, non un’impostazione predefinita che gli sviluppatori gestiscono individualmente. Quel cambio richiede politiche, processi operativi e chiara responsabilità esecutiva. La maggior parte delle organizzazioni non ha ancora fatto quel cambio.

Ha guidato organizzazioni attraverso molte onde tecnologiche. Come il cambiamento attuale guidato dall’AI si confronta con precedenti transizioni come il cloud e il DevOps in termini di velocità e disrupzione?

Il movimento attuale guidato dall’AI è molto simile alle precedenti transizioni tecnologiche. Quando il cloud è emerso come modello di consegna, le organizzazioni che lo hanno trattato come una scelta puramente tecnologica hanno fatto errori molto diversi rispetto a quelle che hanno riconosciuto che era una transizione architettonica e operativa. Quelle che non sono riuscite a fare la transizione di governance hanno pagato per questo per anni in IT ombra, costi eccessivi e debito tecnico e di sicurezza.

Ciò che è diverso nel cambiamento attuale guidato dall’AI è la velocità e l’invisibilità. L’adozione del cloud era visibile. Sapevi quando la tua organizzazione stava migrando i carichi di lavoro da on-prem al cloud. Il DevOps era visibile: le organizzazioni stavano ristrutturando i team, cambiando le pipeline di deploy e riscrivendo i processi. Gli strumenti di codifica AI stanno essere adottati sviluppatore per sviluppatore, chiamata di strumento per chiamata di strumento e il rischio si sta accumulando nel codice base prima che la maggior parte delle organizzazioni abbia registrato che una decisione di governance era stata presa.

La disrupzione è anche asimmetrica in un modo in cui il cloud e il DevOps non lo erano. Queste transizioni hanno creato nuove categorie di rischio, ma hanno largamente preservato l’ipotesi che un essere umano fosse responsabile del codice che è stato spedito. L’AI sta erodendo quell’ipotesi nel punto in cui è più difficile da rilevare. È questo che rende questa transizione diversa. L’esposizione è invisibile fino a quando non lo è più.

Molte aziende lottano per trasformare l’adozione dell’open source in un modello di business sostenibile. Cosa distingue le aziende che hanno successo da quelle che falliscono?

Le organizzazioni che hanno costruito aziende sostenibili sull’open source condividono una caratteristica: sono disciplinate su cosa stanno realmente vendendo. Non stanno vendendo il software open source, che è gratuito. Stanno vendendo l’esperienza, il supporto operativo, l’infrastruttura di governance o il servizio gestito che rende il software gratuito viabile a livello aziendale.

Al contrario, le organizzazioni che falliscono tendono a confondere l’adozione della comunità con la trazione commerciale. Non sono la stessa cosa. Un alto punteggio di stelle su GitHub o una grande comunità segnala che gli sviluppatori trovano il progetto utile. Non segnala che gli acquirenti pagheranno per esso o che la cosa che gli sviluppatori trovano utile è la cosa che le organizzazioni realmente necessitano. La traduzione dall’adozione degli sviluppatori al valore aziendale richiede costruire qualcosa al di là dell’open source stesso e le organizzazioni che falliscono nel fare quella distinzione chiaramente, nella loro posizionamento, nel loro prodotto e nella loro azione di vendita, tendono a non sopravvivere alla transizione alla scala.

Dalla sua esperienza nel far crescere organizzazioni guidate dagli sviluppatori, quali sono le più grandi sfide di leadership nella transizione da una crescita guidata dal prodotto a operazioni su larga scala?

La più grande sfida è che le competenze e gli istinti che li hanno resi di successo nella crescita guidata dal prodotto lavorano contro di loro su larga scala. La crescita guidata dal prodotto premia il muoversi velocemente, l’iterare in pubblico, l’ottimizzare per l’esperienza degli sviluppatori e lasciare che l’adozione guidi il moto commerciale. Le vendite aziendali premiano il processo deliberato, le relazioni esecutive, i lunghi cicli e la capacità di mappare il proprio prodotto su esiti che interessano agli acquirenti che non sono sviluppatori.

L’errore di leadership che vedo più spesso è supporre che la transizione sia principalmente un problema di moto di vendita. Non lo è. È un problema di progettazione organizzativa. Il team che ha costruito il prodotto, la posizionamento e le prime relazioni con i clienti spesso non è il team che può eseguire il moto aziendale. Riconoscere ciò senza perdere ciò che ha reso il prodotto degno di essere acquistato è veramente difficile. I leader che lo fanno bene sono quelli che sono onesti su quali parti dell’organizzazione devono evolversi e che costruiscono le nuove capacità senza smantellare la cultura che ha creato il prodotto.

Ha lavorato estensivamente all’intersezione della sicurezza e della produttività degli sviluppatori. Come le aziende possono bilanciare la velocità e l’innovazione con il crescente bisogno di componenti software sicuri e affidabili?

La cornice della velocità versus sicurezza è una scelta falsa che è persistita perché la strumentazione ha rafforzato questo concetto. Quando la sicurezza viene implementata come un cancello di revisione alla fine del processo di sviluppo, è un collo di bottiglia. Quando viene implementata come una fonte governata di componenti affidabili che gli sviluppatori possono estrarre all’inizio del processo, non rallenta nulla.

Quelli che hanno risolto questa tensione l’hanno fatto spostando dove avviene la sicurezza. Non revisionando il codice dopo che è stato scritto. Non scansionando gli artifact dopo che sono stati costruiti. Governando cosa entra nel catalogo che gli sviluppatori e gli strumenti AI estrarre. Se la fonte è affidabile, la velocità non è vincolata dalla revisione di sicurezza perché il lavoro di sicurezza è stato fatto a monte. Questa è una decisione architettonica, non culturale. Richiede investimenti nell’infrastruttura di governance, ma non richiede scegliere tra muoversi velocemente e spedire in sicurezza.

Man mano che gli strumenti AI generano sempre più codice e dipendenze, come vede l’evoluzione degli ecosistemi open source curati o affidabili nei prossimi anni?

Il ruolo delle fonti open source curate e affidabili sta per spostarsi da una best practice a un requisito di base. Quel cambio è guidato da due cose che non si invertiranno.

La prima è l’ambiente regolatorio. Nel panorama del 2026, essere in grado di dimostrare la provenienza del software è sempre più un requisito legale, non uno standard volontario. I consigli di amministrazione e i regolatori stanno ponendo domande che le organizzazioni non possono rispondere estraendo direttamente dai registri pubblici.

La seconda è la velocità di sviluppo dell’AI. Man mano che gli strumenti AI generano più codice e più dipendenze, il volume di componenti non verificate che entrano in produzione supererà la capacità di qualsiasi organizzazione di esaminarle manualmente. Le organizzazioni che hanno stabilito un catalogo curato e governato dalle politiche come fonte predefinita per i loro sviluppatori e strumenti AI saranno in grado di bilanciare la velocità dell’AI con una governance di sicurezza appropriata. Le organizzazioni che ancora si affidano ai registri pubblici e alla revisione manuale affronteranno un divario crescente tra la velocità con cui il codice viene generato e la completezza con cui viene valutato.

Le ecosistemi curati sono la risposta infrastrutturale a un problema che lo sviluppo dell’AI ha reso inevitabile.

Essendo una delle poche CEO donne nello spazio open source e dell’infrastruttura, quali cambiamenti ha visto nella diversità di leadership negli anni e cosa deve ancora migliorare?

C’è stato un vero cambiamento. Quando ho iniziato la mia carriera, la rappresentanza delle donne nei ruoli esecutivi nello spazio open source e dell’infrastruttura era così bassa che le eccezioni erano degne di nota. Questo non è più vero oggi. Ci sono più donne in ruoli tecnici senior ed esecutivi, più organizzazioni che sono andate oltre la fase della dichiarazione di diversità e stanno facendo cambiamenti strutturali e più modelli per ciò che il leadership in questo spazio può significare.

Il caso d’uso aziendale per la chiusura del divario rimanente non è astratto. I problemi che questo settore sta lavorando ora, il rischio della catena di approvvigionamento del software, la governance dell’AI, i cambiamenti organizzativi necessari per rendere la sicurezza una pratica di primo ordine, sono problemi difficili. I team diversificati producono risultati migliori sui problemi difficili. Non come questione di aspirazione, ma come questione di come le prospettive diverse portino alla luce ipotesi che i team omogenei mancano. Ho visto questo direttamente. Le organizzazioni che hanno fatto progressi reali sull’appartenenza, non solo sulla rappresentanza, sono quelle dove quell’advantage shows up in the work. Belonging is still uneven across the industry. Being in the room is not the same as having your perspective genuinely weighed. That distinction is where the next phase of progress needs to happen. Thank you for the great interview, readers who wish to learn more should visit ActiveState.