Abby Kearns, CEO ActiveState – Wywiad z serii

Abby Kearns jest CEO ActiveState i doświadczonym menedżerem z ponad 25-letnim doświadczeniem w budowaniu i skalowaniu organizacji oprogramowania przedsiębiorstw. Poprzednio pełniła funkcję CTO w firmie Puppet, gdzie pomogła przeprowadzić strategiczną transformację, zakończoną przejęciem firmy przez Perforce Software. Wcześniej w swojej karierze była CEO Cloud Foundry Foundation, gdzie kierowała rozwojem jednego z największych otwartych ekosystemów platform chmurowych w branży. Abby obecnie zasiada w radzie nadzorczej Akka (dawniej Lightbend). Jest znana z pomocy firmom w tłumaczeniu dużych zmian w chmurze, oprogramowaniu open source i sztucznej inteligencji na klarowną strategię produktową i wzrost przedsiębiorstw.

ActiveState to kanadyjska firma oprogramowania założona w 1997 roku, która dostarcza przedsiębiorstwom narzędzia i platformy do budowania, zarządzania i zabezpieczania oprogramowania open source. Jej podstawowa oferta, platforma ActiveState, pomaga zespołom deweloperskim, DevOps i bezpieczeństwa w automatyzowaniu zarządzania zależnościami, wykrywaniu i likwidowaniu luk w zabezpieczeniach oraz tworzeniu bezpiecznych, powtarzalnych środowisk deweloperskich w wielu językach programowania, takich jak Python, Perl i Tcl. Dostarczając prebudowane, zweryfikowane komponenty open source i integrując je z istniejącymi procesami roboczymi, ActiveState ma na celu zmniejszenie ryzyka bezpieczeństwa w łańcuchu dostaw oprogramowania, jednocześnie poprawiając produktywność deweloperów i przyspieszając dostarczanie aplikacji.

Przez całą swoją karierę działała Panie na styku oprogramowania open source, platform chmurowych i transformacji przedsiębiorstw, od kierowania Cloud Foundry Foundation do pełnienia funkcji CTO w firmie Puppet. Co skłoniło Panią do objęcia stanowiska CEO w ActiveState, a jaka jest Pani wizja rozwoju tej firmy w najbliższej fazie wzrostu?

Przewodnim wątkiem mojej kariery było działanie na styku społeczności i infrastruktury w momentach, gdy branża podejmuje decyzje, które będą miały wpływ na lata. Cloud Foundry był tym momentem dla platform chmurowych. Puppet był tym momentem dla zarządzania konfiguracją i wczesnych etapów tego, co teraz nazywamy DevSecOps. ActiveState jest tym momentem dla zarządzania oprogramowaniem open source.

To, co skłoniło mnie tutaj, to problem, który obserwowałam przez długi czas. Każde przedsiębiorstwo, z którym się spotkałam, działa na oprogramowaniu open source. Większość z nich nie potrafi powiedzieć z pewnością, jakie oprogramowanie open source używa, czy zostało ono poprawione, czy kto jest odpowiedzialny za decyzję o jego użyciu. Ta luka, pomiędzy tym, jak podstawowym oprogramowaniem open source się stało, a tym, jak mało rygorystycznie większość organizacji zarządza nim, jest miejscem, w którym branża gromadzi ryzyko. ActiveState przez dwadzieścia lat budował infrastrukturę, aby zamknąć tę lukę. Moja praca polega na upewnieniu się, że rynek rozumie, dlaczego zamykanie jej jest pilne.

Wizja na tę następną fazę jest klarowna: ActiveState staje się domyślną odpowiedzią na pytanie, skąd pochodzi oprogramowanie open source dla przedsiębiorstw. Nie skaner. Nie raport. Zaufany, zweryfikowany, ciągle poprawiany źródło, na które organizacje mogą wskazać, gdy regulatorzy, rady nadzorcze lub odpowiedzialni za incydenty pytają, jak zarządzali łańcuchem dostaw oprogramowania.

ActiveState pozycjonuje się jako krytyczna warstwa w zabezpieczaniu łańcucha dostaw oprogramowania w czasie, gdy sztuczna inteligencja przyspiesza generowanie kodu. Jak sztuczna inteligencja fundamentalnie zmienia profil ryzyka oprogramowania open source?

Rozwój wspomagany przez sztuczną inteligencję łamie podstawowe założenie, na którym została zbudowana cała infrastruktura zarządzania oprogramowaniem open source: że deweloper podjął świadomą decyzję o uwzględnieniu zależności.

