Open Foundations With or Weis  ## Metadata - Author: [[The Business of Open Source]] - Full Title: Open Foundations With or Weis - Category: #podcasts - URL: https://share.snipd.com/episode/cf07fc72-86fd-4778-a412-01ebe7d74004 ## Document Notes ## Highlights - **Access Control Became A Core Problem** - Permit.io exists because rebuilding access control repeatedly at Rookout drove Or Weis to solve the problem generically. - Access control complexity grows with software and AI increases the need for fine-grained permissions. Transcript: Or Weis So I'm an engineer, started writing code at the age of five. My career actually took off serving in the military. I was an officer, developer versus engineer, team leader, yada, yada, yada. Afterwards, I worked in a startup called Intigua, where we built container technology before containers were a thing, but with a truly horrible go-to even worse than Docker's after They ruined their go-to And after that, well, there were great companies that came out of Integua, if not Integua itself, SoloIO, LogsIO, PermitIO. I then co-founded and ran a company called Reactful.com that was acquired by Metadata.io. I then was a VP of R&D, a cybersecurity company catering to governments and like-minded agencies worldwide. And between late 2016 and up till four or five years ago, I was the founder and CEO of a company called Rookout, which is a production debugging solution, another developer tool. And during my time working on Rookout, I ended up rebuilding the access control to our product five times when the company wasn't even three years old. Drove me insane, as people can often tell. And that's what led me to create my current company, Permit.io, which focuses on delivering access control as a service. More fine-grained permissions. And as software continues to grow in complexity, you constantly need more advanced permissioning. And this has become most apparent now with AI use where organizations trying to adopt this are trying to say, how can I give AI access to the things that I wanted to access so it can do the Work for me, but how can I also make sure it doesn't blow up in my face? So this is what we're solving with Permit.io and also with our new offering, Agent.Security. ([Time 0:00:25](https://share.snipd.com/snip/539ab027-a3c2-4d70-83f1-7765f3659577)) - **Opal Started From A Real Need** - Opal began as a necessity to scale policy engines across many instances for Permit.io's product. - It became the de facto control plane for loading policy and data into engines at scale. Transcript: Or Weis Of all, there are open source projects that we use and are a key part of our product that we contribute to, but we haven't created or maintained. Key examples there would be OPA, Open Policy Agent, and the feeder from AWS, both are policy engines. And there the main thought was, I don't want to reinvent the wheel. I don't want to create some open source just so I can say, oh, here's here's another one, but this one's for me. So here we align with open source projects, identifying what's the standards in the market. Ironically, nowadays, we've become the main commercial support for OPA as the company behind it, Styra, was acqui-hired sort of by Apple. And the other part, maybe the core part, is open source projects that we create. Key amongst those is OPAL, OPAL Open Policy Administration Layer. It's a key part of both the OPA ecosystem, Cedar ecosystem, also a bit of OpenFGA. And it has become the de facto way to manage policy engines at scale. If you have a policy engine, if you're running just a couple, it's not a big challenge. But if you have hundreds or thousands or tens of thousands, it's pretty hard to make sure that each one of them is loaded with the right policy and data. So that's what Opal solves. And for us, we started with it because that's just was the first problem that we needed to solve to build permit itself. I want to be able to provide a control plane for policy and for data for my customers. I want to work with these open source policy engines, but I need them to scale. ([Time 0:02:57](https://share.snipd.com/snip/fd487c97-8683-4b56-b2c9-4cf265b4119f)) - **Use Open Source To Win Developers** - Use open source when building developer tools because it aligns with how developers inspect and adapt software. - Offer an open fallback to reduce perceived vendor lock-in and increase adoption. Transcript: Or Weis Think there are two main reasons when you're doing a developer-oriented company. There are two main reasons from at least a commercial or go-to perspective, reasons to do open source. The first one, and maybe the most significant, is that open source aligns with the best practices of how developers want to work. It's easier for them to examine the software and see if it's a good fit for them. It's easier for them to maintain it from both a stability, security, scalability setup in terms of when they're deploying it into their infrastructure. And it's easier for them to aggregate the knowledge on how to use this when the offering itself is open source. And also to collaborate and contribute back to the project. A lot of times when you're giving tools to developers, it's really about the fine grain details. It's really about how this will work for their specific scenario. And a lot of times it requires a lot of customization and adaptations and a closed solution is a lot harder to adapt. So that's kind of the first reason. It's a more natural way to provide solutions for developers. Oh, another key aspect there is lock-in. Developers often don't like being locked in into a vendor. So having an open source fallback option is very significant. The other part is basically your distribution or market penetration strategy. Developers in the end of the day align very well with bottom-up strategies. ([Time 0:05:34](https://share.snipd.com/snip/c885913f-d986-4938-bf4a-e5bf23067f4f)) - **Open Foundation Versus Open Core** - Open core often fails because open source and commercial products share the same value proposition and competitors move faster now. - Open foundation separates the open project and product so they support different value propositions. Transcript: Or Weis I started with kind of a drastic approach and actually wrote extensively about it. I started with the belief that starting in the early 2020s, open core, which was the main strategy for open source, was basically dead in the water. To explain quickly, in open core, you create an open source project. It's standalone by itself. And then you either wrap it or add services on top of it to create the commercial offering. The problem with that approach is that the value proposition for both your open source and your commercial offering are basically the same. And since the market has sped up dramatically, both in the rate that companies adopt products and in the rate that companies do go to market on new offerings, the time that companies Had to go from creating the open source project to commercializing it, that window has basically diminished to zero. And we see this with a lot of examples, I think very prominent. We saw it with Docker that struggled. They created an amazing open source offering, but then weren't really able to commercialize it. And then they tried to kind of pull back and got a lot of clash. They were supposed to be the main daemon for running containers in Kubernetes. And they were kicked out because of their attempts to commercialize and create enterprise versions from their Docker product. They ended up recanting on that and going back into the fold, but they've lost a lot of the momentum that they had. Another very prominent example is with Elastic. Elastic basically created a whole observability and data aggregation stack that became super popular. But as they were building the open source and trying to commercialize it, other companies like LogsIO, CoreLogix, and AWS came in and commercialized it faster than Elastic. So they ended up basically speeding up their competition and getting a little, very little out of it. So then they tried to change the licensing. Long story short, they ended up losing the battle there, pivoting to a security company, and then in retrospect, shifting the licensing back into open source years later. So looking at all of that, I very quickly said, okay, OpenCore doesn't work anymore. If you succeed with it, the competitors are going to either outpace you or the companies using the open source will be able to run with it on their own and you will have nothing to commercialize. You'll basically be cannibalized by your own open source offering. So I wanted to strike a more balanced approach from day one. And I came up with this model, which I call open foundation. In open foundation, the open source offering is a foundation for the commercial offering, but they're not the same thing. They support one another, but they don't have the same value proposition. So for example, with Permit and Opal, so Opal is a way to load policy and data into policy engines, but it doesn't have the, and Permit uses it, but Permit adds a lot on top. It adds an opinion API to author policies. It adds a lot of interfaces, including our policy editor. It adds Terraform on top. It adds CICD pipelines, a whole thing. So it uses Opal, but it isn't Opal. ([Time 0:09:26](https://share.snipd.com/snip/6a374487-0a13-4aa2-b979-a4835f3f357a)) - **Draw Clear Boundaries Early** - Define a clear line between project and product before adding features to avoid constant debates and wasted time. - Let product managers and community contributors use that line to decide what belongs where. Transcript: Or Weis So for example, when you're coming in to add a new feature, your product mentor, not yourself, you know instinctively what's the right thing to do, but your product manager or someone In your community comes in to add a feature. How do they decide what goes in the open source and what goes in the commercial offering? Unless there's a very clear line, it's very hard to do. And then you're wasting a lot of time and energy figuring out the balance, constantly trying to re-figure out the balance. ([Time 0:14:18](https://share.snipd.com/snip/dd89d76a-0494-44c3-a1ce-faefd1ac93fe)) - **Open Source Fuels Discovery, Not Clear Attribution** - Attribution from open source to commercial sales is noisy but traceable through customer conversations and embedded questions. - Many customers start with open source tools and then discover the commercial product as a managed solution. Transcript: Or Weis So in developer marketing, what you're getting is, first of all, a lot of organic traffic, right? Because people are going through the open source. They're doing research and they're finding things on their own. There's a lot of word in mouth. So you're getting a lot of organic traffic and a lot of direct traffic. And as a result of that, it's terribly hard to know who's coming from where. That becomes even more hard to do when you realize that developers are the leading personas in using ad blockers and in minimizing data collected about them and leading kind of privacy. They swim in the waters. They know how the sausage gets made. And so they avoid getting into the sausage making process. So you're a lot of times flying blind. And so that makes attribution on your traffic and how people got to your commercial offering super, super hard. More than in probably any other subcategory. But still, the answer is hidden within the customer journey. And in the end of the day, you are able, or at least we are able, to talk to our customers and ask them, hey, how did you hear about the product? So we've made sure that we are baking that question as much as possible into the product, into scheduling meetings with us. When we meet people, we make a point of asking and we see that people tell us. And also it's about like our reasoning of how people go about tackling this problem and finding solutions for it. So for us, it's, oh, I've been tasked as a developer to build new access control or upgrade access control to a system. So I start by researching, what can I use to build this? So Google, and I go to chat GPT and other searching utilities. And then you find, and you usually start with the open source offerings. And then you start to learn about those. And then you're trying to see how can I best utilize this? And then you start running into the commercial offerings. And when we talk to customers, we often see, I'd say in more than 70% of cases, they start with the open source offerings. By the way, not necessarily our open source offering. They'll start, for example, with OPA, and then they'll discover Opal, and then researching Opal, they'll discover Permit, and then they'll say, and this is actually something pretty Unique, they won't go about implementing Opal and then go and adopt Permit. They'll see, oh, Opal is made by these guys from Permit, and they actually give me a more holistic solution. This doesn't happen all the time, but a certain percentage of customers. And then they get into the commercial offering. So it's very hard to tell, and it's very hard to keep tabs on this. But if you dig in, you can get the answer, and that's the answer that we see. ([Time 0:15:38](https://share.snipd.com/snip/008524ab-ee52-4eae-ab87-67f4686ddf42)) - **Enable Honest Self-Selection** - Let developers self-select by providing transparent docs and examples instead of pushing sales messaging. - Add information that helps users choose between the open project and the commercial product without forcing them. Transcript: Or Weis I actually don't try and put a lot of effort into that because it's, well, there's a lot of challenges working with developers, but there's also a lot of advantages. And one of the key advantages is that developers will do a lot of their research and heavy lifting on their own, and they'll self-select. So the worst thing you can do, especially if you're doing an enterprise offering, the worst thing you can do is get your pipeline filled with the wrong customers. Customers that will end up saying, oh, actually, I can just go with the open source. So you want to do that selection early on in the process. So you don't want to force people into a path that isn't suitable for them. So we want to give people as much information as possible. We want to give people as much options as possible, but we're not trying to shove it down their throats. And I think both this creates the right kind of culture that developers expect, and it also creates for us a more efficient pipeline. That being said, we do try to include more information in the docs. So like when you're looking at Opal, we'll give you some examples that you can see with Permit. When we embedded an AI agent, this thing is the most that we did that it kind of maybe crosses that line. So there's an AI agent that helps you answer questions as part of the docs. And it will give you answers from both Permit and Opal. And you can choose what's the right fit for you. But in general, we try not to force that. ([Time 0:19:17](https://share.snipd.com/snip/26b9cde5-6584-4391-b7a6-b2b3a6bf892f)) - **Open Source Gravity Creates Trade-Offs** - Giving more in open source increases gravity and adoption but reduces commercial differentiation and potential monetization. - Balancing openness and commercial value is a risk-reward decision with existential stakes. Transcript: Or Weis Obviously, the more you give in your open source, the more your open source has value, the more gravity it has. The more you're offering people, the more excited they'll be about it. The more flexible it is, the more it can attract different use cases. And so when you're deciding to do something that is more contained, by definition, it has less gravity. So if I would have gone and made all of Pyramid open source, I'm very confident as an open source project, it would have grown a lot faster. It would have garnered more GitHub stars, more forks, more contributions, more customers, all in all. But it will also come with a cost of probably the commercial. I'll probably never know what is the exactly right balance, but I think it's a given that you need a balance. Like I think today the option of not having a clear line, having the being stuck into a situation where everything is in the open source and you can't commercialize your product. And I think that's essentially what happened to companies like Steyr. They had an amazing market access, that amazing community, that amazing growth, but they weren't able to capitalize on it in the way that they wanted. So it, to some degree, can be a death sentence, a death verdict for a company. So while, like, it's like a lot of things in life, it's a risk-reward kind of situation, and you need to choose what's the right balance for you. ([Time 0:25:40](https://share.snipd.com/snip/fc86e244-c2b5-40e6-808d-b5065b2dabf5)) - **Build Core Moats, Not Surface Features** - Avoid relying on shallow moats like SSO or a prettier UI because competitors can replicate them quickly. - Build differentiation that lives in the core product rather than superficial add-ons. Transcript: Or Weis Like if you go back to 2010 or 2005, it worked. But I think it's actually super easy to see with recent innovation how that line has basically disappeared. So adding SSO, yeah, that's a little bit of friction, but how long does it take a competitor to take your open source offering and throw SSO on top? But take them a week. If they build SSO from scratch, it will take them a month. There's no mode here. And very apparent now, you're talking about adding a nice UI on top. Now with AI-driven development, like vibe coding, like you go into lovable, how long will it take you to add a beautiful UI on top of an open source project? A day? A week? You have no, again, no moat, nothing that significant differentiates between your open source offering and your commercial offering. So you literally have no leg to stand on. So I think as you go back in time, those moats grow and they had more depth and they lasted for longer and they had more also services that were required around that. ([Time 0:28:25](https://share.snipd.com/snip/c2c0150f-3d8a-447f-9f8c-077e1ace77bb)) - **AI Will Rewire Open Source And Interfaces** - AI will shift software interfaces toward agent-to-agent protocols and make open source projects increasingly AI-first. - Much open source may be authored or assembled by AI, creating new feedback loops between projects and agents. Transcript: Or Weis Nowadays, vibe coding or AI- coding is all the rage. Like when I'm writing code, I'm not writing code. I'm talking to an agent who's writing code for me. And everyone's kind of realizing that this is coming for everything. So like we have vibe coding, you're going to have vibe shopping and vibe investing and vibe real estate and vibe vacations and vibe legal and vibe accounting and vibe every possible Little thing and this means that the main identities the main actors in software are no longer human we humans are we still have a very important role but we're moving up the chain most Of the conversations even think about conferences, like AIs coming together and talking to one another to kind of come into agreement on doing something together. That's the future that is around the corner. And in a future like that, all the interfaces and all the way that we build software no longer aligns with how humans work with software. It aligns primarily with how agents work with software, with protocols like MCP and A2A. And so that means, I think, two main things. One, that when we're building open source, and open source will remain a key component of how we get the ecosystem to integrate and how we set up these motions into the market. So as we build this, these open source projects would be by themselves more aligned with AI. So when you're thinking about open source projects, these will be AI first as well. And B, it probably means that the main authors of open source projects are also going to be AI. And this will also probably create this feedback loop where more and more open source is AI built by AI and for AI. ([Time 0:31:47](https://share.snipd.com/snip/d791de18-1a77-4d39-8ef8-734122e54c5a)) - **Play A Longer Game For AI-Driven Demand** - Think longer term about how AI will multiply demand for permissioning and design product strategy accordingly. - Plan for larger future value rather than only today's market size when building foundational security products. Transcript: Or Weis Question. Emily O'Meara I think I would have said, think longer term. Or Weis Like now we're seeing, like the value that our product has is minuscule compared to the value that it has now in this emerging AI world. Like permissioning and APIs and software was super important. But now it's become even more important. Like the market value is doubled in size and like all of a sudden. And I had this at the back of my head from like the get-go i always thought oh this when ai comes this would be a very big thing but one i didn't realize how quickly it's going to happen and B i didn't fully comprehend how big it's going to be so i think if i like in the chess game that's kind of emerging here, if I thought a little further, I think I would have played a slightly Different game, a longer game than I initially thought I was playing. ([Time 0:34:34](https://share.snipd.com/snip/f37074e3-1727-4b24-a972-92436955c3af))