Congratulations to the team.
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.
- 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
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.”
Outer Planets Alliance. Bloody terrorists they are.
What are the counterexamples, where Apple acquiring a project results in it being more open with sustained development?
From this announcement, they are going to open source the enterprise version of this tool, which was also previously closed source.
FoundationDB wasn't even Open Source when Apple acquired them.
How did this idiotic, uninformed meme come about exactly?
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.
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)
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.
Has anyone seen more options?
Nirmata provides commercial/enterprise options around Kyverno.
OPA is a great project and I am glad they are looking to open-source the Enterprise OPA offerings
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...).
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?
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.
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.
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.
