Abby Kearns, ActiveStaten toimitusjohtaja – Haastattelusarja

Abby Kearns on ActiveStaten toimitusjohtaja ja teknologiajohtaja, jolla on yli 25 vuoden kokemus yritysohjelmistojen rakentamisesta ja skaalauttamisesta. Hän toimi aiemmin Puppetin CTO:na, jossa hän auttoi strategisen muodonmuutoksen johdossa, joka päättyi yrityksen myyntiin Perforce Softwarelle. Uransa alussa hän oli Cloud Foundry Foundationin toimitusjohtaja, jossa hän johti yhden alan suurimman avoimen lähdekoodin pilvi-alustan kasvua. Abby on tällä hetkellä Akkan (entinen Lightbend) hallituksen jäsen. 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 tuotestrategiaksi ja yrityksen kasvuksi.

ActiveState on kanadalainen ohjelmistoyritys, joka perustettiin vuonna 1997 ja tarjoaa yrityksille työkaluja ja alustoja avoimen lähdekoodin ohjelmistojen kehittämiseen, hallintaan ja turvallisuuteen. Yrityksen keskeinen tuote, ActiveState-alusta, auttaa kehittäjiä, DevOps- ja turvallisuustiimejä automatisoimaan riippuvuuksien hallintaa, havaitsemaan ja korjaamaan haavoittuvuuksia sekä luomaan turvallisia ja toistettavia kehitysympäristöjä useilla ohjelmointikielillä, kuten Python, Perl ja Tcl. Toimittamalla esivalmistellut ja varmistetut avoimen lähdekoodin komponentit ja integroimalla ne olemassa oleviin työkulkuihin ActiveState pyrkii vähentämään turvallisuusriskejä ohjelmistojen toimitusketjussa ja parantamaan kehittäjien tuottavuutta sekä nopeuttaa sovellusten toimitusta.

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

Uran läpi kulkeva teema on ollut toimiminen yhteisön ja infrastruktuurin leikkauspisteessä silloin, kun ala tekee päätöksiä, jotka vaikuttavat vuosien ajan. Cloud Foundry oli sellainen hetki pilvi-alustoille. Puppet oli sellainen hetki konfiguraatiomanagementille ja DevSecOpsin varhaisille vaiheille. ActiveState on sellainen hetki avoimen lähdekoodin hallinnolle.

Mikä minua veti tänne, on ongelma, jota olen seurannut pitkään. Jokainen yritys, johon olen tutustunut, käyttää avoimen lähdekoodin ohjelmistoa. Useimmat eivät kuitenkaan voi kertoa, mitä avoimen lähdekoodin ohjelmistoa he käyttävät, onko se päivitetty tai kuka on vastuussa päätöksestä käyttää sitä. Tuo aukko, joka on syntynyt siitä, kuinka perustavanlaatuinen avoin lähdekoodi on, ja kuinka vähän järjestelmällisyyttä useimmat organisaatiot soveltavat sen hallinnassa, on siellä, missä alan riski kertyy. ActiveState on viettänyt kaksikymmentä vuotta rakentamassa infrastruktuuria, joka sulkee tämän aukon. Minun tehtäväni on varmistaa, että markkinat ymmärtävät, miksi tämän aukon sulkeminen on kiireellistä.

Visio tälle seuraavalle kasvuvaiheelle on selkeä: ActiveStatesta tulee oletusvastaus kysymykseen, mistä yritysten avoin lähdekoodi tulee. Ei skannaus. Ei raportti. Luotettu, varmistettu, jatkuvasti korjattu lähde, johon organisaatiot voivat viitata, kun sääntelijät, hallitukset tai vastuuvälineet kysyvät, miten he hallinnoivat ohjelmistojen toimitusketjua.

ActiveState asettaa itsensä kriittiseksi kerrokseksi ohjelmistojen toimitusketjun turvallisuudessa, kun tekoäly nopeuttaa koodin generointia. Miten tekoäly muuttaa perustavanlaatuiseen avoimen lähdekoodin ohjelmistojen riskiprofiilia?

Tekoälyavusteinen kehitys rikkoo perusoletuksen, jolle koko avoimen lähdekoodin hallintatyökalu on rakennettu: 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. Koodausvälineet, jotka ajavat tekoälyn omaksumista, tuottavuusvertailut, kehittäjien kyselyt, GitHub-tähdet, mikään näistä arviointikehyksistä ei sisällä turvallisuutta ensisijaisena mittarina. Ala optimoi nopeuden ja oikeellisuuden 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 riskejä, joita se esittää.

