Abby Kearns, CEO of ActiveState – Interview Series

Abby Kearns je CEO společnosti ActiveState a technologický manažer s více než 25 lety zkušeností s budováním a škálováním podnikových softwarových organizací. Předtím působila jako CTO ve společnosti Puppet, kde pomáhala vést strategickou transformaci, která vyvrcholila akvizicí společnosti Perforce Software. Na počátku své kariéry byla CEO Cloud Foundry Foundation, kde řídila růst jedné z největších open source cloudových platforem. Abby目前 působí v představenstvu společnosti Akka (dříve Lightbend). Je známá tím, že pomáhá společnostem překládat významné změny v cloudu, open source a AI do jasných produktových strategií a růstu podniků.

ActiveState je kanadská softwarová společnost založená v roce 1997, která poskytuje podnikové nástroje a platformy pro budování, správu a zabezpečení open source softwaru. Jeho hlavní nabídka, ActiveState Platform, pomáhá vývojářům, DevOps a bezpečnostním týmům automatizovat správu závislostí, detekovat a odstraňovat zranitelnosti a vytvářet bezpečné, reprodukovatelné vývojové prostředí napříč několika programovacími jazyky, jako je Python, Perl a Tcl. Dodáním předem sestavených, ověřených open source komponent a jejich integrací do stávajících pracovních postupů si ActiveState klade za cíl snížit bezpečnostní rizika v softwarovém dodavatelském řetězci, zatímco zlepšuje produktivitu vývojářů a urychluje dodání aplikací.

Vy jste strávila svou kariéru na rozhraní open source, cloud-native platforem a podnikové transformace, od vedení Cloud Foundry Foundation až po funkci CTO ve společnosti Puppet. Co vás přivedlo k tomu, aby jste přijala roli CEO ve společnosti ActiveState, a jaký je váš výhled pro společnost v této další fázi růstu?

Prostřednictvím mé kariéry je společným jmenovatelem působení na rozhraní komunity a infrastruktury v okamžicích, kdy průmysl činí rozhodnutí, která se budou sčítat po mnoho let. Cloud Foundry byl takový okamžik pro cloud-native. Puppet byl takový okamžik pro konfigurační management a rané fáze toho, co nyní nazýváme DevSecOps. ActiveState je takový okamžik pro open source governance.

To, co mě sem přivedlo, je problém, který jsem sledovala po dlouhou dobu. Každá společnost, se kterou jsem se setkala, běží na open source. Většina z nich nemůže s jistotou říci, jaký open source běží, zda byl opraven, nebo kdo je zodpovědný za rozhodnutí jej použít. Tato mezera mezi tím, jak zásadní se open source stal, a jak málo přísnosti většina organizací aplikuje na jeho governance, je místem, kde se průmyslův rizikum kumuluje. ActiveState strávil dvacet let budováním infrastruktury, aby tuto mezeru uzavřela. Moje práce spočívá v tom, aby trh pochopil, proč je její uzavření naléhavé.

Výhled pro tuto další fázi je jasný: ActiveState se stane výchozím řešením pro otázku, odkud pochází open source pro podniky. Ne skener. Ne zpráva. Důvěryhodný, ověřený, kontinuálně odstraňovaný zdroj, na který organizace mohou odkázat, když regulační orgány, představenstva nebo týmy pro řešení incidentů se ptají, jak spravovaly svůj softwarový dodavatelský řetězec.

ActiveState se позициuje jako kritická vrstva při zabezpečení softwarového dodavatelského řetězce v době, kdy AI urychluje generování kódu. Jak AI fundamentálně mění rizikový profil open source softwaru?

AI-pomocné vývojové nástroje porušují základní předpoklad, na kterém byla vybudována celá open source governance toolchain: že vývojář učinil úmyslné rozhodnutí zahrnout závislost.

