Abby Kearns, ActiveStaten toimitusjohtaja – Haastattelu

Abby Kearns on ActiveStaten toimitusjohtaja ja teknologiajohtaja, jolla on yli 25 vuoden kokemus yritysohjelmistoyhtiöiden rakentamisesta ja skaalauksesta. Hän toimi aiemmin Puppetin CTO:na, jossa hän auttoi johtamaan strategisen muodonmuutoksen, joka päättyi yhtiön omistusoikeuden siirtymiseen Perforce Softwarelle. Uransa alussa hän toimi Cloud Foundry Foundationin toimitusjohtajana, jossa hän ohjasi yhden alan suurimman avoimen lähdekoodin pilvi-alustan ekosysteemin kasvua. Abby palvelee tällä hetkellä Akkan (entinen Lightbend) hallituksessa. Hänet tunnetaan siitä, että hän auttaa yrityksiä kääntämään merkittäviä muutoksia pilvessä, avoimessa lähdekoodissa ja tekoälyssä selkeäksi tuote-strategiaksi ja yrityksen kasvuuksi.

ActiveState on kanadalainen ohjelmistoyhtiö, joka perustettiin vuonna 1997 ja tarjoaa yrityksille työkaluja ja alustoja avoimen lähdekoodin ohjelmistojen luomiseen, hallintaan ja turvallisuuteen. Sen ydin tuote, ActiveState-alusta, auttaa kehitys-, DevOps- ja turvallisuustiimejä automatisoimaan riippuvuuksien hallinnan, havaitsemaan ja korjaamaan haavoittuvuuksia sekä luomaan turvallisia, toistettavia kehitysympäristöjä useilla ohjelmointikielillä, kuten Python, Perl ja Tcl. Toimittamalla esikokoitetut, vahvistetut avoimen lähdekoodin komponentit ja integroimalla ne olemassa oleviin työnkulkuihin ActiveState pyrkii vähentämään turvallisuusriskejä ohjelmistotoimitusketjussa parantaen samalla kehittäjien tuottavuutta ja nopeuttaen sovelluksen toimituksen.

Olet viettänyt urasi avoimen lähdekoodin, pilvi-alustojen ja yritysten muodonmuutoksen risteyksessä, Cloud Foundry Foundationin johdosta Puppetin CTO:ksi. Mikä veti sinut ActiveStatessa toimitusjohtajan rooliin, ja mikä on visiosi yhtiön seuraavassa kasvuvaiheessa?

Urani läpi kulkeva teema on ollut toimiminen yhteisön ja infrastruktuurin leikkauspisteessä silloin, kun ala tekee päätöksiä, jotka tulevat kertautumaan vuosien varrella. Cloud Foundry oli se hetki pilvi-alustoille. Puppet oli se hetki konfiguraatiomanagementille ja DevSecOpsin varhaisille vaiheille, mitä nyt kutsutaan. ActiveState on se hetki avoimen lähdekoodin hallinnolle.

Mikä minuun vetoaa, on ongelma, jota olen seurannut pitkään. Jokainen yritys, jota olen tavannut, toimii avoimen lähdekoodin avulla. Useimmat eivät voi kuitenkaan kertoa minulle luottavaisesti, mitä avoimen lähdekoodin ohjelmistoa he käyttävät, onko se päivitetty, tai kuka on vastuussa päätöksestä sen käytöstä. Tuo kuilu, joka on syntynyt siitä, kuinka perustavanlaatuinen avoin lähdekoodi on, ja kuinka vähän järjestelmällisyyttä useimmat organisaatiot soveltavat sen hallintaan, on siellä, missä alan riski kertyy. ActiveState on viettänyt kaksikymmentä vuotta rakentamassa infrastruktuuria, joka sulkee tämän kuilun. Minun tehtäväni on varmistaa, että markkina ymmärtää, miksi sen sulkeminen on kiireellistä.

