Abby Kearns, CEO de ActiveState – Seria de interviuri

Abby Kearns este CEO de ActiveState și un executiv î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 conducerea unei transformări strategice care a culminat cu achiziționarea companiei de către Perforce Software. La începutul carierei sale, a fost CEO al Cloud Foundry Foundation, ghidând creșterea uneia dintre cele mai mari ecologii de platforme de nor deschis din industrie. Abby face parte în prezent din consiliul de administrație al Akka (fost Lightbend). Ea este cunoscută pentru ajutorul acordat companiilor în traducerea schimbărilor majore în nor, deschis și AI în strategii de produs și creștere a întreprinderii clare.

ActiveState este o companie de software canadiană fondată în 1997, care oferă instrumente și platforme pentru întreprinderi pentru construirea, gestionarea și securizarea software-ului deschis. 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 reproductibile pentru multiple limbi de programare, cum ar fi Python, Perl și Tcl. Prin furnizarea de componente deschise 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 software deschis, platforme native de nor și transformare a întreprinderilor, de la conducerea Cloud Foundry Foundation la funcția de CTO la Puppet. Ce v-a atras să preluați rolul 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 funcționarea la intersecția dintre comunitate și infrastructură în momente în care industria lua decizii care aveau să se cumuleze de-a lungul anilor. Cloud Foundry a fost acel moment pentru platformele native de nor. 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 software-ului deschis.

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 software deschis. Majoritatea lor nu pot spune cu încredere ce software deschis rulează, dacă a fost actualizat sau cine este responsabil pentru decizia de a-l utiliza. Decalajul dintre cât de fundamental a devenit software-ul deschis și cât de puțină rigurozitate aplică majoritatea organizațiilor în guvernanța acestuia este acolo unde 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 software-ul deschis pentru întreprinderi. Nu un scanner. Nu un raport. O sursă de încredere, verificată și remediată continuu, la care organizațiile pot face referire 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ă AI fundamental profilul de risc al software-ului deschis?

Dezvoltarea asistată de AI sparge o ipoteză fundamentală pe care întreaga lanț de guvernanță a software-ului deschis a fost construită: aceea 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ă trage acea bibliotecă. Atunci 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ță sunt proiectate pentru a căuta decizii. AI face schimbări în producție care ocolesc decizia în întregime.

Există un al doilea strat aici. Instrumentele de codare care au condus la adoptarea AI, benchmark-urile de productivitate, chestionarele dezvoltatorilor, stelele de pe GitHub, niciunul dintre aceste cadre de evaluare nu au 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ă software-ul deschis neadministrat devine o vulnerabilitate majoră pentru întreprinderi. De ce guvernanța software-ului deschis ajunge acum la nivelul consiliului de administrație, și ce subestimează încă executivii?

Acesta ajunge la nivelul consiliului de administrație deoarece mediul regulamentar 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 “Aveți un scanner?” la “Puteți dovedi că software-ul dvs. a fost sigur la momentul originii?” Acestea sunt întrebări foarte diferite, și majoritatea organizațiilor nu pot răspunde la a doua întrebare.

Ceea ce executivii subestimează încă este faptul că aceasta este o problemă structurală, nu una de resurse. Organizațiile pe care le văd răspunzând la riscul software-ului deschis prin adăugarea de instrumente de scanare suplimentare nu rezolvă problema de bază. Scanarea detectează probleme după ce au intrat în mediu.

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 software deschis intră în mediu și cine este responsabil pentru aceste decizii.

Cum ar trebui organizațiile să reconsidere software-ul deschis ca infrastructură și nu doar ca o conveniență de dezvoltare?

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

Acesta nu este realitatea actuală. Software-ul deschis este baza software-ului modern. Nouăzeci și șase la sută din aplicații includ componente de software deschis. Nu este un strat de conveniență pe o infrastructură proprietară. 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 software deschis 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 norul și DevOps, în ceea ce privește viteza și perturbarea?

