Abby Kearns, CEO de ActiveState – Serie de entrevistas

Abby Kearns es la CEO de ActiveState y una ejecutiva de tecnología con más de 25 años de experiencia en la construcción y escalada de organizaciones de software empresariales. Anteriormente, se desempeñó como CTO de Puppet, donde ayudó a liderar una transformación estratégica que culminó en la adquisición de la empresa por Perforce Software. Al comienzo de su carrera, fue CEO de la Cloud Foundry Foundation, guiando el crecimiento de uno de los ecosistemas de plataforma de nube de código abierto más grandes de la industria. Abby actualmente forma parte de la junta directiva de Akka (anteriormente Lightbend). Es conocida por ayudar a las empresas a traducir los cambios importantes en la nube, el código abierto y la IA en una estrategia de producto clara y crecimiento empresarial.

ActiveState es una empresa de software canadiense fundada en 1997 que proporciona herramientas y plataformas empresariales para construir, administrar y proteger software de código abierto. Su oferta principal, la Plataforma ActiveState, ayuda a los equipos de desarrollo, DevOps y seguridad a automatizar la administración de dependencias, detectar y remediar vulnerabilidades, y crear entornos de desarrollo seguros y reproducibles en varios lenguajes de programación como Python, Perl y Tcl. Al entregar componentes de código abierto preconstruidos y verificados, e integrarlos en flujos de trabajo existentes, ActiveState pretende reducir los riesgos de seguridad en la cadena de suministro de software mientras mejora la productividad de los desarrolladores y acelera la entrega de aplicaciones.

Ha pasado su carrera en la intersección de código abierto, plataformas nativas de la nube y transformación empresarial, desde liderar la Cloud Foundry Foundation hasta servir como CTO en Puppet. ¿Qué la llevó a asumir el papel de CEO en ActiveState, y cuál es su visión para la empresa en esta próxima fase de crecimiento?

La línea de mi carrera ha sido operar en la intersección de la comunidad y la infraestructura en momentos en que la industria está tomando decisiones que se multiplicarán durante años. Cloud Foundry fue ese momento para la nube nativa. Puppet fue ese momento para la administración de configuración y las primeras etapas de lo que ahora llamamos DevSecOps. ActiveState es ese momento para la gobernanza de código abierto.

Lo que me llevó aquí es un problema que he estado viendo crecer durante mucho tiempo. Cada empresa que he encontrado se ejecuta en código abierto. La mayoría de ellas no pueden decirle con confianza qué código abierto están ejecutando, si ha sido parcheado, o quién es responsable de la decisión de usarlo. Esa brecha, entre lo fundamental que se ha vuelto el código abierto y lo poco que la mayoría de las organizaciones aplican para gobernarlo, es donde se está acumulando el riesgo de la industria. ActiveState ha pasado veinte años construyendo la infraestructura para cerrar esa brecha. Mi trabajo es asegurarme de que el mercado entienda por qué cerrarla es urgente.

La visión para esta próxima fase es clara: ActiveState se convierte en la respuesta predeterminada a la pregunta de dónde proviene el código abierto empresarial. No un escáner. No un informe. Una fuente verificada, confiable y continuamente remediada a la que las organizaciones pueden señalar cuando los reguladores, las juntas o los respondedores de incidentes preguntan cómo gobernaron su cadena de suministro de software.

ActiveState se está posicionando como una capa crítica para garantizar la seguridad de la cadena de suministro de software en un momento en que la IA está acelerando la generación de código. ¿Cómo cambia fundamentalmente la IA el perfil de riesgo del software de código abierto?

El desarrollo asistido por IA rompe una suposición fundamental en la que se basó toda la cadena de herramientas de gobernanza de código abierto: que un desarrollador tomó una decisión deliberada de incluir una dependencia.

