This is a very well written announcement. It immediately defines OPA (for people like me who don’t immediately recognize it). It says what’s not changing for people, and says where things will go.
For the people who are currently experiencing the first time a project they heavily used gets acquired by a for-profit company, it's worth remembering that everything written is "As it stands currently", which can change at any time.
It wouldn't be the first time the founders/company/project said "Nothing will change now when we got acquired" only for it to shutdown/change drastically just months after.
Lots of FOSS maintainers are happy to bitch and moan about how they are doing god's work for little or no remuneration. They are of course, quite correct to do so, it is indeed hard work, long hours, poor or no pay.
But, and its a big BUT .... you can put all the donation, crowdfunding buttons that you like on your GitHub page. The reality is that will only get you so far.
So there is a lot to be said for corporations that recognise the work and are willing to pay an old-school salary to the maintainers. It provides life-stability for the maintainers, and it provides product-stability for the corporation ... win-win.
And in 2025 the reality is that corporation thinking on open-source is a far cry of what it was back-then. In the majority they are far more enlightened and open to contributing-back.
Yes it will never be sufficient for the die-hard FOSS greybeards. But even a billion dollar corporation cannot possibly put dollars behind every single tiny piece of open-source software it ever uses. You have to pick-and-choose, its just the reality of life.
Finally, regarding the FUD about "oh, its going to be shutdown tomorrow". That road is paved with examples where it DID NOT happen ... I seem to recall that the usual suspects (Redhat / Canonical / IBM etc.) all employ a great deal of maintainers of various critical parts of Linux. As far as I can tell the output of those maintainers taking the corporate dime has neither suffered or been shutdown.
>But, and its a big BUT .... you can put all the donation, crowdfunding buttons that you like on your GitHub page. The reality is that will only get you so far.
I agree. Most people simply won't donate, be it individuals or companies using the tools.
>In the majority they are far more enlightened and open to contributing-back.
Ehh, it's mixed. A few companies won't mind going open source, some "open source", and many "open source but not really". Just having your code readable isn't the FOSS menality, and that's pretty much where the buck stops.
>Finally, regarding the FUD about "oh, its going to be shutdown tomorrow". That road is paved with examples where it DID NOT happen
Suvivor's bias doesn't really feel reassuring here. And just because it's not shut down doesn't mean it won't be subject to corporate rot. That's honestly worst than an honorable death.
I was left with the somewhat opposite feeling. I still don’t know what OPA actually is or does. It has a nice paragraph describing it without saying anything at all.
OPA solves the problem of defining and enforcing policies across a system. Some examples:
- How do I enforce that inbound API requests come only from trusted sources?
- How do I enforce fine-grained access to user records?
- How do I enforce a set of naming conventions for a data update?
Many such policies may come from regulatory requirements, may be regional in nature, and may change in otherwise stable codebases. And it's even harder when you're applying this to a highly-scalable production internet service. As a result, defining policy at an organizational level with auditing is a challenge for large enterprises. OPA helps enterprises administer and enforce policies.
That's still not saying what it is, though. Is it a thing you put in front of your backend to allow/deny requests? Is it an endpoint something like nginx calls with an auth token and the http verb and url that responds with 200/403 that nginx can react to? Is it a library you embed in your application? Is it an agentic AI?
It's as though you're describing a car to someone who's never seen a car before by listing all the places you can go in a car.
I guess I’m familiar with the general concept/domain it’s in. I haven’t used it myself, but having it spelled out was enough base knowledge for me to grab on to.
Looking again, I see your point. If you don’t know what it is having the acronym spelled out doesn’t help much at all.
Still it clears the low bar provided by those announcements that just say something like:
“BEOTZ’s developers are joining Flmp.io. As well all know BEOTZ is popular and Flmp.io is a top provider to enterprises. We look forward to exciting things coming soon.”
A counter example would be Weaveworks(folks behind Flux/FluxCD and many other widely used oss tools). I'm sure the ex employees would've preferred to get acquihired vs closing up for good. I highly doubt Styra was pulling in enough money to fund their business, and the days of zirp are long gone, so I doubt they would've been able to raise another round to keep the lights on for another few years.
ControlPlane was able to hire (not acqui-) a few of the FluxCD maintainers and other WeaveWorks staff to continue supporting the project — we did what we could, agree this is better for Styra folk than the uncertainty of closing up shop.
The shop (Styra) did get closed. A few of the most senior maintainers were hired by Apple. Many - including anyone not directly involved in engineering of the OSS product - are now looking for jobs.
Was FoundationDB a CNCF project at the time of acquisition, or in some similar incubator/umbrella? Besides, seems FoundationDB was open sourced after Apple acquired it, wouldn't mean FoundationDB get more open after the acquisition? Although development stalled no matter what so maybe doesn't matter.
FoundationDB development has not stalled; v8 is still on the way. If anything, it's mostly just been stable for a while now, and it has now been developed as open source longer than it existed as closed source.
Right, FoundationDB wasn't even open source when Apple acquired them. The FoundationDB story is a prime example of why it is important to use open source technologies for foundational infrastructure.
Excuse me? FDB was a closed source product, and Apple open sourced it under a permissive license and have since spent tens of millions of dollars on maintainers salaries and open sourced all kinds of adjacent software.
How did this idiotic, uninformed meme come about exactly?
Yup, reads like the typical announcement from the Apache Foundation era, where projects just go to wither.
This leaves me quite bummed out. After Oso[0] went from a superb open source policy evaluation solution to one that's completely closed, OPA is what I'm typically reaching for now, but now it'll likely be on life support.
From the post, I'm pretty sure Apple didn't buy Styra. Sounds like Apple hired the maintainers who worked at Styra (including Tim, Teemu and Torin). I'm guessing that Styra is just shutting down.
It's great to see authorization getting more attention in the mainstream developer conversation.
For folks exploring policy-based authorization solutions, we've written up a detailed comparison between Cerbos and OPA that might be helpful: https://www.cerbos.dev/blog/cerbos-vs-opa
The key differences tend to be around developer experience, policy language complexity, and deployment patterns. Both are solid open source options depending on your specific needs.
Seems similar to Apple's 2015 acquisition of FoundationDB -- they sunset the commercial offering. But it's unclear if they acquired Styra or just hired the team?
This is a more defensible take than some on here, but still a wild comparison. FDB was closed source software that existing customers kept source access to the entire time it was closed, and then opened under a permissive license soon after. So yes, you couldn’t buy it, but if you had, you kept access to new development.
At scale, the larger companies end up needing to be able to make policy decisions (read: authn/authz, most of the time) across a large number of "policies" in an efficient way. Everybody starts with simple representations that can go fast but have limited expression, then moves to various forms of extensions/templating/substitution/rules/etc.
OPA and Rego use a datalog variant to bring order to that bespoke mess. Think IAM policy, but you DRY because it's a real programming language with a library full of nice-to-have built-ins.
1. Any idea on what should I start next so that I can get acquihired?
2. It looks like Apple didn't get much 'ownership' of OPA in this case, what was the point of purchasing the company as a whole versus simply offering these 3 employees generous sign-on bonuses?
3. Why is it that companies generally tend to pay a lot more per employee in an acquihire scenario?
3. (From zero authority here as I’ve never bought a company:)
Perhaps the acquired employees might prefer this for tax reasons. If they stand to profit mainly via capital gains, that is wildly better than receiving ordinary income, like a bonus, would be.
Or, a completely different, unverifiable possibility:
An acquisition does not set any precedent for compensation of any kind. As a general rule corporations hate paying humans, but don’t mind paying other corporations.
3. It's very hard to know what kind of compensation employees are actually getting in an acqui-hire. I've been involved in a few of these - money flows through the cap table, so investors and founders get most of it depending on liquidation preference. Retained employees get a typical, levelled offer + some cash/stock (probably more stock) incentive with the usual 1 year cliff and 3-4 year earn-out. Incentives are also usually contingent on specific business goals.
In other words, the scenarios I've seen if the acquired company is not doing well the acquirer pays off the investors and gives the employees a small bonus contingent on staying for 1+ years and hitting goals. It's not necessarily a crazy windfall.
1. probably something with AI in it. You got maybe 2-3 years before the bubble pops.
2. branding. cultural awareness can take years or more, and I'm sure coporate knows by now that their brands aren't the best thing to slap onto every scenario. Disney is well learned in this kind of conduct.
3. Because the last thing you want in an aquihire is for all the talent your poaching to jump ship. Some employees may have even worked there previously and used a company to get away from that corporate culture.
So a lot of an aquihire's money tends to go towards golden handcuffs.
This is a very well written announcement. It immediately defines OPA (for people like me who don’t immediately recognize it). It says what’s not changing for people, and says where things will go.
Congratulations to the team.
> It says what’s not changing for people
For the people who are currently experiencing the first time a project they heavily used gets acquired by a for-profit company, it's worth remembering that everything written is "As it stands currently", which can change at any time.
It wouldn't be the first time the founders/company/project said "Nothing will change now when we got acquired" only for it to shutdown/change drastically just months after.
And the other side of that coin is ...
Lots of FOSS maintainers are happy to bitch and moan about how they are doing god's work for little or no remuneration. They are of course, quite correct to do so, it is indeed hard work, long hours, poor or no pay.
But, and its a big BUT .... you can put all the donation, crowdfunding buttons that you like on your GitHub page. The reality is that will only get you so far.
So there is a lot to be said for corporations that recognise the work and are willing to pay an old-school salary to the maintainers. It provides life-stability for the maintainers, and it provides product-stability for the corporation ... win-win.
And in 2025 the reality is that corporation thinking on open-source is a far cry of what it was back-then. In the majority they are far more enlightened and open to contributing-back.
Yes it will never be sufficient for the die-hard FOSS greybeards. But even a billion dollar corporation cannot possibly put dollars behind every single tiny piece of open-source software it ever uses. You have to pick-and-choose, its just the reality of life.
Finally, regarding the FUD about "oh, its going to be shutdown tomorrow". That road is paved with examples where it DID NOT happen ... I seem to recall that the usual suspects (Redhat / Canonical / IBM etc.) all employ a great deal of maintainers of various critical parts of Linux. As far as I can tell the output of those maintainers taking the corporate dime has neither suffered or been shutdown.
>But, and its a big BUT .... you can put all the donation, crowdfunding buttons that you like on your GitHub page. The reality is that will only get you so far.
I agree. Most people simply won't donate, be it individuals or companies using the tools.
>In the majority they are far more enlightened and open to contributing-back.
Ehh, it's mixed. A few companies won't mind going open source, some "open source", and many "open source but not really". Just having your code readable isn't the FOSS menality, and that's pretty much where the buck stops.
>Finally, regarding the FUD about "oh, its going to be shutdown tomorrow". That road is paved with examples where it DID NOT happen
Suvivor's bias doesn't really feel reassuring here. And just because it's not shut down doesn't mean it won't be subject to corporate rot. That's honestly worst than an honorable death.
See Xamarin, and what is left of it in 2025, as a good example.
Styra was also a for profit company. The project is part of CNCF though.
I was left with the somewhat opposite feeling. I still don’t know what OPA actually is or does. It has a nice paragraph describing it without saying anything at all.
OPA solves the problem of defining and enforcing policies across a system. Some examples:
- How do I enforce that inbound API requests come only from trusted sources?
- How do I enforce fine-grained access to user records?
- How do I enforce a set of naming conventions for a data update?
Many such policies may come from regulatory requirements, may be regional in nature, and may change in otherwise stable codebases. And it's even harder when you're applying this to a highly-scalable production internet service. As a result, defining policy at an organizational level with auditing is a challenge for large enterprises. OPA helps enterprises administer and enforce policies.
More details on what OPA does here: https://www.openpolicyagent.org/docs/philosophy
And you can see some examples of Rego (the policy language) here: https://play.openpolicyagent.org
That's still not saying what it is, though. Is it a thing you put in front of your backend to allow/deny requests? Is it an endpoint something like nginx calls with an auth token and the http verb and url that responds with 200/403 that nginx can react to? Is it a library you embed in your application? Is it an agentic AI?
It's as though you're describing a car to someone who's never seen a car before by listing all the places you can go in a car.
Fundamentally it's a programming language so all the normal ways of running it apply:
Use their library in your application to evaluate policies.
Run it from the cli.
Embed it in some service like nginx.
The language itself is pretty focused on some prolog-ish describing of what constitutes an allow/deny decision.
I guess I’m familiar with the general concept/domain it’s in. I haven’t used it myself, but having it spelled out was enough base knowledge for me to grab on to.
Looking again, I see your point. If you don’t know what it is having the acronym spelled out doesn’t help much at all.
Still it clears the low bar provided by those announcements that just say something like:
“BEOTZ’s developers are joining Flmp.io. As well all know BEOTZ is popular and Flmp.io is a top provider to enterprises. We look forward to exciting things coming soon.”
The nice things about such an obituary is that it isn't a person so we don't have to feel bad and we don't need to know what it was going to do.
> It immediately defines OPA (for people like me who don’t immediately recognize it)
Outer Planets Alliance. Bloody terrorists they are.
Isn't Styra like a company of like 50-100 people? Seems like it'd be a bummer to be an employee at the company that gets left behind.
A counter example would be Weaveworks(folks behind Flux/FluxCD and many other widely used oss tools). I'm sure the ex employees would've preferred to get acquihired vs closing up for good. I highly doubt Styra was pulling in enough money to fund their business, and the days of zirp are long gone, so I doubt they would've been able to raise another round to keep the lights on for another few years.
ControlPlane was able to hire (not acqui-) a few of the FluxCD maintainers and other WeaveWorks staff to continue supporting the project — we did what we could, agree this is better for Styra folk than the uncertainty of closing up shop.
The shop (Styra) did get closed. A few of the most senior maintainers were hired by Apple. Many - including anyone not directly involved in engineering of the OSS product - are now looking for jobs.
Capitalism is ruthless.
In most acquisitions, the buyer interviews employees and only takes part of them - or only offers bonuses to part of them.
Based on Apple's acquisition of FoundationDB, this seems like it will have negative consequences for public development of OPA.
What are the counterexamples, where Apple acquiring a project results in it being more open with sustained development?
Apple literally purchased FoundationDB as a closed source tool and open sourced it with open source development continuing to this day.
From this announcement, they are going to open source the enterprise version of this tool, which was also previously closed source.
Was FoundationDB a CNCF project at the time of acquisition, or in some similar incubator/umbrella? Besides, seems FoundationDB was open sourced after Apple acquired it, wouldn't mean FoundationDB get more open after the acquisition? Although development stalled no matter what so maybe doesn't matter.
FoundationDB development has not stalled; v8 is still on the way. If anything, it's mostly just been stable for a while now, and it has now been developed as open source longer than it existed as closed source.
Right, FoundationDB wasn't even open source when Apple acquired them. The FoundationDB story is a prime example of why it is important to use open source technologies for foundational infrastructure.
It was independent (I think it predates the CNCF actually), but was acquired by Apple in 2015 and disappeared until it was open sourced in 2018.
>Based on Apple's acquisition of FoundationDB,
FoundationDB wasn't even Open Source when Apple acquired them.
CUPS?
apple reopened foundationdb in 2018
Wrong. Apple opened it FOR THE FIRST TIME. It was closed source software prior to acquisition.
Excuse me? FDB was a closed source product, and Apple open sourced it under a permissive license and have since spent tens of millions of dollars on maintainers salaries and open sourced all kinds of adjacent software.
How did this idiotic, uninformed meme come about exactly?
Yup, reads like the typical announcement from the Apache Foundation era, where projects just go to wither.
This leaves me quite bummed out. After Oso[0] went from a superb open source policy evaluation solution to one that's completely closed, OPA is what I'm typically reaching for now, but now it'll likely be on life support.
[0]: https://www.osohq.com/
From the post, I'm pretty sure Apple didn't buy Styra. Sounds like Apple hired the maintainers who worked at Styra (including Tim, Teemu and Torin). I'm guessing that Styra is just shutting down.
Congrats to the team and Apple!
It's great to see authorization getting more attention in the mainstream developer conversation.
For folks exploring policy-based authorization solutions, we've written up a detailed comparison between Cerbos and OPA that might be helpful: https://www.cerbos.dev/blog/cerbos-vs-opa
The key differences tend to be around developer experience, policy language complexity, and deployment patterns. Both are solid open source options depending on your specific needs.
(Disclosure: I'm a cofounder of Cerbos)
Seems similar to Apple's 2015 acquisition of FoundationDB -- they sunset the commercial offering. But it's unclear if they acquired Styra or just hired the team?
I'm maintaining an article about this news (as well as commercial alternatives to OPA) on the Oso blog: https://www.osohq.com/post/opa-maintainers-join-apple-oss-co...
Disclaimer is that I work with Oso :-) but hope it will be helpful regardless.
This is a more defensible take than some on here, but still a wild comparison. FDB was closed source software that existing customers kept source access to the entire time it was closed, and then opened under a permissive license soon after. So yes, you couldn’t buy it, but if you had, you kept access to new development.
With Both Aserto and Styra gone - there aren't any commerical/enterprise options to get capabilities and support around OPA.
Has anyone seen more options?
Here are a few OPA alternatives: https://www.osohq.com/learn/open-policy-agent-authorization-...
Not OPA-based , but Kyverno-based. Kyverno is also CNCF, basically an overlap of OPA functionality (with some give and take.)
Nirmata provides commercial/enterprise options around Kyverno.
Permit.io
they don't actually "support" OPA. more like they run/depend on OPA
Gabriel from Permit.io here
Actually, Permit does support OPA. In fact, about 15% of our large customers came from StyraDAS and use Permit as their enterprise OPA solution.
On top of that, we offer OPAL+, which is already adopted by Fortune 100 companies as a production-grade OPA framework.
[dead]
Great job Styra team, great job Apple!
OPA is a great project and I am glad they are looking to open-source the Enterprise OPA offerings
This is an extremely smart acquisition by Apple, very nice to see.
Can you explain why
At scale, the larger companies end up needing to be able to make policy decisions (read: authn/authz, most of the time) across a large number of "policies" in an efficient way. Everybody starts with simple representations that can go fast but have limited expression, then moves to various forms of extensions/templating/substitution/rules/etc.
OPA and Rego use a datalog variant to bring order to that bespoke mess. Think IAM policy, but you DRY because it's a real programming language with a library full of nice-to-have built-ins.
OPA and Rego can basically "become" other types of access control systems (see https://www.openpolicyagent.org/docs/comparison-to-other-sys...).
Thanks.
I’m very familiar with opa.
My only assumption for this was that Apple’s infrastructure needs have evolved to the point where they need quite a focused effort around policy.
Styra either acquired or became available through a different form of change management. And Apple was already a major customer.
Just blind guesses. I was hoping for more insight.
Props to this team for giving it their all
1. Any idea on what should I start next so that I can get acquihired?
2. It looks like Apple didn't get much 'ownership' of OPA in this case, what was the point of purchasing the company as a whole versus simply offering these 3 employees generous sign-on bonuses?
3. Why is it that companies generally tend to pay a lot more per employee in an acquihire scenario?
3. (From zero authority here as I’ve never bought a company:)
Perhaps the acquired employees might prefer this for tax reasons. If they stand to profit mainly via capital gains, that is wildly better than receiving ordinary income, like a bonus, would be.
Or, a completely different, unverifiable possibility:
An acquisition does not set any precedent for compensation of any kind. As a general rule corporations hate paying humans, but don’t mind paying other corporations.
3. It's very hard to know what kind of compensation employees are actually getting in an acqui-hire. I've been involved in a few of these - money flows through the cap table, so investors and founders get most of it depending on liquidation preference. Retained employees get a typical, levelled offer + some cash/stock (probably more stock) incentive with the usual 1 year cliff and 3-4 year earn-out. Incentives are also usually contingent on specific business goals.
In other words, the scenarios I've seen if the acquired company is not doing well the acquirer pays off the investors and gives the employees a small bonus contingent on staying for 1+ years and hitting goals. It's not necessarily a crazy windfall.
1. probably something with AI in it. You got maybe 2-3 years before the bubble pops.
2. branding. cultural awareness can take years or more, and I'm sure coporate knows by now that their brands aren't the best thing to slap onto every scenario. Disney is well learned in this kind of conduct.
3. Because the last thing you want in an aquihire is for all the talent your poaching to jump ship. Some employees may have even worked there previously and used a company to get away from that corporate culture.
So a lot of an aquihire's money tends to go towards golden handcuffs.
Is it even clear it is an acquihire rather than the more boring “company hires maintainer of code it uses”?