Abby Kearns, CEO of ActiveState – Interview Series

Abby Kearns is CEO of ActiveState and a technology executive with more than 25 years of experience building and scaling enterprise software organizations. She previously served as CTO of Puppet, where she helped lead a strategic transformation culminating in the company’s acquisition by Perforce Software. Earlier in her career, she was CEO of the Cloud Foundry Foundation, guiding the growth of one of the industry’s largest open source cloud platform ecosystems. Abby currently serves on the board of Akka (formerly Lightbend). She is known for helping companies translate major shifts in cloud, open source, and AI into clear product strategy and enterprise growth.

ActiveState is a Canadian software company founded in 1997 that provides enterprise tools and platforms for building, managing, and securing open source software. Its core offering, the ActiveState Platform, helps development, DevOps, and security teams automate dependency management, detect and remediate vulnerabilities, and create secure, reproducible development environments across multiple programming languages like Python, Perl, and Tcl. By delivering prebuilt, verified open source components and integrating them into existing workflows, ActiveState aims to reduce security risks in the software supply chain while improving developer productivity and accelerating application delivery.

You’ve spent your career at the intersection of open source, cloud-native platforms, and enterprise transformation, from leading the Cloud Foundry Foundation to serving as CTO at Puppet. What drew you to take on the CEO role at ActiveState, and what is your vision for the company in this next phase of growth?

The through-line of my career has been operating at the intersection of community and infrastructure at moments when the industry is making decisions that will compound for years. Cloud Foundry was that moment for cloud-native. Puppet was that moment for configuration management and the early stages of what we now call DevSecOps. ActiveState is that moment for open source governance.

What drew me here is a problem I have watched build for a long time. Every enterprise I have encountered runs on open source. Most of them cannot tell you with confidence what open source they are running, whether it has been patched, or who is responsible for the decision to use it. That gap, between how foundational open source has become and how little rigor most organizations apply to governing it, is where the industry’s risk is accumulating. ActiveState has spent twenty years building the infrastructure to close that gap. My job is to make sure the market understands why closing it is urgent.

The vision for this next phase is clear: ActiveState becomes the default answer to the question of where enterprise open source comes from. Not a scanner. Not a report. A trusted, verified, continuously remediated source that organizations can point to when regulators, boards, or incident responders ask how they governed their software supply chain.

ActiveState is positioning itself as a critical layer in securing the software supply chain at a time when AI is accelerating code generation. How does AI fundamentally change the risk profile of open source software?

AI-assisted development breaks a foundational assumption that the entire open source governance toolchain was built on: that a developer made a deliberate decision to include a dependency.

Every SBOM mandate, every SCA tool, every vulnerability management workflow assumes there was a human in the loop who chose to pull that library. When AI generates code, dependencies arrive in production that no one selected, reviewed, or in many cases even knows are there. The governance tooling is looking for decisions. AI is making production changes that bypass the decision entirely.

There is a second layer to this. The coding tools that drove AI adoption, the productivity benchmarks, the developer surveys, the GitHub stars, none of those evaluation frameworks included security as a first-order measure. The industry optimized for speed and correctness and shipped the infrastructure without asking whether the output was safe. That is not a tooling failure. It is a leadership failure in how adoption decisions were made. We are now operating at scale on a foundation that was never evaluated for the risk it was introducing.

You’ve said that unmanaged open source is becoming a major enterprise vulnerability. Why is open source governance now rising to the board level, and what are executives still underestimating?

It is reaching the board because the regulatory environment has changed the accountability structure. The EU Cyber Resilience Act, SEC disclosure requirements, CISA’s Secure by Design guidance: these frameworks are shifting the question from “Did you have a scanner?” to “Can you prove your software was secure at the point of origin?” Those are very different questions, and most organizations cannot answer the second one.

What executives are still underestimating is that this is a structural problem, not a resourcing problem. The organizations I see responding to open source risk by adding more scanning tools are not solving the underlying issue. Scanning detects problems after they have entered your environment.

When everything is flagged, nothing gets prioritized, and the volume of alerts becomes its own operational dysfunction. The organizations that will navigate this successfully are not the ones buying more tools. They are the ones changing how they make decisions about what open source enters their environment in the first place, and who is accountable for those decisions.

With open source now embedded across most enterprise software stacks, how should organizations rethink open source as infrastructure rather than just a development convenience?

The mental model most organizations are working from is a decade out of date. Open source started as a development convenience. Developers could pull libraries, move faster, and avoid reinventing foundational components. That framing made sense when open source was optional and supplementary.

That is not the current reality. Open source is the foundation of modern software. Ninety-six percent of applications include open source components. It is not a convenience layer on top of proprietary infrastructure. It is the infrastructure. And infrastructure has to be governed like infrastructure, with explicit policies about what enters the environment, defined ownership for maintenance and remediation, and accountability that sits at the right level of the organization.

The organizations that are ahead on this have made a deliberate shift: open source consumption is a strategic decision with security and financial consequences, not a default setting that developers manage individually. That shift requires policy, operational process, and clear executive accountability. Most organizations have yet to make that shift.

You’ve led organizations through multiple technology waves. How does the current AI-driven shift compare to earlier transitions like cloud and DevOps in terms of speed and disruption?