Cada mandato de SBOM, cada herramienta de SCA, cada flujo de trabajo de administración de vulnerabilidades supone que hubo un ser humano en el bucle que eligió tirar de esa biblioteca. Cuando la IA genera código, las dependencias llegan a producción que nadie seleccionó, revisó o, en muchos casos, ni siquiera sabe que están allí. La herramienta de gobernanza está buscando decisiones. La IA está haciendo cambios en producción que pasan por alto la decisión por completo.

Hay una segunda capa en esto. Las herramientas de codificación que impulsaron la adopción de IA, los benchmarks de productividad, las encuestas de desarrolladores, las estrellas de GitHub, ninguno de esos marcos de evaluación incluyó la seguridad como una medida de primer orden. La industria se optimizó para la velocidad y la corrección, y envió la infraestructura sin preguntar si la salida era segura. Eso no es un fallo de la herramienta. Es un fallo de liderazgo en la forma en que se tomaron las decisiones de adopción. Ahora estamos operando a escala sobre una base que nunca se evaluó por el riesgo que estaba introduciendo.

Ha dicho que el código abierto no administrado se está convirtiendo en una vulnerabilidad empresarial importante. ¿Por qué la gobernanza de código abierto ahora está llegando al nivel de la junta, y qué es lo que los ejecutivos aún subestiman?

Está llegando a la junta porque el entorno regulatorio ha cambiado la estructura de rendición de cuentas. El Acta de Resiliencia Cibernética de la UE, los requisitos de divulgación de la SEC, la guía de Diseño Seguro de CISA: estos marcos están cambiando la pregunta de “¿Tenías un escáner?” a “¿Puedes demostrar que tu software era seguro en el punto de origen?”. Esas son preguntas muy diferentes, y la mayoría de las organizaciones no pueden responder a la segunda.

Lo que los ejecutivos aún subestiman es que este es un problema estructural, no un problema de recursos. Las organizaciones que responden al riesgo de código abierto agregando más herramientas de escaneo no están resolviendo el problema subyacente. El escaneo detecta problemas después de que hayan entrado en su entorno.

Cuando todo está marcado, nada se prioriza, y el volumen de alertas se convierte en su propia disfunción operativa. Las organizaciones que navegarán esto con éxito no son las que compran más herramientas. Son las que cambian cómo toman decisiones sobre qué código abierto entra en su entorno, y quién es responsable de esas decisiones.

Con el código abierto ahora integrado en la mayoría de las pilas de software empresariales, ¿cómo deben las organizaciones replantear el código abierto como infraestructura en lugar de solo una comodidad de desarrollo?

El modelo mental con el que la mayoría de las organizaciones están trabajando es una década obsoleto. El código abierto comenzó como una comodidad de desarrollo. Los desarrolladores podían tirar de bibliotecas, moverse más rápido y evitar reinventar componentes fundamentales. Ese marco tenía sentido cuando el código abierto era opcional y suplementario.

Esa no es la realidad actual. El código abierto es la base del software moderno. El noventa y seis por ciento de las aplicaciones incluyen componentes de código abierto. No es una capa de comodidad sobre la infraestructura propietaria. Es la infraestructura. Y la infraestructura tiene que ser gobernada como infraestructura, con políticas explícitas sobre qué entra en el entorno, propiedad definida para el mantenimiento y la remediación, y rendición de cuentas que se sienta al nivel correcto de la organización.

Las organizaciones que están por delante en esto han hecho un cambio deliberado: el consumo de código abierto es una decisión estratégica con consecuencias de seguridad y financieras, no una configuración predeterminada que los desarrolladores gestionan individualmente. Ese cambio requiere política, proceso operativo y rendición de cuentas ejecutiva clara. La mayoría de las organizaciones aún no han hecho ese cambio.

Ha liderado organizaciones a través de múltiples oleadas tecnológicas. ¿Cómo se compara el cambio actual impulsado por la IA con transiciones anteriores como la nube y DevOps en términos de velocidad y perturbación?

