Hey all! I'm Sam, CTO at oso.<p>Thanks to OP for posting this. A very pleasant surprise to wake up and find this here :)<p>I'll be around to answer any questions people have, but you can also find myself and the team in our community slack: <a href="https://join-slack.osohq.com/" rel="nofollow">https://join-slack.osohq.com/</a><p>All the docs are hosted here: <a href="https://docs.osohq.com/" rel="nofollow">https://docs.osohq.com/</a><p>And we have written up various articles on using oso and some of the internals on our blog: <a href="https://www.osohq.com/company/blog" rel="nofollow">https://www.osohq.com/company/blog</a>
The recent TalkPython podcast "oso authorizes Python" is great for understanding what oso does, how it goes about it, and how oso's role is different from identity providers.<p><a href="https://talkpython.fm/episodes/show/294/oso-authorizes-python" rel="nofollow">https://talkpython.fm/episodes/show/294/oso-authorizes-pytho...</a>
This is quite interesting, although I'm worried about the policies being tied to the underlying programming language. While this does allow for additional flexibility, it makes them hard to share in a polyglot shop.
I'd like to buy into Rust for authentication, but the compile times cost too much money and I wound up purging it.<p>This library needs a lot of work to speed up compile times before I can use it. Procedural macros are usually opt-in through cargo features because of their extreme hits to compile time (this includes stuff like serde), and if you're trying to monetize this I'd recommend having precompiled binaries available somewhere so I don't need to pull things from crates.io to compile it cold.<p>I timed it on a laptop that I know to have similar power to a CI runner. This is after `cargo build`:<p>real 5m16.508s<p>user 10m41.961s<p>sys 0m44.432s