Abby Kearns, CEO al ActiveState – Seria de interviuri

Abby Kearns este CEO al ActiveState și un expert în tehnologie cu peste 25 de ani de experiență în construirea și scalarea organizațiilor de software pentru întreprinderi. Anterior, a ocupat funcția de CTO la Puppet, unde a ajutat la transformarea strategică a companiei, culminând cu achiziționarea acesteia de către Perforce Software. Mai devreme în cariera sa, a fost CEO al Cloud Foundry Foundation, ghidând creșterea uneia dintre cele mai mari ecologii de platforme cloud open source din industrie. Abby este membru al consiliului de administrație al Akka (fost Lightbend). Ea este cunoscută pentru ajutorul acordat companiilor în traducerea schimbărilor majore în cloud, open source și AI în strategii de produs și creștere a întreprinderilor clare.

ActiveState este o companie canadiană de software fondată în 1997, care oferă instrumente și platforme pentru întreprinderi pentru construirea, gestionarea și securizarea software-ului open source. Oferta sa principală, platforma ActiveState, ajută echipele de dezvoltare, DevOps și securitate să automatizeze gestionarea dependențelor, să detecteze și să remedieze vulnerabilitățile și să creeze medii de dezvoltare sigure și reproduse pe mai multe limbi de programare, cum ar fi Python, Perl și Tcl. Prin livrarea de componente open source preconstruite și verificate și integrarea lor în fluxurile de lucru existente, ActiveState își propune să reducă riscurile de securitate în lanțul de aprovizionare cu software, îmbunătățind în același timp productivitatea dezvoltatorilor și accelerând livrarea de aplicații.

Ați petrecut cariera la intersecția dintre open source, platforme cloud-native și transformare a întreprinderilor, de la conducerea Cloud Foundry Foundation la funcția de CTO la Puppet. Ce v-a atras să preluați funcția de CEO la ActiveState și care este viziunea dvs. pentru companie în această nouă fază de creștere?

Linia mea de carieră a fost marcată de operarea la intersecția dintre comunitate și infrastructură în momente în care industria lua decizii care aveau să se cumuleze pe termen lung. Cloud Foundry a fost acel moment pentru cloud-native. Puppet a fost acel moment pentru gestionarea configurației și primele etape ale ceea ce numim astăzi DevSecOps. ActiveState este acel moment pentru guvernanța open source.

Ceea ce m-a atras aici este o problemă pe care am urmărit-o de mult timp. Fiecare întreprindere pe care am întâlnit-o rulează pe open source. Majoritatea lor nu pot spune cu încredere ce open source rulează, dacă a fost actualizat sau cine este responsabil pentru decizia de a-l utiliza. Decalajul dintre cât de fundamental a devenit open source și cât de puțină rigurozitate aplică majoritatea organizațiilor în guvernanța acestuia este locul în care se acumulează riscul industriei. ActiveState a petrecut douăzeci de ani construind infrastructura pentru a închide acest decalaj. Rolul meu este să mă asigur că piața înțelege de ce închiderea acestuia este urgentă.

Viziunea pentru această nouă fază este clară: ActiveState devine răspunsul implicit la întrebarea de unde provine open source pentru întreprinderi. Nu un scanner. Nu un raport. O sursă verificată, remediată în mod continuu, în care organizațiile pot să se bazeze atunci când regulatorii, consiliile de administrație sau respondenții la incidente întreabă cum au guvernat lanțul de aprovizionare cu software.

ActiveState se poziționează ca un strat critic în securizarea lanțului de aprovizionare cu software într-un moment în care AI accelerează generarea de cod. Cum modifică fundamental AI riscul asociat software-ului open source?

Dezvoltarea asistată de AI rupe o ipoteză fundamentală pe care întreaga lanț de guvernanță open source a fost construită: că un dezvoltator a luat o decizie deliberată de a include o dependență.

