필사 모드: OPA 现在由谁维护 — Styra 团队加入 Apple，之后 11 个月的可验证记录

• 引言 — 「Apple 收购了 OPA」到底有几分是真的
• 2025 年 8 月 20 日，公告的准确内容
• 那到底算不算收购 — 能确认的和不能确认的
• 此后的 11 个月，发布从未停止
• Styra 各工具的不同命运
• 治理算术 — 当全部维护者都隶属同一家公司
• open core 用户该从这起事件中检查些什么
• 所以你该做什么
• 结语
• 参考资料

引言 — 「Apple 收购了 OPA」到底有几分是真的

2025 年 8 月末，在授权(authorization)技术栈里装了 OPA 的团队之间流传起传言:「Apple 收购了 Styra」「OPA 归 Apple 了」。策略引擎这种东西一旦装上就深深嵌入基础设施，这类传言不容易一笑置之。可这些说法并不准确 — 而准确地说清楚哪里、怎样不准确，对实务者来说很重要。

本文的事实核查全部依据一手资料: OPA 官方博客的公告原文、通过 GitHub API 查询到的发布、提交、仓库元数据，仓库中的 MAINTAINERS.md 与 GOVERNANCE.md 原文，以及公共 DNS 解析器的查询结果(截至 2026-07-17)。从给传言打分开始，一路记录到 11 个月后的今天 OPA 究竟处于什么状态。

2025 年 8 月 20 日，公告的准确内容

公告不是 Apple 发的，而是发在 OPA 博客上。Note from Teemu, Tim, and Torin to the Open Policy Agent community — 这是以 OPA 创始人们的名义发出的文章，日期是 2025 年 8 月 20 日。要点如下。