Każdy mandat SBOM, każde narzędzie SCA, każdy proces zarządzania lukami w zabezpieczeniach zakłada, że był człowiek w pętli, który wybrał pociągnięcie tej biblioteki. Gdy sztuczna inteligencja generuje kod, zależności pojawiają się w produkcji, których nikt nie wybrał, nie przeglądał, a w wielu przypadkach nawet nie wie, że są tam. Narzędzia do zarządzania szukają decyzji. Sztuczna inteligencja wprowadza zmiany w produkcji, które omijają decyzję całkowicie.

Istnieje druga warstwa tego problemu. Narzędzia programistyczne, które napędzały adopcję sztucznej inteligencji, wskaźniki produktywności, ankiety deweloperów, gwiazdki na GitHub, żadne z tych ram oceny nie uwzględniały bezpieczeństwa jako pierwszorzędnego miernika. Branża optymalizowała pod kątem szybkości i poprawności, a infrastrukturę dostarczyła bez pytania, czy wyjście jest bezpieczne. To nie jest awaria narzędzi. To jest awaria przywództwa w podejmowaniu decyzji o adopcji. Teraz działamy w skali na fundamencie, który nigdy nie został oceniony pod kątem ryzyka, które wprowadza.

Powiedziała Pani, że niezarządzane oprogramowanie open source staje się dużą luką w zabezpieczeniach przedsiębiorstw. Dlaczego zarządzanie oprogramowaniem open source teraz dociera do poziomu zarządu, a co wyżsi menedżerowie nadal niedoceniają?

Dociera do poziomu zarządu, ponieważ środowisko regulacyjne zmieniło strukturę odpowiedzialności. Akt o cyberodporności UE, wymagania dotyczące ujawniania informacji przez SEC, wytyczne CISA dotyczące bezpiecznego projektu: te ramy zmieniają pytanie z “Czy miałeś skaner?” na “Czy możesz udowodnić, że twoje oprogramowanie było bezpieczne w momencie powstania?”. To są bardzo różne pytania, a większość organizacji nie może odpowiedzieć na to drugie.

Co wyżsi menedżerowie nadal niedoceniają, to fakt, że jest to problem strukturalny, a nie problem zasobów. Organizacje, które reagują na ryzyko oprogramowania open source, dodając więcej narzędzi do skanowania, nie rozwiązują podstawowego problemu. Skanowanie wykrywa problemy po tym, jak już się pojawiły w środowisku.

Gdy wszystko jest oznaczone, nic nie jest priorytetem, a objętość alertów staje się sama w sobie dysfunkcją operacyjną. Organizacje, które będą radzić sobie z tym skutecznie, to nie te, które kupują więcej narzędzi. To te, które zmieniają sposób podejmowania decyzji o tym, jakie oprogramowanie open source wchodzi do ich środowiska, oraz kto jest odpowiedzialny za te decyzje.

Jak organizacje powinny przemyśleć oprogramowanie open source jako infrastrukturze, a nie tylko jako wygodzie deweloperskiej?

Model mentalny, który większość organizacji stosuje, jest przestarzały o dekadę. Oprogramowanie open source zaczęło się jako wygoda deweloperska. Deweloperzy mogli pociągać biblioteki, poruszać się szybciej i unikać odtwarzania podstawowych komponentów. To podejście miało sens, gdy oprogramowanie open source było opcjonalne i uzupełniające.

To nie jest już rzeczywistość. Oprogramowanie open source jest podstawą nowoczesnego oprogramowania. Dziewięćdziesiąt sześć procent aplikacji zawiera komponenty open source. Nie jest to warstwa wygody na górze infrastruktury własnościowej. To infrastruktura. A infrastruktura musi być zarządzana jak infrastruktura, z wyraźnymi zasadami dotyczącymi tego, co wchodzi do środowiska, określoną własnością do konserwacji i likwidacji, oraz odpowiedzialnością, która siedzi na odpowiednim poziomie organizacji.

Organizacje, które są na czele w tej kwestii, dokonały świadomej zmiany: konsumpcja oprogramowania open source jest decyzją strategiczną z konsekwencjami bezpieczeństwa i finansowymi, a nie ustawieniem domyślnym, które deweloperzy zarządzają indywidualnie. Ta zmiana wymaga polityki, procesu operacyjnego i wyraźnej odpowiedzialności wykonawczej. Większość organizacji jeszcze nie dokonała tej zmiany.

Jak bieżąca zmiana napędzana przez sztuczną inteligencję porównuje się do wcześniejszych przełomów, takich jak chmura i DevOps, pod względem szybkości i perturbacji?