Visio tulevasta kasvuvaiheesta on selkeä: ActiveStatesta tulee oletusvastaus kysymykseen, mistä yritysten avoin lähdekoodi tulee. Ei skannaus. Ei raportti. Luotettu, vahvistettu, jatkuvasti korjattu lähde, johon organisaatiot voivat viitata, kun sääntelijät, hallitukset tai vastuuvakuutuspyynnöt kysyvät, miten he hallinnoivat ohjelmistonsa toimitusketjua.

ActiveState asettuu kriittiseksi kerrokseksi ohjelmistotoimitusketjun turvallisuudessa aikana, jolloin tekoäly nopeuttaa koodin generointia. Miten tekoäly muuttaa perustavanlaatuista avoimen lähdekoodin ohjelmistojen riskiprofiilia?

Tekoälyavusteinen kehitys rikkoo perustavanlaatuisen oletuksen, jolle koko avoimen lähdekoodin hallintatyökalu on perustunut: että kehittäjä on tehnyt tietoisen päätöksen sisällyttää riippuvuus.

Jokainen SBOM-määräys, jokainen SCA-työkalu, jokainen haavoittuvuuden hallintatyökalu olettaa, että ihminen on valinnut kirjaston. Kun tekoäly generoi koodia, riippuvuudet saapuvat tuotantoon, joita kukaan ei ole valinnut, tarkastanut tai useissa tapauksissa edes tiedä, että ne ovat siellä. Hallintatyökalut etsivät päätöksiä. Tekoäly tekee tuotantoon muutoksia, jotka ohittavat päätöksen kokonaan.

On toinen kerros tähän. Koodityökalut, jotka ajavat tekoälyn omaksumista, tuottavuusvertailut, kehittäjien kyselyt, GitHub-tähdet, mikään näistä arviointikehyksistä ei sisältänyt turvallisuutta ensisijaisena mittarina. Ala optimoi nopeudelle ja oikeellisuudelle ja toimitti infrastruktuurin ilman kysymystä, onko tuotos turvallinen. Se ei ole työkaluvirhe. Se on johtamisvirhe siinä, miten omaksumispäätökset tehtiin. Toimimme nyt mittakaavassa perustalla, jota ei koskaan arvioitu riskeistä, joita se esittää.

Kerroit, että hallitsematon avoin lähdekoodi muodostuu suureksi yritysvuikutukseksi. Miksi avoimen lähdekoodin hallinta nousee nyt hallitustasolle, ja mitä johtajat yhä aliarvioivat?

Se saavuttaa hallituksen, koska sääntely-ympäristö on muuttunut vastuu-rakennetta. EU:n kyberresilienssi-asetus, SEC:n ilmoitusvaatimukset, CISA:n suunniteltu suunnittelu: nämä kehykset siirtävät kysymyksen “Oletko skannannut?” kysymykseen “Voitko todistaa, että ohjelmistosi oli turvallinen alkuperästä?” Nämä ovat erilaisia kysymyksiä, ja useimmat organisaatiot eivät voi vastata jälkimmäiseen.

Mitä johtajat yhä aliarvioivat, on se, että tämä on rakenteellinen ongelma, ei resurssointiongelma. Organisaatiot, jotka vastaavat avoimen lähdekoodin riskiin ostamalla lisää skannaus-työkaluja, eivät ratkaise perusongelmaa. Skannaus havaitsee ongelmat sen jälkeen, kun ne ovat jo päässeet ympäristöön.

Kun kaikki on merkitty, mitään ei priorisoida, ja hälytysten määrä muodostaa oman toiminnallisen dysfunktionsa. Organisaatiot, jotka selviävät tästä onnistuneesti, eivät ole niitä, jotka ostavat enemmän työkaluja. Ne ovat niitä, jotka muuttavat sitä, miten he tekevät päätöksiä siitä, minkä avoimen lähdekoodin he ottavat ympäristöönsä, ja kuka on vastuussa näistä päätöksistä.

Avoimen lähdekoodin ollessa upotettuna useimpiin yritysohjelmistopinoihin, miten organisaatioiden tulisi uudelleenarvioida avoimen lähdekoodin infrastruktuurina eikä ainoastaan kehitystyönä?