El movimiento actual impulsado por la IA es muy similar a las transiciones tecnológicas anteriores. Cuando la nube surgió como un modelo de entrega, las organizaciones que la trataron como una elección puramente tecnológica cometieron errores muy diferentes a las organizaciones que reconocieron que era un cambio arquitectónico y operativo. Las que fallaron en hacer la transición de gobernanza pagaron por ello durante años en TI sombra, sobrecostos y deuda técnica y de seguridad.

Lo que es diferente sobre el cambio actual impulsado por la IA es la velocidad y la invisibilidad. La adopción de la nube era visible. Sabías cuándo tu organización estaba migrando cargas de trabajo desde la infraestructura local a la nube. DevOps era visible: las organizaciones estaban reestructurando equipos, cambiando pipelines de implementación y reescribiendo procesos. Las herramientas de codificación de IA se están adoptando desarrollador por desarrollador, llamada de herramienta por llamada de herramienta, y el riesgo se está acumulando en la base de código antes de que la mayoría de las organizaciones hayan registrado que se tomó una decisión de gobernanza.

La perturbación también es asimétrica de una manera que la nube y DevOps no lo fueron. Esas transiciones crearon nuevas categorías de riesgo, pero en gran medida preservaron la suposición de que un ser humano era responsable del código que se envió. La IA está erosionando esa suposición en el punto donde es más difícil detectar. Eso es lo que hace que esta transición sea diferente. La exposición es invisible hasta que no lo es.

Muchas empresas luchan por convertir la adopción de código abierto en un modelo de negocio sostenible. ¿Qué separa a las empresas que tienen éxito de las que fracasan?

Las organizaciones que han construido negocios sostenibles sobre código abierto comparten una característica: son disciplinadas sobre qué producto están vendiendo en realidad. No están vendiendo el software de código abierto, que es gratuito. Están vendiendo la experiencia, el soporte operativo, la infraestructura de gobernanza o el servicio administrado que hace que el software gratuito sea viable a escala empresarial.

Por el contrario, las organizaciones que fracasan tienden a confundir la adopción de la comunidad con la tracción comercial. No son lo mismo. Un alto recuento de estrellas de GitHub o una gran comunidad señala que los desarrolladores encuentran el proyecto útil. No señala que los compradores pagarán por ello, o que lo que los desarrolladores encuentran útil es lo que las organizaciones realmente necesitan. La traducción de la adopción de desarrolladores al valor empresarial requiere construir algo más allá del código abierto en sí, y las organizaciones que no hacen esa distinción claramente, en su posicionamiento, su producto y su movimiento de ventas, tienden a no sobrevivir a la transición a escala.

Desde su experiencia en la escalada de organizaciones impulsadas por desarrolladores, ¿cuáles son los mayores desafíos de liderazgo al transitar de un crecimiento impulsado por el producto a operaciones a escala empresarial?

El mayor desafío es que las habilidades y los instintos que te hicieron tener éxito en el crecimiento impulsado por el producto trabajan en tu contra a escala empresarial. El crecimiento impulsado por el producto recompensa moverse rápido, iterar en público, optimizar la experiencia del desarrollador y dejar que la adopción lidere el movimiento comercial. Las ventas empresariales recompensan el proceso deliberado, las relaciones ejecutivas, los ciclos largos y la capacidad de mapear su producto a resultados que importan a los compradores que no son desarrolladores.

El error de liderazgo que veo con más frecuencia es asumir que la transición es principalmente un problema de movimiento de ventas. No lo es. Es un problema de diseño organizacional. El equipo que construyó el producto, el posicionamiento y las primeras relaciones con los clientes a menudo no es el equipo que puede ejecutar el movimiento empresarial. Reconocer eso sin perder lo que hizo que el producto valiera la pena comprar es genuinamente difícil. Los líderes que lo hacen bien son los que son honestos sobre qué partes de la organización necesitan evolucionar y que construyen las nuevas capacidades sin desmantelar la cultura que creó el producto.

Ha trabajado extensamente en la intersección de la seguridad y la productividad de los desarrolladores. ¿Cómo pueden las empresas equilibrar la velocidad y la innovación con la creciente necesidad de componentes de software seguros y de confianza?

