Torin Sandall: When people come along to the project and they try it out and it does what they want, they're happy, right. When they continue to use it and they get to some interesting kind of edge case. And they're far along the scale in terms of adoption and they have some problem and they come to you and you actually can help them. Then that goes a really, really long way. Eric Anderson: This is Contributor a podcast telling the stories behind the best open source projects and the communities that make them I'm Eric Anderson. I'm joined today by Torin Sandall, who's the co-creator of Open Policy Agent. Torin, thanks for coming on the show. Torin Sandall: Thanks Eric. Glad to be here. Eric Anderson: So, for the uninitiated, Open Policy Agent, maybe you could tell us just briefly what it is for those who aren't as familiar. Torin Sandall: For sure. Yeah. So Open Policy Agent or OPA some people call it or OPA as we like to call it is a general purpose policy engine. So what that means is that you can use OPA to offload policy decision-making from your software. And so when we say that it's general purpose, we really mean that. It is a very kind of general purpose domain agnostic piece of software or a piece of technology. So it's not tied to any project or product or domain specific data model. It allows you to express policies basically against any service at any layer in any system. And so those policies can be related to a number of different parts of your system. A lot of the time when people look at OPA they're looking at it in the context of authorization, or essentially controlling who can do what in applications, or microservices or container platforms or CI/CD systems, and so on. Eric Anderson: Got it with that out of the way, Torin, I want to hear how this came about, and I imagine some of the story of OPA is some of the story behind you and what you've been working on lately. Where's the right place to start? Torin Sandall: Well, I guess we can start back in 2015 and we can go backwards or forwards, I guess. In 2015, some folks got together and they started Styra. And so that's the company that I work for. I'm the VP of open-source there I drive our kind of our open source efforts. And so Styra was founded with the kind of vision or the goal of rethinking policy and authorization for modern cloud or cloud native environments as they're called now. In 2015, if you went and you talked to large enterprises like financial services companies or insurance companies or healthcare companies what they would tell you is that they have hundreds of different systems that they manage, right? They run one of every programming language, run up one of every database, they run workloads on all kinds of different platforms. They have different CI/CD systems or API gateways. Torin Sandall: And the problem is that every single one of those pieces of software, those products, those open source projects, they all had their own way of letting their administrators specify who can do what, right, of writing down the rules, the control, the system. That is basically fragmentation, right? It's very difficult for an administrator to control who has access to what in the system, or just even understand who has access to what in the system. And so Styra was founded out of a belief that that could be improved, that that should change. And so part of that strategy was the creation of the Open Policy Agent project. So I came on board shortly after the company was founded to start building policy agent, along with Tim Hendricks, who's the CTO and co-creator of OPA. And so we got to work creating the projects. That's sort of where it started. It started out out of exactly that basically conversations with folks at large financial services companies and whatnot that wanted a better way of managing policy at scale. Eric Anderson: This wasn't a pain point personally, of yours as it was things that you were hearing about as you talk to these operators in large companies, is that fair? Torin Sandall: Yeah, so, I started my career in the networking domain. So I worked for a bunch of different telco networking vendors. And I spent most of my career kind of as a dark matter developer, I was like not building open-source. I was building proprietary networking systems to do things like packet analysis and routing and forwarding and all that kind of stuff. And the Telco Space Policy is a major part of those systems. Torin Sandall: So I spent a long time, I sort of ended up working my way up the stack all the way from kind of a little level of kind of firmer bits up to management systems and kind of seeing what was sort of needed to operate large networks at scale, I spent a lot of time working on more kind of general purpose orchestration systems, systems that deploy like virtual network functions and stuff like that. And after working on that for a little while, I became interested in this problem of policy management. And through that work, I ended up connecting with Tim Hendricks through OpenStack actually at the time. So, Tim had been working on a policy project in the context of OpenStack. And so that's how I kind of got connected. Eric Anderson: And often on this show, we have people who start open source projects, and then they find their way, those open source projects find their way into a company. It sounds like you had the vision of bringing this product to market, or at least somebody did. And then the idea to start the open source is that fair to say? Torin Sandall: The open source project was started because if you look at the policy management space, there were existing attempts to solve these kinds of problems sort of holistically, and generally. They were made a while ago, but they weren't well suited to more kind of modern cloud native environments. So, they typically relied on areas like centralized solutions that don't port well to kind of like modern heterogeneous dynamic environments. They weren't developed necessarily with developers kind of in mind, right? If you look at modern organizations, developers are driving a lot of the decisions about what technologies adopt these days. They might not necessarily have all the buying power today, but they certainly have a lot of influence into what technologies get adopted and what technologies get purchased. And there weren't really a lot of alternatives at the time that were developer centric policy management solutions. Torin Sandall: So, it was a clear need in the space. Early on in the project, one of the ways that we would find interesting integrations to look at and to kind of experiment with was to just go and search for like the word policy, and issue trackers for popular open source projects. If you were to search for policy in the Kubernetes issue tracker back in like 2015 you'd find all these issues about people, like users, describing policies that they wanted to implement, but which they couldn't, because there was no kind of like generic policy enforcement mechanism in Kubernetes at the time. And it was the same for other projects in this space. So, there was a clear need for having a more flexible way of describing like rules, basically, they need to be enforced in the system without having to go in and make actual, let's say code changes to the system. Eric Anderson: And so you say this all began in 2015, I noticed on your website, you refer to this as kind of a cloud native affiliated thing. And cloud native I feel like wasn't all that popular a term then how did you find that kind of niche and association, or was that just a natural place to put this to work? Torin Sandall: Yeah, if you look at cloud native and you look at what OPA provides, like what OPA provides or what it enables is like a distributed model for policy enforcement, right? So, you can basically take OPA and you can drop it in, ideally, as close to the software that has [inaudible 00:07:37] links possible on the same machine, or in Kubernetes in the same pot. What we wanted to do with OPA was enable this distributed enforcement model. And that meant that OPA had to be designed, and implemented to be very lightweight and kind of easy to embed and easy to integrate. And so some of the design decisions that went into OPA very, very early on, just made it a very natural fit for kind of like the cloud native ecosystem. And so, yeah, when we started the project we didn't immediately target microservices or microservices running on Kubernetes or Kubernetes itself. Torin Sandall: We looked at a whole bunch of different projects across the ecosystem, and we did all kinds of experiments with other orchestrators, like Mesos, Marathon, Docker Swarm and so on. And we ended up focusing on Kubernetes partially because it was clearly gaining traction at the time, but also because it was clearly designed to be extensible from the beginning. And so it made it very easy to plug in something like OPA whether you're talking about talking in the policy engine, like at the control plane level to do things like admission control and put guard rails in place over the workload configurations, or whether you're talking about application level authorization, where you want to have OPA running next to the actual instance container, right. It just made that very easy. And so it was clearly like, OPA was a good fit for that problem, Kubernetes had the right kind of mix of extension capabilities built into it from the start. So it was just very natural. Eric Anderson: Yeah. So Torin, tell us about the early days of the project then. It's mostly you going to work on this new framework that you would intend eventually to be open-source. Is that right? Torin Sandall: Pretty much, yeah. It was myself and Tim and we spent a lot of time early on focusing on like the design of the declarative language that you would use to write rules in the projects. We spent maybe like six months or nine months, just on the core, like R&D for the projects that was building out the language and the runtime needed for that language. And we were looking for these examples basically from different systems that we could test out, right? So once we had that core language and run-time implemented, we went and we took it and we started trying to apply it to all kinds of different projects out there. I think one of the first kind of integrations that we looked at a few months after we started the project was the Kubernetes Scheduler, right? Torin Sandall: So the piece of software in servicing Kubernetes, that's responsible for deciding what nodes or instances your workloads are going to run on. We took the Kubernetes Scheduler, we looked at the go code for it, and we basically ported most of the logic that was hard coded inside the scheduler into this declarative language. And we were like, "Okay, this is cool." The language is clearly expressive enough to deal with real world use cases. It turned out that that wasn't necessarily a great fit. There wasn't a ton of demand for that at the time, but it was definitely an interesting exercise and stress testing language and stress testing the runtime. And from there, we started looking around more in the Kubernetes space and we saw that admission control in Kubernetes was this problem that a lot of people that were kind of on day two of their Kubernetes journey were encountering, right? Torin Sandall: They were running into issues around security, but also cost management and ensuring stability, and ensuring adherence to best practices. So there are all kinds of problems related to admission control that we thought could be solved by OPA. But then at the same time, we also started looking at different applications or different use cases at the application layer. So we were playing around with different projects that power like a service oriented architecture, right. So, early on, we were experimenting with like Linkerd, but I know you guys did a podcast with Williams. Torin Sandall: We did integration with Linkerd and Spring, and a whole bunch of different kind of service frameworks to show how you could use OPA at the application layer. And so we spent quite a bit of time early on just kind of demonstrating that you can use OPA to solve a variety of different problems. And over time, people started to notice that and they started to try it out. And so it took a little while it took at least a year and a half or so for people to start picking it up and running with it. But once they did it started to take off and people started to talk about it at conferences and then kind of one thing led to another. And the project's popularity really started to take off. Eric Anderson: We have some people on the show who start from Uber or Google, and they have a massive use case that they have to support initially. And then they kind of work to generalize it over time and find other users. And in your case, which is kind of the other half of the people we have on the show, they have this vision of something. And then they have to find people to which they can support. In the early days with limited capability and more of the time who were these first users that you're able to solve a need for, and then expand from? Torin Sandall: Yeah, no I definitely, I see what you're saying. I think a lot of the time you see projects emerging from a lot of these like web-scale companies, right. And they gain traction really quickly because they've been battle-tested in these web-scale basically environments, right? So they have like a starter pack of adopters. And that's really valuable, I think in the open source space, because developers are heavily influenced by like the stories, and the case studies and the use cases that they see at conferences or in blogs or on hacker news or wherever. And so that was like one of the main things that we had to overcome, creating the technology to start up, was like, "How do we convince people that this is worth taking a look at?" And so that's why it took a little bit of time, but like once we had that initial set of users, it started to really accelerate. Torin Sandall: One of the first big users was Netflix. One of the security engineering teams or the security engineering team at Netflix, they came across OPA and we'd already been kind of like blogging about it and talking about it when they came across it. And what they were looking for at the time was a way of expressing authorization rules over essentially a very complex, diverse set of services. So, Netflix is well known for leading the way in terms of microservice architectures, right? So they run thousands of microservices on thousands of instances. And it's a very heterogeneous environment, right? They have services written in all kinds of different languages. They have services that speak all kinds of different protocols. It's not just like HTTP everywhere, right? They've got like custom binary protocols and stuff that they have to deal with. They've got these services running in all kinds of different execution environments, right? Torin Sandall: It's like some are on instances, other on containers and so on. You've got different identity systems in the mix, right? The way you identify a contractor is different than the way you identify a batch job that's calling your service. Right? So they had this many, many, many problem and in all these different dimensions and what they wanted was like a single way to express rules that control access to API end points for [inaudible 00:14:16] services in that environment. And that's one of the things that OPA is really good at it because it's not tied to like HTTP or Kubernetes or any kind of project or domain specific data model. It lends itself very naturally to that problem. So they took it and they integrated it into their platform. And we ended up doing a joint talk at one of the Kubecon events, and that was tremendously valuable from the project's perspective, because it was something that people found and thought, "Oh, yeah, I have the same problem internally." Torin Sandall: You've got all these organizations today that are all making this migration to microservices, right? And they all see the same set of problems essentially. And they're all motivated by needs, right? Everybody's trying to move to microservices because it allows them to move faster at the business level. It allows independent teams to kind of operate in parallel, but that doesn't mean that they don't have to deal with all of the regulations and policies from the past, right? They still have to support those things. And so the question is how do they do that in these more modern environments? And OPA is like one tool or building blocks that helps solve that problem. Eric Anderson: I can't think of a better kind of a launch scenario, if you want to call it that, then the Netflix using your service and letting you talk about it with them at Kubecon. This has to be kind of the Cinderella moment for the project, I imagine. What was the state of the project at that point, you were kind of ready to go, ready to take on new users and well-market it, or was this kind of still raw, I guess? Torin Sandall: The project itself, in terms of the code and the infrastructure and so on was pretty solid at that point, at least for the core, like minimum viable product, the core use case that it was solving, it was pretty stable. And we'd spent a lot of time like optimizing the engine and making sure that it would meet strict performance requirements and so on. So we were comfortable from that point of view. One of the things that I learned from like past gigs was that documentation is important, right? So, we spent a lot of... I mean, just in the beginning of the project, we followed like a documentation driven approach to development. So before we'd go off and implement, even actually before we implemented anything, we wrote up this page, that's basically still there in the documentation, like the policy language page, and that described like all of the language features and so on. Torin Sandall: And we did that before we wrote any code. So, we made sure from kind of from the outset that the project was like well-documented and kind of easy to integrate and clean and so on. And so we were comfortable from that point of view. We'd spent time in the lead up doing blogging about just generally explaining how the project works and how it could be applied to different couple of different use cases. And we'd also spend a little bit of time talking at some conferences and talking about different use cases. So, we had an initial, base of material that was out there that we were confident in and we just needed other people to start talking about it. And so that was sort of the starting point. And so that was sort of at the end of 2017, I guess, that that happened. And then the following year, like 2018, we just started to see talk after talk about the project. They were just popping up organically. So, it was very satisfying to see that that kind of like organic process kickoff over the next 12 months or so. Eric Anderson: And how is the team or kind of contributor base changing? Up until now it's been, I think you and Tim mostly. Are there kind of core people at Netflix helping out is the team at Styra expanding? Torin Sandall: Yeah the team at Styra is expanding. I think that there's, generally, when you're talking about open source and you're thinking about... When people think about communities around open source projects, they kind of imagine like a huge pool of developers out there on the internet that are like interested in contributing to your project. And they think it's like this ideal environment where everybody is contributing equal amounts of code and stuff like that. Eric Anderson: There's free labor and code's just pouring in or something. Torin Sandall: Yeah. Yeah. It just shows up for free, right? And then all contributions are of equal weight, right? But in most open source projects, that's not really the case. There's almost like a power law usually in effect, when you look at the contribution weights, right. In a lot of open projects, it depends on the type of the project, right? Some projects are very like integration or plugin intensive, right. So the core project in order to do anything needs to be modified in order to provide some value, right? OPA is not really that way. It's essentially like a declarative language and a runtime and some management API APIs for operationalizing the runtime. And so there's not like... It doesn't require a ton of ongoing work. So it's almost a good thing that the project itself, like the contributions to the very core of the project, you wouldn't want that to kind of be continually changing. Torin Sandall: On the other hand, what we see is the integrations community. And the integration ecosystem is really where things are growing quite a bit today. So we see new integrations pop up all the time, basically, like every week, there's a new integration. You have a page on the website, it's an ecosystem page where people can come and kind of link to their integrations, because that's been successful. And then with a few integrations, they've been very successful. And so we've had kind of collaboration between a bunch of different companies on those things. So, for example, I was talked a bunch about Kubernetes at the beginning, and that was one of the early use cases that took off. And in 2018, we got together with folks from Microsoft and Google and started to jointly collaborate on what's now called OPA Gatekeeper. Torin Sandall: So, OPA Gatekeeper, and people have heard of it. It's like a integration between OPA and Kubernetes that lets you manage admission control policy in a Kubernetes native way. And so that's a joint project with a bunch of people working on it actively, very actively. And you see a lot of contributions there. We recently onboarded comp test, which is a popular tool for running OPA policies like locally on your development machine, as well as like inside CI/CD pipelines. So we recently onboarded that and there's a bunch of folks that work on that. So the project is kind of like a federation of a bunch of different sub projects that all kind of come together to provide this unified policy enforcement model or policy enforcement solution. And we're always looking for new integrations. OPA loves new integrations because it is so flexible. And the APIs that it provides are pretty simple for somebody to integrate, right? So if there's anything we ask for, it's like, please bring your ideas around integrations to the project because somebody will pick it up or even you could pick it up if you're... Eric Anderson: I mean, this idea of like creatively thinking of new integrations also applies to just use cases for OPA. I mean, we've talked a lot about Kubernetes and cloud native, but it sounds like this thing is a fairly general purpose, and could be used in all kinds of places. What surprised you is people pick this up and try out new things? Torin Sandall: That's a good question. I think the most surprising one of the funniest one I saw was from a fellow named Kevin Hoffman, who talks a lot about different technologies, but he had already been using OPA for API authorization. And then he realized, Oh, I could use the... He's an RPG fan. So he ended up writing a blog post about how you could like write a little RPG, like role-playing game engine in [inaudible 00:20:58] and so he, he had all these great examples of like what happens when the monster gets hit by a certain type of sword or something like that. So, I think that was one of the funnier ones, but there is just like a long tail of use cases that we see people leveraging it for. Torin Sandall: I was chatting with someone the other day about how they're going to be using it for enforcing access control over system calls that processes can make at the host level. I was talking to someone the other day about how they use it to, they basically built a VPN gateway using it. So they write policies that basically describe like what users can connect into the gateway. And then they have a little program that gets the result of the policy and then pushes down like IP table rules effectively. So there's no shortage of new use cases popping up all the time. And we're always looking for ones that are getting traction and that are solving valuable problems. Eric Anderson: And how much awareness visibility do you feel like you have in all the use cases? I mean, part of the blessing and curse is that you don't really know where OPA is being used in all cases. Torin Sandall: Yeah. It's tough. People can take it and they can do whatever they want with it, right? That's sort of open-source and I think we do rely on people to kind of like disclose the fact that they're using it right. That's, from my perspective, I almost view it as like a little bit of a sales funnel, right. It's like, if people come in at the top, they look at the website, they poke around and maybe they go away or maybe they continue, right? And they continue using it. We can kind of tell like the people are using it. We can see how many downloads it's getting and we can see how many instances are running. Torin Sandall: It can report back to a central place so that we know how many instances of a particular version of running. So we get these like anonymized metrics basically, that tell us people are using it. But at the end of the day, what I love to see are people like disclosing their usage of it either by adding themselves to the adopters file or writing a blog post or talking at a conference, that's the most kind of satisfying outcome for me is just to see it being used in the wild, like at scale, by real people and seeing it solve real problems. Eric Anderson: And I suppose there's some kind of implicit culture of goodwill there where people often do. I mean, if they get excited about a project they're inclined to add themselves or report their kind of use case on the website or talk about you at a conference. Torin Sandall: It does take goodwill. It takes a certain personality as well, right? You need to be interested in kind of communicating the work you've done to an audience or to audiences that may not immediately understand I. So you need to be able to take something that you've done in a very specific domain and then communicate it in such a way that people can understand it and be satisfied by doing that. So, it's not like every software developer, not every technologist, not every platform engineer has that, and it can be tough. And the other aspect of it is that a lot of the time employers don't always make that super easy. So we have lots of folks that come to us that say, "Oh, hey, like I'm using this at Acme Corp, but I can't talk about it right now because of Acme Corp's legal department [crosstalk 00:00:23:50]" Eric Anderson: Right. Torin Sandall: So that's been tricky, but I think over time, we've noticed that a lot of companies have been kind of like opening up in terms of talking about their tech stacks and so on. And so that's been good, but it's definitely been a challenge for sure. Eric Anderson: And how do you structure yourselves, I guess, as a company or as a project in order to promote that and help people through that? I know it's increasingly popular to have developer advocates or developer relations, people who collaborate with adopters to generate content and that sort of thing, is that what you've seen as valuable and worthwhile and successful? Torin Sandall: I think at the end of the day, I mean, it comes down to building up a bit of a relationship with your users, right? So, you need to engage with them and you need to build trust with your users. When people come along to the project and they try it out and it does what they want, they're happy, right? When they continue to use it and they get to some interesting kind of edge case and they're they're far along there along the scale in terms of adoption and they have some problem and they come to you and you actually can help them. Then that goes a really, really long way. So helping build up trust with users, by supporting them when they need it is a really good way of doing that. Torin Sandall: So we try to be pretty welcoming when it comes to like new users, as well as existing users when they have questions. And so you'll see a lot of people on like the OPA Slack, for example, asking questions and I'll often drop in there and try to answer as much as I can and help people along because it goes a long way. And that's something that we focused on a lot at the beginning of the project was just being very attentive to what people were asking for as well as just answering questions that they might have. Torin Sandall: It's like, if I'm a developer and my job is to integrate this tool into my stack, I'll spend up to a certain amount of time on that, right? So, the important thing to get in front of them and help them solve their problems before they go passed that horizon where they just drop it and move on to something else. So, making sure that we have like good documentation and good support channels and just generally like good ways of helping people is super important. That's one way we've found that helps people feel, I think, they're willing to kind of contribute back in some way, if you help them out a little bit. So, and often one of the best ways that people can contribute back is just by talking about their use cases and kind of publishing like case studies or reference architectures for the technology. And that goes with [inaudible 00:26:09] first project, I think. Eric Anderson: Yeah. And I assume there's this virtuous cycle of you're unblocking people at the same time you're documenting the problems and issues and feature requests. And that goes into the kind of the next version of the project. And it evolves on its own towards improvement. Torin Sandall: Yeah. I think that there really is something there about just being kind of like unreasonably aggressive when it comes to support, like a lot of projects can be confrontational or they can be, they're not responsive, and I think that, maybe that works in some cases, but I think most people need a little bit of help to get off the ground, and then, but then once they get off the ground, they're up and running and they're off. So, it's just a matter of getting people over that initial kind of hurdle, essentially, whether you do that for documentation, or you do that through conference talks, or you do it through Slack interaction or whatever, it's really important. Eric Anderson: So, take us to the project today and where you see the project going forward, from my perspective, it seems like OPA has been very successful. It's kind of the standard, or kind of emerging standard, and, as you pointed out, wasn't maybe a widely recognized need. Do you feel the same or do you feel like there's still a lot more you need to do in order to kind of make OPA into what it could be and what does the future look like for the project? Torin Sandall: I mean, I think early on like one of the problems that we had to overcome was getting people to think about policy as a first-class citizen in the system. A lot of the time, if you were talking to an application developer or a platform engineer, and you asked them to draw a diagram on a whiteboard for their system, they would have a little box in there and it said policy engine on it. So we kind of had to do a lot of work to seed that. And I think we see that a lot more now. It's becoming a first class citizen in a lot of systems and a lot of people's minds when they're designing their systems. So, that, I think, is going really well. Because if you look at the project today, it solves a bunch of use cases quite well, I think. Torin Sandall: I think it, this is sort of the core set of use cases around like API authorization and config validation. So what you see for people using it for microservices and what you see people using it for in like spaces like Kubernetes and Terraform and so on, it solves those problems quite well. And there's always ways we can improve it. We can always optimize it. We can always provide better tooling and so on, but it solves those problems well, and so we're always looking for new use cases where it can be applied. One of the areas that I'm interested in is just applications of OPA around data filtering. So, like access to sensitive data. That's something I've been working on for a little while and talking to folks about. But yeah, so I generally think that like going forward, we're just going to see it integrated into more and more parts of the stack and it will be supported out of the box by more and more vendors. We see a lot of vendors in the space right now, picking it up and integrating it. Torin Sandall: And it is sort of becoming that de facto standard, I guess you'd say for expressing these kinds of like rules. So, that's sort of state of it right now. One of the things that we've been working on for a little while is support for taking OPA policies and compiling them into WebAssembly. And I think that that's going to unlock a lot of interesting applications because it'll allow OPA policies to execute inside environments that they couldn't before, because they would need to have the overrun time deployed. So I'm particularly interested in use cases around WebAssembly like, I think that it's emerging as like a standard execution environment for extensions and inside of different systems. You see it in envoys, databases, you see it on content delivery networks. And so we've got basic support for that, but I think the next stage is to go and basically do what I described before is like build out the case studies and the use cases for that, and really show it off to people because I think there's just a ton of different applications there. Eric Anderson: This may seem specific, but clarify for me, the relationship with service mesh, I think service mesh has maybe ambiguous ambitions at times to do all the things on behalf of people related to their clusters in terms of security monitoring. And maybe some of that would include policy. And I imagine one way you can do this as with OPA you can use OPA alongside your service mesh. Is there any tension with service mesh vendors themselves where they might have their own kind of approaches to policy? Torin Sandall: Yeah, service mesh's, they're actually nice from our perspective because they give us a kind of a clean insertion point into the request path, right? So, if you look at Envoy for example, right, it has an extension mechanism that allows you to enforce authorization policy. And there's also an extension mechanism that allows you to drop WebAssembly in there. So from my perspective, like it makes our lives easier because we don't have to do a bunch of heavy lifting in order to get OPA inserted into the request path for service to service communication inside of the system. But service to service communication is only kind of like one part of the problem space that OPA operates in, right? It doesn't deal with access to data, doesn't deal with application level authorization use cases really. Torin Sandall: It's not really meant for that. It certainly doesn't deal with any of the desired state security or config validation use cases that you see like gatekeeper and OPA widely adopted for in the Kubernetes space. So, I think service mesh solves like a set of problems that people have around connecting services and having them talk to each other and having them be observed and secured. But I don't get the sense from talking to users that like the inbuilt policy mechanisms are necessarily always enough, or that they're going to be enough or that they want to have, like, I think one of the value propositions that OPA brings is that it provides you with a consistent way of expressing policy across not just your services service traffic, but also at the application level or at the platform level or at the data level. So, that's kind of how I see it at least. Eric Anderson: Very good. And then Torin, we learned a lot today, those interested in OPA how can they get involved? Where are your kind of needs and interests for the project? Torin Sandall: Yeah, for sure. So if you're, if you're interested in just learning about OPA I highly recommend checking out the new OPA Academy that we launched at Styra. So, that's an online course that that folks can take. If they're interested in learning about OPA and the language, it was one of the most like heavily... We run user surveys for the project every year or so. And that was one of the most heavily requested things that people had for the project. So we launched that at Styra about a month ago and we've had lots of sign-ups. So check that out for sure. And if you're interested in kind of getting involved with the project itself and contributing to it, feel free to check out the issue tracker. We tag issues to indicate when they're a good match for somebody coming into the project for the first time. Torin Sandall: So look for those issues. And like I said before OPA loves new integrations. So if you have a system where you'd like to see OPA integrated feel free to bring it up on Slack or file a [inaudible 00:33:00] issue, or if you've built something and you want to just have it shown to the community, like feel free to reach out. We're always looking for ways that we can help out with that, whether it's by posting it under the OPA org or putting it in the contract repo or writing a blog post about it, or whatever the case may be. We're always happy to showcase new integrations between OPA, and other systems. So, that's how I would recommend people get involved with a project to start. Eric Anderson: Awesome. Sounds like, Torin, you've been at this, you're five years into this and we all appreciate the work you're putting into here. I imagine it's a labor of love to a degree, but certainly well received, which has got to be exciting. Torin Sandall: Yeah. There's nothing better than hearing folks say that they took this thing, and they ran it, and it just worked, and then they can move on to other things, right? That's one of the goals for the project was to help people avoid that heavy lifting that they otherwise they shouldn't be doing. So it's been really satisfying to see it solve a bunch of use cases for people across all kinds of different verticals and all parts of their stack. For sure. Eric Anderson: Thanks for coming on the show. Torin Sandall: My pleasure. Thanks Eric. Bye, bye. [inaudible 00:34:06] Eric Anderson: You can find today's show notes and past episodes at contributor.fyi. Until next time I'm Eric Anderson and this has been Contributor.