Mental-malli, josta useimmat organisaatiot toimivat, on kymmenen vuoden takainen. Avoin lähdekoodi alkoi kehitystyönä. Kehittäjät voivat vetää kirjastoja, liikkua nopeammin ja välttää peruskomponenttien uudelleenkeksimistä. Tämä kehys oli järkevä, kun avoin lähdekoodi oli valinnainen ja täydentävä.

Tämä ei ole enää nykytilanne. Avoin lähdekoodi on modernin ohjelmiston perusta. 96 prosenttia sovelluksista sisältää avoimen lähdekoodin komponentteja. Se ei ole mukavuuskerros perinteisen infrastruktuurin päällä. Se on infrastruktuuri. Ja infrastruktuurin on hallittava infrastruktuurin tavoin, selkeiden käytäntöjen kera siitä, mitä ympäristöön otetaan, määritellyn omistajuuden kera ylläpidolle ja korjaamiselle, ja vastuulla, joka on oikealla tasolla organisaatiossa.

Organisaatiot, jotka ovat edellä tässä, ovat tehneet tietoisen siirtymän: avoimen lähdekoodin kulutus on strateginen päätös, jolla on turvallisuus- ja taloudellisia seuraamuksia, ei oletusasetus, jota kehittäjät hallinnoivat yksin. Tämä siirtymä vaatii käytäntöjä, operatiivisia prosesseja ja selkeää johtamisvastuuta. Useimmat organisaatiot eivät ole vielä tehneet tätä siirtymää.

Olet johtanut organisaatioita useiden teknologia-aaltojen läpi. Miten nykyinen tekoälyllä ajettu siirtymä vertautuu aiempiin siirtymiin, kuten pilveen ja DevOpsiin, nopeuden ja häirinnän suhteen?

Nykyinen tekoälyllä ajettu liike on hyvin samanlainen kuin aiemmat teknologiset siirtymät. Kun pilvi nousi toimitusmallina, organisaatiot, jotka käsittivät sen pelkästään teknologiana, tekivät erilaisia virheitä kuin ne, jotka tunnistivat sen arkkitehtuurisena ja operatiivisena siirtymänä. Ne, jotka epäonnistuivat tekemään hallintasiirtymän, maksoivat siitä vuosien ajan varjossa olevalla IT:llä, kustannusylityillä, turvallisuus- ja teknisellä velalla.

Mikä on erilaista nykyisessä tekoälyllä ajatussa siirtymässä, on nopeus ja näkymättömyys. Pilven omaksuminen oli näkyvää. Tiesit, kun organisaatiosi siirsi työmäärää paikallisesti pilveen. DevOps oli näkyvää: organisaatiot uudelleenjärjestivät tiimejä, muuttivat käyttöönotto-prosesseja ja uudelleenkirjoittivat prosesseja. Tekoälykoodityökalut ovat omaksuttavissa kehittäjä kerrallaan, työkalu kerrallaan, ja riski kertyy koodipohjaan ennen kuin useimmat organisaatiot ovat rekisteröineet, että hallintapäätös on tehty.

Häiriö on epäsymmetrinen tavalla, joka pilvi ja DevOps eivät olleet. Nämä siirtymät loivat uusia riskiluokkia, mutta säilyttivät oletuksen, että ihminen oli vastuussa toimitetusta koodista. Tekoäly kuluttaa tämän oletuksen siinä vaiheessa, jossa se on vaikeinta havaita. Se on se, mikä tekee tämän siirtymän erilaiseksi. Altis on näkymätön, kunnes se ei ole.

Monet yritykset kamppailevat avoimen lähdekoodin omaksumisen kestävän liiketoimintamallin luomisessa. Mitä erottaa yritykset, jotka onnistuvat, niistä, jotka epäonnistuvat?

Organisaatiot, jotka ovat luoneet kestäviä liiketoimintamalleja avoimen lähdekoodin avulla, jakavat yhden ominaisuuden: he ovat kurinalaisia siinä, mitä tuotetta he todella myyvät. He eivät myy avoimen lähdekoodin ohjelmistoa, joka on ilmainen. He myyvät asiantuntemusta, operatiivista tukea, hallintainfrastruktuuria tai hallittua palvelua, joka tekee ilmaisen ohjelmiston toimivaksi yrityskoossa.

