Abby Kearns, CEO da ActiveState – Série de Entrevistas

Abby Kearns é CEO da ActiveState e uma executiva de tecnologia com mais de 25 anos de experiência em construir e escalar organizações de software empresariais. Ela atuou anteriormente como CTO da Puppet, onde ajudou a liderar uma transformação estratégica que culminou na aquisição da empresa pela Perforce Software. No início de sua carreira, ela foi CEO da Cloud Foundry Foundation, orientando o crescimento de uma das maiores plataformas de nuvem de código aberto da indústria. Abby atua atualmente no conselho da Akka (anteriormente Lightbend). Ela é conhecida por ajudar as empresas a traduzir mudanças significativas em nuvem, código aberto e IA em estratégias de produto e crescimento empresarial claras.

ActiveState é uma empresa de software canadense fundada em 1997 que fornece ferramentas e plataformas empresariais para construir, gerenciar e proteger software de código aberto. Sua oferta principal, a Plataforma ActiveState, ajuda equipes de desenvolvimento, DevOps e segurança a automatizar o gerenciamento de dependências, detectar e remediar vulnerabilidades e criar ambientes de desenvolvimento seguros e reprodutíveis em várias linguagens de programação, como Python, Perl e Tcl. Ao fornecer componentes de código aberto pré-construídos e verificados e integrá-los em fluxos de trabalho existentes, a ActiveState visa reduzir os riscos de segurança na cadeia de suprimento de software, melhorar a produtividade dos desenvolvedores e acelerar a entrega de aplicativos.

Você passou sua carreira na interseção de código aberto, plataformas nativas de nuvem e transformação empresarial, desde liderar a Cloud Foundry Foundation até atuar como CTO da Puppet. O que o levou a assumir o papel de CEO da ActiveState, e qual é sua visão para a empresa nessa próxima fase de crescimento?

A linha de minha carreira tem sido operar na interseção de comunidade e infraestrutura em momentos em que a indústria está tomando decisões que se acumularão por anos. Cloud Foundry foi esse momento para plataformas nativas de nuvem. Puppet foi esse momento para gerenciamento de configuração e os estágios iniciais do que agora chamamos de DevSecOps. ActiveState é esse momento para governança de código aberto.

O que me atraiu aqui é um problema que eu tenho visto se construir por muito tempo. Cada empresa que encontrei executa em código aberto. A maioria delas não pode dizer com confiança qual código aberto está executando, se foi corrigido ou quem é responsável pela decisão de usá-lo. Essa lacuna, entre como o código aberto se tornou fundamental e como poucas organizações aplicam rigor à governança, é onde o risco da indústria está se acumulando. A ActiveState passou vinte anos construindo a infraestrutura para fechar essa lacuna. Meu trabalho é garantir que o mercado entenda por que fechar é urgente.

A visão para essa próxima fase é clara: a ActiveState se torna a resposta padrão para a pergunta de onde vem o código aberto empresarial. Não um scanner. Não um relatório. Uma fonte confiável, verificada e continuamente corrigida que as organizações possam apontar quando reguladores, conselhos ou respondentes de incidentes perguntam como governaram sua cadeia de suprimento de software.

A ActiveState está se posicionando como uma camada crítica na segurança da cadeia de suprimento de software em um momento em que a IA está acelerando a geração de código. Como a IA muda fundamentalmente o perfil de risco do software de código aberto?

O desenvolvimento assistido por IA quebra uma suposição fundamental sobre a qual toda a cadeia de ferramentas de governança de código aberto foi construída: que um desenvolvedor tomou uma decisão deliberada para incluir uma dependência.

Toda a diretiva SBOM, toda a ferramenta SCA, toda a rotina de gerenciamento de vulnerabilidades assume que houve um humano no loop que escolheu puxar essa biblioteca. Quando a IA gera código, dependências chegam à produção que ninguém selecionou, revisou ou, em muitos casos, nem sabe que estão lá. A ferramenta de governança está procurando por decisões. A IA está fazendo alterações de produção que contornam a decisão por completo.

Há uma segunda camada para isso. As ferramentas de codificação que impulsionaram a adoção da IA, os benchmarks de produtividade, as pesquisas de desenvolvedores, as estrelas do GitHub, nenhum desses quadros de avaliação incluiu segurança como uma medida de primeira ordem. A indústria otimizou para velocidade e correção e enviou a infraestrutura sem perguntar se a saída era segura. Isso não é um fracasso da ferramenta. É um fracasso de liderança em como as decisões de adoção foram tomadas. Agora estamos operando em escala sobre uma base que nunca foi avaliada para o risco que estava introduzindo.

Você disse que o código aberto não gerenciado está se tornando uma vulnerabilidade empresarial importante. Por que a governança de código aberto agora está subindo para o nível do conselho, e o que os executivos ainda subestimam?