Fiecare mandat SBOM, fiecare instrument SCA, fiecare flux de lucru de gestionare a vulnerabilităților presupune că a existat un om în buclă care a ales să tragă acea bibliotecă. Când AI generează cod, dependențele ajung în producție fără ca nimeni să le fi selectat, revizuit sau, în multe cazuri, să știe că există. Instrumentele de guvernanță caută decizii. AI face schimbări în producție care ocolesc decizia în totalitate.

Există un al doilea strat aici. Instrumentele de codare care au condus la adoptarea AI, benchmark-urile de productivitate, sondajele dezvoltatorilor, stelele de pe GitHub, niciunul dintre aceste cadre de evaluare nu a inclus securitatea ca o măsură de prim ordin. Industria a optimizat pentru viteză și corectitudine și a expediat infrastructura fără a întreba dacă ieșirea era sigură. Acesta nu este un eșec al instrumentelor. Este un eșec de conducere în modul în care au fost luate deciziile de adoptare. Acum operăm la scară pe o fundație care nu a fost evaluată niciodată pentru riscul pe care îl introduce.

Ați spus că open source neadministrat devine o vulnerabilitate majoră pentru întreprinderi. De ce guvernanța open source ajunge acum la nivelul consiliului de administrație, și ce subestimează încă executivii?

Ajunge la nivelul consiliului de administrație pentru că mediul regulator a schimbat structura de responsabilitate. Actul de Reziliență Cibernetică al UE, cerințele de divulgare ale SEC, ghidul Secure by Design al CISA: aceste cadre schimbă întrebarea de la “Ați avut un scanner?” la “Puteți dovedi că software-ul dvs. a fost sigur în momentul originii?” Acestea sunt întrebări foarte diferite, și majoritatea organizațiilor nu pot răspunde la a doua întrebare.

Ce subestimează executivii este că acesta este un problemă structurală, nu una de resurse. Organizațiile pe care le văd răspunzând la riscul open source prin adăugarea de instrumente de scanare nu rezolvă problema de bază. Scanarea detectează probleme după ce au intrat în mediul dvs.

Când totul este marcat, nimic nu este prioritizat, și volumul de alerte devine o disfuncție operațională în sine. Organizațiile care vor naviga cu succes această situație nu sunt cele care cumpără mai multe instrumente. Sunt cele care schimbă modul în care iau decizii despre ce open source intră în mediul lor și cine este responsabil pentru aceste decizii.

Cum ar trebui organizațiile să reconsidere open source ca infrastructură și nu doar ca o conveniență de dezvoltare?

Modelul mental cu care lucrează majoritatea organizațiilor este depășit de zece ani. Open source a început ca o conveniență de dezvoltare. Dezvoltatorii puteau trage biblioteci, puteau merge mai repede și evita să reinventeze componente fundamentale. Acest cadru avea sens atunci când open source era opțional și suplimentar.

Acesta nu este realitatea actuală. Open source este fundația software-ului modern. Nouăzeci și șase la sută din aplicații conțin componente open source. Nu este un strat de conveniență deasupra infrastructurii proprietare. Este infrastructura. Și infrastructura trebuie guvernată ca atare, cu politici explicite despre ce intră în mediu, proprietate definită pentru întreținere și remediere, și responsabilitate care stă la nivelul potrivit al organizației.

Organizațiile care sunt înainte în acest sens au făcut o schimbare deliberată: consumul de open source este o decizie strategică cu consecințe de securitate și financiare, nu o setare implicită pe care dezvoltatorii o gestionează individual. Această schimbare necesită politici, procese operaționale și responsabilitate executivă clară. Majoritatea organizațiilor nu au făcut încă această schimbare.

Ați condus organizații prin multiple valuri tehnologice. Cum se compară schimbarea actuală condusă de AI cu tranzițiile anterioare, cum ar fi cloud și DevOps, în ceea ce privește viteză și perturbare?

