In this episode, we team with Madrona Partner, Anu Sharma who hosts her own podcast, Traction, as she talks to the founder of former Madrona portfolio company Heptio, Joe Beda. Joe is also more well known as one of the creators of Google Compute engine and Kubernetes. He and another Kubernetes creator Craig McLuckie formed Heptio – a company Madrona backed at day one – to help enterprises adopt Kubernetes. VMWare purchased the company and Joe is now ‘doing cloud native stuff’ at VMWare as his linked in reflects. Joe is a thought leader in so many ways and in this frank conversation with Anu, who brings her own extensive experience at AWS to the table, he talks about open source, open core, open extensibility and how startups should think about building companies around, attached to or based on open source software – and their communities. Turns out this has more to do with ordering a hamburger during these COVID times than you may imagine.
Transcript (this is machine driven transcription so expect some typos)
Anu Sharma: Joe, it’s great to have you on the show. Welcome
Joe Beda: I’m glad to join you.
Anu Sharma: Joe. Open source means different things to different people. What does it mean to you?
Joe Beda: You know, I think open source is fundamentally a positive sum game, and I think this is what’s so great about our industry in general is that it’s really one of the imaginations of how can we have folks come together and do something that wasn’t possible before? And I think open source is really fascinating in my point of view, because it gets a lot of folks that care about something that are coming from different directions, with different expectations and different needs.
They find common cause and create something that wouldn’t have otherwise been created. And so that idea of like I bring something, you bring something, somebody else brings something and we create something that’s greater than the sum of the parts. That really that positive sum game is really what open source is about for me.
Anu Sharma: So, you’re hinting more at the community aspect of open source rather than the open-source aspect of open source. It’s not the code being open source that makes that’s the material aspect here.
Joe Beda: Yeah, I think community is fundamentally what’s at the heart of open source in so many different ways and it really comes, and the more senior I become as an engineer the more I recognize that the hard problems aren’t technical. And so, a big part of this is that you end up with a set of folks that feel ownership over that project in certain ways.
And when somebody feels ownership and when it evokes an emotional response that actually creates, community that creates things that aren’t possible before, when you think about great branding, right? Nike, Apple, these like these top-level brands, they evoke an emotional response and the people that are actually buying those products, working with those companies, they feel a connection there.
They feel ownership over that brand. It becomes part of their identity. And I think open source is a way to do that, both to motivate people to come together to do great things. But I also think there’s opportunities to make sure that you can in a smart and respectful way, use that to your advantage as you’re looking to build a business.
Anu Sharma: One of the ways I think about open-source projects is it solves a problem. A user probably had the problem, approached it in a solution mindset and wrote up software that could solve the problem. And then there’s a different aspect of the productization off that solution which requires documentation, the usage aspect of it, the buying aspect of it, but also the consumption aspect of it. Uh, I don’t want to host it for example, and I just want it to be completely operated and managed by somebody else. And that’s, that’s a whole fully more productized version of it.
How do you think about the separation between open source and the commercial product that comes out of it?
Joe Beda: Well, I think that the words that you’re using there, and I think they’re so close that they sometimes confuse us is project and product. And. And I think oftentimes when folks get really enmeshed in this world, they start to confuse these things and they view the open-source project as the product in and of itself.
Now, I think this is exacerbated because we’re seeing open-source projects become more product like. For instance, um, Joyent started the node ecosystem. And the reality is that you can go and download node and you get documentation; you get an install experience. It feels very much like a product.
And I think that’s part modern open source where it, these lines are starting to blur, but at the end of the day, it’s still just a project, right? It’s not, a product in my mind is something that has a skew, and you pay money and, for goods and services, right?
Like that is a product. And a project really is, you know, there’s still an amount, a, you know, a certain amount of like, you’re on your own here, take it or leave it type of thing. Um, and so I think, you know, part of this is, is a product is the value that you’re adding on top of the projects that you can bring in and charge money for it.
And there’s different things that you can actually, and I think it’s worth talking about what are the size of the modes that you bring, as you start adding that value. And I think that the easiest thing to think about is, is, you know, some support and documentation and trusted builds and that type of thing.
And I think it’s very easy to say, well, we’ll take this open-source project. We’ll provide support. We’ll have a, you know, 24, seven on-call. If you hit problems, we’ll provide extended documentations, and we’ll all wrap it up in a bow for you. And I think that’s the traditional distribution model. And I think this comes from sort of the Linux distribution world where a Linux distribution, you know, I had a former Red Hat employee that, that worked for us call it, walking over broken glass as a service, right? Because the traditional open source is you take all the different projects that maybe some of them have versions, maybe some of them, you know, have, have bugs and they all are built in different ways. And you’re bringing all this stuff together, doing some cross integration tests and say like, here’s a set of things based on open source that we’ve brought together, can work together and we’re going to support it.
And so that’s the traditional sort of open-source support model. And there’s a lot of value to be added there. And, you know, but one of the problems there is that the crappier the open-source projects are in terms of user experience, the more value you’re bringing as we look at these more modern projects, right?
Like it’s very hard to build a distribution over something like node because the project is so darn good that the level of value there. And so, and in that world, what we see is we see companies like Sneak start to come up where now what they’re doing is they’re helping you to, hey, you’re just not using node, you’re using the node ecosystem. The node ecosystem is big and hairy. How can we actually provide a level of, you know, intelligence and thoughtfulness around making sure that as you bring that stuff together, you’re bringing it together in a responsible way. So, they’re starting to fill in some of those gaps around security and compatibility and, and sort of hygiene that you often would use to buy through, the Linux distros. Next level of, of value is that there’s features that you can get when you, when you buy the product, and those features aren’t available when you’re talking about the project and right.
And I think that’s where we get into sort of like, you know, what we were calling previously the difference between open core, where only one company can deliver those enterprise features. Whereas I think open extensibility, there’s a level playing field for multiple folks, open-source projects or, commercial companies adding those value-added features.
And then finally, I think, the last level is the hosting experience around this open source. Where especially when we’re moving into the cloud world, distributed systems, software is not, you know, a static thing, right. I think, you know, old open sources like lib PNG, I can decode PNGs without having to write my own decoder.
Right. Modern open source is Cassandra or Kubernetes or what have you. These things take a certain level of complexity, a certain level of skill and, you know, and dedication. They’re living, breathing things that somebody needs to be on the hook for. I think anybody who’s ever administered a database knows this, right?
Like, like you don’t just launch, you know, launch a database and be like, okay, it’s good. Done step away. Right? No, you need a DBA. You need somebody doing backups and testing those backups. That’s real value that’s being layered on top of this. And so that’s another place that you can create a product out of the project.
And so, I think we’re seeing different companies look across these different ways of monetizing and really constructing both the open source to allow for this stuff, but also, you know, playing around with the different models for how they can start adding value and turn product from project.
Anu Sharma: And going back to the time when you’ve been, you founded and built Heptio, could you wind back a little bit to how your experience has been in building a business around open source?
Joe Beda: So, a little bit of my history here is that I’ve been in industry for 25 years or something now. And while I was at Google, I started Google compute engine and then started Kubernetes. I left Google and then co-founder Craig McLuckie and I started Heptio as a way to take Kubernetes, open-source project founded in Google, but how do we actually start building a company around Kubernetes and really take it to the next level and bring it to customers. And thank you Madrona for being great investors and working with us through that journey. We ended up selling Heptio to VMware and we’re continuing that, that journey and that mission inside of VMware on a somewhat larger stage. The thinking about open source and establishing Kubernetes in general, I think a big part of getting open source out there and building that sense of ownership is releasing it and engaging in building that community probably earlier than when you’re comfortable.
You really need to get this stuff out there when it’s still half baked, when there’s still a lot of things to be done, when there’s big decisions to be made, because then you can involve your community. As you look to make those decisions, you can let them help shape you. And so, this really mirrors the journey that I see a lot of startups go through in general.
This idea that if you wait too long to release your product, oftentimes, you get in your own head and you don’t listen to folks. When you see healthy startups, they have an early customer base. They have a user community for their products, which mirrors the user community for open-source projects.
And they really get this really tight flywheel feedback loop with their early customers that really helps to accelerate and home in on that product market fit that is so critical for startups to be successful. Starting Heptio, we were in a little bit of an interesting situation because the project was already up and running, and successful, and was really finding a lot of traction. So, it was really, our problem was how do we actually construct a business around this open-source project after the fact, with the reality that, you know, a lot of the patterns, a lot of the technology was already in motion and set there.
Now, I think luckily enough, the way that Kubernetes was involved, and I think being part of that, I think we steered it that way, is that there’s parts of Kubernetes where it’s fundamentally extensible and there’s opportunities for us to build up and around on top of that to start building more products that compliment Kubernetes. And I think, that’s one of the keys, and I think we can probably get to this a little bit later. What are the different avenues for commercialization of open source? And I think one of the key things is to actually build the open-source projects so that it’s usable by itself, but it also has extensibility points that create opportunities for you and others to be able to work on top of that and start really bringing that next level of value on top of that open-source base and foundation.
Anu Sharma: Yeah. We spent a bit of time at ourselves on a couple of open-source projects at AWS, where we thought a lot about how to open source a project while still leaving enough room for the community to contribute, to bring in, as you said, their sense of ownership into the progress of the project. How did you think about which areas you wanted to leave open for extensibility?
Or was there a certain principle that you went into it as a tenant, for example, on, we want to leave this extensible and this is why we’re designing it this way?
Joe Beda: I think this is where things get really fascinating because product planning and business sort of planning and strategy starts to meet technical architecture and starts to, you know, so there’s this puzzle of we want this project to be useful enough that it will attract a user and a developer community that aren’t necessarily customers of ours, and we also want to make sure that we have room to find the right customers who maybe don’t have the energy, the time or the wherewithal to get involved in that community so that we can bring them value and build that next level on top of things. Now, with respect to Kubernetes, I don’t think we planned this from the start, but one of the things that we saw as the project continued and evolve is that the project itself was becoming a gatekeeper for new features.
So, everybody was showing up saying, I want to put this into Kubernetes. I want to put that into Kubernetes. And really it was overwhelming the project. We couldn’t keep up with all the ideas and the things that people wanted to do and build into Kubernetes. And frankly, it scared us, because, like we want to embrace that. We don’t want to say no, but we also can’t say yes to everything. And so, I think a big part of our evolution there was recognizing that if we don’t want to say no, but we can’t say yes, is there a third option? And so that third option really is, yes, you can do that, but you’re going to have to build it on top of using these plugin mechanisms.
So, we really let that community help to guide us in terms of what are things that people want to do on top of Kubernetes, and then what are the ways that we can provide a way for them to do that without the project itself, becoming a gatekeeper where it’s you must go through us to get something integrated into the core.
And I think when you look at sort of the way that this market has evolved, and for those not super involved in the Kubernetes cloud native world, you can go to the cloud native computing foundation and they have this landscape slide. And VCs love these things because they’re mapping all the different companies and you’re like, which one should we go and talk to?
And you check them off when you’ve met the founders and stuff. But from the point of view of, from my point of view, that’s a thriving ecosystem and it’s chaotic and it’s somewhat overwhelming. But it’s the sign that, that platform, that accountability mechanism has created enormous amount of opportunity outside of core Kubernetes.
Now from the customer point of view, that is also overwhelming and scary. And we’ll often see customers look at that and their eyes go wide and they, they start getting some cold sweats because there’s so much there for them to understand. But that’s also opportunity for vendors to be able to bring this stuff together and provide a curated introduction or view onto that world.
And that’s very much the point of view that we were taking with Heptio and what we’re continuing to do with VMware and VMWare Tanzu.
Anu Sharma: So, at this point, the project has evolved into a successful community, you’ve built a platform that is thriving with a vibrant ecosystem. As part of the company, when you’re building new features and new technology, how do you think about what goes into the open-source repository and what is part of what you believe is the company’s resource or asset?
Joe Beda: It’s, I think this is a place where you have to have a theory and you have to test it. There’s a couple of rules of thumbs here. And I hesitate to even say these things because for every rule there is a counterexample of it. But a couple of things that I think about when I look at this number one is that developers don’t pay for stuff.
I think once you start getting into more operational roles, and I think that’s what I would view paying for cloud services start to be, then I think those rules start to change, so it really depends on your definition of developer. But the reality is that a typical developer sitting in an enterprise, they would rather spend their weekends writing code, then figure out the purchase order process of their enterprise.
And companies make this hard on purpose to spend money for a lot of their, a lot of their developers. And so often times what you find is that this distorts things where the people who do spend money in enterprises, the people who are your buyers are often not your users. And so, when you think about that user versus buyer dichotomy, it really comes down to what are the features that are critical for users?
Put those into the open source. What are the features that are critical for buyers? Those are the things that you want to actually make sure that you reserve and that you think about building a business around. And this is and this is where it gets more subtle here because these groups don’t operate independently, right?
If you get a lot of traction with a set of users, and now the buyer, whether this be the head of IT or some, some business unit GM, or what have you, those folks have the engineers that they trust. And they’re going to go to them for spot checks in terms of whether the technology that they’re looking at buying is viable and healthy or not. And so now what you want to do is you want to go in there, establish a relationship, establish a brand, establish that ownership and that emotional attachment, and then be able to say okay, we can both maintain that experience that the users love. And then also go through and provide the set of features that are absolutely critical to the buyers on top of that.
And it becomes a reinforcing action from both sort of bottoms up and top down when you think about your sales motion.
Anu Sharma: Yeah, and there are parts or features that are clearly buyer side. There are features that are clearly user side. And then there are some in the middle. For example, you can think of, authentication SSO and maybe SSO falls more on the buyer side, but authentication almost as a core feature of your application, if you’re not authenticating, you’re lacking core security features. How do you think about that element? Is there a gray area in between and how you, how would you disambiguate that?
Joe Beda: There is a gray area in between. And honestly, I’m conflicted about this because I think, it’s not unusual. And I think I saw joke on Twitter, earlier this week where it’s SaaS, it’s you have the free version, you have the solo version that’s 50 bucks a year.
And then you have the enterprise version that has SSO and it’s “call us” and, “call us” means that it’s significantly more expensive. And that’s the common pattern that we see because some of these features, whether we’re talking layering features on top of open source or whether we’re talking about like coming up with the addition’s breakdown strategy for SAS.
Some of these features have outsize utility for the people that have money. So, the idea is that what are the critical features for the folks that have money, who can pay you for it? Those are the features that you want to charge a lot for. And I think as a developer, and as an engineer, it’s somewhat offensive where the value of a feature is not always proportional to the complexity of the implementation of that feature.
And so, breaking that assumption like I’m convinced that you can make millions of dollars with the right bash script. It’s not about, it’s not always about coming up with groundbreaking new, hard technology. It’s really about solving the right problem in the right way for the right person.
And if you can do that, then you can start to do the segmenting and actually come up with the right the right features to actually have for your enterprise edition and all that. And I think, you know, also as an engineer, we find this somewhat offensive. You’re charging how much for what? And I think, but it costs a lot of money to run a company.
It costs a lot of money to be able to actually create and support some of these projects. And I think that, part of building a business is recognizing that you’re going to be giving up some value. You’re not going to be capturing all the value that you create, but in doing so, you’re making a deal where, you know, you can, can capture more reliably, a smaller part of a larger market versus, the entirety of a smaller market.
And that’s some of the trade-offs that I think you make, as you think about whether you’re doing a free edition for SAS or you think about whether you’re going to start getting involved in open source and put real money, real time, real effort, real engineering behind that.
Anu Sharma: You started to get a bit into the monetization bits with buyers. You’ve probably thought about this a whole lot on all of the different options that you have in front of you for monetization. How would you consider that? Of course, how did you think about it for Heptio and how do you think about it now going forward, if you were to start a new project?
Joe Beda: I think looking at Heptio, I think I definitely learned a lot as we’ve gone through, and I think, my thinking on this has gotten a lot crisper than I think we were fumbling our way through with Heptio to be honest, in some degree. So, the first thing to recognize is that they’re different types of open source.
And fundamentally I started out saying, what excites me about open source is this community people coming together? And I think fundamentally when you look at a project, there is an unspoken contract between that project and its community. And you establish that early on and you set expectations with your community.
And as you set those expectations that defines your degrees of freedom in terms of, hey, here’s the stuff that we’re going to be doing to be able to monetize this stuff. And I think one of the worst things that you can do is to unilaterally redefine that contract with your community as you go.
And so, I think a lot of the places where we’ve seen companies struggle with open source is where they’ve had some implied contract or relationship with their community, and then the situation changes and they’re like, we’re going to change the license because we need to be able to monetize. Or we’re going to exert control that we hadn’t been exerting before, because technically we can do that, but because we haven’t done it before, and because of some of these sorts of statements that we’ve said, now, all of a sudden, we’re changing that contract with our community. And so, I would say that the contract that you have with your community, both, will influence the growth and the level of ownerships that people feel with your open-source project.
And it will also, constrain and enable the monetization motions that you can bring relative to that open-source project. And so, I think looking at different types of open source, I think that there’s on one end of the spectrum, there’s what I would call, throw it over the wall open source where it’s like, hey, I’m writing code, but people can read that code.
Maybe even it has an open-source license, but I’m not accepting any contributions. I’m only interested in a user community. I’m not interested in a collaborative sort of contributing community. And sometimes people will call it open source, even if the license is relatively restrictive as they do that.
I think a great example of this would be Android, right? Android is open source. People can take it and do other things with it as noticed by the gazillion Android derived phones that you know in, in far East. But there’s still a core of that, that is, the fundamental Android experience is tied to Google services and it’s very clear that the next version of Android is being enabled by Google.
And the set of flowing back into that code base is very limited. At the other end of the spectrum is what I would call open community, and open governance. And this is what we see a lot with things like projects in the CNCF or the Apache foundation. This idea where you want projects, where the direction and the roadmap of the project is driven by the community itself. And oftentimes you’ll see these things be places where multiple vendors come together. There are things like elections for decision makers inside the process. And so, it’s very much that community is driving where that thing goes. And I think from my point of view, a healthy sign of a project that is open governance is that if any single vendor, even the most critical one to that project, if they were to step back and say, you know what, we’re not interested anymore, the project would still be viable, would still have a life beyond that vendor stepping back.
And in the middle there, what we have is this emergent of what I would call open core projects. And I think this is where I think a lot of folks get very confused. And there’s a lot of companies exploring redefining some of these contracts and looking at this sometimes to great effect sometimes by, ham handedly, redefining that contract with their community and creating a lot of problems for themselves.
And so, I think there’s a way that we can start slicing this more, finally, that I think is useful. Open core often times what you have is a single vendor driving a project. And they reserve for themselves, the right to offer the enterprise edition of that product that has extended features.
And so, if you are a member of that community, fundamentally you can use the open-source version. But if you want to contribute to that open-source version, something that will start to conflict with the enterprise version, they’re going to put a stop to it, close to PR and say, no, right. And we’ve seen this happen with a lot of companies. Now where things get really hard is when like the original license, was very liberal and then going forward, they’re going to be changing license for the contributions they’re bringing to the project. They still own the trademark.
Those are the things that can create a lot of turbulence and can help to really damage communities. Now slightly on the other side of that is something that, we’re still workshopping the phrasing for, this is what I would call maybe open extensibility. And this is I think, where we look at where Kubernetes is. Where the open-source project is open and it’s a level playing field. You may set limits into what goes in that project. So, if somebody comes with a PR saying, we want to add XYZ feature, you may say no, but instead of saying, no, it’s impossible, you say no, but here’s the extensibility mechanisms that you can use to do it yourself.
Perhaps in another open-source project, perhaps in a proprietary thing. So now as a company you’re sponsoring that open-source project, you’re building it, you’re building the extension mechanisms. You’re then using those extension mechanisms to build your commercial products that are complimentary to the project.
But fundamentally it’s a somewhat level playing field between you and other folks because those same extensibility mechanisms could be used by your competitors, or it could be used by complimentary open-source projects. It’s a little bit riskier, but I think it also, from the point of view of business, but also, I think it stays true to a lot of more of the sensibilities and the ethos that a lot of your contributor and user communities will be expecting out of that open-source project.
And so that’s, I think in my mind, the sweet spot is to actually do that open extensibility, but I think it’s worth recognizing that there’s a whole host of models along that spectrum, that, that really come into play.
Anu Sharma: I love it. Open extensibility. And that, as you said, opens the room for more risk, more competition. How do you think about competition? Somebody using the project that you have created, that you feel ownership for, but also then I guess throwing a chip in and saying, I also feel some level of ownership, I also want to build a commercial product. How do you think about competing with them?
Joe Beda: As a company you always like, and I’ll probably, again don’t misquote me on this, but companies love to be monopolies. Like your dream as a company is to have huge modes and to have something that’s so unique that you own a hundred percent of a growing and thriving and critical market.
That’s our dream, that’s not always in the cards, that’s really hard and that’s super risky. And so, I think a big part of the way to view this is, again, I think, would you rather have a smaller part of a large and thriving ecosystem or a hundred percent of something that’s rather small. And clearly, the answer is why can’t I have both. But that’s not always what you’re going to get to. So, I think there’s a strategic decision around, we want to create something, a movement in a rising tide that we can then participate in. That is very difficult to do, if you don’t have a community aspect, if you don’t have that ecosystem to be able to build and build around. There are tons of companies that have Hey, I want to rebuild a windows office, like duopoly type of thing, and it’s yeah, that’s great work if you can get it. But a lot of people have tried and broken themselves against that particular type of goal.
Anu Sharma: And to that point, you might’ve noticed the recent flurry with a bunch of different open-source projects and commercial companies and for projects from other competitors, how do you think about disambiguating some of the narrative there. What would you say in terms of clarifying perspective?
Joe Beda: I would say that a lot of these things are, the fundamental cause is that the way that the communities for the open-source projects were structured was incompatible with the business models for the companies that were sponsoring them. And that’s the type of thing that you can paper over for a while, but you’re going to have to solve that. Either the company goes out of business because they don’t have enough of a business to support that project, or they go, and they redefine the rules and they run the risk where the community will revolt on them. And it’s a problem that I think, you very much, as you engage in open source, you want to make sure that you know how this is going to play out and that you have a game plan there. And I think, to be fair to some of these companies, there’s an emergence of other motions that they probably didn’t foresee like this idea. And I think this is especially common in startups built around open-source databases, where a lot of the monetization comes from being able to run these things and actually bring that experience, the full experience to it. And they found that them being the sponsors of the open-source community did not give them enough of a leg up when it came to be able to manage these things and run these things as a managed service. Oftentimes others are maybe better prepared to make that be a feature of a larger platform versus a standalone product.
And so that’s a really hard situation for everybody to be in. The point of open source is, you take this risk where you put it out there. Other people can do stuff with it, and sometimes they will and sometimes they may actually take it in a way that’s inconvenient for your business. And so, I think that’s something that you got to be, you got to be thinking about and working through as you go. Yeah, I think and some of this is understanding, like where is IP critical and where is IP really secondary to the larger experience that you’re delivering?
And I think one analogy here is I think we’re all sitting at home with, COVID not with COVID, but like quarantine because of COVID. I hope we’re not all sitting at home with COVID and like I’m ordering a lot from restaurants. And it makes you think about where is the value there when you’re doing that?
Because if I have a hamburger. I can make that hamburger at home. Actually, I’m getting pretty good at it. And it can be a good hamburger. And it’ll be a heck of a lot cheaper, right? The IP for making a hamburger is not the fry sauce is a ketchup in tomato, ketchup and mayonnaise mixed together.
Right? There’s this secret sauce is not that secret is in when it comes to a hamburger. So, the IP around this is actually relatively low. But yet there’s still real value for me going to a restaurant and having a hamburger and having somebody do that for me. And there may be complimentary IP Hey, they make this great cocktail and I have no idea what the proportions are, what goes into it right. There may be other, IP that I don’t get, that’s complimentary to that main thing, that is the hamburger. And I think we see with things like delivery services. It’s like somewhere in the middle and it’s the worst of both worlds to some degree it’s more expensive and it’s not as good at being at the restaurant or making it yourself.
So, I think, there’s definitely some lessons to be taken from an analogy like that.
Anu Sharma: I love that analogy. And you know, one of the aspects that we struggle with and hear from engineering leaders in some of our portfolio companies, but even some of the larger ones, is how do you evaluate open-source projects? And of course, maybe an extension to that question is how would you advise investors evaluating open-source projects?
Joe Beda: I think valuing and evaluating open-source projects from those different angles is I think very different. The, I think any engineering org should be thoughtful and responsible as they take on dependencies. And I think we’re starting to see this as we look at, more focused on the supply chain in general, and the risks that you take on board as you look at, sort of like, oh, I’m taking a dependency on this, so this node library. It’s everything from that to I’m buying this vendor product, that’s going to be, you know, where I’m committing to only running on this particular cloud. I think, it’s really important that as you make those decisions, whether you’re buying something, whether you’re building on open source, whether you’re building a component yourself, that you’d be really thoughtful about understanding the pros and the cons and the risk about that.
I think oftentimes in my end of the business, people will talk a lot about lock-in and how like lock-in is bad and, and open source is a way to avoid lock-in and I think, to some degree, there’s true, but I think that’s a somewhat simplistic view. I think the right way to view lock-in is vendor risk.
If I take this bet on this vendor, what are the risks that I’m taking and what are the benefits that I’m getting for that risk? And I think when we look at open source, there’s a different set of risk and benefits from it. Some of the risks may be that I have to run it myself versus having a trusted person.
Some of the risks may be that like, I’m going to have to buy support from somebody versus being able to, and that’s going to be part of the cost. But some of the benefit here is that I have more degrees of freedom. I can always take the source code and build up a team to dig into it.
I can always run it in a way that’s off label because it’s me supporting my own thing. And so, I think there’s a different sort of risk benefit analysis when it comes to open source. So that’s from the point of view of a user getting involved with open source. And I think also some of this is, open governance with a healthy project.
And what happens if that single vendor that’s sponsoring it, steps back, will the project still have a life beyond that? That’s also some of the things that I think folks should take into account as they’re evaluating, taking independency on an open-source project.
From the point of view of an investor, what I would do is when I’ve, advised and looked at folks who are building a business around open source, they should have a very strong thesis for how they’re going to build a commercial compliment to that open source. I think it’s very tempting and I think, to say, hey, I’m going to write a bunch of code. I’m going to get a bunch of users and then magically I’ll figure out how to monetize those. Now in the consumer world, you can do that, right? You get a hundred million people doing anything. You can find a way to monetize it, right? In the enterprise developer, open-source world, you can get everybody to some definition of everybody using your product and it will then be project and it’ll be very difficult for you to be able to monetize that. So, it’s without that theory, without that thesis, without planning for that, I would say, it I would have a hard time investing in a company that is that is basing something on open source.
Conversely, if they view open source through a very evolved smart lens, then you’re like, all right, these are folks who know how to build community, use that community to boost their business while staying true to that community. I think that’s, skills around that are something that’s pretty rare and something that should very much be valued.
Anu Sharma: A hundred percent. That’s what BC as well, and excited for open source in general for the next decade or more even. And we’re continuing to see a whole bunch of new projects that require that kind of balance between community and managing expectations, of course. And, but more importantly ownership along with building the commercial business model and scaling that to a multi-billion dollar business, hopefully.
That’s that was great, Joe. Thank you so much. This was fantastic. Really appreciate you taking time and enjoyed our conversation.
Joe Beda: Thank you so much for having me on.
Anu Sharma: Thank you.
Erika Shaffer: Thanks for joining us for Founded and Funded. If you enjoyed this conversation, please share it with your friends and subscribe. It’s available on all the platforms and we really enjoy making these and bringing them to you. And please send us ideas [email protected]. Thanks very much.
Related Insights