Mișcarea actuală condusă de AI este foarte similară cu schimbările tehnologice anterioare. Când a apărut norul ca model de livrare, organizațiile care l-au tratat ca o alegere pur tehnologică au făcut greșeli foarte diferite față de 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 aceasta timp de ani în IT umbrit, depășiri de costuri și datorii tehnice și de securitate.

Ceea ce este diferit despre schimbarea actuală condusă de AI este viteza și invizibilitatea. Adoptarea norului a fost vizibilă. Știai când organizația ta migra încărcări de lucru de la premisă la nor. DevOps a fost vizibil: organizațiile restructurau echipe, schimbau fluxuri de implementare și rescriau procese. Instrumentele de codare AI sunt adoptate dezvoltator cu dezvoltator, apel de instrument cu apel de instrument, și riscul se acumulează în baza de cod înainte ca majoritatea organizațiilor să fi înregistrat că a fost luată o decizie de guvernanță.

Perturbarea este și asimetrică într-un mod în care norul și DevOps nu au fost. Aceste tranziții au creat noi categorii de risc, dar au păstrat în mare măsură ipoteza că un om a fost responsabil pentru codul livrat. AI erodează această ipoteză în punctul în care este cel mai greu de detectat. Acesta este ceea ce face această tranziție diferită. Expunerea este invizibilă până când nu mai este.

Multe companii luptă să transforme adoptarea software-ului deschis într-un model de afaceri durabil. Ce diferențiază companiile care reușesc de cele care eşuează?

Organizațiile care au construit afaceri durabile pe software deschis au o caracteristică comună: sunt disciplinate în ceea ce privește produsul pe care îl vând cu adevărat. Nu vând software-ul deschis, 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.

În schimb, 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 au nevoie cu adevărat. Traducerea de la adoptarea dezvoltatorilor la valoarea întreprinderii necesită construirea a ceva dincolo de software-ul deschis în sine, și organizațiile care nu 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ă.

În calitate de expert în scalarea organizațiilor axate pe dezvoltatori, care sunt cele mai mari provocări de conducere atunci când se face tranziția de la creșterea condusă de produs la operațiuni 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 recompensează 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 recompensează 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 presupunerea 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 nu este adesea echipa care poate executa mișcarea la scară de întreprindere. Recunoașterea acestui fapt fără a pierde ceea ce a făcut produsul valoros de cumpărat în primul rând este cu adevărat greu. Conducătorii care o fac bine sunt cei care sunt onești cu privire la care părți ale organizației trebuie să evolueze și care construiesc capacități 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 viteză și inovare cu nevoia crescândă de componente de 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 prin revizuirea codului după ce a fost scris. Nu prin scanarea artifactelor după ce au fost construite. Prin guvernarea a ceea ce intră în catalogul din care dezvoltatorii și instrumentele AI pot trage. 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 anticipați că va evolua rolul ecosistemelor de software deschis curate sau de încredere în următorii ani, pe măsură ce instrumentele AI generează cod și dependențe?

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

Primul este mediul regulamentar. În peisajul din 2026, demonstrarea provenienței software-ului devine din ce în ce mai mult o cerință legală, nu un standard voluntar. Consiliile de administrație și regulatorii pun întrebări care nu pot fi răspunse de organizațiile care trag direct din registre publice.

Al doilea este viteza de dezvoltare AI. Pe măsură ce instrumentele AI generează mai mult cod și trag mai multe dependențe, volumul de componente neverificate 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, guvernat de politici, ca sursă implicită pentru dezvoltatorii și instrumentele AI vor putea să țină pasul cu viteza AI cu guvernanță de securitate corespunzătoare. 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.

Ecosistemele 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 software-ului deschis și infrastructurii, 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 software deschis și infrastructură era suficient de scăzută încât excepțiile erau notabile. Acest lucru este mai puțin 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 poate însemna 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 unde avantajul operațional se manifestă în lucrare.

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 minunat. Citiitorii care doresc să afle mai multe ar trebui să viziteze ActiveState.