Está alcançando o conselho porque o ambiente regulatório mudou a estrutura de responsabilidade. O Ato de Resiliência Cibernética da UE, os requisitos de divulgação da SEC, a orientação de Design Seguro da CISA: esses quadros estão mudando a pergunta de “Você tinha um scanner?” para “Você pode provar que seu software era seguro no ponto de origem?” Essas são perguntas muito diferentes, e a maioria das organizações não pode responder à segunda.

O que os executivos ainda subestimam é que isso é um problema estrutural, não um problema de recursos. As organizações que respondem ao risco de código aberto adicionando mais ferramentas de varredura não estão resolvendo a questão subjacente. A varredura detecta problemas após eles terem entrado no ambiente.

Quando tudo é sinalizado, nada é priorizado, e o volume de alertas se torna sua própria disfunção operacional. As organizações que navegarão com sucesso por isso não são as que compram mais ferramentas. São as que mudam como tomam decisões sobre o que entra em seu ambiente e quem é responsável por essas decisões.

Com o código aberto agora incorporado em muitas pilhas de software empresariais, como as organizações devem repensar o código aberto como infraestrutura e não apenas como uma conveniência de desenvolvimento?

O modelo mental que a maioria das organizações está trabalhando é uma década defasado. O código aberto começou como uma conveniência de desenvolvimento. Os desenvolvedores podiam puxar bibliotecas, mover-se mais rápido e evitar reinventar componentes fundamentais. Essa estrutura fez sentido quando o código aberto era opcional e suplementar.

Essa não é a realidade atual. O código aberto é a base do software moderno. Noventa e seis por cento dos aplicativos incluem componentes de código aberto. Não é uma camada de conveniência sobre infraestrutura proprietária. É a infraestrutura. E a infraestrutura precisa ser governada como infraestrutura, com políticas explícitas sobre o que entra no ambiente, propriedade definida para manutenção e remediação, e responsabilidade que se encontra no nível certo da organização.

As organizações que estão à frente nisso fizeram uma mudança deliberada: o consumo de código aberto é uma decisão estratégica com consequências de segurança e financeiras, não um ajuste padrão que os desenvolvedores gerenciam individualmente. Essa mudança requer política, processo operacional e responsabilidade executiva clara. A maioria das organizações ainda não fez essa mudança.

Você liderou organizações por meio de várias ondas tecnológicas. Como a mudança atual impulsionada pela IA se compara às transições anteriores, como nuvem e DevOps, em termos de velocidade e interrupção?

O movimento atual impulsionado pela IA é muito semelhante às transições tecnológicas anteriores. Quando a nuvem surgiu como um modelo de entrega, as organizações que a trataram como uma escolha puramente tecnológica cometeram erros muito diferentes das organizações que reconheceram que era uma mudança arquitetônica e operacional. As que falharam em fazer a transição de governança pagaram por isso por anos em TI sombra, excessos de custo e dívida técnica e de segurança.

O que é diferente sobre a mudança atual impulsionada pela IA é a velocidade e a invisibilidade. A adoção de nuvem era visível. Você sabia quando sua organização estava migrando cargas de trabalho de prem para a nuvem. DevOps era visível: as organizações estavam reestruturando equipes, alterando pipelines de implantação e reescrevendo processos. As ferramentas de codificação da IA estão sendo adotadas desenvolvedor por desenvolvedor, chamada de ferramenta por chamada de ferramenta, e o risco está se acumulando na base de código antes que a maioria das organizações tenha registrado que uma decisão de governança foi tomada.

A interrupção também é assimétrica de uma maneira que nuvem e DevOps não foram. Essas transições criaram novas categorias de risco, mas em grande parte preservaram a suposição de que um humano era responsável pelo código que foi enviado. A IA está erodindo essa suposição no ponto em que é mais difícil detectar. É isso que torna essa transição diferente. A exposição é invisível até que não seja mais.

Muitas empresas lutam para transformar a adoção de código aberto em um modelo de negócios sustentável. O que separa as empresas que têm sucesso das que falham?

As organizações que construíram negócios sustentáveis sobre código aberto compartilham uma característica: elas são disciplinadas sobre qual produto elas estão realmente vendendo. Elas não estão vendendo o software de código aberto, que é gratuito. Elas estão vendendo a expertise, o suporte operacional, a infraestrutura de governança ou o serviço gerenciado que torna o software gratuito viável em escala empresarial.

Por outro lado, as organizações que falham tendem a confundir a adoção da comunidade com tração comercial. Eles não são a mesma coisa. Uma contagem alta de estrelas do GitHub ou uma grande comunidade sinaliza que os desenvolvedores encontram o projeto útil. Isso não sinaliza que os compradores pagarão por isso, ou que a coisa que os desenvolvedores encontram útil é a coisa que as organizações realmente precisam. A tradução da adoção do desenvolvedor para valor empresarial requer construir algo além do próprio código aberto, e as organizações que falham em fazer essa distinção claramente, em sua posição, produto e movimento de vendas, tendem a não sobreviver à transição para escala.

Com base em sua experiência em escalar organizações lideradas por desenvolvedores, quais são os maiores desafios de liderança ao migrar do crescimento liderado por produto para operações em escala empresarial?