Mișcarea actuală condusă de AI este foarte similară cu schimbările tehnologice anterioare. Când cloud a apărut ca model de livrare, organizațiile care l-au tratat ca o alegere pur tehnologică au făcut greșeli foarte diferite decât cele care au recunoscut că este o schimbare arhitecturală și operațională. Cele care nu au reușit să facă tranziția de guvernanță au plătit pentru asta timp de ani în shadow IT, costuri excedate și datorii tehnice și de securitate.

Ce este diferit despre schimbarea actuală condusă de AI este viteza și invizibilitatea. Adoptarea cloud a fost vizibilă. Știați când organizația dvs. migra încărcări de lucru de la premisă la cloud. DevOps a fost vizibil: organizațiile restructurau echipe, schimbau conducte de deploy, rescriau procese. Uneltele de codare AI sunt adoptate dezvoltator cu dezvoltator, apel cu apel, și riscul se acumulează în baza de cod înainte ca majoritatea organizațiilor să fi înregistrat că a fost luată o decizie de guvernanță.

Multe companii luptă să transforme adoptarea open source într-un model de afaceri durabil. Ce separă companiile care reușesc de cele care eșuează?

Organizațiile care au construit afaceri durabile pe open source împărtășesc o caracteristică: sunt disciplinate în ceea ce privește produsul pe care îl vând realmente. Nu vând software-ul open source, care este gratuit. Vând expertiza, suportul operațional, infrastructura de guvernanță sau serviciul gestionat care face software-ul gratuit viabil la scară de întreprindere.

Invers, organizațiile care eșuează tind să confunde adoptarea comunității cu tracțiunea comercială. Nu sunt același lucru. Un număr mare de stele pe GitHub sau o comunitate mare semnalează că dezvoltatorii găsesc proiectul util. Nu semnalează că cumpărătorii vor plăti pentru el sau că lucrul pe care dezvoltatorii îl găsesc util este ceea ce organizațiile realmente au nevoie. Traducerea de la adoptarea dezvoltatorilor la valoarea întreprinderii necesită construirea a ceva dincolo de open source în sine, și organizațiile care nu reușesc să facă această distincție clar, în poziționarea, produsul și mișcarea de vânzări, tind să nu supraviețuiască tranziției la scară.

De la experiența dvs. de a scala organizații conduse de dezvoltatori, care sunt cele mai mari provocări de conducere atunci când se trece de la creșterea condusă de produs la operațiunile la scară de întreprindere?

Cea mai mare provocare este că abilitățile și instinctele care v-au făcut să reușiți în creșterea condusă de produs lucrează împotriva dvs. la scară de întreprindere. Creșterea condusă de produs răsplătește mișcarea rapidă, iterarea în public, optimizarea pentru experiența dezvoltatorului și lăsarea adoptării să conducă mișcarea comercială. Vânzările la scară de întreprindere răsplătesc procesul deliberat, relațiile executive, ciclurile lungi și capacitatea de a mapa produsul dvs. la rezultate care contează pentru cumpărători care nu sunt dezvoltatori.

Greșeala de conducere pe care o văd cel mai des este asumarea că tranziția este în primul rând o problemă de mișcare de vânzări. Nu este. Este o problemă de proiectare organizațională. Echipa care a construit produsul, poziționarea și relațiile cu clienții inițiali este adesea echipa care nu poate executa mișcarea de vânzări la scară de întreprindere. Recunoașterea acestui fapt fără a pierde ceea ce a făcut produsul demn de cumpărat în primul rând este cu adevărat dificil. Conducătorii care o fac bine sunt cei care sunt onești despre care parte a organizației are nevoie să evolueze și care construiesc capacitățile noi fără a demonta cultura care a creat produsul.

Ați lucrat extensiv la intersecția dintre securitate și productivitatea dezvoltatorilor. Cum pot companiile echilibra viteza și inovația cu nevoia crescândă de componente software sigure și de încredere?

