Graham Neray:
The vision has been to put security in the hands of developers. This is who we are as a company, it's the guiding principle behind all of our decision-making. And if you were to take anyone at the company, wake them up in the middle of the night, shake them and ask them what is this company about? I can pretty much guarantee that, that's what they would say.

Eric Anderson:
This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I am Eric Anderson.

Eric Anderson:
Everybody, we are welcoming today, Graham Neray, to the show today. He is one of the creators or maybe the creative we'll find out of oso. And I'm pretty excited about oso, what's neat for us, we often do projects that have been around for years and have a lot of history to tell. Here this is recent memory. So maybe the best place to start would be, just tell us what oso is for context and then we can dive into how it came to be.

Graham Neray:
Yeah, absolutely. So oso helps developers add authorization to their applications. So if you imagine you're a developer and you want to add payments to your e-commerce website, you can use something like Stripe, or if you want to add SMS to your application, you can use something like Trulioo. And if you want to add authorization to your application, like deciding who's allowed to do what once they log in, you can use oso. And the way that we do that is by giving developers an open source policy engine that comes with a library and a language that they can use to express all kinds of rules around, who's allowed to do what.

Eric Anderson:
Got it. And now we know what it is. Maybe you can tell us how you got into this situation. Have you been searching for a solution for apps for a long time?

Graham Neray:
Yes and No. I think most founders, a lot of this stuff happened organically. My background is I worked at a company called MongoDB for many years. And towards the end of my time there, I met someone named Sam Scott, who's now my co-founder. Sam is a brilliant engineering cryptographer, he'd finished a PhD in cryptography recently. At the time, this is now almost two and a half years ago. We got together for coffee. I was thinking about ways to make infrastructure software easier for developers and Sam was thinking about ways to make security more accessible for developers. And we just clicked, we met for coffee outside Bryan Park in July 2018, and never looked back.

Graham Neray:
And so we started talking to a bunch of security and engineering teams about the problems that they were facing primarily related actually at the time to infrastructure authentication and authorization. And I would say after many meetings and many revisions, what we found was a lot of teams saying, infrastructure, that's interesting, but I just spent 12 months building an RBAC system. RBAC which stands for role-based access control. We were like, what? What are you talking about? That seems such a solved problem. People were like, well, it's a solved problem, but it's also one that everyone is solving in a bespoke way over and over and over again.

Graham Neray:
And so we started asking people about that problem, at the application layer. And more and more and more, we find that you end up with these very common paths. Small companies start out with a very simple model, you've got a basic user and an admin. It's not really that complicated, and then you start to add a few more roles and then maybe you want to add, a concept of organizations and teams and you reflect all this in terms of if statements in your code, and you just keep adding more and more things until over time, you need to do some refactor. And we found tons and tons of companies who reached this tipping point where they need to do a big refactor, six, 12, 18 months, a full team of engineers. And so we were like, I think we can take everything that we've been doing and put it towards this problem instead. And so that's how this whole thing,

Eric Anderson:
And I don't want to do too much alternative comparison, but maybe just to clarify things for me, when you first said, Stripe for payments and other things for auth. I initially imagined Auth0, are you similar or different? Am I bucketing these things the wrong way?

Graham Neray:
No, it's definitely like we play in very similar spaces. And I think for most people who don't spend all their time thinking about the problems auth is auth is auth, but there's an important distinction, which is Auth0 primarily deals in authentication, which is effectively getting you to log in. So log in screen, social integrations, multifactor authentication, password reset, stuff like that. What we do is authorization, which is deeply embedded in the application, think in an application like Salesforce, they're extremely complicated rules that go well beyond rules that dictate who's allowed to do what inside of Salesforce. In the simplest case, it's about maybe where you sit in the hierarchy. The head of sales can see the whole forecast, but the individual rep can only see their forecast, and expressing a bunch of different use cases like that. So all of that is different from the stuff that Auth0 does.

Eric Anderson:
Yeah. So Auth0, if you use, it might tell you who you are, this is Eric at the app. And then it throws that over the fence and says, now here's Eric do what you want with him. And also could pick that up and tell you what Eric can do in what context and what situations, that sort of thing.