Bieżący ruch napędzany przez sztuczną inteligencję jest bardzo podobny do wcześniejszych przełomów technologicznych. Gdy chmura pojawiła się jako model dostarczania, organizacje, które traktowały ją jako czysty wybór technologiczny, popełniły inne błędy niż organizacje, które rozpoznały ją jako zmianę architektoniczną i operacyjną. Te, które nie dokonały przejścia do zarządzania, zapłaciły za to przez lata w postaci IT cieni, przekroczeń kosztów i długów technologicznych i bezpieczeństwa.

Co różni bieżącą zmianę napędzaną przez sztuczną inteligencję, to szybkość i niewidoczność. Adopcja chmury była widoczna. Wiedzieliście, gdy wasza organizacja migrowała obciążenia z lokalizacji na chmurę. DevOps był widoczny: organizacje reorganizowały zespoły, zmieniały potoki wdrożeń i przepisywały procesy. Narzędzia do kodowania sztucznej inteligencji są przyjmowane przez deweloperów, po jednym wywołaniu narzędzi, a ryzyko gromadzi się w kodzie przed większością organizacji zarejestruje, że decyzja dotycząca zarządzania została podjęta.

Perturbacja jest również asymetryczna w sposób, w jaki chmura i DevOps nie były. Te przejścia stworzyły nowe kategorie ryzyka, ale w dużej mierze zachowały założenie, że człowiek był odpowiedzialny za kod, który został dostarczony. Sztuczna inteligencja niszczy to założenie w punkcie, w którym jest najtrudniej je wykryć. To sprawia, że ten przełom jest inny. Eksponowanie jest niewidoczne, aż do momentu, gdy już nie jest.

Wiele firm ma trudności z przekształceniem adopcji oprogramowania open source w zrównoważony model biznesowy. Co odróżnia firmy, które się udają, od tych, które nie?

Organizacje, które zbudowały zrównoważone biznesy na oprogramowaniu open source, dzielą jedną cechę: są zdyscyplinowane w tym, jaki produkt sprzedają. Nie sprzedają oprogramowania open source, które jest darmowe. Sprzedają ekspertyzę, wsparcie operacyjne, infrastrukturę zarządzania lub usługę zarządzaną, która sprawia, że darmowe oprogramowanie jest wykonalne w skali przedsiębiorstw.

Odwrót, organizacje, które nie powiodły się, mają tendencję do łączenia adopcji społeczności z przyczepnością komercyjną. Są to dwie różne rzeczy. Wysoka liczba gwiazdek na GitHub lub duża społeczność sygnalizuje, że deweloperzy uważają projekt za użyteczny. Nie sygnalizuje, że kupujący zapłacą za to, ani że rzecz, którą deweloperzy uważają za użyteczną, jest tym, czego potrzebują organizacje. Tłumaczenie z adopcji deweloperskiej na wartość przedsiębiorstw wymaga budowania czegoś poza samym oprogramowaniem open source, a organizacje, które nie robią tej różnicy wyraźnie w swoim pozycjonowaniu, produkcie i ruchu sprzedażowym, mają tendencję do nieprzeżycia przejścia do skali.

Z Pani doświadczenia w skalowaniu organizacji zorientowanych na deweloperów, jakie są największe wyzwania przywódcze przy przejściu od wzrostu napędzanego produktem do operacji w skali przedsiębiorstw?

Największym wyzwaniem jest to, że umiejętności i instynkty, które sprawiły, że byliście skuteczni we wzroście napędzanym produktem, przeciwstawiają się wam w skali przedsiębiorstw. Wzrost napędzany produktem nagradza szybkie działanie, iterację w miejscu publicznym, optymalizację doświadczenia deweloperskiego i pozwala adopcji prowadzić ruch komercyjny. Sprzedaż przedsiębiorstw nagradza celowy proces, relacje wykonawcze, długie cykle i umiejętność mapowania produktu na wyniki, które mają znaczenie dla kupujących, którzy nie są deweloperami.

Błąd przywódczy, który widzę najczęściej, to założenie, że przejście jest głównie problemem ruchu sprzedażowego. Nie jest. To problem projektowania organizacyjnego. Zespół, który zbudował produkt, pozycjonowanie i wczesne relacje z klientami, często nie jest zespołem, który może wykonać ruch przedsiębiorstw. Rozpoznanie tego bez utraty tego, co sprawiło, że produkt był wart kupienia, jest naprawdę trudne. Przywódcy, którzy to robią dobrze, są tymi, którzy są szczerzy co do tego, które części organizacji muszą ewoluować, i którzy budują nowe możliwości bez demontowania kultury, która stworzyła produkt.

Jak firmy mogą równoważyć szybkość i innowacje z rosnącym zapotrzebowaniem na bezpieczne, zaufane komponenty oprogramowania?

