艾比·卡恩斯，ActiveState 首席执行官 – 采访系列

艾比·卡恩斯 是 ActiveState 的首席执行官，也是一位拥有超过 25 年经验的技术高管，曾参与建设和扩展企业软件组织。她曾担任 Puppet 的首席技术官，在公司被 Perforce Software 收购之前，帮助领导了公司的战略转型。在她的职业生涯早期，她曾担任 Cloud Foundry 基金会的首席执行官，指导了该行业最大的开源云平台生态系统的增长。艾比目前担任 Akka（前身为 Lightbend）的董事会成员。她以帮助公司将云、开源和人工智能等重大转变转化为清晰的产品战略和企业增长而闻名。

ActiveState 是一家成立于 1997 年的加拿大软件公司，提供企业工具和平台用于构建、管理和保护开源软件。其核心产品 ActiveState 平台帮助开发、DevOps 和安全团队自动化依赖管理、检测和修复漏洞，并在多种编程语言（如 Python、Perl 和 Tcl）中创建安全、可复现的开发环境。通过提供预构建、验证的开源组件并将其集成到现有的工作流中，ActiveState 旨在减少软件供应链中的安全风险，同时提高开发人员的生产力和加速应用程序交付。

您在整个职业生涯中都处于开源、云原生平台和企业转型的交叉点，从领导 Cloud Foundry 基金会到担任 Puppet 的首席技术官。是什么吸引您担任 ActiveState 的首席执行官，您对公司的下一阶段增长有什么愿景？

我的职业生涯的主线是运营在社区和基础设施的交叉点，当行业正在做出将在未来几年内累积的决定时。Cloud Foundry 是云原生的那一刻。Puppet 是配置管理和我们现在称为 DevSecOps 的早期阶段的那一刻。ActiveState 是开源治理的那一刻。

我被吸引到这里的是一个我已经观察了很久的问题。每个企业我遇到过都运行在开源上。其中大多数都无法自信地告诉你他们运行哪些开源软件，是否已修补，或者谁负责决定使用它。这种差距，在开源已经变得多么基础和大多数组织应用于治理它的严谨性之间，正是行业风险积累的地方。ActiveState 已经花了 20 年时间构建基础设施来填补这一差距。我的工作是确保市场了解为什么关闭它是紧急的。

这一阶段的愿景是明确的：ActiveState 成为企业开源的默认来源。不是扫描仪。不是报告。一个值得信赖、经过验证、持续修复的来源，组织可以指向它，当监管机构、董事会或事件响应人员询问如何管理他们的软件供应链时。

ActiveState 正在将自己定位为软件供应链安全的关键层，尤其是在人工智能加速代码生成时。人工智能如何从根本上改变开源软件的风险概况？

人工智能辅助开发打破了整个开源治理工具链的基本假设：开发人员故意决定包含依赖项。

每个 SBOM 条例、每个 SCA 工具、每个漏洞管理工作流程都假设有一个人类在循环中选择了该库。当人工智能生成代码时，依赖项以无人选择、审查甚至不知道它们存在的方式进入生产。治理工具链正在寻找决定。人工智能正在绕过决定本身做出生产更改。

还有第二层。驱动人工智能采用的编码工具、生产力基准、开发人员调查、GitHub 星级，所有这些评估框架都没有将安全性作为第一级指标。该行业优化了速度和正确性，并在未询问输出是否安全的情况下交付了基础设施。这不是工具链故障。这是领导层在采纳决策方面的失败。我们现在正在规模上运行一个从未被评估为引入的风险的基础设施上。

您曾说过，未经管理的开源软件正在成为企业的一大漏洞。为什么开源治理现在正在上升到董事会层面，什么是高管仍然低估的东西？

它正在达到董事会层面，因为监管环境已经改变了问责结构。欧盟网络安全法、SEC 披露要求、CISA 的安全设计指南：这些框架正在将问题从“您有扫描仪吗？”转变为“您能证明您的软件在源头是安全的吗？”大多数组织无法回答第二个问题。

高管仍然低估的是，这是一个结构问题，而不是资源问题。响应开源风险的组织通过添加更多扫描工具并没有解决根本问题。扫描仅在问题进入环境后检测到它们。

当一切都被标记时，什么都不被优先考虑，警报的数量本身就成为一种运营失灵。成功应对这一问题的组织不是购买更多工具的组织，而是改变决定哪些开源进入其环境以及谁对这些决定负责的组织。

随着开源软件现在嵌入到大多数企业软件栈中，组织应该如何重新思考开源软件作为基础设施而不是仅仅作为开发便利？

大多数组织正在使用的思维模型已经过时了。开源软件最初是开发便利。开发人员可以拉取库，移动得更快，避免重新发明基础组件。当开源软件是可选的和补充性的时，这种框架是有意义的。

这不是当前的现实。开源软件是现代软件的基础。96% 的应用程序包含开源组件。它不是在专有基础设施之上的便利层。它是基础设施。基础设施必须像基础设施一样被治理，具有明确的政策来决定什么进入环境，明确的所有权用于维护和修复，以及适合组织级别的问责制。

领先的组织已经做出了刻意的转变：开源消费是一项具有安全性和财务后果的战略决策，而不是开发人员个别管理的默认设置。这种转变需要政策、运营流程和明确的高管问责制。大多数组织尚未做出这种转变。

您曾领导过多次技术波浪。当前的人工智能驱动的转变与云和 DevOps 等早期转变相比如何，速度和破坏性如何？