Graham Neray:
Yeah, absolutely. And I think traditionally Auth0 has basically in their documentation said, this is a problem that's deeply embedded in the application, so this is best suited for you to manage inside your application. Just recently, they've teased in this rogue Twitter account that they have, that they're working on something related to authorization, which is really not that surprising at all, because this is a hard problem that we see a lot of people thinking about. And so we view this as incredibly good validation that lots of people, I think increasingly now are going to start to spend more and more time looking at this problem space because it's so important and so many companies are trying to solve it. Except at this point now we feel like we have a pretty good head start working on it.

Eric Anderson:
Okay. So you've got this idea, great idea. And a co-founder sounds like a great co-founder, you then go to work. And at what point are you decide this is an open source project, as well as a company?

Graham Neray:
From pretty early on, we were more or less convinced that we wanted it to be an open source product. There's two reasons for that. We experimented with a few different ways of making this available to the developer from a consumption model standpoint. And after not that long settled on a library as the best way for a developer to use this. And the main reason for that is that authorization logic is so tightly coupled with the application. So specifically, I'll give you an example of what I mean by that. Imagine that you're building Google Docs. So you might write a rule inside of Google Docs that says, the person who owns a file can view that file or can edit that file or can delete that file. So that's a pretty simple rule, but all the data about who owns what file is stored as part of the application.

Graham Neray:
And so in this way, all the authorization logic is very tightly wound up in the application logic and data. And so we very quickly determined that the library was the right way to go because it makes it easiest for us to facilitate having access to that data. So from there, you basically have two reasons why it makes sense to make this available as an open source product. So number one, for developers, there's not really a strong history and recent memory of closed source libraries, particularly closed source libraries that are effectively for a language, which is what we are. And so I think a lot of developers would have a really hard time thinking about embedding something that, that's so tightly coupled with their application, if it's closed source.

Graham Neray:
And I totally understand that because it's just so tightly wound up in what they're doing, it just feels too risky. So that's number one. And then number two, because developers are a target market, we're in the friction removal business. And so we want to make it as easy as possible for them to get started, and we felt that open source was the right path for that. So those were the two main reasons we went that route.

Eric Anderson:
Makes sense. I guess another question might be, at what point do you go open source? I imagine you could try this out with a few friends, but at some point you decide to make a public GitHub repo and advertise it. Was it clear when to do that? And how did you go about it?

Graham Neray:
Definitely not at all. And I think that team fought us, me in particular on it for a while. I use the term fight a little bit in jest, we were working on it for a good period of time over six months before we open sourced it. I don't know whether people think that's too long or too short. We had already had a bunch of people kicking the tires on it, but I think the team felt they wanted more time and they wanted more eyes on it and more people to beat it up. And my outlook was, we're not saying the product is GA and the best way for more people to get more eyes on it. This is one of the reasons why I think developers can get more trust in open source software is because you can get more eyes on it.

Graham Neray:
So if this is the approach that we've taken, we might as well make the most of it. And so I was a fan of getting it out there sooner. Of course, sure enough, it ended up going, I think even better than we'd hoped. And it's not like there were no major surprises. It wasn't like we found something and we were shocked and, Oh my God, what was in there? Something like that. It actually turned out pretty well. I don't think the decision is obvious. There's no real way. I think for us, the main factors that we were thinking about were, did we feel like we were circling around a core set of features that we thought would be useful to someone based on the people that we'd been speaking with thus far?

Graham Neray:
And did we feel like we could expose those in a way to people that we wouldn't necessarily be able to meet one-on-one? Did we feel like we could document them effectively in a way that someone could try them out on their own without speaking with us? And once we felt we were getting to that point, it was like a month in that. That was in maybe June, end of May or June of this year. And we developed a plan to open source it inside of a month and a half. Maybe it was like, I don't know, five or six weeks. And we just went about doing it and a big part of the plan after that was just to go and write a lot of docs.

Eric Anderson:
Yeah. You want to get it out as soon as possible, but not until it's self service. You'd hate to publish something that no one really can consume without you doing a lot of handholding.

Graham Neray:
Yeah. And I don't think it needs to be perfect. I think people understand something that's early on in its life cycle, the type of person that wants to look at that is the type of person that's going to look a little bit more closely, but you got to give them something to go on and you got to explain to them, when do you use this and how should I think about using it and stuff like that. We made a big push on docs in particular.

Eric Anderson:
No, I hear the documentation is quite a hurdle. I think with a previous episode, we talked about documentation driven development, where as you're writing your docs, you're realizing, Oh, actually there's a gap here we need to address.