Ramy szybkości versus bezpieczeństwa to fałszywy wybór, który utrzymywał się, ponieważ tooling wzmocnił go. Gdy bezpieczeństwo jest wdrożone jako brama przeglądowa na końcu procesu deweloperskiego, jest to wąskie gardło. Gdy jest wdrożone jako zarządzane źródło zaufanych komponentów, które deweloperzy pobierają na początku procesu, nie spowalnia niczego.

Te, które rozwiązały ten konflikt, zrobiły to, przesuwając, gdzie bezpieczeństwo się dzieje. Nie przeglądając kodu po napisaniu. Nie skanując artefaktów po zbudowaniu. Zarządzając tym, co wchodzi do katalogu, z którego deweloperzy i narzędzia AI pobierają. Jeśli źródło jest zaufane, prędkość nie jest ograniczona przez przegląd bezpieczeństwa, ponieważ praca bezpieczeństwa odbywała się wcześniej. To jest decyzja architektoniczna, a nie kulturowa. Wymaga inwestycji w infrastrukturę zarządzania, ale nie wymaga wyboru pomiędzy szybkością a bezpieczeństwem.

Jak Pani widzi ewolucję kuratorów lub zaufanych ekosystemów open source w ciągu najbliższych kilku lat, w miarę jak narzędzia AI coraz częściej generują kod i zależności?

Rola kuratorów, zaufanych źródeł open source, będzie musiała przesunąć się od najlepszych praktyk do wymogu podstawowego. Ten przełom jest napędzany przez dwie rzeczy, które nie będą odwracane.

Pierwsza to środowisko regulacyjne. W krajobrazie 2026 roku możliwość udowodnienia pochodzenia oprogramowania staje się coraz bardziej wymogiem prawnym, a nie dobrowolnym standardem. Rady nadzorcze i regulatorzy zadają pytania, na które organizacje nie mogą odpowiedzieć, pobierając bezpośrednio z publicznych rejestrów.

Druga to prędkość rozwoju AI. Gdy narzędzia AI generują więcej kodu i pobierają więcej zależności, objętość niezweryfikowanych komponentów wchodzących do produkcji przewyższy każdą organizację, która może je przeglądać ręcznie. Organizacje, które ustanowiły kuratora, politycznie zarządzany katalog jako domyślne źródło dla swoich deweloperów i narzędzi AI, będą mogły dopasować prędkość AI do odpowiedniego zarządzania bezpieczeństwem. Organizacje, które nadal polegają na publicznych rejestrach i przeglądzie ręcznym, będą miały rosnącą lukę pomiędzy tym, jak szybko kod jest generowany, a tym, jak gruntownie jest oceniany.

Ekosystemy kuratorów są odpowiedzią infrastrukturalną na problem, który rozwój AI uczynił nieuniknionym.

Jako jedna z nielicznych kobiet-CEO w przestrzeni open source i infrastruktury, jakie zmiany Pani widzi w różnorodności przywództwa na przestrzeni lat, a co jeszcze musi się poprawić?

Były prawdziwe zmiany. Gdy zaczynałam swoją karierę, reprezentacja kobiet na stanowiskach kierowniczych w open source i infrastrukturze była na tyle niska, że wyjątki były zauważalne. To już nie jest prawdą. Jest więcej kobiet na stanowiskach technicznych i kierowniczych, więcej organizacji, które przeszły poza fazę deklaracji różnorodności i wprowadzają zmiany strukturalne, oraz więcej modeli dla przywództwa w tej przestrzeni.

Przypadek biznesowy dla zamknięcia pozostałej luki nie jest abstrakcyjny. Problemy, nad którymi branża pracuje teraz, ryzyko łańcucha dostaw oprogramowania, zarządzanie AI, zmiany organizacyjne wymagane do uczynienia bezpieczeństwa pierwszorzędną praktyką, są trudne. Zróżnicowane zespoły produkują lepsze wyniki na trudnych problemach. Nie jako kwestia aspiracji, ale jako kwestia, w jaki sposób różne perspektywy ujawniają założenia, które zespoły jednorodne pomijają. Widziałam to bezpośrednio. Organizacje, które zrobiły prawdziwy postęp w przynależności, a nie tylko reprezentacji, są tymi, gdzie ta operacyjna przewaga jest widoczna w pracy.

Przynależność jest nadal nierówna w branży. Być w pokoju nie jest tym samym, co mieć swoją perspektywę szczerze ważoną. To rozróżnienie jest miejscem, w którym następna faza postępu musi się wydarzyć.

Dziękuję za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić ActiveState.