Olet sanonut, että hallitsematon avoin lähdekoodi on muuttumassa merkittäväksi yritysvuoriksi. Miksi avoimen lähdekoodin hallinta nousee nyt hallitustasolle, ja mitä johtajat aliarvioivat edelleen?

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

Mitä johtajat aliarvioivat edelleen, on se, että tämä on rakenteellinen ongelma, ei resurssiongelma. Organisaatiot, jotka reagoivat avoimen lähdekoodin riskiin lisäämällä enemmän skannausvälineitä, 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 epäkohteen. Organisaatiot, jotka selviävät tästä onnistuneesti, eivät ole niitä, jotka ostavat enemmän työkaluja. Ne ovat niitä, jotka muuttavat päätöksentekoa siitä, mitä avoimen lähdekoodin ohjelmistoa he ottavat ympäristöönsä, ja kuka on vastuussa näistä päätöksistä.

Avoimen lähdekoodin ollessa nyt upotettuna useimpien yritysten ohjelmistopinoihin, miten organisaatioiden tulisi ajatella avoimen lähdekoodin uudelleen infrastruktuurina eikä ainoastaan kehittämisen mukavuutena?

Mental modeli, josta useimmat organisaatiot lähtevät liikkeelle, on kymmenen vuoden vanha. Avoimen lähdekoodin ohjelmisto aloitti kehittämisen mukavuutena. Kehittäjät voivat vetää kirjastoja, liikkua nopeammin ja välttää peruskomponenttien uudelleenkeksimistä. Tämä viitekehyksen asettaminen oli järkevää, kun avoin lähdekoodi oli valinnainen ja täydentävä.

Tämä ei ole enää nykytilanne. Avoimen lähdekoodin ohjelmisto on modernin ohjelmiston perusta. 96 prosenttia sovelluksista sisältää avoimen lähdekoodin komponentteja. Se ei ole mukavuuden kerros perusinfrastruktuurin päällä. Se on infrastruktuuri. Ja infrastruktuurin on hallittava infrastruktuurina, jossa on selkeät käytäntöjä siitä, mitä ympäristöön otetaan, määritelty omistajuus ylläpidolle ja korjaamiselle sekä vastuu, joka sijaitsee oikealla tasolla organisaatiossa.

Organisaatiot, jotka ovat edellä tässä, ovat tehneet tietoisen siirtymisen: avoimen lähdekoodin kulutus on strateginen päätös, jolla on turvallisuuden ja taloudelliset seuraukset, eikä oletusarvo, jota kehittäjät hallinnoivat yksin. Tämä siirtymä vaatii käytäntöjä, operatiivisia prosesseja ja selkeää johtamisen vastuuta. Useimmat organisaatiot eivät ole vielä tehneet tätä siirtymää.

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

Nykyinen tekoälylle perustuva liike on hyvin samanlainen kuin aiemmat teknologiset siirtymät. Kun pilvi tuli toimitusmallina, organisaatiot, jotka käsittivät sen pelkästään teknologiana, tekivät erilaisia virheitä kuin ne, jotka tunnistivat sen arkkitehtoonisena ja operatiivisena siirtymänä. Ne, jotka eivät onnistuneet tekemään hallintasiirtymää, maksoivat siitä vuosien ajan varjopilvessä, kustannusylityksissä ja turvallisuuden ja teknisen velan suhteen.

Mikä on erilaista nykyisessä tekoälylle perustuvassa 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-putkistoa ja kirjoittivat prosesseja uudelleen. Tekoälykoodausvälineet omaksutaan kehittäjä kehittäjältä, työkalu kutsusta, ja riski kertyy koodipohjaan ennen kuin useimmat organisaatiot ovat rekisteröineet, että hallintopäätös tehtiin.

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

Organisaatiot, jotka ovat rakentaneet kestäviä liiketoimintamalleja avoimen lähdekoodin varaan, jakavat yhden ominaisuuden: he ovat kurinalaisia siinä, mitä tuotetta he 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 vetoon. Ne eivät ole sama asia. 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 yrityksen arvoon vaatii rakentamista avoimen lähdekoodin ohjelmistoa laajemmin, ja organisaatiot, jotka eivät tee tätä eroa selkeästi asemassaan, tuotteessaan ja myyntiliikkeessään, eivät yleensä selviä siirtymästä mittakaavaan.

Olet johtanut kehittäjien ensin -organisaatioita useiden kasvuvaiheiden läpi. Mitkä ovat suurimmat johtamisen haasteet siirtymässä tuotejohtaisesta kasvusta yrityskohtaiseen toimintaan?