Graham Neray:
Oh, absolutely. We've done that before. We try to think about... It's almost like the developer version of what some folks have done at Amazon, where you might think about writing their press release before you launched the thing. Taking that down to a technical level and thinking about writing the docs before you build the thing. And we've certainly gone down the path of writing the docs for a way that you would achieve something with the current version of the product before building the feature that would enable you to do it in the next iteration. I don't know if that makes any sense, but that is something that we're doing.

Eric Anderson:
That almost brings us to the present day is that right? The launch was months ago.

Graham Neray:
We did an open source launch, not a huge splash of any kind basically, we emailed the folks that we'd been in touch with, who put something on Show HN. We did that at the end of July of this year, 2020.

Eric Anderson:
I imagine you have some idea, but don't really know what will come of a launch. Any surprises?

Graham Neray:
No massive surprises. I think we were all holding our breath like, Oh my goodness, what if there's something that we've overlooked or something like that. And there wasn't anything like that. I'll say one thing that was just as amazing and I would say beautiful change for me personally and for the team. We had spent the first seven months of the year, in a cave figuratively in a number of senses. Okay. So we're not developing out in the open, the website says almost nothing on it. We're meeting with people on a one-off basis, anyone that we're talking to, we can basically trace how they found out about us back to someone that I specifically reached out to or something like that. And on top of all that, we're all relatively isolated as a result of coronavirus.

Graham Neray:
And then all of a sudden there are people who are joining our Slack, tweeting about us, like random things that happened. We got dropped into some Japanese equivalent of Hacker News and we started getting 20% of our traffic starts coming from Japan. We get dropped into a Python newsletter where I was planning to submit a blog post that we'd written. And it turns out that someone had done it two weeks prior, this is a few weeks after we'd launched. A couple of things after that, where it just felt like there was a real sense of gratification, which felt good for me. I think it felt really good for the team who had been working incredibly hard and really poured its heart into the product. That like, wow, there's people outside of this group, that's interested in what we're doing. They were trying it and using it. They want to figure it out. And that, I guess we've just been so focused on launching it that we hadn't even thought about what it would feel like to do it.

Eric Anderson:
Yeah. Wild to be discovering after the launch, wait, that's right. Everyone knows about this now.

Graham Neray:
Yeah.

Eric Anderson:
Our ideas are out in the open.

Graham Neray:
Even still we have people who drop into the Slack and we're like, because of the way... Like I said, we're in the friction removal business, we don't ask people for their emails to download anything. When people follow us on Twitter or join our Slack or anything like that, we don't always know where they come from or anything like that. And so it's wild to find out, Oh, you're using oso. Like, how did you find out about us and what are you using it for? And tell us about your use case and your situation and stuff like that. It's always a lot of fun

Eric Anderson:
Going back to the product a little bit. I'm imagining two broad arenas for authorization and one being, I'm building product and I want to specify within the application who can do what. And then another might be, I have a company with a bunch of internal tools and databases, and I want to choose what employees can do what. Is that a bifurcation that's worth thinking about? And do you play in one more than the other?

Graham Neray:
It's definitely like a relevant bifurcation. I think for one reason or another, we've definitely had more traction in the former category of companies who are building externally focused applications. There's not a ton of great reasons, honestly why you would necessarily care. The authorization logic might necessarily look different between an externally focused application and an internal one. It is coming sometimes that those internal applications are tied up in, depending on the company and a legacy system based on something like LDAP or Active Directory or something like that. So that could be one reason, but a lot of the same patterns end up applying. People try to implement things like rules, they implement things like hierarchies and various other authorization patterns.

Eric Anderson:
And part of the benefit of oso is that you give them these primitives, you mentioned role-based at the beginning, you've talked about hierarchies and they're other ways of thinking about authorization is that right? And you give them these building blocks out of the box.

Graham Neray:
Yeah, absolutely. I think another good example that represents a variety of different types of these patterns is the GitHub authorization model. We actually wrote a whole blog post about this because when we were first building the very, very, very early versions of oso at the beginning of the year, we basically picked, what do we think is a sufficiently complex use case where if we could make that simple, we would feel like we were building something that could be generic enough and useful to a broad enough group of people? And so we said, let's build for GitHub. So in the case of GitHub, there are orgs and there are teams and there are repositories. There's a lot of very complex ways that you can think about how a given user might have access to a given piece of code.

