(some of those features are enterprise only)
The self-hosted space is another headache. I wasted so much time trying to make smaller self-hosted auth solutions work, since Keycloak has a reputation for being heavyweight.
I looked into the Ory stack extensively trying to actually use it as advertised for self-hosted / open-source auth. It's aggressively gimped and its SSO features are emphatically _not_ open-source and are gated behind licensing, with no way to find out until you're actually running it.
It's also just unfinished. Their "stack" is a lot of cobbled-together Go mixed with incompletely rebranded acquisitions like SAML Jackson (now "Polis"), which they managed to gut so completely it went from a best-in-class OSS library to unusable.
Open source development needs to be paid by someone - most of the time people complaining about paying for software are working themselves (for money!) in some company making huge bucks, or looking up to "successful (as in money) tech leaders".
For Ory, B2B login is a good value differentiator, because it's required by companies selling to other companies meaning they can spend some money on licenses to further develop software.
Ory powers the largest technology providers, and super small solo projects. It's robust, stable, Apache2 licensed. It's the best CIAM tech out there that's free (!!).
In the end, everyone is entitled to their opinion but the "open source can't make money" train is honestly a bottom tier opinion and I'm tired of reading it on HN, probably written by people making $100K+ a year for writing software and using open source daily (without paying a dime).
It's like the people complaining that Wikipedia is collecting too many donations, while they cheer on Apple or Anthropic or whoever raking in billions of dollars.
Somehow, only if it's open source / non profit it's bad to make money. If it's proprietary nobody gives a damn. Says a lot about society.
There is software that is cutting edge and always changing, and those types of products need to be paid for much more than software that is stable.
With a stable product like Auth (which requires only security fixes and minor features), the 'pay per MAU' model employed across Auth companies is unreasonable
A combination of the people and companies using the product for free or selling its support (like RedHat and IBM for KeyCloak) along with an open license allowing it to be offered as a cloud service should be sufficient?
If you want to pay per monthly active user for the rest of your life, up to you.
Vercel have raised multiple rounds, last one was in 2025 and $300m. So we don't know what the VC's are going to demand for revenue targets. https://en.wikipedia.org/wiki/Vercel
I can’t speak for Vercel‘s goals or pricing - but Ory is evidently still open source while many others went other routes!
even the items i mentioned only change every 5 years or so, in my experience. i accept that there will be a lot of work preventing attackers from gaining unauthorized access, but again this feels partially solved by just rejigging the authn flow (rather than username -> password -> totp (leads to password sprays), just do username -> totp -> password)
It also really shows its age, imo. The interface is clunky, roles and groups having overlapping responsibilities is confusing, making custom UIs for it makes me feel ancient, etc.
I really can't complain though. There is simply no alternative that's as open atm. It's also not easy to make one ( I tried :( ).
It's Apache 2.0 and a CNCF incubating project.
Just before I hurl myself at this for several days/weeks -- where were the pain points? I'm usually wary of new projects in this space but OpenFGA looks pretty mature already
(1) The need to write relationships and keep them updated in the permissions database. Often, this requires writing to both the application database and the permissions database, at the same time. On the SpiceDB side, we provide a Postgres FDW [1] to make this easy IF your application data lives in Postgres
(2) Representing complex permissions in ReBAC schema can be a challenge (at first) if you're coming from an ABAC system - you need a slightly different mental model for ReBAC, where (as its name implies), permissions are reachable via the relationships between objects, rather than attributes on objects.
(3) ACL-aware searching: this is a very hard problem in authz in general and gets slightly harder with ReBAC. The separation of the search index and the permissions database makes it harder to integrate and computing permissions, at scale, is incredibly complex. For SpiceDB, we have Materialize to help solve this problem [2].
[1] https://github.com/authzed/spicedb/tree/e9d636d2b58dd9e92c44...
[2] https://authzed.com/docs/authzed/concepts/authzed-materializ...
Disclaimer: I'm CTO and cofounder of AuthZed and we build SpiceDB (https://spicedb.io), the most scalable OSS implementation of Zanzibar