Entrevistas
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 construindo e escalando 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 ecossistemas de plataforma de nuvem de código aberto da indústria. Abby atualmente serve 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 a gestão 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 entregar componentes de código aberto pré-construídos e verificados e integrá-los nos fluxos de trabalho existentes, a ActiveState visa reduzir os riscos de segurança na cadeia de suprimentos de software, melhorando a produtividade dos desenvolvedores e acelerando 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 condução da minha carreira foi operar na interseção de comunidade e infraestrutura nos momentos em que a indústria está tomando decisões que se somarão por anos. Cloud Foundry foi esse momento para nativo de nuvem. Puppet foi esse momento para gerenciamento de configuração e os primeiros estágios do que agora chamamos de DevSecOps. ActiveState é esse momento para governança de código aberto.
O que me levou aqui é um problema que observei 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 na 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 fechá-la é 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, continuamente corrigida que as organizações possam apontar quando reguladores, conselhos ou respondentes a incidentes perguntam como governaram a cadeia de suprimentos de software.
A ActiveState está se posicionando como uma camada crítica na segurança da cadeia de suprimentos 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 fez uma decisão deliberada de incluir uma dependência.
Cada mandato de SBOM, cada ferramenta de SCA, cada fluxo de trabalho de gerenciamento de vulnerabilidades supõe que havia 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, 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 inteiramente.
Há uma segunda camada disso. 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 otimizada para velocidade e correção e enviou a infraestrutura sem perguntar se a saída era segura. Isso não é uma falha de ferramenta. É uma falha de liderança em como as decisões de adoção foram tomadas. Agora estamos operando em escala em uma fundação que nunca foi avaliada para o risco que estava introduzindo.
Você disse que o código aberto não gerenciado está se tornando uma grande vulnerabilidade empresarial. Por que a governança de código aberto agora está chegando ao 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 scanner não estão resolvendo o problema subjacente. O scanner 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 no 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. Desenvolvedores podiam puxar bibliotecas, mover 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 a infraestrutura proprietária. É a infraestrutura. E a infraestrutura tem que 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 exige 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 por IA se compara às transições anteriores, como nuvem e DevOps, em termos de velocidade e disruptura?
A mudança atual impulsionada por 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, excesso de custos e dívida técnica e de segurança.
O que é diferente sobre a mudança atual impulsionada por 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 local para a nuvem. DevOps era visível: as organizações estavam reestruturando equipes, mudando 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 no código antes que a maioria das organizações tenha registrado que uma decisão de governança foi tomada.
A disruptura também é assimétrica de uma maneira que nuvem e DevOps não foram. Essas transições criaram novas categorias de risco, mas preservaram em grande parte 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 daquelas que falham?
As organizações que construíram negócios sustentáveis em código aberto compartilham uma característica: elas são disciplinadas sobre o que realmente estão vendendo. Elas não estão vendendo o software de código aberto, que é gratuito. 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. 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. 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 de desenvolvedores para valor empresarial exige construir algo além do código aberto em si, e as organizações que não fazem claramente essa distinção 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 orientadas a desenvolvedores, quais são os maiores desafios de liderança na transição de crescimento orientado a produto para operações em escala empresarial?
O maior desafio é que as habilidades e instintos que o tornaram bem-sucedido no crescimento orientado a produto trabalham contra você em escala empresarial. O crescimento orientado a 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 o processo deliberado, as relações executivas, os 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 relações de cliente iniciais muitas vezes 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 desenvolvedores. Como as empresas podem equilibrar velocidade e inovação com a crescente necessidade de componentes de software confiáveis e seguros?
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 no início do processo, não desacelera nada.
Aqueles 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 digitalizando 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 upstream. É uma decisão arquitetônica, não cultural. Exige investimento na infraestrutura de governança, mas não exige escolher entre se mover rapidamente e enviar com segurança.
À medida que as ferramentas de 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 puxando diretamente de registros públicos.
A segunda é a velocidade de desenvolvimento da IA. À medida que as ferramentas de 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 dependem de registros públicos e revisão manual enfrentarão uma lacuna crescente entre a velocidade com que o código está sendo gerado e como 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 funções executivas em código aberto e infraestrutura era baixa o suficiente para que as exceções fossem notáveis. Isso é menos verdadeiro agora. Há mais mulheres em funções técnicas e executivas seniores, mais organizações que mudaram da fase de declaração de diversidade para fazer 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 a indústria está trabalhando agora, risco de cadeia de suprimentos 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 em que a vantagem operacional aparece 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.