Každá SBOM směrnice, každý SCA nástroj, každý workflow pro správu zranitelností předpokládá, že existoval člověk, který zvolil stažení knihovny. Když AI generuje kód, závislosti se dostanou do produkce, které nikdo nevybral, nepřezkoumal nebo dokonce neví, že tam jsou. Governance tooling hledá rozhodnutí. AI činí produkční změny, které zcela obcházejí rozhodnutí.

Existuje druhá vrstva. Kódovací nástroje, které poháněly přijetí AI, produktivní benchmarky, vývojářské průzkumy, GitHub hvězdičky, žádné z těchto hodnocení neobsahovaly bezpečnost jako primární měřítko. Průmysl se optimalizoval pro rychlost a správnost a dodal infrastrukturu bez toho, aby se ptal, zda výstup je bezpečný. To není selhání nástrojů. Je to selhání vedení v rozhodnutích o přijetí.

Vy jste řekla, že nespravovaný open source se stává významnou podnikovou zranitelností. Proč se open source governance stává otázkou pro představenstvo, a co výkonní ředitelé stále podceňují?

Dostává se to na představenstvo, protože regulační prostředí změnilo strukturu odpovědnosti. EU Kybernetický zákon o odolnosti, požadavky na zveřejňování SEC, pokyny CISA Secure by Design: tyto rámce mění otázku z “Měl jste skener?” na “Můžete prokázat, že váš software byl bezpečný v okamžiku svého původu?” To jsou velmi odlišné otázky, a většina organizací nemůže odpovědět na druhou otázku.

Co výkonní ředitelé stále podceňují, je to, že se jedná o strukturální problém, ne o problém zdrojů. Organizace, které reagují na riziko open source přidáním více skenovacích nástrojů, nevyřeší základní problém. Skenování detekuje problémy poté, co již vstoupily do vašeho prostředí.

Když je vše označeno, nic není prioritizováno, a objem upozornění se stává svou vlastní provozní dysfunkcí. Organizace, které tuto situaci zvládnou, nejsou ty, které kupují více nástrojů. Jsou to ty, které mění způsob, jakým činí rozhodnutí o tom, jaký open source vstoupí do jejich prostředí, a kdo je zodpovědný za tato rozhodnutí.

Jak by organizace měly přehodnotit open source jako infrastrukturu, a not only jako vývojářský komfort?

Mentální model, se kterým většina organizací pracuje, je deset let starý. Open source začal jako vývojářský komfort. Vývojáři mohli stahovat knihovny, pohybovat se rychleji a vyhnout se opakovanému vytváření základních komponent. Tohoto rámcování mělo smysl, když open source byl volitelný a doplňkový.

To již není aktuální realita. Open source je základem moderního softwaru. Šedesát šest procent aplikací obsahuje open source komponenty. Není to komfortní vrstva nad proprietární infrastrukturou. Je to infrastruktura. A infrastruktura musí být spravována jako infrastruktura, s explicitními zásadami pro to, co vstupuje do prostředí, definovaným vlastnictvím pro údržbu a odstraňování, a odpovědností, která leží na správné úrovni organizace.

Organizace, které jsou v tomto ohledu pokročilé, provedly úmyslnou změnu: spotřeba open source je strategické rozhodnutí s bezpečnostními a finančními důsledky, ne výchozí nastavení, které vývojáři spravují individuálně. Tato změna vyžaduje politiku, provozní proces a jasnou výkonnou odpovědnost. Většina organizací dosud tuto změnu neučinila.

Vy jste vedla organizace prostřednictvím několika technologických vln. Jak se aktuální AI-poháněná změna srovnává s předchozími přechody, jako je cloud a DevOps, z hlediska rychlosti a narušení?

Aktuální AI-poháněné hnutí je velmi podobné předchozím technologickým změnám. Když se cloud objevil jako dodavatelský model, organizace, které jej považovaly za čistě technologické rozhodnutí, udělaly velmi odlišné chyby než organizace, které rozpoznaly, že se jedná o architektonickou a provozní změnu. Ty, které selhaly při přechodu na governance, zaplatily za to po mnoho let v podobě stínového IT, nákladů a technického dluhu.

