Yes. This is happening. Stay tuned.
197 karma · joined February 15, 2018
*Old problem, new $25B+ market*
Companies like AWS, Stripe, and Twilio have shown that if a technology isn't core to your value proposition, you should offload it. Still, every engineering team builds and rebuilds one piece: authorization, how you control who has access to what in your app. We intend to change that.
We see a world where developers never roll their own authorization again, and instead say, "Just use Oso" – the same way you might say, "Oh, you should just use Postgres for that." In doing so, we're creating the $25B+ authorization market.
*Why Oso?*
We have the lead – in traction, capital, and team.
- Traction: Oso is used by thousands of companies from startups to the Fortune 500, like Wayfair, Arc, Intercom, Visa, Oxide, and Codecademy.
- Capital: We're the best-capitalized, with 4+ years of runway from the world’s best investors, including Sequoia, Felicis, and infrastructure entrepreneurs like Olivier Pomel (Founder, Datadog), Dev Ittycheria (CEO, MongoDB), Arman Dadgar (Founder, Hashicorp), Edith Harbaugh (Founder, LaunchDarkly), Guy Podjarny (Founder, Snyk), Paul Copplestone, (Founder, Supabase), Christina Cacioppo (Founder, Vanta), and Calvin French-Owen (Founder, Segment).
- Team: We've spent 3+ years going deep on the domain. We've met with thousands of engineering teams and know more about this problem than anyone. And we have two of the best developer go-to-market leaders on earth who have done it before at MongoDB at Snyk.
*Why now?*
We're at an inflection point. What it takes to get from where we are today to a world where developers say “Just use Oso” is going to be different. And we see that. The opportunity is for you to join at this inflection point, in a role that’s bigger and different than usual.
To apply, please visit: https://jobs.ashbyhq.com/Oso/1778e946-7138-4ab7-8ad2-8d664d1...
For more info, visit: https://www.osohq.com/company/jobs
*Old problem, new $25B+ market*
Companies like AWS, Stripe, and Twilio have shown that if a technology isn't core to your value proposition, you should offload it. Still, every engineering team builds and rebuilds one piece: authorization, how you control who has access to what in your app. We intend to change that.
We see a world where developers never roll their own authorization again, and instead say, "Just use Oso" – the same way you might say, "Oh, you should just use Postgres for that." In doing so, we're creating the $25B+ authorization market.
*Why Oso?*
We have the lead – in traction, capital, and team.
- Traction: Oso is used by thousands of companies from startups to the Fortune 500, like Wayfair, Arc, Intercom, Visa, Oxide, and Codecademy.
- Capital: We're the best-capitalized, with 4+ years of runway from the world’s best investors, including Sequoia, Felicis, and infrastructure entrepreneurs like Olivier Pomel (Founder, Datadog), Dev Ittycheria (CEO, MongoDB), Arman Dadgar (Founder, Hashicorp), Edith Harbaugh (Founder, LaunchDarkly), Guy Podjarny (Founder, Snyk), Paul Copplestone, (Founder, Supabase), Christina Cacioppo (Founder, Vanta), and Calvin French-Owen (Founder, Segment).
- Team: We've spent 3+ years going deep on the domain. We've met with thousands of engineering teams and know more about this problem than anyone. And we have two of the best developer go-to-market leaders on earth who have done it before at MongoDB at Snyk.
*Why now?*
We're at an inflection point. What it takes to get from where we are today to a world where developers say “Just use Oso” is going to be different. And we see that. The opportunity is for you to join at this inflection point, in a role that’s bigger and different than usual.
To apply, please visit: https://jobs.ashbyhq.com/Oso/043fb953-d2b9-4bbe-8640-497272c...
For more info, visit: https://www.osohq.com/company/jobs
*Old problem, new $25B+ market*
Companies like AWS, Stripe, and Twilio have shown that if a technology isn't core to your value proposition, you should offload it. Still, every engineering team builds and rebuilds one piece: authorization, how you control who has access to what in your app. We intend to change that.
We see a world where developers never roll their own authorization again, and instead say, "Just use Oso" – the same way you might say, "Oh, you should just use Postgres for that." In doing so, we're creating the $25B+ authorization market.
*Why Oso?*
We have the lead – in traction, capital, and team.
- Traction: Oso is used by thousands of companies from startups to the Fortune 500, like Wayfair, Arc, Intercom, Visa, Oxide, and Codecademy.
- Capital: We're the best-capitalized, with 4+ years of runway from the world’s best investors, including Sequoia, Felicis, and infrastructure entrepreneurs like Olivier Pomel (Founder, Datadog), Dev Ittycheria (CEO, MongoDB), Arman Dadgar (Founder, Hashicorp), Edith Harbaugh (Founder, LaunchDarkly), Guy Podjarny (Founder, Snyk), Paul Copplestone, (Founder, Supabase), Christina Cacioppo (Founder, Vanta), and Calvin French-Owen (Founder, Segment).
- Team: We've spent 3+ years going deep on the domain. We've met with thousands of engineering teams and know more about this problem than anyone. And we have two of the best developer go-to-market leaders on earth who have done it before at MongoDB at Snyk.
*Why now?*
We're at an inflection point. What it takes to get from where we are today to a world where developers say “Just use Oso” is going to be different. And we see that. The opportunity is for you to join at this inflection point, in a role that’s bigger and different than usual.
To apply, please visit: https://jobs.ashbyhq.com/Oso/043fb953-d2b9-4bbe-8640-497272c...
For more info, visit: https://www.osohq.com/company/jobs
This resonates. Negative permissions can be a real footgun, which is why we are being very surgical on if/where to introduce them at Oso[1]
Companies like AWS, Stripe, and Twilio have demonstrated that if a technology is not core to your value proposition, you should offload it. Still, every engineering team builds and rebuilds one piece: *authorization*, how you control who has access to what in your app. You’ve probably started with something quick 'n dirty – some IF statements and roles in a database...until you need to add more features, and more features. And inevitably you band-aid onto this system until you have to do a big refactor. Have you seen this before?
We're changing this picture and in doing so, we are creating the next $25B+ dollar market: the authorization market. We’re on a mission to create the global standard for authorization. Our vision is that in 10 years engineers will spend 1/10 the time and brainpower they spend on authorization today.
This is a once-in-a-career opportunity to join a company at a stage late enough that the problem and solution are de-risked, but early enough that you can shape the product, company, and the market.
We are based in NYC and hiring folks onsite/hybrid.
To apply, please visit: https://jobs.ashbyhq.com/Oso/043fb953-d2b9-4bbe-8640-497272c...
For more info, visit: https://www.osohq.com/company/jobs
If so, how did you evaluate them relative to each other and/or building yourselves?
There are a lot more differences in the requirements for these use cases though, e.g., feature flags products want for more analytics, controlled rollout, etc.; authorization, not so much. Authorization requires access to lots of shared application data/state; feature flags, not so much.
Another area of overlap I see is entitlements/billing, e.g., can this person access this feature based on the plan they've signed up for? I've seen a lot of companies use the same underlying systems for feature flags, authorization, and entitlements (esp at earlier-stage companies and ones with a heavy DIY bent). Is this consistent with what others see/do?
i don't mind the turn signal buttons but the driving experience is not ideal for quick reactions, and the horn...has got to go
Eg Authorization is one such use case. Polar is a logic programming language (like Prolog) specifically designed for authorization: https://www.osohq.com/docs/reference/polar-syntax
1) Better abstractions for disentangling authorization
2) Better technical literature on the subject [1][2]
3) Increasing comfort with third-party infra services (RDS, LaunchDarkly, etc.)
Note: I'm cofounder of an authorization-as-a-service company (Oso) [3]
[1] https://www.osohq.com/academy
FWIW I totally see the benefit of having standards and widely adopted open source solutions, Jimmy. But neither of the solutions you called out has been out for more than ~1 year, so I can also see why Omri and the Topaz team decided to go their own route. Your two companies also compete directly with each other, so I can’t really blame them.
Neither of those solutions was around when we released the first version of Oso in 2020, so we too went our own route and have learned a lot along the way. We’ve since shared a lot of what we’ve learned in Authorization Academy [0], a series of technical guides on building application authorization that are not specific to Oso. We also recently wrote about our view of what an authorization system should look like — opinionated but flexible — in a post on what authorization can learn from Rails [1].
Will be instructive to see what feedback the dev community shares in the years to come.
Disclaimer: I'm founder of Oso[2], a batteries-included system for authorization.
[0] https://www.osohq.com/academy
[1] https://www.osohq.com/post/learn-authorization-from-rails
It's good to see more activity in this domain. One thing I've noticed over the last several years has been: beyond the fact that we haven't had good options for authorization tools, the world doesn't have enough mental models and good language for describing the authorization _problem_. It's mostly RBAC and ABAC. That is...limited!
As more people work on this problem, I hope we'll continue to build out the collective knowledgebase in addition to having tools that supercharge us. To get the ball rolling, we've written a number of articles, e.g.,
- What is Google Zanzibar (https://www.osohq.com/learn/google-zanzibar)
- Authorization Academy, a series of technical guides on building authorization into an application (https://www.osohq.com/academy)
- Why Authorization is Hard (https://www.osohq.com/post/why-authorization-is-hard)
- Best Practices for Authorization Microservices (https://www.osohq.com/post/microservices-authorization-patte...)
- Authorization Patterns in GraphQL (https://www.osohq.com/post/graphql-authorization)
Onward :)
Avoid, be bland, lie? There is no integrity here.
The upside of being honest is 1) preserving your integrity, and 2) most people who leave share their reasons for leaving with someone ultimately, which usually gets back to the team they left. If you share a different story and your old team finds out later, it's just going to create a worse impression.
How about: find a clear but respectful way of articulating why you are leaving. And if the complaints are longstanding, you don't need to go on and on about them, you can just reference past conversations and be done with it.