Graham Neray:
So examples that we've talked about already are roles, and that's a very common thing that people reach for in the beginning. But the reality is roles is a crude way of construing authorization that only gets you so far. Hierarchies is a very common one. So we talked about, you might be say, not even in the context of GitHub, but something that might be more accessible in Salesforce or an HR application, you might have a VP can see all the data and then a manager can see that team's data and then the individual contributor can only see their individual data. You might have inheritance, which should be some super role can have all these permissions and then some subset of those roles can inherit those permissions, but maybe have offshoots of those roles.

Graham Neray:
You might want to represent graph relationships, which might map more closely to how you think about the data model in your application. And so there are all these different patterns is the word that I keep coming back to because they're just things that just keep coming up over and over and over again in the users that we talked to and the things that they're trying to do in their applications. And so what we have right now is a really nice way for them to express those things using oso. And we're continuing to build out more and more building blocks so that all of that just gets faster and faster and faster for them to do right out of the box.

Eric Anderson:
Awesome. And has the vision shifted over time? I imagine you have this idea at the beginning, we're going to do X and then you talk to people and then you go launch to open source and other people start talking. How does that affect your plans?

Graham Neray:
For us, the vision and the thing on which my co-founder and I have always been a hundred percent aligned, has been to put security in the hands of developers. This is who we are as a company, it's the guiding principle behind all of our decision-making. And if you were to take anyone at the company, wake them up in the middle of the night, shake them and ask them like, what is this company about? I can pretty much guarantee that, that's what they would say. And it starts with authorization, which is just this problem that has been completely overlooked for a long time. But I think there's really like a... The thing that we've built around authorization, which is at its core, this policy engine and this language you could imagine actually using for a bunch of other use cases. The reality is authorization as a problem is such a big space that I think we'll easily spend a long time working on that alone.

Graham Neray:
But just to give you an example, so that the language that we built, which is called Polar, we had an internal hackathon about a month ago and a couple of developers on the team built a text-based adventure game with it. And we wrote a post about it on our blog. So there's actually quite a bit of things that you can do with it. Other people have expressed interest in doing a lot of other things with this language. You can imagine that would extend beyond authorization. And so I think while there's a temptation to go outside of the core focus, which has authorization, and I think we might get there in the future. We're focused on solving authorization for our users now.

Eric Anderson:
So you mentioned language, but you also mentioned that you offer these things as libraries specific to a programming language.

Graham Neray:
Yeah. Basically the way that you would consume oso is you write policies in our language, which is called Polar. So the policies, they're like pretty human readable, they'll say things like allow and then it takes the format of an actor and action and a resource. So the actor could be like the user or the action could be read and the resource could be like a document. So allow a user to read a document, if they are the owner of that document. That's could be an example of rule. And so you'd write that policy in Polar and it gets stored in a file, but then we have language libraries to integrate that with your application. So we currently support five languages, Python, JavaScript, more specifically Node, Ruby, Java, and Rust. And so that's where the actual application language bit comes into play.

Eric Anderson:
Got it. And I would use those if you want to call them client libraries to access my Polar files and apply them in certain situations. Got it. Polar is like a domain specific language of sorts. It's not like a tour and complete full on programming language?

Graham Neray:
Actually. It's funny. I think because we're applying it to a specific use case, people often reach for the term domain specific language, but it's actually more of a general purpose programming language. It's based on something called Prolog, which is a logic programming language. Okay. So funnily enough, we're exploring different solutions to this problem. This is way at the beginning of the year. And over the weekend, one of our engineers guy named Alex, who you won't find on the internet because he's just not on the internet, but he's this brilliant engineer who has a PhD in among other things, programming language design, not even the thing for which we originally hired him, but he's just this incredibly brilliant guy. And so we're exploring these different ways to solve these problems around authorization. And he writes this little compiler over the weekend.

Graham Neray:
He's like, I wrote this little thing. I think it could be a nice way to solve this. What do y'all think? And so I get in on Monday morning and a bunch of the team is huddled around one of our engineers monitors being like, did you see this thing that Alex pushed on last night, Sunday night? No, I didn't see this. And so this is actually really where the origins of Polar itself started and Alex is really an expert in Prolog. And a lot of the thinking and design comes from his background and expertise in it. Basically beaten against a number of other members of the team who come from a more modern web development background. And so what we did is we took this traditional language Prolog, which is known to be impenetrable, very powerful, but not really that easy to use or get your head around and made it look and feel a lot more like something like Python or JavaScript. And so we're using it for authorization, but you actually could use it for a lot of other things.