Co je odlišné o současné AI-poháněné změně, je rychlost a neviditelnost. Adopce cloudu byla viditelná. Věděli jste, kdy vaše organizace migrovala zátěže z on-prem do cloudu. DevOps byl viditelný: organizace reorganizovaly týmy, měnily nasazovací kanály a přepisovaly procesy. AI kódovací nástroje jsou přijímány vývojář po vývojáři, nástroj po nástroji, a riziko se kumuluje v kódu předtím, než většina organizací registrovala, že bylo učiněno rozhodnutí o governance.

Narušení je také asymetrické způsobem, který cloud a DevOps nebyly. Tyto přechody vytvořily nové kategorie rizika, ale většinou zachovaly předpoklad, že člověk byl zodpovědný za kód, který byl dodán. AI eroduje tento předpoklad v okamžiku, kdy je nejtěžší jej detekovat. To je to, co dělá tuto změnu odlišnou. Expozice je neviditelná, dokud není.

Mnohé společnosti mají potíže s tím, aby z open source adopce vytvořily udržitelný obchodní model. Co odlišuje společnosti, které se daří, od těch, které selhávají?

Organizace, které vybudovaly udržitelné podniky na open source, sdílejí jednu charakteristiku: jsou disciplinované v tom, jaký produkt vlastně prodávají. Neprodávají open source software, který je zdarma. Prodávají odborné znalosti, provozní podporu, governance infrastrukturu nebo spravovanou službu, která dělá zdarma software životaschopným na podnikové úrovni.

Naopak organizace, které selhávají, tendují k tomu, aby splývaly komunitní adopci s komerčním tahem. Není to totéž. Vysoký počet GitHub hvězdiček nebo velká komunita signalizuje, že vývojáři považují projekt za užitečný. Neznačí to, že kupující budou platit za něj, nebo že věc, kterou vývojáři považují za užitečnou, je tím, co organizace skutečně potřebují. Překládání z vývojářské adopce na podnikovou hodnotu vyžaduje budování něčeho nad rámec open source samotného, a organizace, které nečiní tento rozdíl jasně ve svém позиčním prohlášení, produktu a prodejním pohybu, tendují k tomu, aby nepřežily přechod na škálovatelnost.

Z vašich zkušeností se škálováním vývojářských organizací, jaké jsou největší výzvy pro vedení při přechodu od produktově vedeného růstu k podnikovému měřítku?

Největší výzvou je to, že dovednosti a instinkty, které vás učinily úspěšnými v produktově vedeném růstu, pracují proti vám na podnikovém měřítku. Produktově vedený růst odměňuje rychlé pohyby, iterace ve veřejném prostoru, optimalizaci pro vývojářské zkušenosti a umožnění adopci vést komerční pohyb. Podnikový prodej odměňuje úmyslný proces, výkonné vztahy, dlouhé cykly a schopnost mapovat váš produkt na výsledky, které záleží na kupujících, kteří nejsou vývojáři.

Chyba vedení, kterou nejčastěji vidím, spočívá v tom, že se předpokládá, že přechod je primárně problémem prodejního pohybu. Není to tak. Je to problém organizačního designu. Tým, který postavil produkt, pozici a rané zákaznické vztahy, často není týmem, který může provést podnikový pohyb. Rozpoznání toho, aniž by se ztratilo to, co učinilo produkt kupovatelným, je skutečně obtížné. Lídři, kteří to dělají dobře, jsou ti, kteří jsou upřímní o tom, které části organizace potřebují evolucí a kteří budují nové schopnosti bez demontáže kultury, která vytvořila produkt.

Vy jste pracovala extenzivně na rozhraní bezpečnosti a vývojářské produktivity. Jak mohou společnosti vyvážit rychlost a inovace s rostoucí potřebou bezpečných a důvěryhodných softwarových komponent?