Toisaalta organisaatiot, jotka epäonnistuvat, sekoittavat usein yhteisön omaksumisen kaupalliseen vauhtiin. Ne eivät ole samaa. Korkea GitHub-tähtiluku tai suuri yhteisö merkitsee, että kehittäjät pitävät projektiista. Se ei merkitse, että ostajat maksavat siitä, tai että se, mitä kehittäjät pitävät hyödyllisenä, on se, mitä organisaatiot todella tarvitsevat. Käännös kehittäjien omaksumisesta yritysarvoon vaatii rakentamista jotain avoimen lähdekoodin itse lisäksi, ja organisaatiot, jotka eivät tee tämän eron selkeästi asemansa, tuotteensa ja myyntiliikkeensä suhteen, eivät yleensä selviä siirtymästä mittakaavaan.

Johtajan kokemuksesi kehittäjien ensin -organisaatioiden skaalauksesta, mitkä ovat suurimmat johtamishaasteet siirtymässä tuotejohtoiseen kasvuun yrityskohtaiseen toimintaan?

Suurin haaste on, että taidot ja vaistot, jotka tekivät sinut onnistuneeksi tuotejohtoisessa kasvussa, työskentelevät sinua vastaan yrityskoossa. Tuotejohtoinen kasvu palkitsee nopean liikkeen, iteroinnin julkisesti, optimoinnin kehittäjäkokemukselle ja omaksumisen johtamiselle kaupalliseen liikkeeseen. Yritysmyynti palkitsee tarkoituksenmukaisen prosessin, johtajien suhteet, pitkät syklit ja kyvyn kartoittaa tuotetta tuloksiin, jotka ovat tärkeitä ostajille, jotka eivät ole kehittäjiä.

Johtamisvirhe, jota näen useimmin, on oletus, että siirtymä on pääasiassa myyntiliikkeen ongelma. Se ei ole. Se on organisaatiomuotoilun ongelma. Tiimi, joka rakensi tuotteen, asemoinnin ja varhaiset asiakassuhteet, ei usein ole sama tiimi, joka voi suorittaa yritysliikkeen. Tunnustaminen ilman menettämistä sitä, mikä teki tuotteen ostettavaksi, on todella vaikeaa. Johtajat, jotka tekevät sen hyvin, ovat niitä, jotka ovat rehellisiä siitä, mitkä osat organisaatiosta tarvitsevat kehittyä, ja jotka rakentavat uudet kyvyt ilman kulttuurin purkamista, joka loi tuotteen.

Olet työskennellyt laajasti turvallisuuden ja kehittäjien tuottavuuden leikkauspisteessä. Miten yritykset voivat tasapainottaa nopeuden ja innovaation kasvavan tarpeen turvallisten ja luotettavien ohjelmistokomponenttien kanssa?

Nopeuden ja turvallisuuden välinen kuvaus on väärä valinta, jota työkalut ovat vahvistaneet. Kun turvallisuus toteutetaan tarkastusporttina kehitysprosessin lopussa, se on pullonkaula. Kun se toteutetaan hallituna lähteenä luotettavista komponenteista, joita kehittäjät vetävät prosessin alussa, se ei hidasta mitään.

Ne, jotka ovat ratkaisseet tämän jännityksen, ovat tehneet sen siirtämällä turvallisuutta tapahtumaan. Ei koodin tarkastamista sen kirjoittamisen jälkeen. Ei skannauksen tekemistä sen jälkeen, kun se on rakennettu. Hallitsemalla, mitä katalogiin otetaan, josta kehittäjät ja tekoälytyökalut vetävät. Jos lähde on luotettava, nopeus ei ole rajoitettu turvallisuustarkastuksella, koska turvallisuustyö tapahtui jo aiemmin. Se on arkkitehtuuri-päätös, ei kulttuurinen. Se vaatii investointeja hallintainfrastruktuuriin, mutta se ei vaadi valintaa nopeuden ja turvallisen toimittamisen välillä.