Suurin haaste on, että ne taidot ja vaistot, jotka tekivät sinut onnistuneeksi tuotejohtaisessa kasvussa, työskentelevät sinua vastaan yrityskoossa. Tuotejohtainen kasvu palkitsee nopean liikkeen, julkisen iteroinnin, kehittäjäkokemuksen optimoinnin ja kaupallisen liikkeen, jota johtaa omaksuminen. Yrityskauppa palkitsee tarkoituksenmukaisen prosessin, johtajien suhteet, pitkät syklit ja kyvyn kytkeä tuotteen ostajien kannalta tärkeisiin tuloksiin, jotka eivät välttämättä 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, aseman, varhaiset asiakassuhteet, usein ei ole sama tiimi, joka voi suorittaa yrityskaupan. Tunnustaminen siitä, mitkä osat organisaatiosta tarvitsevat kehittyä, 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 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 vastakkain asettaminen on väärä valinta, joka on säilynyt, koska työkalut ovat vahvistaneet sen. Kun turvallisuus toteutetaan katselmuksena 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.

Nämä, jotka ovat ratkaisseet tämän jännityksen, ovat tehneet sen siirtämällä, missä turvallisuus tapahtuu. Ei katsomalla koodia sen jälkeen, kun se on kirjoitettu. Ei skannaamalla artefakteja sen jälkeen, kun ne 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 turvallisuuskatselmuksella, koska turvallisuustyö tapahtui virtausjoen yläpuolella. Se on arkkitehtuuripäätös, ei kulttuurinen. Se vaatii investointeja hallintainfrastruktuuriin, mutta se ei vaadi valintaa nopeuden ja turvallisen toimittamisen välillä.

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

Kuratoiden ja luotettavien avoimen lähdekoodin lähteiden rooli on siirtymässä hyvän käytännön vaatimuksesta pakolliseksi vaatimukseksi. Tämä siirtymä on ajettu kahteen asiaan, jotka eivät peruuta. Ensinnäkin sääntely-ympäristö. Vuoden 2026 maisemassa ohjelmistojen alkuperän osoittaminen on yhä enenevissä määrin lakisääteinen vaatimus, ei vapaaehtoinen standardi. Hallitukset ja sääntelijät kysyvät kysymyksiä, joille organisaatiot eivät voi vastata.

Toiseksi tekoälykehityksen nopeus. Kun tekoälytyökalut generoivat enemmän koodia ja vetävät enemmän riippuvuuksia, unohdettujen komponenttien määrä, joka tulee tuotantoon, ylittää nopeasti minkä tahansa organisaation kyvyn tarkastaa ne manuaalisesti. Organisaatiot, jotka ovat perustaneet kuratoidun, käytäntöjen mukaan hallitun katalogin oletusarvoisesti kehittäjilleen ja tekoälytyökaluilleen, voivat vastata tekoälyn nopeutta asianmukaisella turvallisuuden hallinnalla. Organisaatiot, jotka riippuvat edelleen julkisista rekistereistä ja manuaalisesta tarkastelusta, kohtaavat kasvavan aukon siinä, kuinka nopeasti koodi generoidaan ja kuinka perusteellisesti se arvioidaan.

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

Olet yksi harvoja naispuolisia toimitusjohtajia avoimen lähdekoodin ja infrastruktuurin alalla. Mitkä muutokset olet nähnyt johtajuuden monimuotoisuudessa vuosien varrella, ja mitä tarvitsee edelleen parantaa?

On tapahtunut todellista muutosta. Kun aloitin urani, naisten edustus johtajarooleissa 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 johtamistehtävissä, enemmän organisaatioita, jotka ovat siirtyneet näytellyn monimuotoisuusvakuutuksen vaiheesta 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, ohjelmistojen toimitusketjun riski, tekoälyn hallinta, organisaatiomuutokset, jotka tarvitaan, jotta turvallisuus on ensisijainen käytäntö, ovat vaikeita ongelmia. Monimuotoiset tiimit tuottavat parempia tuloksia vaikeissa ongelmissa. Ei toiveena vaan siitä, miten erilaiset näkökulmat paljastavat oletukset, joita yhdenmukaiset tiimit eivät huomaa. Olen nähnyt tämän suoraan. Organisaatiot, jotka ovat tehneet todellista edistystä kuuluvuudessa, eivät ainoastaan edustavuudessa, ovat niitä, joissa tämä operatiivinen etu näkyy työssä.

Kuuluvuus on edelleen epätasainen alan sisällä. Olla huoneessa ei ole sama asia kuin olla todella kuultu. Se ero on siellä, missä seuraava edistysaskel on tapahtumassa.

Kiitos hienosta haastattelusta, lukijat, jotka haluavat oppia enemmän, voivat vierailla ActiveStatessa.