Abby Kearns, generální ředitelka ActiveState – Rozhovor

Abby Kearns je generální ředitelka ActiveState a technologický manažer s více než 25 lety zkušeností s budováním a rozvojem podnikových softwarových organizací. Předtím působila jako technický ředitel Puppet, kde pomohla vést strategickou transformaci, která vyvrcholila akvizicí společnosti Perforce Software. V počátcích své kariéry byla generální ředitelkou Cloud Foundry Foundation, kde vedla růst jedné z největších open source cloudových platforem. Abby目前 působí v představenstvu Akka (dříve Lightbend). Je známa 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áváním předem sestavených, ověřených open source komponent a jejich integrací do stávajících pracovních postupů se ActiveState snaží snížit bezpečnostní rizika v softwarovém dodavatelském řetězci, zatímco zvyš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 technického ředitele v Puppet. Co vás přimělo vzít na sebe roli generální ředitelky 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 fungování na rozhraní komunity a infrastruktury v okamžicích, kdy se průmysl rozhoduje o věcech, které se budou kumulovat po mnoho let. Cloud Foundry byl takový okamžik pro cloud-native. Puppet byl takový okamžik pro správu konfigurace a rané fáze toho, co nyní nazýváme DevSecOps. ActiveState je takový okamžik pro open source governance.

Co mě sem přivedlo, je problém, který jsem sledovala po dlouhou dobu. Každá podniková 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ím se open source stal, a jak málo organizací aplikuje na jeho řízení rigor, je tam, kde se průmyslův rizik kumuluje. ActiveState strávil dvacet let budováním infrastruktury, aby tuto mezeru uzavřela. Moje práce je zajistit, aby trh pochopil, proč je uzavření této mezery naléhavé.

Výhled pro tuto další fázi je jasný: ActiveState se stane výchozím zdrojem pro open source v podnikové sféře. Ne skener. Ne zpráva. Důvěryhodný, ověřený, neustále odstraňovaný zdroj, na který se organizace mohou odvolat, když regulátoři, představenstvo nebo respondenti na incidenty se zeptají, jak řídily 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 celá open source governance toolchain postavena: ž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 tohoto problému. Nástroje pro kódování, které poháněly přijetí AI, produktivitní benchmarky, vývojářské průzkumy, GitHub hvězdy, žádné z těchto evaluačních rámců nezahrnovaly bezpečnost jako primární měřítko. Průmysl optimalizoval pro rychlost a správnost a dodal infrastrukturu bez toho, aby se zeptal, zda výstup byl bezpečný. To není selhání nástrojů. Je to selhání vedení v tom, jak byly přijímány rozhodnutí o přijetí.

Vy jste řekla, že neřízený open source se stává významnou podnikovou zranitelností. Proč se open source governance nyní dostává na úroveň představenstva a co výkonní ředitelé stále podceňují?

Dostává se tam, protože se změnil regulační prostředí. EU Kybernetický zákon, požadavky na zveřejnění SEC, pokyny CISA pro Secure by Design: tyto rámce mění otázku z “Měl jste skener?” na “Můžete prokázat, že váš software byl zabezpečen v okamžiku jeho vzniku?” To jsou velmi odlišné otázky a většina organizací nemůže odpovědět na tu druhou.

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 open source riziko 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á sám o sobě operační 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 vstupuje 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ářskou výhodu?

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

To není aktuální realita. Open source je základem moderního softwaru. Devadesát šest procent aplikací obsahuje open source komponenty. Není to výhoda nad proprietární infrastrukturou. Je to infrastruktura. A infrastruktura musí být řízena 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 zodpovědností, která sedí na správné úrovni organizace.

Organizace, které jsou v tomto směru pokročilejší, 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 individuálně spravují. Tato změna vyžaduje zásady, provozní procesy a jasnou výkonnou zodpovědnost. Většina organizací dosud tuto změnu neučinila.

Vy jste vedla organizace přes několik 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ý pohyb 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é jej rozpoznaly jako architektonickou a provozní změnu. Ty, které selhaly při přechodu na governance, zaplatily za to po mnoho let v podobě shadow IT, nákladových přebytků a bezpečnostních a technických dluhů.