Kun tekoälytyökalut lisäävät koodin ja riippuvuuksien generointia, miten näet kuratoiden tai luotettavien avoimen lähdekoodin ekosysteemien roolin kehittyvän seuraavien vuosien aikana?

Kuratoiden, luotettavien avoimen lähdekoodin lähteiden rooli tulee siirtymään parhaisiin käytäntöihin perusvaatimukseksi. Tämä siirtymä on ajettu kahteen asiaan, jotka eivät peruuta.

Ensimmäinen on sääntely-ympäristö. Vuoden 2026 maisemassa ohjelmistoperäisen alkuperän osoittaminen on yhä enenevissä määrin lakisääteinen vaatimus, ei vapaaehtoinen standardi. Hallitukset ja sääntelijät kysyvät kysymyksiä, joita organisaatiot eivät voi vastata, jos ne vetävät suoraan julkisista rekistereistä.

Toinen on tekoälykehitetty nopeus. Kun tekoälytyökalut generoivat enemmän koodia ja riippuvuuksia, määrä tarkastamattomia komponentteja, jotka tulevat tuotantoon, ylittää minkä tahansa organisaation kyvyn tarkastaa ne manuaalisesti. Organisaatiot, jotka ovat perustaneet kuratoidun, käytäntöjen mukaisen katalogin oletuslähteeksi kehittäjilleen ja tekoälytyökaluilleen, voivat vastata tekoälyn nopeudella sopivalla turvallisuuden hallinnalla. Organisaatiot, jotka vielä riippuvat julkisista rekistereistä ja manuaalisesta tarkastelusta, kohtaavat kasvavan kuilun siinä, kuinka nopeasti koodi generoidaan ja kuinka perusteellisesti se arvioidaan.

Kuratoidut ekosysteemit ovat infrastruktuurivastaus ongelmaan, jonka tekoälykehitetty toiminta on tehnyt välttämättömäksi.

Kun yksi harvoista naisjohtajista avoimen lähdekoodin ja infrastruktuurin alalla, mitkä muutokset olet nähnyt johtamisen monimuotoisuudessa vuosien varrella, ja mitä tarvitaan vielä parantamista?

On tapahtunut todellista muutosta. Kun aloitin urani, naisten edustus johtajuuksissa avoimen lähdekoodin ja infrastruktuurin alalla oli niin alhainen, että poikkeukset olivat merkittäviä. Se ei ole enää totta. On enemmän naisia johtavissa teknisissä ja johtajuuksissa, enemmän organisaatioita, jotka ovat siirtymässä diversity-lauselmien yli ja jotka tekevät rakenteellisia muutoksia, ja enemmän malleja siitä, miltä johtajuus tässä alalla voi näyttää.

Liiketoimintatapaus monimuotoisuuden sulkemiseksi ei ole abstrakti. Ongelmat, joilla tämä alan on parhaillaan, ohjelmistotoimitusketjun riski, tekoälyn hallinta, organisaatiomuutokset, jotka ovat tarpeen, jotta turvallisuus voi olla ensisijainen käytäntö, ovat vaikeita ongelmia. Monimuotoiset tiimit tuottavat parempia tuloksia vaikeista ongelmista. Ei aspiraationa, vaan siitä, miten erilaiset näkökulmat paljastavat oletukset, joita homogeeniset tiimit eivät huomaa. Olen nähnyt tämän suoraan. Organisaatiot, jotka ovat tehneet todellista edistystä kuuluvuudessa, eivät ainoastaan edustavuudessa, ovat ne, joissa tämä operatiivinen etu näkyy työssä.

Kuuluvuus on edelleen epätasainen koko alalla. Olla huoneessa ei ole sama kuin että näkemyksesi otetaan tosissaan. Tuo ero on se, missä seuraava vaihe edistystä tarvitaan.

Kiitos haastattelusta, lukijat, jotka haluavat oppia lisää, kannattaa vierailla ActiveState:ssa.