Joe Beda, co-creator of Kubernetes, speaks about his experience with building one of the most popular open source projects in the world and the evolution of business models around open source.
Open source projects are a positive sum game and can extend the sense of ownership to developers who want to contribute to the project. Building a business around open source is about establishing a sense of trust with the community of contributors who co-own the project with you.
Listen to the conversation on Madrona’s Founded and Funded Podcast or watch it on the Traction channel on YouTube.
Open Source is a positive sum game
Anu: Joe, it’s great to have you on the show. Welcome,
Joe: I’m glad to join you.
Anu: Joe, open source means different things to different people. What does it mean to you?
Joe: Oh, wow, 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 imagination of how can we have folks come together and do something that wasn’t possible before. And I think open source is really fascinating from 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 I bring something, you bring something, somebody else brings something, and we create something that’s greater than the sum of the parts. That positive sum game is really what open source is about for me.
Anu: 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 sourced that’s the material aspect here.
Joe: Yeah, I think community is fundamentally what’s at the heart of open source in so many different ways. The more senior I become as an engineer, the more I recognize that the hard problems aren’t technical. 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 a community that creates things that aren’t possible before. When you think about great branding, right? Like Nike, Apple, these these top level brands, right? They evoke an emotional response in 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 also, 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.
Building a business: releasing early and embracing the community’s sense of ownership
Anu: Going back to the time when 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: Well, a little bit of my history here, is that I’ve been in industry for like 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 journey and that mission inside of VMware on a somewhat larger stage.
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 build those decisions, 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 like, 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 hone in on that product market fit that is so critical for startups to be successful.
So, 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 our problem was how do we actually construct a business around this open source project after the fact with the reality that 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 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 key, 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: Yeah, we spent a bit of time ourselves on a couple of open source project 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 circle principle that went into it as a tenant? For example, we want to leave this extensible and this is why we’re designing it this way.
Joe: Things get really fascinating because product planning and business planning and strategy starts to meet technical architecture. 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. 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 plan this from the start, but one of the things that we saw as the project continued and evolved 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 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 like, you must go through us to get something integrated into the core.
And I think when you look at 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, when you’ve met the founders and stuff. But 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 platform, that extensibility mechanism has created an 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 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 taken with Heptio and what we’re continuing to do with, with VMware and VMware Tanzu.
What features go into the open source repository?
Anu: So at this point, the project has evolved into a successful community. You 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: 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. 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. #1 is that developers don’t pay for stuff. Once you start getting into more operational roles and I think that’s what I would view pain 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 than figure out the purchase order process of their enterprise. And companies make this hard on purpose to spend money for a lot of their developers. And so oftentimes 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.
This is where it gets more subtle 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 business unit GM, 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 like go in there, establish a relationship, establish a brand, establish that ownership and that emotional attachment, and then be able to say like, ‘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: 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 is a core feature of your offer your application. If you’re not authentic getting, you’re lacking core security features. How do you think about that element? I mean, is that a gray area in between and how you, how would you disambiguate with that?
Joe: There is a gray area in between. And honestly, I’m conflicted about this because I think, you know, it’s not unusual. And I think I saw joke on Twitter. Earlier this week where it’s like SaaS, it’s like, you have the free version, you have the solo version that’s like 50 bucks a year.
And then you have the enterprise version that has SSO and it’s like call us and, you know 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 sort of like coming up with the additions breakdown strategy for SaaS some of these features have outsized utility for the people that have money. The idea is that like ‘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. Right? 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 the right features to actually have for your enterprise edition and all that. Also as an engineer, we find this somewhat offensive, ‘You’re charging how much for what?’ 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. Part of, of, 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 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 SaaS 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.
Monetizing open source: a spectrum of business models
Anu: You started to get 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? 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: Well, I think looking at Heptio, I think I definitely learned a lot as we’ve gone through, and my thinking on this has gotten a lot crisper than I think we were kind of fumbling our way through with Heptio to be honest, in some degree. So the first thing to recognize is that they’re sort of different types of open source. And fundamentally like, you know, I started out saying, what excites me about open source is this community people coming together. And I think fundamentally when you look at it project, there is a 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 expectation that defines your degrees of freedom in terms of like, ‘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 sort 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, 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, 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 sort of Android, right? Android is open source. People can take it and do other things with it as noticed by like the gazillion Android derived phones in the far East. But there’s still a core of that. 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 in the roadmap map of the project is driven by the community itself. And oftentimes you’ll see these things be places where multiple vendors come together. There’s 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, ‘We’re not interested anymore’, the project would still be viable, would still have a life beyond that vendor stepping back.
And so in the middle there is what I would call an emergence 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 is 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.
I think there’s a way that we can start slicing this more finely that I think is useful. Open core is fftentimes 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. 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 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 from the point of view of business, but also I think it stays true to a lot more of the sensibilities and the ethos that a lot of your contributors and user communities will be expecting out of that open source project.
And so in my mind, the sweet spot is to actually do Open Extensibility, but I think it’s worth recognizing that there’s a whole host of models along that spectrum that really come into play.
Competition and Defensibility: Know where the value is
Anu: 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 them 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: Well, as a company you always like, and I’ll probably, again, don’t misquote me on this, but like companies love to be monopolies. Like your dream as a company is to have huge moats 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, right? That’s not always in the cards. That’s really, really hard and that’s super, super risky. And so I think a big part of the way to view this is would you rather have a smaller part of a large and thriving ecosystem or a 100% of something that’s rather small and clearly. The answer is clearly why can’t I have both? But like 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 and a rising tide that we can then participate in that is very, very difficult to do if you don’t have a community aspect, if you don’t have that ecosystem to be able to build. There’s tons of companies that have like, ‘Hey, I want to rebuild a windows office, like duopoly type of thing.’ And it’s like, ‘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: And to that point, you might’ve noticed the recent furore with a bunch of different open source projects and commercial companies and forked projects from other competitors. How do you think about disambiguating some of the narrative there? What would you say in terms of petrifying perspective?
Joe: 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 eventually 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 so, it’s a problem that as you engage in open source, you want to make sure that you know how this is going to play out in 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 that 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 sources is that 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 that’s something that you gotta be thinking about and working through as you go.
And some of this is understanding, like where is it IP critical and where is IP really secondary to the larger experience that you’re delivering? 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. It makes you think about where is the value there when you’re doing that? Because like, 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 like the fry sauce is ketchup and mayonnaise mixed together. The secret sauce is not that secret is when it comes to a hamburger. Right? 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, like, ‘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, you know, there’s definitely some lessons to be taken from an analogy like that.
From an open source project to a commercial product
Anu: One of the ways I think about open source projects is it solves a problem. And then there’s a different aspect off the productization of that solution: the usage aspect of it, the buying aspect of it, but also the consumption aspect of it. 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 a whole productized version of it. How do you think about the separation between open source and the commercial product that comes out of it?
Joe: The words that you’re using there, and I think they’re so close that they sometimes confuse us, is project and product. And I think oftentimes when folks get really a mesh 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, Joyent started the Node ecosystem. But 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 of modern open source where these lines are starting to blur, but at the end of the day, it’s still just a project, right? A product in my mind is something that has a SKU, and you pay money, for goods and services, right? That is a product. And a project really is, there’s still a certain amount of like, ‘You’re on your own here, take it or leave it type of thing.’ Part of this is, a product is the value that you’re adding on top of the projects that you can bring in and charge money for. And there’s different things that you can actually do, and I think it’s worth talking about what are the size of the moats that you bring as you start adding that value. And I think that the easiest thing to think about is, 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 24/7 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 the Linux distribution world where a Linux distribution, I had a former Red Hat employee that worked for us call it, Walking-over-broken-glass-as-a-service. Because the traditional open source is you take all these different projects that may be, some of them have versions, maybe some of them 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 open source support model. And there’s a lot of value to be added there.
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, it’s very hard to build the distribution over something like Node because the project is so darn good that the level of value there [is low]. And so, and in that world, what we see is companies like Snyk 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 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 hygiene that you often would use to buy through the distribution, the Linux distros.
Next level of value is that there’s features that you can get when you buy the product and those features aren’t available when you’re talking about the project. And I think that’s where we get into what we were calling previously, the difference between like Open Core where only one company can deliver those enterprise features, whereas I think (with) Open Extensibility, there’s a level playing field for multiple folks, open source projects or a 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 a static thing. Old open source is like LIBPNG, I can decode PNGs without having to write my own code. Modern open source is Cassandra or K8s, or what have you. These things take a certain level of complexity. I mean a certain level of skill 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. Like you don’t just launch a database and be like, ‘Okay, it’s good. Done step away.’ 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 playing around with the different models for how they can start adding value and turn product from project.
Anu: Yeah, your analogy the burger, with the experience, I think is so apt here where it’s the experience that I buy. And there’s a central IP there that, of course it stands at the core of it, but that’s not what I’m looking for. As a buyer, I’m looking for the whole experience and whether it’s a cocktail and whether you need a cocktail or a great ambiance to go with it, that’s maybe successive questions to ask.
Joe: And maybe we can mix in some of the meal prep services into the analogy there also, right? Because like that’s kind of open source. Like there’s a certain level of open source product, which is the meal prep where it’s like, ‘Hey, you’re still doing it all yourself, but we’re going to give you the directions and the support. And we’re going to give you all the things already neatly cut and prepare, and it’s going to be beautiful.’