Eric Anderson:
Man, Alex must be so excited. There are so many engineers out there who want to write a [inaudible 00:23:10] language and don't really have the right use case for it or whatever, but how awesome.

Graham Neray:
Yeah, it's funny, when we thought about building the team for the company in some respects, I think it was luck and in some respects, I think we were doing the right things, which is, we are not looking for people with specific sets of expertise in one thing or another, because I think startups change direction. That's the thing that happens. It certainly happened in our case over the last two and a half years. But we have Alex who has this incredibly relevant set of expertise. We have another engineer on the team named Steve who has done... As it turns out he's written a bunch of lexers and parsers and loves to work on programming languages. And he's one of the engineers who built that text-based adventure game and really if I can brag for [inaudible 00:23:56], all the engineers on the team have just made it.

Graham Neray:
I think because it's the thing that engineers can easily get excited about. Building a programming language have really just poured their heart into this. And I'd like to think that, that really shows in the end experience for our end users. Obviously we have a way to go, the project is very early compared to a lot of other open source projects out there. But I think they really care.

Eric Anderson:
Oh yeah. Well, and as a bit of an aside, part of the reason I do this podcast on open source projects and not startups, for example, because I spent a lot of time on startups is that I think the startup focus is all around the generally the purpose of the startup creating monetary value growth. Where I think with an open source project, just building something useful and beautiful in some cases is the end and means and purpose. And so certainly very exciting that you've got a perfect group to put together. Sounds like a great solution.

Graham Neray:
Yeah. We're excited. Like I said, still tons of work to do and we love getting feedback on it. We love having people who've come in and read them. A bunch of people asking us questions about different ways to do things in the Slack just before I was joining. And I was following along, we love having people who filed can have issues and ask us, when will you support this? Or can you try this that way or the other way or whatever? That's another really nice benefit of doing things in this way is I think it encourages a different engagement with the community, which I think is pretty gratifying for everyone on the team.

Eric Anderson:
Right. Right. Less transactional, like what are you offering me for? What value? It's more like, Hey, here's this thing we're working on together and everyone's chipping in.

Graham Neray:
Yeah. Absolutely.

Eric Anderson:
Great. Graham, thanks so much. Anything we missed that we should've covered today?

Graham Neray:
Yeah. Certainly if anyone wants to get involved by all means our docs are available at osohq.com. We have a Slack, we're on GitHub. We love to have folks contributing and filing issues as I mentioned. And of course we're hiring.

Eric Anderson:
Right. Yes. And you get to maybe design your own programming language. Actually Graham, I had a question written down that I forgot to get to if you have a second and back to the comparison game, I recently did a show with on Open Policy Agent. And I recognize that what you're doing is different. I think, but I don't know that I could put it in good words as well as probably you could. Is that a comparison that ever comes up?

Graham Neray:
Absolutely. So I have a lot of respect for what the folks at... I don't know if I'm going to pronounce it right. Styra or Styra, the folks behind the OPA project. I think there's a smart group of engineers over there and they seem to be doing some really good work. The main pieces of feedback that we've heard and the way that we view the primary differences between oso and OPA are as follows. So one, in terms of use cases, we see OPA primarily being used for Kubernetes authorization. That seems to be their like core use case. That definitely seems to be the main commercial focus for the company behind it. Whereas oso is primarily focused on application authorization. And so behind that, there's a couple of main reasons for the difference. I think one, oso is deployed as a library, which is a really developer friendly way to get started.

Graham Neray:
Whereas the most common way to deploy OPA my understanding is as a standalone service, like a sidecar. So that just creates a different getting starting experience. And then two, the way that data is handled, basically because of that. All those things that I was talking about earlier, the way that authorization decisions require access to application data, because oso is tightly integrated with the application it immediately has access to all of that application data. Whereas in the case of OPA it's on the developer to figure out how to get that data over to OPA. So I think it's just focus the use cases in different directions.

Eric Anderson:
Perfect. Yeah, no, I think when we talked about OPA bit back, it sounded like they started general purpose and they could have gone many directions and have really, as you mentioned, found a niche and a following within, like you said, Kubernetes cloud native authorization. Graham, again, thank you for doing this today. It was fun actually, when we connected on whether we should do this show to hear that we had a lot of mutual contacts and I expect we'll keep running into each other.

Graham Neray:
Absolutely. Yeah. Thanks so much for having me.

Eric Anderson:
You can find today's show notes and past episodes at contributor.fyi. Until next time I'm Eric Anderson and this is been Contributor.