Cadrarea vitezei versus securității este o alegere falsă care a persistat pentru că instrumentele au întărit-o. Când securitatea este implementată ca o poartă de revizuire la sfârșitul procesului de dezvoltare, este un blocaj. Când este implementată ca o sursă guvernată de componente de încredere pe care dezvoltatorii le pot trage de la începutul procesului, nu încetinește nimic.

Cele care au rezolvat această tensiune au făcut-o prin schimbarea locului în care are loc securitatea. Nu revizuind codul după ce a fost scris. Nu scanând artifacte după ce au fost construite. Guvernanța a ceea ce intră în catalogul din care dezvoltatorii și uneltele AI trag. Dacă sursa este de încredere, viteza nu este constrânsă de revizuirea de securitate pentru că lucrul de securitate a avut loc în amonte. Acesta este un decizie arhitecturală, nu una culturală. Necessită investiții în infrastructura de guvernanță, dar nu necesită alegerea între mișcarea rapidă și livrarea în siguranță.

Cum vedeți evoluția ecosistemelor open source curate sau de încredere pe următorii ani, pe măsură ce uneltele AI generează cod și dependențe în mod tot mai frecvent?

Rolul surselor open source curate și de încredere va trece de la o practică recomandată la o cerință de bază. Această schimbare este condusă de două lucruri care nu se vor inversa.

Primul este mediul regulator. În peisajul din 2026, demonstrarea provenienței software-ului devine tot mai mult o cerință legală, nu un standard voluntar. Consiliile de administrație și regulatorii întreabă întrebări pe care organizațiile nu le pot răspunde.

Al doilea este viteza de dezvoltare AI. Pe măsură ce uneltele AI generează mai mult cod și trag mai multe dependențe, volumul de componente neevaluate care intră în producție va depăși capacitatea oricărei organizații de a le revizui manual. Organizațiile care au stabilit un catalog curat și guvernat de politici ca sursă implicită pentru dezvoltatorii și uneltele AI lor vor putea să țină pasul cu viteza AI cu guvernanța de securitate adecvată. Organizațiile care încă se bazează pe registre publice și revizuire manuală vor face față unui decalaj tot mai mare între viteza cu care se generează codul și cât de temeinic este evaluat.

Ecouri curate sunt răspunsul infrastructural la o problemă pe care dezvoltarea AI a făcut-o inevitabilă.

Ca una dintre puținele CEO femei în spațiul open source și infrastructură, ce schimbări ați văzut în diversitatea conducerii de-a lungul anilor, și ce mai trebuie îmbunătățit?

A existat o schimbare reală. Când am început cariera, reprezentarea femeilor în roluri executive în open source și infrastructură era suficient de scăzută încât excepțiile erau notabile. Acest lucru nu este atât de adevărat astăzi. Există mai multe femei în roluri tehnice și executive senior, mai multe organizații care au trecut de faza declarațiilor de diversitate și fac schimbări structurale, și mai multe modele pentru ceea ce înseamnă conducerea în acest spațiu.

Cazul de afaceri pentru închiderea decalajului rămas nu este abstract. Problemele pe care industria le lucrează acum, riscul lanțului de aprovizionare cu software, guvernanța AI, schimbările organizaționale necesare pentru a face securitatea o practică de prim ordin, sunt probleme grele. Echipele diverse produc rezultate mai bune la probleme grele. Nu ca o chestiune de aspirație, ci ca o chestiune de modul în care perspectivele diferite aduc la suprafață ipoteze pe care echipele omogene le ratează. Am văzut acest lucru direct. Organizațiile care au făcut progrese reale în ceea ce privește apartenența, nu doar reprezentarea, sunt cele în care avantajul operațional se manifestă în munca lor.

Apartenența este încă inegală în industrie. A fi în cameră nu este același lucru cu a avea perspectiva dvs. cu adevărat luată în considerare. Acesta este locul în care următoarea fază a progresului trebuie să aibă loc.

Mulțumim pentru acest interviu excelent, cititorilor care doresc să afle mai multe, le recomandăm să viziteze ActiveState.