• OPA 的创始人们和多名 Styra 团队成员将加入 Apple。
• Apple 已经是 OPA 的大规模用户 — 公告明确写道，Apple 把它作为全球云服务授权基础设施的核心组件在用。
• OPA 依然是 CNCF 毕业项目，项目治理与许可证都不会改变。
• 维护者名单保持不变，唯一变化的是这些维护者的所属标注(从 Styra 改成 Apple)。
• 原本在 Styra GitHub 下的工具 — 商业发行版 EOPA、OPA Control Plane、各种 SDK(TypeScript、React、C#、Java 等)、Rego 检查器 Regal — 将启动迁移到 CNCF 旗下 OPA GitHub 组织的社区流程。
• 网站继续由 CNCF 和社区运营，Rego Playground 继续由 Styra 运营。
• 维持月度发布节奏，继续推进 2025 年路线图(语言扩展、类型检查、工具链、部分求值、性能、决策日志)。

有一点值得注意。这份公告里从头到尾没有出现「收购」这个词。这不是一家公司买下另一家公司的故事，而是人员换了雇主的故事。

那到底算不算收购 — 能确认的和不能确认的

对照媒体报道的原文来看，措辞更明确。Cloud Native Now 的报道写道，Apple 招募了 Styra 联合创始人 Tim Hinrichs 和 Torin Sandall，以及若干资深工程师，但并未收购这家公司或其资产，并称之为「没有收购的 acquihire(收购人才)」。目前没有发现 Apple 就此事以自己名义发布的另一份声明。

此后 Styra 这家公司发生了什么，并没有留下官方文档。不过有些可观察到的事实。截至本文写作时的 2026 年 7 月 17 日:

• styra.com 在公共解析器(1.1.1.1、8.8.8.8)上查询 A 记录和 NS 记录都返回 SERVFAIL。这个域名的网站已经实际上消失了。
• github.com/StyraInc 组织页面返回 404。旧的 StyraInc/regal 之类地址会重定向到 open-policy-agent 组织下的仓库。
• 关于公司的法律状态(是否清算等)，没有找到官方声明。不知道的事情如实写作不知道，才是准确的做法。

另一方面，人们在 Apple 内部继续从事 OPA 相关工作，这一点可以直接从公开提交记录中确认。比如 open-policy-agent/swift-opa 仓库里，公告发布之后仍然能看到创始成员用 Apple 邮箱提交代码的记录。顺带一提，这个仓库本身建于公告之前的 2025 年 4 月，Swift OPA 发布文章则是在 2025 年 5 月 14 日上线的 — 这是 Apple 方面对 OPA 的使用早在 8 月公告之前就已经在进行的旁证。

此后的 11 个月，发布从未停止

一个项目是死是活，回答问题的是发布记录，不是言语。从 OPA 发布列表 里只挑出公告之后的次版本发布，结果如下。

中间还有若干补丁发布，截至本文写作时最新版本是 v1.18.2(2026-07-02)。公告承诺的月度节奏被字面意义上地遵守了。顺带一提，OPA 1.0.0 是在 2024 年 12 月 20 日发布的，所以整个 1.x 时代都和这场剧变重叠，但从发布节奏上看不出任何断层。

内容也不只是维护性的修修补补。公告里写的路线图条目中，有几项确实已经出货。

• v1.15.0 — 日志插件接口，以及支持轮转的文件日志器。对应路线图中「把日志写到磁盘」这一项。
• v1.17.0 — 通过 future.keywords.not 导入，改善了 Rego 长期存在的否定(negation)语义问题。这是路线图语言扩展项之一。
• v1.18.0 — 容器感知的资源限制(恢复 GOMAXPROCS、支持 GOMEMLIMIT)，以及一处破坏性修复: 出站 User-Agent 请求头违反了 RFC 9110，因此从 Open Policy Agent/版本 的形式改成了 Open-Policy-Agent/版本 的形式。如果你有精确匹配这个字符串的 WAF 规则或日志过滤器，需要更新。

发布说明的贡献者列表里，除了 Apple 系维护者之外的名字也一直在出现。不过「有发布」和「项目健康」并不是一回事，这一点我们在后面的治理小节里再谈。

Styra 各工具的不同命运

公告承诺的迁移确实发生了。但迁移之后各工具的走向却各不相同 — 这正是这起事件里最值得学习的部分。

Regal — 活下来的那个。 Rego 检查器 Regal 迁移到 open-policy-agent 组织之后依然持续发布。最新的 v0.42.0 发布于 2026 年 7 月 16 日 — 就在本文前一天。

OPA Control Plane — 正在成长的新生事物。 opa-control-plane 是一个管理组件，负责从 Git 仓库构建策略包，并部署到 S3、GCS、Azure Blob 之类的对象存储。迁移后的第一个标签 v0.1.0 发布于 2025 年 11 月 18 日，最新的 v0.7.0 发布于 2026 年 6 月 9 日。它还是 0.x 版本，这一点照字面理解就好 — 现在正处在被搭建的阶段。

EOPA — 捐了出来，却停下来了。 曾经面向数据密集型负载的商业发行版 EOPA 被捐赠为开源，从 2025 年 8 月 28 日的 v1.43.0 一直发布到 11 月 6 日的 v1.45.1。然后就停了。此后只偶尔出现依赖升级提交，直到 2026 年 6 月 26 日随一次「归档说明」提交，仓库被归档。README 里留了话，说代码可以随便拿去用，如果有人有兴趣维护，欢迎去 OPA Slack 联系。从捐赠到归档大约 10 个月 — 没有人接手。

其他情况。 Rego Playground 今天依然返回 HTTP 200(公告发布时的运营方是 Styra，但现在究竟是谁在运营，没有官方文档可以确认)。SDK 们也在迁移名单里，但各个仓库具体的活跃程度，本文没有逐一核实。还有一处明显的空白 — 曾是 Styra SaaS 管理平面的 DAS，压根没有出现在公告的 FAQ 列表里。至于商业客户收到了什么样的通知，如今 styra.com 已经消失，靠公开信息源已经无从确认。

治理算术 — 当全部维护者都隶属同一家公司

接下来是不太舒服的部分。读一下截至今天的 MAINTAINERS.md，负责 opa 仓库领域的 6 位维护者(Anders Eknert、Ash Narkar、Charlie Egan、Stephan Renatus、Tim Hinrichs、Torin Sandall)的所属，全部是 Apple。Gatekeeper 系列(constraints、gatekeeper 等)情况不同，由 1 位 Google 所属和 3 位 Microsoft 所属的维护者负责，其中 Microsoft 那 3 位的更新时间标注为 2026 年 1 月 30 日。

GOVERNANCE.md 规定了以组织为单位的投票(organizational voting) — 不论一个组织有多少维护者，每个组织只有一票，文档表明的用意是不让任何一个组织支配某个特定领域。可算一算账就会发现，目前在 opa 领域拥有投票权的组织只有 Apple 一家。安全阀在形式上还在，但那个领域里已经没有能与之制衡的组织了。

公平地说，这种集中并不是新问题。同一批人昨天为止都还隶属 Styra，所以 opa 领域实际上集中在一家公司手里，这在 Styra 时代同样如此。变化的是这家公司的性质 — 从一家靠卖策略引擎为生的公司，变成一家把策略引擎当作内部基础设施来用的公司。厂商有动机把开源项目维持成商业产品的引流入口，大规模用户则有动机为了自身基础设施的稳定性而维护它。哪一种结构对社区更好，无法一概而论，而目前为止这 11 个月的数据，至少不支持「放任不管」的剧本。

最后一道安全网，就在于这个项目归属于一个基金会，而不是个人或公司这件事本身。OPA 在 2021 年 2 月成为 CNCF 毕业项目，代码采用 Apache-2.0 许可证。即便在最坏的情形下，分叉与传承在法律上依然是敞开的 — HashiCorp 变更许可证时从 Vault 分叉出来的 OpenBao，就是这条路径的实例，那段故事在《OpenBao v2.6》梳理文章里另有专门讨论。正因为治理权归于基金会，OPA 才得以在没有分叉的情况下挺过这场剧变 — 这是两个案例对比中最突出的一点。

open core 用户该从这起事件中检查些什么

EOPA 的走向就是核心教训。当厂商消失时，把商业产品开源出来，无疑是一种体面的退场方式，但开源化只能保证代码的存续，保证不了产品的存续。哪怕代码是公开的，只要没有人出来维护，10 个月后照样会被归档。如果你在用处境类似的工具，检查清单如下。

• 把你现有技术栈里依赖商业专属功能的部分列出来。如果你是 EOPA 用户，数据过滤或数据库集成功能就属于这一类。
• 确认项目的所有权结构。归属于基金会(如 CNCF)还是完全归厂商所有，厂商消失这种情形下的结果会完全不同。这正是这次 OPA 得以顺利渡过、没出大乱子的首要原因。
• 真正去读一遍 MAINTAINERS 文件。维护者所属的多样性，是一个能从公开文档里确认的风险指标。
• 提前算好退出成本。策略引擎属于替换成本很高的一类 — 换一种策略语言(Rego、Cedar、关系元组)，移植基本等于重写。

所以你该做什么

只用开源 OPA 的团队 — 眼下没什么要做的。发布节奏、治理文档、许可证都和公告之前一样维持着。不过有几个指标值得盯着: 月度节奏是否维持，是否出现非 Apple 背景的贡献和新维护者的加入。

依赖 EOPA 功能的团队 — 需要做决定了。仓库已经被归档，而且是 Apache-2.0 许可，所以自己分叉维护是自由的，但如果承担不起那个成本，就需要一个迁移替代方案。要注意，上游 OPA 并没有把 EOPA 的功能全部吸收进去。

用 Styra DAS 管理 OPA 集群的团队 — 公告里没有提到 DAS，处理同一问题空间(构建和分发策略包)的是迁移过来的 OPA Control Plane。但没有任何文档正式宣布它是继任者，版本也还是 0.x。这还不是一个可以不经验证就切换过去的东西。

正在考虑新引入的团队 — 这起事件本身不是回避 OPA 的理由。相反，它更像是一个证明了基金会治理价值的案例。引擎的选择依然由问题的类型决定 — 是通用策略求值(OPA)，还是基于关系的授权(Zanzibar 系列)，这方面的比较整理在授权引擎深度对比里。如果目标是 Kubernetes 准入策略，也可以参考Kyverno 与 OPA Gatekeeper 对比 — 正如上文所见，Gatekeeper 领域是由 Google 和 Microsoft 的维护者在守着的。

结语

只留下事实，是这样的。收购从未被宣布过，发生的是人员换雇主。项目归属于基金会，所以即便人们的雇主变了，治理和发布依然延续下来。商业产品被捐赠为开源，其中检查器活了下来，商业发行版却在 10 个月后被归档 — 同一起事件里同时展示了开源化并不等于可持续性。

「厂商一消失，开源项目就完了」是错的，「反正是开源，所以绝对安全」也是错的。真正的分岔口在于所有权结构和维护动机落在哪里。借这个机会，建议你打开 MAINTAINERS 文件，看看自己技术栈里有哪些组件正悬在一家公司手里。

参考资料

• Note from Teemu, Tim, and Torin to the Open Policy Agent community (OPA 博客，2025-08-20)
• OPA 发布列表 (GitHub)
• OPA MAINTAINERS.md (原文) / GOVERNANCE.md (原文)
• open-policy-agent/eopa — 捐赠后被归档的仓库
• Regal 发布记录 / OPA Control Plane 发布记录
• OPA v1.17.0 发布说明 — future.keywords.not / v1.18.0 发布说明 — User-Agent 破坏性修复
• CNCF，OPA 毕业公告 (2021-02-04)
• Apple Buys Styra Brains, OPA Remains Open (Cloud Native Now)
• Introducing Swift OPA (OPA 博客，2025-05-14)
• 授权引擎深度对比 — FGA/Zanzibar 系列比较 (相关文章)
• OpenBao v2.6 — 从 Vault 分叉之后 (相关文章)