当前的人工智能驱动运动与以前的技术转变非常相似。当云作为交付模型出现时，认为它是纯技术选择的组织犯了与认为它是架构和运营转变的组织不同的错误。那些未能进行治理转变的组织在影子 IT、成本超支、安全性和技术债务方面为此付出了多年的代价。

不同之处在于速度和不可见性。云采用是可见的：您知道您的组织何时正在将工作负载从本地迁移到云端。DevOps 是可见的：组织正在重组团队、更改部署流水线和重写流程。人工智能编码工具正在被开发人员、工具调用逐一采用，而风险正在代码库中积累，大多数组织甚至还没有注册到治理决策中。

破坏也不同。云和 DevOps 转变创造了新的风险类别，但大致保留了人类负责交付代码的假设。人工智能正在侵蚀这一假设，在最难以检测的点上。

许多公司难以将开源软件采纳转化为可持续的商业模式。什么因素区分了成功和失败的公司？

在开源软件上建立可持续业务的组织共享一个特征：它们在销售什么产品方面非常有纪律。它们不销售开源软件本身，因为它是免费的。它们销售的是专业知识、运营支持、治理基础设施或使免费软件在企业规模上可行的托管服务。

相反，失败的组织往往混淆社区采用和商业牵引力。它们不是同一件事。高的 GitHub 星级或大社区表明开发人员认为该项目有用。它并没有表明买家会为它付费，或者开发人员认为有用的东西是组织真正需要的东西。从开发人员采用到企业价值的转换需要建立超出开源软件本身的东西，无法清晰地在定位、产品和销售动作中区分这一点的组织往往无法生存到扩大规模。

从您的经验来看，开发者优先的组织如何转变为企业规模的运营？领导层面临的最大挑战是什么？

最大的挑战是使您在产品主导增长中成功的技能和直觉在企业规模上起到了反作用。产品主导增长奖励快速移动、公开迭代、优化开发人员体验和让采用率引领商业动作。企业销售奖励故意的流程、执行关系、长周期和将您的产品映射到买家关心的结果的能力，而买家不是开发人员。

我看到的最常见的领导错误是假设转变主要是一个销售动作问题。它不是。这是一个组织设计问题。建立产品、定位和早期客户关系的团队往往不是执行企业动作的团队。认识到这一点而不失去使产品值得购买的东西是真正具有挑战性的。做得好的领导者是那些诚实地承认哪些部分需要演变并建立新能力而不拆除创造产品的文化的人。

您在安全性和开发人员生产力交叉点上工作了很长时间。公司如何平衡速度和创新与对安全可靠的软件组件的日益增长的需求？

速度与安全性的框架是一个错误的选择，这个选择一直持续下去，因为工具链已经加强了它。当安全性作为开发过程结束时的审查门实施时，它是一个瓶颈。当它作为开发人员和人工智能工具从一开始就拉取的可信组件的治理来源实施时，它不会减慢任何事情。

那些解决了这一紧张关系的组织通过改变安全性发生的位置来实现这一目标。不再是在代码写完后审查代码。不再是在构建后扫描工件。在开发人员和人工智能工具拉取的目录中治理进入其中的内容。如果来源是可信的，安全审查不会限制速度，因为安全工作发生在上游。

随着人工智能工具越来越多地生成代码和依赖项，您如何看待可信开源生态系统的角色在未来几年内的演变？

可信开源来源的角色将从最佳实践转变为基线要求。这种转变是由两个不会逆转的因素驱动的。

第一个是监管环境。到 2026 年，能够证明软件来源的能力越来越成为法律要求，而不是自愿标准。董事会和监管机构正在提出无法通过直接从公共注册表中拉取来回答的问题。

第二是人工智能开发速度。随着人工智能工具生成更多代码并拉取更多依赖项，未经审查的组件进入生产的数量将超过任何组织手动审查的能力。建立了可信、基于策略的目录作为开发人员和人工智能工具的默认来源的组织将能够用适当的安全治理来匹配人工智能的速度。仍然依赖公共注册表和手动审查的组织将面临代码生成速度与代码评估彻底性之间日益扩大的差距。

策划的生态系统是对人工智能开发使之不可避免的问题的基础设施答案。

作为开源和基础设施领域的少数女性首席执行官之一，您在这些年里看到领导力多样性发生了怎样的变化？还有什么需要改进的？

已经发生了真正的变化。当我开始我的职业生涯时，开源和基础设施领域的女性在高级职位中的代表性非常低，以至于例外是值得注意的。这不再是真的。现在有更多的女性担任高级技术和执行职位，有更多的组织已经超越了表演性多样性声明阶段，并正在进行结构性改变，还有更多的领导力模型可以在这个领域中看到。

弥合剩余差距的商业理由并不是抽象的。该行业目前正在处理的软件供应链风险、人工智能治理以及使安全成为首要实践所需的组织性变化都是艰难的问题。多样化的团队在艰难的问题上产生更好的结果。这不是一个愿望的问题，而是一个如何处理艰难问题的实际问题。不同视角会揭示同质化团队会忽略的假设。我已经直接看到这一点。真正在归属感方面取得了进步的组织是那些在工作中表现出优势的组织。

归属感仍然在整个行业中是不均匀的。进入房间与真正被重视的视角是不同的。进步的下一个阶段需要发生在这一区别中。

感谢这次精彩的采访，希望读者能够通过访问 ActiveState 了解更多信息。