The current AI-driven movement is very similar to prior technological shifts. When cloud emerged as a delivery model, the organizations that treated it as a pure technology choice made very different mistakes than the organizations that recognized it as an architectural and operational shift. The ones that failed to make the governance transition paid for it for years in shadow IT, cost overruns, and security and technical debt.

What is different about the current AI-driven shift is the speed and the invisibility. Cloud adoption was visible. You knew when your organization was migrating workloads from on prem to the cloud. DevOps was visible: organizations were restructuring teams, changing deployment pipelines, and rewriting processes. AI coding tools are being adopted developer by developer, tool call by tool call, and the risk is accumulating in the codebase before most organizations have registered that a governance decision was made.

The disruption is also asymmetric in a way that cloud and DevOps were not. Those transitions created new categories of risk but largely preserved the assumption that a human was responsible for the code that shipped. AI is eroding that assumption at the point where it is hardest to detect. That is what makes this transition different. The exposure is invisible until it is not.

Many companies struggle to turn open source adoption into a sustainable business model. What separates companies that succeed from those that fail?

The organizations that have built sustainable businesses on open source share one characteristic: they are disciplined about what product they are actually selling. They are not selling the open source software, which is free. They are selling the expertise, the operational support, the governance infrastructure, or the managed service that makes the free software viable at enterprise scale.

Conversely, organizations that fail tend to conflate community adoption with commercial traction. They are not the same thing. A high GitHub star count or a large community signals that developers find the project useful. It does not signal that buyers will pay for it, or that the thing developers find useful is the thing organizations actually need. The translation from developer adoption to enterprise value requires building something beyond the open source itself, and the organizations that fail to make that distinction clearly, in their positioning, their product, and their sales motion, tend not to survive the transition to scale.

From your experience scaling developer-first organizations, what are the biggest leadership challenges when transitioning from product-led growth to enterprise-scale operations?

The biggest challenge is that the skills and instincts that made you successful in product-led growth work against you at enterprise scale. Product-led growth rewards moving fast, iterating in public, optimizing for developer experience, and letting adoption lead the commercial motion. Enterprise sales rewards deliberate process, executive relationships, long cycles, and the ability to map your product to outcomes that matter to buyers who are not developers.

The leadership mistake I see most often is assuming the transition is primarily a sales motion problem. It is not. It is an organizational design problem. The team that built the product, the positioning, and the early customer relationships is often not the team that can execute the enterprise motion. Recognizing that without losing what made the product worth buying in the first place is genuinely hard. The leaders who do it well are the ones who are honest about which parts of the organization need to evolve and who build the new capabilities without dismantling the culture that created the product.

You’ve worked extensively at the intersection of security and developer productivity. How can companies balance speed and innovation with the growing need for secure, trusted software components?

The framing of speed versus security is a false choice that has persisted because the tooling has reinforced it. When security is implemented as a review gate at the end of the development process, it is a bottleneck. When it is implemented as a governed source of trusted components that developers pull from at the beginning of the process, it does not slow anything down.

Those that have resolved this tension have done it by shifting where security happens. Not reviewing code after it is written. Not scanning artifacts after they are built. Governing what goes into the catalog that developers and AI tools pull from. If the source is trusted, the velocity is not constrained by the security review because the security work happened upstream. That is an architectural decision, not a cultural one. It requires investment in the governance infrastructure, but it does not require choosing between moving fast and shipping safely.

As AI tools increasingly generate code and dependencies, how do you see the role of curated or trusted open source ecosystems evolving over the next few years?

The role of curated, trusted open source sources is going to shift from a best practice to a baseline requirement. That shift is being driven by two things that are not going to reverse.

The first is the regulatory environment. In the 2026 landscape, being able to demonstrate software provenance is increasingly a legal requirement, not a voluntary standard. Boards and regulators are asking questions that cannot be answered by organizations pulling directly from public registries.

The second is AI development velocity. As AI tools generate more code and pull more dependencies, the volume of unvetted components entering production will exceed any organization’s capacity to review them manually. The organizations that have established a curated, policy-governed catalog as the default source for their developers and AI tools will be able to match AI’s velocity with appropriate security governance. The organizations still relying on public registries and manual review will face a widening gap between how fast code is being generated and how thoroughly it is being evaluated.

Curated ecosystems are the infrastructure answer to a problem that AI development has made unavoidable.

As one of the few female CEOs in the open source and infrastructure space, what changes have you seen in leadership diversity over the years, and what still needs to improve?

There has been real change. When I started my career, the representation of women in executive roles in open source and infrastructure was low enough that the exceptions were notable. That is less true now. There are more women in senior technical and executive positions, more organizations that have moved past the performative diversity statement phase and are making structural changes, and more models for what leadership in this space can look like.

The business case for closing the remaining gap is not abstract. The problems this industry is working on now, software supply chain risk, AI governance, the organizational changes required to make security a first-order practice, are hard problems. Diverse teams produce better outcomes on hard problems. Not as a matter of aspiration but as a matter of how different perspectives surface assumptions that homogeneous teams miss. I have seen this directly. The organizations that have made real progress on belonging, not just representation, are the ones where that operational advantage shows up in the work.

Belonging is still uneven across the industry. Being in the room is not the same as having your perspective genuinely weighed. That distinction is where the next phase of progress needs to happen.

Thank you for the great interview, readers who wish to learn more should visit ActiveState.