Co je odlišné o aktuální AI-poháněné změně, je rychlost a neviditelnost. Přijetí cloudu bylo viditelné. Věděli jste, kdy vaše organizace migrovala úkoly z lokality do cloudu. DevOps byl viditelný: organizace restrukturalizovaly týmy, měnily nasazení 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, 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 rizik, alelargely zachovaly předpoklad, že člověk byl zodpovědný za kód, který byl dodán. AI podkopává tento předpoklad v okamžiku, kdy je nejtěžší jej detekovat. To je to, co dělá tento přechod odlišným. Expozice je neviditelná, dokud není.

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

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

Naproti tomu organizace, které selhávají, tendují k tomu, aby splývaly komunitní přijetí s komerčním tahem. Není to totéž. Vysoký počet hvězd na GitHub nebo velká komunita signalizuje, že vývojáři považují projekt za užitečný. Nesignalizuje to, že kupující zaplatí 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řevod z vývojářského přijetí na podnikovou hodnotu vyžaduje budování něčeho nad rámec open source samotného, a organizace, které selhávají při tomto rozlišování jasně, ve svém позиčním prohlášení, produktu a prodejním pohybu, tendují k tomu, aby nepřežily přechod na škálu.

Z vašich zkušeností se škálováním vývojářských organizací, jaké jsou největší výkonné výzvy při přechodu z produktově vedeného růstu na podnikovou škálu?

Největší výzvou je to, že dovednosti a instinkty, které vás činily úspěšnými v produktově vedeném růstu, pracují proti vám na podnikové úrovni. 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í přijetí 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é jsou důležité pro kupující, kteří nejsou vývojáři.

Výkonná chyba, kterou nejčastěji vidím, je předpoklad, že přechod je primárně prodejním problémem. Není to tak. Je to problém organizačního designu. Tým, který vybudoval produkt, позиční prohlášení a rané zákaznické vztahy, často není tím týmem, který může provést podnikový pohyb. Rozpoznání toho, aniž byste ztratili to, co učinilo produkt worth kupujícího, je skutečně obtížné. Výkonní, kteří to dělají dobře, jsou ti, kteří jsou upřímní o tom, které části organizace potřebují evoluci, 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ámec rychlosti versus bezpečnosti je falešnou volbou, která přetrvává, protože tooling ji posílil. 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 řízený zdroj důvěryhodných komponent, které vývojáři čerpají na začátku procesu, nezdržuje to nic.

Ty, kteří vyřešili tento napětí, udělali to tak, že změnili, kde se bezpečnost děje. Nekontrolovali kód po jeho napsání. Neskenovali artefakty po jejich sestavení. Řídili, co vstupuje do katalogu, ze kterého vývojáři a AI nástroje čerpají. Pokud je zdroj důvěryhodný, rychlost není omezena bezpečnostní kontrolou, protože bezpečnostní práce proběhla výše. 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 měnit z nejlepší praxe na základní požadavek. Tato změna je poháněna dvěma věcmi, které se nebudou měnit.

První je regulační prostředí. V roce 2026 bude schopnost prokázat software provenience stále více právní požadavek, ne dobrovolný standard. Představenstva a regulátoři budou klást otázky, na které většina organizací nemůže odpovědět.

Druhé je AI vývojová rychlost. Když AI nástroje generují více kódu a čerpají více závislostí, objem neověřených komponent, které vstupují do produkce, překročí kapacitu organizace ručně je přezkoumat. Organizace, které zavedly kultivovaný, policy-řízený katalog jako výchozí zdroj pro své vývojáře a AI nástroje, budou moci AI rychlosti přizpůsobit odpovídající bezpečnostní governance. Organizace, které stále spoléhají na veřejné registry a manuální kontrolu, budou čelit rostoucí mezeře mezi rychlostí, s jakou je kód generován, a tím, jak důkladně je hodnocen.

Kultivované ekosystémy jsou infrastrukturou 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šení?

Byla skutečná změna. 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í tolik pravda. Existuje více žen ve seniorních technických a výkonných pozicích, více organizací, které přesáhly fázi performativních prohlášení o diverzitě a dělají strukturální změny, a více modelů pro to, jak může vypadat leadership v tomto prostoru.

Obchodní případ pro uzavření zbývající mezery není abstraktní. Problémy, se kterými tento průmysl nyní pracuje, software supply chain riziko, AI governance, organizační změny vyžadované pro bezpečnost jako primární praxi, jsou tvrdé problémy. Diverse týmy produkují lepší výsledky na tvrdých problémech. Ne jako otázka aspirace, ale jako otázka, 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 operační výhoda projevuje v práci.

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

Děkuji za skvělý rozhovor, čtenáři, kteří chtějí se dozvědět více, by měli navštívit ActiveState.