O maior desafio é que as habilidades e instintos que os tornaram bem-sucedidos no crescimento liderado por produto trabalham contra eles em escala empresarial. O crescimento liderado por produto recompensa mover-se rapidamente, iterar em público, otimizar a experiência do desenvolvedor e deixar a adoção liderar o movimento comercial. As vendas empresariais recompensam um processo deliberado, relacionamentos executivos, ciclos longos e a capacidade de mapear seu produto para resultados que importam para compradores que não são desenvolvedores.

O erro de liderança que vejo com mais frequência é assumir que a transição é principalmente um problema de movimento de vendas. Não é. É um problema de design organizacional. A equipe que construiu o produto, a posição e as primeiras relações de cliente não é a equipe que pode executar o movimento empresarial. Reconhecer isso sem perder o que tornou o produto digno de compra é genuinamente difícil. Os líderes que fazem isso bem são aqueles que são honestos sobre quais partes da organização precisam evoluir e que constroem as novas capacidades sem desmontar a cultura que criou o produto.

Você trabalhou extensivamente na interseção de segurança e produtividade de desenvolvedor. Como as empresas podem equilibrar velocidade e inovação com a necessidade crescente de componentes de software seguros e confiáveis?

A estruturação de velocidade versus segurança é uma escolha falsa que persistiu porque a ferramenta reforçou isso. Quando a segurança é implementada como um portão de revisão no final do processo de desenvolvimento, é um gargalo. Quando é implementada como uma fonte governada de componentes confiáveis que os desenvolvedores puxam do início do processo, não desacelera nada.

Os que resolveram essa tensão fizeram isso mudando onde a segurança acontece. Não revisando o código após ele ser escrito. Não varrendo artefatos após serem construídos. Governando o que entra no catálogo que os desenvolvedores e as ferramentas da IA puxam. Se a fonte for confiável, a velocidade não é constrangida pela revisão de segurança porque o trabalho de segurança aconteceu a montante. Isso é uma decisão arquitetônica, não cultural. Requer investimento na infraestrutura de governança, mas não requer escolher entre se mover rapidamente e enviar com segurança.

À medida que as ferramentas da IA geram cada vez mais código e dependências, como você vê o papel dos ecossistemas de código aberto curados ou confiáveis evoluindo nos próximos anos?

O papel das fontes de código aberto curadas ou confiáveis irá mudar de uma prática recomendada para um requisito básico. Essa mudança está sendo impulsionada por duas coisas que não irão reverter.

A primeira é o ambiente regulatório. No cenário de 2026, ser capaz de demonstrar a provenança do software é cada vez mais um requisito legal, não um padrão voluntário. Conselhos e reguladores estão fazendo perguntas que as organizações não podem responder.

A segunda é a velocidade de desenvolvimento da IA. À medida que as ferramentas da IA geram mais código e puxam mais dependências, o volume de componentes não verificados que entram na produção excederá a capacidade de qualquer organização de revisá-los manualmente. As organizações que estabeleceram um catálogo curado e governado por políticas como a fonte padrão para seus desenvolvedores e ferramentas da IA poderão combinar a velocidade da IA com a governança de segurança apropriada. As organizações que ainda confiam em registros públicos e revisão manual enfrentarão uma lacuna crescente entre como rápido o código está sendo gerado e como bem ele está sendo avaliado.

Os ecossistemas curados são a resposta de infraestrutura para um problema que o desenvolvimento da IA tornou inevitável.

Como uma das poucas CEOs femininas no espaço de código aberto e infraestrutura, quais mudanças você viu na diversidade de liderança ao longo dos anos, e o que ainda precisa melhorar?

Houve uma mudança real. Quando comecei minha carreira, a representação de mulheres em papéis executivos em código aberto e infraestrutura era baixa o suficiente para que as exceções fossem notáveis. Isso é menos verdade agora. Há mais mulheres em papéis técnicos e executivos seniores, mais organizações que passaram da fase de declarações de diversidade performáticas e estão fazendo mudanças estruturais, e mais modelos para o que a liderança nesse espaço pode parecer.

O caso de negócios para fechar a lacuna restante não é abstrato. Os problemas que essa indústria está trabalhando agora, risco de cadeia de suprimento de software, governança da IA, as mudanças organizacionais necessárias para tornar a segurança uma prática de primeira ordem, são problemas difíceis. Equipes diversificadas produzem melhores resultados em problemas difíceis. Não como uma questão de aspiração, mas como uma questão de como diferentes perspectivas revelam suposições que equipes homogêneas perdem. Eu vi isso diretamente. As organizações que fizeram progresso real em pertencimento, não apenas representação, são aquelas onde essa vantagem operacional se manifesta no trabalho.

O pertencimento ainda é desigual em toda a indústria. Estar na sala não é o mesmo que ter sua perspectiva genuinamente considerada. Essa distinção é onde a próxima fase de progresso precisa acontecer.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar ActiveState.