Rámcování rychlosti versus bezpečnosti je falešnou volbou, která přetrvává, protože nástroje ji posílily. Když je bezpečnost implementována jako kontrolní brána na konci vývojového procesu, je to úzké místo. Když je implementována jako spravovaný zdroj důvěryhodných komponent, které vývojáři stahují na začátku procesu, nezpomaloňuje to nic.

Ty, kteří vyřešili tento napětí, udělali to tak, že posunuli, kde bezpečnost nastává. Nekontrolují kód po jeho sepsání. Neskenují artefakty po jejich sestavení. Spravují, co vstupuje do katalogu, ze kterého vývojáři a AI nástroje stahují. Pokud je zdroj důvěryhodný, rychlost není omezena bezpečnostní kontrolou, protože bezpečnostní práce proběhla po proudu. To je architektonické rozhodnutí, ne kulturní. Vyžaduje investice do governance infrastruktury, ale nevyžaduje volbu mezi rychlým pohybem a bezpečným dodáním.

Jak vidíte roli kultivovaných nebo důvěryhodných open source ekosystémů v průběhu příštích několika let, když AI nástroje stále více generují kód a závislosti?

Role kultivovaných, důvěryhodných open source zdrojů se bude posouvat z nejlepší praxe na základní požadavek. Tato změna je poháněna dvěma věcmi, které se nebudou vracet.

První je regulační prostředí. V roce 2026 bude schopnost prokázat software provenience stále více právní požadavkem, ne dobrovolným standardem. Představenstva a regulační orgány kladou otázky, na které organizace nemohou odpovědět, pokud stahují přímo z veřejných registrů.

Druhá je AI vývojová rychlost. Když AI nástroje generují více kódu a stahují více závislostí, objem nekонтrolovaných komponent, které vstupují do produkce, překročí kapacitu jakékoliv organizace ručně je přezkoumat. Organizace, které zavedly kultivovaný, politicky řízený katalog jako výchozí zdroj pro své vývojáře a AI nástroje, budou moci AI rychlost vyrovnat s odpovídající bezpečnostní governance. Organizace, které stále spoléhají na veřejné registry a manuální kontrolu, budou čelit rozšiřující se mezery mezi tím, jak rychle je kód generován, a jak důkladně je hodnocen.

Kultivované ekosystémy jsou infrastrukturní odpovědí na problém, který AI vývoj učinil nevyhnutelným.

Jako jedna z mála žen-CEO v open source a infrastrukturním prostoru, jaké změny jste viděla v leadershipu diverzity v průběhu let, a co ještě potřebuje zlepšit?

Došlo k skutečné změně. Když jsem začala svou kariéru, zastoupení žen ve výkonných rolích v open source a infrastruktuře bylo dostatečně nízké, aby byly výjimky pozoruhodné. To již není pravda. Existuje více žen ve seniorních technických a výkonných pozicích, více organizací, které přešly od prohlášení o diverzitě k provádění strukturálních změn, a více modelů pro to, co může vedení v tomto prostoru vypadat.

Obchodní případ pro uzavření zbývající mezery není abstraktní. Problémy, se kterými tento průmysl nyní pracuje, rizika softwarového dodavatelského řetězce, AI governance, organizační změny vyžadované k tomu, aby se bezpečnost stala první prioritou, jsou obtížné. Diverzifikované týmy produkují lepší výsledky u obtížných problémů. Ne jako otázka aspirace, ale jako otázka toho, jak různé perspektivy odhalují předpoklady, které homogenní týmy přehlížejí. Viděla jsem to přímo. Organizace, které udělaly skutečný pokrok v oblasti příslušnosti, ne pouze reprezentace, jsou ty, kde se tato provozní výhoda projevuje v práci.

Přslušnost je stále nerovnoměrná v celém průmyslu. Být v místnosti není totéž jako mít váš názor skutečně zvážen. To je místo, kde další fáze pokroku potřebuje nastat.