La configuración de la velocidad versus la seguridad es una elección falsa que ha persistido porque la herramienta ha reforzado. Cuando la seguridad se implementa como una puerta de revisión al final del proceso de desarrollo, es un cuello de botella. Cuando se implementa como una fuente gobernada de componentes de confianza que los desarrolladores pueden tirar desde el principio del proceso, no ralentiza nada.

Aquellos que han resuelto esta tensión lo han hecho cambiando dónde sucede la seguridad. No revisando el código después de que se escribió. No escaneando artefactos después de que se construyeron. Gobernando qué entra en el catálogo que los desarrolladores y las herramientas de IA pueden tirar. Si la fuente es de confianza, la velocidad no se ve limitada por la revisión de seguridad porque el trabajo de seguridad sucedió aguas arriba. Eso es una decisión arquitectónica, no cultural. Requiere inversión en la infraestructura de gobernanza, pero no requiere elegir entre moverse rápido y enviar de manera segura.

À medida que las herramientas de IA generan cada vez más código y dependencias, ¿cómo ve evolucionar el papel de los ecosistemas de código abierto curados o de confianza en los próximos años?

El papel de las fuentes de código abierto curadas y de confianza va a cambiar de una buena práctica a un requisito básico. Ese cambio está siendo impulsado por dos cosas que no van a revertir.

La primera es el entorno regulatorio. En el panorama de 2026, ser capaz de demostrar la procedencia del software es cada vez más un requisito legal, no un estándar voluntario. Las juntas y los reguladores están haciendo preguntas que las organizaciones no pueden responder.

La segunda es la velocidad de desarrollo de IA. A medida que las herramientas de IA generan más código y más dependencias, el volumen de componentes no verificados que entran en producción excederá la capacidad de cualquier organización para revisarlos manualmente. Las organizaciones que han establecido un catálogo curado y gobernado por políticas como la fuente predeterminada para sus desarrolladores y herramientas de IA podrán igualar la velocidad de IA con la gobernanza de seguridad adecuada. Las organizaciones que aún confían en registros públicos y revisión manual enfrentarán una brecha creciente entre lo rápido que se genera el código y lo exhaustivo que se evalúa.

Los ecosistemas curados son la respuesta de infraestructura a un problema que el desarrollo de IA ha hecho inevitable.

Como una de las pocas CEO mujeres en el espacio de código abierto y infraestructura, ¿qué cambios ha visto en la diversidad de liderazgo a lo largo de los años, y qué aún necesita mejorar?

Ha habido un cambio real. Cuando comencé mi carrera, la representación de mujeres en roles ejecutivos en código abierto e infraestructura era lo suficientemente baja como para que las excepciones fueran notables. Eso es menos cierto ahora. Hay más mujeres en puestos técnicos y ejecutivos senior, más organizaciones que han pasado de la fase de declaración de diversidad performática y están haciendo cambios estructurales, y más modelos para lo que el liderazgo en este espacio puede parecer.

El caso de negocio para cerrar la brecha restante no es abstracto. Los problemas que esta industria está trabajando ahora, el riesgo de la cadena de suministro de software, la gobernanza de IA, los cambios organizacionales necesarios para hacer que la seguridad sea una práctica de primer orden, son problemas difíciles. Los equipos diversos producen mejores resultados en problemas difíciles. No como una cuestión de aspiración, sino como una cuestión de cómo las diferentes perspectivas sacan a la luz suposiciones que los equipos homogéneos pierden. Lo he visto directamente. Las organizaciones que han hecho progreso real en la pertenencia, no solo en la representación, son las que donde la ventaja operativa se muestra en el trabajo.

La pertenencia aún es desigual en la industria. Estar en la sala no es lo mismo que tener su perspectiva genuinamente sopesada. Esa distinción es donde la próxima fase de progreso necesita suceder.

Gracias por la gran entrevista, los lectores que deseen aprender más deben visitar ActiveState.