Supercharge Your Commercial Product By Doing Open Source the Right Way with Lukas Gentele

An open-source project. Excellent, good for you. What's next? Well, you were expecting it would take off, of course. You expected contributors, but no one is helping. You assumed it would drive leads, but users take your free version and never convert. And now the free version is draining your time and money. 80% of open source projects ultimately flop. What does it take to make one grow? Hey, what's going on everybody? I'm Mike Sirius and this is Mastering Tech Growth. Each episode we sit down with industry leaders to bring you actionable insights that drive growth. If you enjoy the show, make sure to subscribe and send us your biggest growth questions at masteringtechgrowth.com. Joining me today is Lukas Gentili, CEO and co-founder of Loft Labs. Lukas has built tools used by platform engineers over 100 companies. His leading voice on Kubernetes and, and in open source space. He's spoken at KubeCon, launched multiple dev tools, and helped define what virtual clusters can do for modern teams. We got Lukas over today to talk about why most founders get the open source wrong and how to build a project that actually grows, brings in users, and makes money. Awesome to have you on, Lukas.

Good to be here, Mike. Thanks for the invite.

Brilliant. I got a bunch of questions I was dying to ask, so let's just jump in. Lukas, when I say mastering tech growth, what comes to mind?

Oh, a whole bunch of challenges, I think. Uh, you know, I think especially if you're open source founder like me, you're, you're really wondering, how can we, you know, grow the community and the open source, the effective, you know, free for everybody to take piece, but then at the same time, how can you actually build a company? And that obviously requires building a revenue stream, generating leads, you know, optimizing the sales funnel, hiring go-to-market folks, right? I think it's a plethora of challenges you have, but you're always balancing also this this part of the open source side of the company. It's a very unique challenge.

Let me make this more difficult on you. So from all the things that drive growth within tech ventures, and you know, for you guys, it's Loft Labs, you got sales, you got marketing, you got product fit, you got the timing, you got the quality of tools, like you got a rainbow of things which can drive growth, right? You can choose only one. What would be your number one that drive growth?

What would be the number one to drive growth? Um, I think is having the right problem to focus on in the right market, right? I think sometimes you can attack a problem that people are never going to pay for, and they're going to be very interested in it, right? And it's going to help them with something, but it's never able to, you know, be a paid product. And I think, uh, getting that right, finding something that people or companies— right, if you're a B2B, uh, focused venture, then, uh, you know, that getting that right is the prerequisite for, for growth. I mean, if we're talking growth in terms of you know, uh, AR and, and actually growing, uh, a sustainable business.

Yep. I love that. Focusing on the right problem. So effectively, which is saying don't build stuff people don't need, right?

Well, they may need it, but, uh, they don't need it to the extent that they're, you know, like there may not be a willingness to pay for it, right?

Yeah. Here you go.

It may have a, may have a great utility and it may be a lot of fun to use or it make your life easier. But if there's no budget allocated for it and no willingness to pay, it's still a difficult problem. Actually, the first, you know, before we pivoted to what we're doing today, we were focusing on something exactly like that. We had an open source project that was thriving, but it was really hard to commercialize it. And we just realized there's no budget for the kind of work that we were focusing on.

What was that?

It was a developer tool. It was improving developer experience with Kubernetes. And it's still a very active project. Tons of companies are relying on it. A lot of people love it. We use it internally still, right? It started as an internal tool in my previous company and we are still using it today for the post-pivot company. But I think the willingness to pay, like if you ask my CTO, hey, would you approve budget for this? Probably say, no, I'd rather hire another engineer.

Yeah, that's— it's like, why don't you care about my, you know, experience as developer? Dear CTO, can you buy me this tool? But I get exactly what you're saying, Lukas. There's really a threshold of the need where a person is willing to pay for or not. So when you're doing market research, or effectively trying to understand the problem space you're trying to provide the solution for, You need to make sure that the market is going to be ready to pay for that. I love that. Okay, so we jumped over that one. This is a question we love to ask every guest, by the way, Lukas. So let's go back to open source. So a lot of founders launch an open source project expecting it to grow on its own, but the reality is that most of them fail. Why? Because they are missing a clear business model. Solid leadership, and an actual community engagement. Without these, even the best ideas will flop. And according to Linux Foundation, only 17% of open source projects report having a clear governance and a defined monetization strategy, leading to high burnout and effectively project abandonments. Lucas, when you first entered the open source ecosystem, what were some of the big mistakes you saw founders making, or maybe you even made it yourself?

Yeah, I mean, it's definitely the build it and they will come mentality, right? It's definitely true. Even if your product is open source. I mean, there are certainly things that explode overnight and that are these like, you know, unforeseen successes, right? But those are the miracle stories, right? Those are the 0.001% cases, right? In most cases, success is a combination of luck in some case, but then also creating opportunities for luck. I'll give you an example. So if you are launching an open source project, and, you know, you're posting it on Hacker News or Reddit or something like that, and you're only posting it once, then you have one opportunity to, you know, for that post to go viral on Hacker News. And the likelihood of that happening on that particular day, with all the other news that may have happened on that day that you couldn't plan for, possibly, you know, know about, is super slim. Versus if you're starting to write content, you know, we wrote a lot of content in the early days of the companies, and we still do, right, about why the product is useful, how can you use it, you know, we ship new features and talked about them, um, you create more and more opportunities for that kind of luck. Because in the end, you know, like, uh, I remember we had an announcement, uh, at one point in time, and literally Silicon Valley Bank, uh, went bankrupt. Well, that announcement is gone, right? Like, no, nobody cared about our little announcement, but But if you're shipping consistently new features that you can talk about, you have more opportunities to become lucky rather than unlucky.

Okay, so effectively, it's just, you need to participate within the social space a lot more than people think. Is that the message we're trying to send? Is that if you're shipping a lot more features, there's going to be a lot more what to talk about. Which means you're going to be producing a lot more content, maybe blog posts, maybe just announcements, maybe social media posts, you know, discoveries of your own failures, maybe successes. And it's just, it's just this constant broadcast of messaging which allows you to be seen effectively at random by, by, by other people.

Yeah, absolutely. It's, it's knowing your audience, engaging with them, knowing where they hang out and making them You know, you want to turn— you want to create an active community and you want to turn strangers into contributors, even if they don't contribute in the sense of actual code contributions. They may contribute an idea, they may contribute to the docs, they may raise an issue and have a feature idea, right? Like those kinds of contributions are incredibly valuable. And I think that's the true power of open source, right? I think a lot of people underestimate that part that you actually have to engage with the community in order to build it.

Okay. So when we say engage with the community, we're not saying just broadcast information. We're actually saying to have active conversation with the community. Yeah. Effectively, where they spend time, like you want to find these communities, go there, start pushing your own message, but then actually have active conversations, comments. Emails, I don't know, going on podcasts, going to conferences. Is that what we're saying?

Yeah, absolutely. I mean, every time I posted something in the early days of the company on Reddit, right? Kubernetes Reddit channel is, or subreddit is super, super active. I stayed on there for at least another hour and got back on comments and Occasionally, if somebody had something really interesting to say, I just DM'd them. I was like, hey, that sounds super interesting. What are you working on? Have you tried this? Have you seen this config option? And that gets really people excited. The other part is you don't just want to find them in the channels that they're in right now. You also want to create channels of your own. So we were pretty late actually to the game to start a Slack channel. We should have, in retrospect, we should have done that way way, way earlier. But giving people a space to meet and giving them a room where that community can thrive because you have a specific topic, everybody talks about vCluster in our case, right? And Kubernetes multitenancy, right? It gives you this joint identity and this joint problem, right? And people want to feel part of that. They want to feel like, okay, I'm talking to like-minded folks that address similar problems here. And it's not just talking to us as maintainers of the project and and the innovators, but also, you know, other practitioners having that same kind of issue or thinking about the same kind of ways and learning from them. I think that's really important as well.

Yeah, I love that. How, how much time you think passed before you realize you should have Slack channel? I mean, is it like 3 months, 6 months, 1 year?

Yeah, I think with vCluster we were smarter than we were with the, uh, with the pre-pivot project, uh, when we were still building DevSpace, our developer experience tool. It took us at least a year or so until we opened Slack channel. And that was a clear mistake. With vCosta, we started right from the start. And I'm so glad we did because even, you know, it makes you even more accessible because one of the reasons for open source as a successful path to build such great products, I think, is people have an easy way to contribute suggestions, raise issues, right? They can look at the code, they can really dig deep. And they know where to go. You go to GitHub, you file an issue, right? The same happens when you have a Slack channel and people want to reach out about some kind of collaboration or they want to submit a talk and want to do it with you as a co-speaker. They can just DM you in that Slack channel because they see you're active on Slack. They click on your name, they hit message and boom, right? You're just much, much more accessible than if you're just the author behind the blog posts and it's harder to get a hold of you, or if it's a SaaS product that doesn't have a clear feedback button, right? I think that's part of the power of open source and of creating that community around it.

With all the tools right now available, Lukas, would you still choose Slack as a sort of community-building DMing tool? I mean, there's like Discord, I've seen Hormozy launching his own school.com, which is sort of like community building. I've seen separate SaaS and services just to build your own sort of communities, monetize these communities. Is like, is Slack still number one tool for this?

Yeah, there's obviously a variety of tools and I know a lot of people have switched over to Discord because of the better, you know, they have some moderation features, right, that are just better than what Slack has. And Slack is a little bit of a struggle in a sense. That, you know, you're always on this free tier. The history is going to be gone after some time, right? It's definitely challenging. But at the same time, you can't afford to pay for a large community if you're paying the regular Slack prices. And I know they're willing to talk to companies and work that piece out. We haven't gotten to that point yet. We're actually still working with the free edition and, you know, we're accepting the hiccups here and there that it may have. But I think the big benefit for us, and I think it really comes down to your audience, right? The big benefit for us is we work with a lot of practitioners who are, you know, they're not in the Series A funded startups. They work at like Fortune 500 companies and very established businesses. And Slack is just the predominant way of communication for them there. Or maybe Microsoft Teams, but I don't think Teams has a way to open up a community channel, at least not that I'm aware of. It's much more internal company communication. So I think Slack for us just lowers the hurdle for people to join. And I think that's a really important piece. So we've considered switching over to Discord, but it's ultimately not worth the price of people may not be able to join or maybe more hesitant to join because It seems like Slack is what they're more familiar with.

Yeah, Slack is fairly, yeah, fairly big. I do agree. And a lot of devs, a lot of engineers use Slack as in, you know, their own DM, different communities, maybe their own business. So it's quite easy to switch between communities and have conversations. Big enterprises, though, big enterprises, they very, very often exposed to Microsoft Office tooling, which means, you know, that this team internally and I work for gaming industry, right? So, so you know what, you know what the tool is? Number one, Skype. Man, that kills me every single time. Like, it's such a pain. Okay, so I love that. All right, so I love how you put that mistake. You went like, look, if you're launching open source, pack it up with the corner for the community to come in and have a chat with you. Even if you're gonna have 1, 3, 5 people initially, it doesn't matter. Make sure that that's getting pushed together with your project. So frankly, that's a big takeaway, right? That's a, that's a, from experience we learned that you don't want to just build up the project to the point of you thinking, oh, it's time to now build a community. No, just do it from the get-go. Is that a good summary?

Yeah, 100%. Launch it early, be transparent about what you're doing, communicate the things that, that you're shipping, right? Get people the chance to get involved. I think that's probably the bottom line, right? You really want to build that community by people that are enthusiastic and rally around the open source.

If I ask this, Lukas, I mean, the Linux Foundation report saying that only 17% of open source projects start good, right? They start with good foundations. They look at the things as sort of like a business module, which would explain why so many of them fail. You know, 80% just gets literally abandoned. From your perspective as a person who spends a lot of time in open source and as well, you know, has huge projects, What do you think is like the biggest pitfalls founders do when they start open source projects and, you know, just abandon them eventually?

Yeah, I think sometimes they, um, they see the open source, uh, almost like a marketing hack and they don't find the right balance between, um, what's open source and what's commercial, or they may think too little about that piece. If you ask me, there's a balance between what you open source and what you don't. You don't want to tip the scale either way. So I've seen examples where people open source a very lightweight client to their proprietary API. That's relatively worthless to anybody because they need your proprietary API to get the value. So the value is actually not in the open source. The value is entirely in the commercial product. And the only reason why you may open source that client or that client-side part of it is maybe to create a little bit of trust of what's running on your machine, et cetera. But that doesn't really create a community and get anybody excited. That's not a true open source motion, right? On the other extreme, you have people that launch an incredibly powerful open source project with tons of features. That is very, very strong, but they have a very thin commercial layer on top. And that's a problem as well, because those projects ultimately end up not funding the company. And if the company goes away, that's not good for anybody in that community. Right. And sometimes community members don't even realize this. Right. It is not, you know, if a company looks at your commercial and your open source, and there's not enough reasons to buy the commercial offering, you could blame the community and say like, "Oh, it's so unfair that they're not buying my product." Or maybe you cut the line at the wrong place, right? Maybe you would've needed a healthier mix between what's open source and what's commercial. And finding that right balance is pretty important.

Yeah, I love, I love you went there. That was one of the questions I wanted to ask. And according to Redpoint Ventures, the most successful open source companies find a 60/40 or 70/30 balance in product access, giving enough to draw a user base, but retaining features that support monetization. So the question I had, how did you guys work that out? What did you do? You know, with your products? Like, was this like a trial and error, or did you strategically somehow went ahead beforehand and decided how much is going to be open source and what exactly and what will be monetized? And if so, what was the thinking pattern behind that?

Yeah, we were very intentional about it. Uh, that doesn't mean we were— we got it right from the start. We were intentional about it and tried to get it right. Uh, but we have definitely changed, uh, our opinion on this. A few times. So initially when we built vCluster, you know, we built a platform to orchestrate your fleet of virtual clusters. So we thought, okay, if you have a couple of vClusters, that's great and nice. If you start having, you know, 50, 100, maybe even 1,000 virtual clusters, you need something to manage and orchestrate these virtual clusters. I still think that's a very valid point and that's definitely why people, you know, one of the reasons why people buy the commercial product. But we've also seen a ton of people that get a lot of value from vCluster and they may just run 20 of them, but they're really high value. So we started looking into, okay, what can we do for each individual vCluster? Because if you're running 20, you maybe you don't need fleet management, right? Like you're probably good to manually maintain these vClusters. So we started thinking about in the second phase of the company, we were, you know, we had this platform, we had the open source vCluster, and then we introduced what we called originally vCluster Pro. And it's essentially making each individual vCluster better. So it had a better backing store, it is more scalable, it had better performance, right? It's more resilient, right? It's more lightweight. It had exactly these kinds of benefits that people were looking for, for the scenarios where they put vCluster under a lot of load in production, very critical applications, right? And we had to, you know, really figure that out over time that this is an important piece of the puzzle as well. But I completely agree with, you know, Redpoint here in that case when you're quoting them that there needs to be a balance between, what's open source and what's commercial. In a way, you almost have to build two products that have a lot of value. You have to build an open source that in and itself has a lot of value and actually has the core innovation of what you're doing. And then you have to have a commercial product which has to have an equal amount of value but layered on top of your core technology. In our case, that's fleet management, better performance, more stability for Zettli clusters. But in a lot of cases, I've seen companies ship, you know, for example, SSO may be the only feature or something like that, right? That's guarded. And you're like, is that really enough, right, to build a sustainable business? Is that really enough to, you know, ask for a price tag that you really need to build the company you're looking to build? Maybe, but in a lot of cases, the answer is no.

So I'm just getting ideas. When you were talking about orchestration and biggest sets, I was thinking scale, and then you mentioned SSO, which is enterprise features as well. So are we saying that the monetization— effectively, we're giving huge amounts of value to majority of the market, which could be like, you know, one team type of founder trying to build something, or a couple of people coming together trying to you know, launch some startups or maybe very early stage bootstrap startups which could utilize your tool, you know, to get efficiency and things like that into their stack. And then eventually, considering they're successful, they're going to reach a level where they will need to scale and they're going to reach a level where they will be expanding. And at that point in time, we effectively— we're saying your success is our success. So everything else is going to get monetized. So we're sort of targeting that higher tier and ability to pay type of, uh, people with our monetization product, right? Yeah.

I mean, it could happen, right? I think when we, when we started with vCluster, I thought we were going after mid-market startup companies, right? Because that's what we were, right? And that's what we were kind of familiar with. Uh, but you know, we put our content marketing and we realized, hey, the biggest pain is actually in enterprise. You know, we, we're very targeted right now on Fortune 500 companies and, you know, G2000s, right? Like companies of a, of a huge amount of scale because they have that amplified problem, right? That means the pain is higher for them. And that doesn't mean that there isn't success stories out there. And a lot of people, especially in the open source, in, you know, startups and mid-market companies being successful with our technology. But when you're talking about commercialization, you go where the biggest pain is felt, right? And that translates to where's the biggest value and what is the easiest path to actually make the switch from open source to commercial. For us, that's definitely been the enterprise route, despite me not expecting that at all, to be honest. I thought, would enterprises trust us with this, right? But part of the benefit of open source is they do because they looked at the code, right? They've seen that this is a great product and they're convinced on the technology. So they want to make sure they work with the company that made that technology for anything that they need on top. And I think that's, that's a beautiful effect of open source that people actually want to work with the folks that build it.

I love that. So It just comes back to the very first point you made when I asked what's one point when it comes to growth, where you said, you know, have a problem and have a right market to solve that problem with. So from your perspective, you just ended up in enterprise level because they have the biggest pain point, as you put it, which leads to this realization. And you correct me if I'm wrong. If you have an open source project and you are effectively targeting the low to mid market, it's very unlikely they're going to be willing to pay in the first place, right? Because they, they probably don't have money themselves, or they're not making enough to actually pay. Or I am wrong, and, and if you actually structure it as well, they will pay.

You, you might be able to do it. Uh, again, like, we've, we've been on a different path, so I, so I can't speak to it, but I've seen a lot of open source companies be very successful with the enterprise, um, versus, I think, um, if you're going broad, mid-market, or even individual developers, right, there's very few products that have, you know, really be successful. I mean, just think about probably one of the most popular products, you know, out there, maybe Docker. And they had a very difficult journey becoming, you know, living up to the kind of valuation, had to recapitalize, right. And like all of these things, right, there were definitely some hard learnings for them. I would argue GitHub is probably another example, right, of a company, you know, that was targeting individual developers, open source community. That's probably the worst segment to focus on because like, you know, a lot of open source projects, as you mentioned, are also hobby projects or become abandoned after some time. So there's definitely not a lot of money to gain from open source. So The question is really, you know, is the model that, you know, companies like GitHub have, right? But another open source company as well, right? So GitHub is more of a service. GitLab was actually more of the open source counterpart, ironically, although the entire open source community lived on GitHub. So I think that's a, it's a really interesting dynamic. It played out well for both companies in the end. To be clear, maybe better for GitHub than for Docker. I think it was less of a struggle for GitHub to be acquired by Microsoft, although everybody kind of feared what would happen there. But Docker, it was definitely a rough path. I think when you're focusing on enterprise, it may be more intimidating at first, but there's definitely a clear willingness to pay for certain things, right? They just have, you know, regulatory compliance requirements. They just need to worry so much more about availability and the scale that they're operating at, right? That a piece of open source software, they can't just, you know, even though the license permits it for them to just take it and spin it into something production grade, somebody's really taking a risk there. And sometimes, you know, if you have the right features that can help mitigate that risk, that is worth a lot to them.

Yeah, I can vouch for that. Again, I work for a big enterprise and open source is being looked at as a risk factor. So like everything open source goes through the whole security oversight. It's very hard to like actually use it in production, especially if you are as well in regulated markets. So going after enterprise licensing, having SLA agreements and things like that, which is effectively B2B relationship, is great. I mean, that's what they will do. And having that open source foundation where they can sort of experience you at a much intimate level, the codebase, the structure, the community, that's a huge selling point. Like, to close these enterprise deals, that's a lot. Like, that's a good red— sorry, good green flag, right? So it just popped in my head that like, if I mean the mid-market open source, they're gonna use your products to launch their own products. It's just, um, just so unlikely that they would be willing to pay enough. But at the same time, I had a couple of projects in my head which I know were successful. So you mentioned that, um, you guys effectively building two different tools. One is open source, one of this enterprise. How does that structure looks like if we actually go deeper into like, you know, repositories, team composition, you know, who's managing open source, who's managing enterprise? Are these two different teams? Or do the features go through the same team? You know, is this split like just at the very public view where you have open source, you know, in GitHub and closed source, which is not even visible? Or does that split actually trickle down through all the layers of the business up to like development teams?

Yeah, I think we definitely see the open source project as a little bit less complex than our enterprise product. So when you look at a new engineer joining our company, it's very likely that they're going to be tasked with some things in the open source project because the scope is a little bit more limited, right, compared to the enterprise product. When you're talking about the enterprise product, you know, like, I mean, one vCluster in one Kubernetes cluster, that, you know, that's just one container you have to worry about. When you're talking about the enterprise, suddenly you have multiple Kubernetes clusters distributed across, you know, potentially public and private cloud. You have the networking in between, right? You have a lot of failover mechanisms. You have all that complexity, right? But in the end, yeah, I think we, we're definitely trying to get every engineer to the position that they can contribute on both ends, right? We need them to understand the product end to end. And one thing which, you know, one reason why we don't have specific, hey, you're on the open source and you're on the commercial team, is because I think that that sometimes creates a little bit of a divide in a company that's heavily open source. And I've seen that from, from other folks building companies in the space, or from engineers working at companies that were structured like that, where they were essentially saying, hey, it was a it was always a fight between the two because, you know, everybody's advocating for like, oh, this should be in the commercial, this should be in the open source, right? And that should not be the perspective. I think it should be a collaborative effort to make the company work. And some things, you know, create a lot of virality, or they're just table stakes features. So they belong in the open source, right? Regardless of where you happen to be located in that org, right? Other things may be better suitable for the enterprise track, right? Um, I think those types of engineering and product decisions are better when people have a broader perspective across the product, uh, rather than, you know, being siloed into, hey, you're just dealing with open source and you're just dealing with the commercial side of the house.

So I want to take us back a little bit, Lukas, to the very— how you effectively made a decision. So let me give this quote. So this is from Boldstart Ventures, which they put it like this: many open source founders confuse adoption with traction. Just because people are using the free version doesn't mean your business is working, right? And I feel like this is where we were going by, you know, by saying like people need to get enough but not enough so that there would be incentive to actually buy for something. So Lukas, can you take us back to the moment you realized that you had to treat open source project like a real product and not just sort of like some type of like growth marketing stuff? Like, what was the moment you guys went away intentional from the gecko when it comes to your first open source project with the for the vClusters?

Yeah, I think that's a good question. I think thinking back, for us, it felt like vCluster is such a fundamental technology that it just kind of had to be open source. At the same time, a lot of things in our space are open source. So it seems a little bit like a requirement. To have, uh, something in the open source space. Um, so I think that there were definitely these kinds of forces. I think if we were to just launch a commercial offering only, I don't think we would have a company today. I think it's— it was very, very difficult, the sentiment in our space, to build a commercial-only company. I think, um, that was our perception, and I think I still stand by that perception. That was definitely the right move. We have been asked a lot, like, why don't you put the open source project into the CNCF, right? Hand it over to the Linux Foundation, create more independent governance from the company. I think that would go a step too far because it would create additional complexity on our end, right? There's lots of like reporting requirements, governance requirements, et cetera. And you have difficult decisions. Like, for example, you can't name your commercial product the same way as you name your open source product anymore. And initially, we actually launched a commercial product under the name Loft, and the open source we called vCosta because we were thinking if we were to sponsor the project into a foundation, we better already have a different name, otherwise it's going to be a big mess to have to rename everything. Turns out we went the exact opposite path. We had to rename everything because we realized there's not a lot of value in us putting it in Foundation. There's a lot of overhead in doing that step, but not a lot of benefit because people didn't care fairly as much as, as we thought they would. As long as you're a good kind of shepherd of the community and steering things the right direction. You have a true open source license. You show that it is okay that people just use the open source, right? Um, I think, uh, for us, having a different name in the commercial product was actually a big hindrance. So we renamed it, and we made an announcement actually at one point to just kind of test it. We've made a press release, and we only swapped out the logo and the name and created the very ugly copy of our homepage. And we announced that and the same day companies reached out who had given a demo before of the Loft product. And we're like, oh, you showed us this Loft thing. We didn't really need it. But what you shipped today, that looks like exactly what we need. This vCosta Enterprise, this vCosta Pro, we need this. And we were like, wow, you know, that subtle change makes a difference. You know, one Fortune 500 company bought the product just because we gave it a different name. They weren't interested before, now they were interested, right? So these subtle differences, yeah, that makes a lot of difference. We're very, very intentional about the strategy of like being open source, being very clear-cut, Apache 2 license, definitely clear open source, no BSL and no dual licensing. But at the same time, we also want to retain the name. And we want to make sure the open source and commercial have the same name and the transition between open source and commercial is as smooth as it can get for people. We're spending a lot of time optimizing for that.

Okay. So effectively what we're saying, the open source project needs to be, needs to have a real product thinking from branding to messaging to positioning, just, just like any commercial product then.

Like it kind of does. Yeah, 100%. Yeah, it has its own brand. People didn't like that Loft was blue and a different name than vCluster because it was orange, right? It's like they wanted the orange and they wanted the vCluster docs, right? And I think the more you're kind of integrating the two in a way that is transparent, right? You don't want to intermingle so people don't understand what is the difference and where do I jump the hurdle to being an enterprise. but you want to make it as integrated and as smooth of a transition as possible. That's at least my perspective on how to build it. Okay.

I love that. That's a strong takeaway. So if you're building an open source and you're thinking you're going to have a business out of this, so you effectively have a business module, which is foundationally starts with an open source product, but you have to think about this from a commercial lens. You can't just sort of wing it and then, you know, expect things to happen, like, that's probably going to be one of your hobby projects which will get abandoned. If you're quite serious, be serious, right? That's what you're aiming for. You're aiming for a business. Another thing which I want to bring, Lukas, is that people often think open source projects will attract free contributions and sort of going to build this out for you. So you sort of, you know, do the beginning and then community comes and they will sort of, you know, do a lot for you, right? Like free development time, let's say like this. But over 90% of users never contribute back. And this is from, this is from 2023 GitHub Octoverse report, which, which puts it very clearly. Over 90% of users are consumers, not contributors. It shows that contributors don't just happen. It actually takes real effort to get people to the space where they want, you know, to contribute. So from your perspective, Lucas, what do you think you guys did well, or when did you see contributions starting to take place? And can you sort of spot a pattern of, you know, what was the, what was the cause to lead to effect of people contributing to your repositories?

Yeah, no, we definitely have contributors from the outside, but I think most products that are driven by a single company, right, like there's the foundation industry-wide, very fundamental projects like Kubernetes itself, or like Linux, right, which is a plethora of companies coming together, making this better, right? Very independent governance. No, you can almost say no commercial path, right? Like Kubernetes itself is not being commercialized by the CNCF, right? It is obviously the foundation for a lot of commercial offerings at, you know, cloud provider sites and, you know, at us by extension, right? But these foundation projects they live off of the outside contribution, because in the inside, there's just the foundation, right? And it's not like the foundation does a lot of like product management, and, you know, these kinds of things and actually engineering effort, right? They're more like putting the frameworks in place, you know, maintaining the trademark, maintaining the governance, right? That's what a foundation is good at. When you look at single vendor projects like ours, and, you know, like a lot of open source projects, I would say the majority of open source projects is single vendor, right? Those projects, I think sometimes people have their hopes up that the community will do, you know, maybe half of the development effort. I think that's an utter misconception. That's utterly wrong, right? I would assume when you're open sourcing as a single vendor, you're still going to do, even if you're a large project, even if you're like WordPress or Terraform or any of these very, very large projects, you're still going to see the large majority of contributions from a single company and from former folks that worked at that single company potentially. Right. And I think that's, yeah, that's just a pretty natural thing to happen. But I wouldn't underestimate the contributions from the community. That are non-code contributions, right? That's part of the value that we're seeing a lot in our community. People, you know, coming with ideas, opening issues, commenting on a pull request, kind of saying like, oh, what's going on here? That would actually not work for us. Can we change it in this direction? You know, while you're building the code and while the pull request draft is out there, I think that's incredibly valuable. And you can have a much deeper discussion with somebody about the direction of the product and a certain feature because they can actually look at the code level. So it's not a superficial, hey, I'm seeing this, can we add this button here, right? It really goes much deeper. It's like, how are things built? How are things architected? How do they work under the hood? People can have much more informed ideas and suggestions because they can literally look at the code if they're interested in doing that.

Okay, so we're saying for, for a single vendor type of open source projects which reach a point, reaches a point where people want to contribute, it's not that the code contributions which will drive the product forward or fix the bugs or fix, you know, security issues and everything else. It's actually the intangibles, which is the conversations you're having and the suggestions they're giving of effectively expressing their pain points, you know, driving your roadmap. That's where a lot of value is. And we should sort of put this under the umbrella of you receiving contributions from, from the community, right?

100%. I think we have about like 100 or so outside contributors and a lot of these contributions are smaller changes, right? There are a couple of lines here. A couple of lines there, there may be a contribution to the docs even, right? Just switching out a sentence or clarifying something or adding something, right? I do think there's still a lot of value in this. You kind of are like, you know, potentially thinking, hey, why does that even matter at all, right? I think it does matter because these people feel even more engaged with the product. So they feel part of this community, they feel part of the project, right? But they also contributed to the product directly. And I think even if it's just a small change, they're proud of that. They're proud of these couple of lines that they added, right? So it is very important to encourage people to still do that, although there should not be the expectation of anyone in the community contributing major features. I think if they come with major ideas, that's also something they can be proud of, right? If they're the ones that opened the issue and suggested something great that ultimately got shipped, We're trying to recognize people in the release notes, for example, in those kinds of ways to really say, hey, thanks for contributing. Thanks for suggesting this idea. Right? Sometimes we even ask folks after they, you know, we see them go to a conference and talk about how they use the open source project and be like, hey, let's do a webinar together and show more people what you've done. Right? And, you know, we've seen you have a talk here. Let's you know, help you promote it on social media because obviously it's great for us as a company if people see how the product is used. But it's also great for these individuals to show off what they've been doing to the broader community.

I love that. When you were mentioning the contributions being small and just sort of like, you know, one-liners, I was thinking about myself and I contributed a lot in my coding days, but it always was like, you know, small fixes, you know, a couple of lines improving maybe logic a little bit. It was never big things. And of course, I'm not saying like I represent, you know, the whole thinking pattern. You know, maybe people love to come to open source projects and go like, hey, I'm going to build a whole shebang feature for you. You know, here's 4 files, 7 files, you know, and 400 lines of code. But it does seem very unlikely. So it does seem that you're probably going to get suggestions on bigger things to get built, which is great. That's, that's a contribution you got for free. Maybe it's a brilliant idea which you didn't thought about. So you're going to build something bigger and then people will sort of try to make this bigger, better with the simple small code change type of contributions. And then I was thinking like, okay, what did I got pushed to contribute? Like, why did I started contributing? And what came to my mind is that I got onboarded into, you know, open source project to the point where changing them became difficult, too timely and too expensive to drive my projects. And they had something which they lacked, like I needed to build something or I needed to fix that feature. And because that open source project was driving so much of a product, I didn't want to that open source and I was like, hey, can you build that for me? Because I need this, you know, to grow my own thing or like, hey, you got this issue over there which is, you know, right now causing me issue in my product. So I'm going to give you a fix for that, right? So that was my sort of driving forces, uh, uh, becoming a contributor. Contributor. But otherwise, like, you, you got shit to do, right? You know, you're doing your own thing, right? Like, what?

100%. Yeah.

Why would you start suddenly contributing to open source? Yeah, maybe you want to build up your CV, right? Yeah, yeah.

Just 2 weeks ago, somebody, uh, reached out to us on, on GitHub, opened an issue and said like, yeah, I really want to, uh, you know, hook up an external etcd, and a couple of these config options are not exposed that I really need to make this work. Um, and then he opened a pull request and he emphasized, this is really important to me because I have 1,000 virtual clusters running, and without this change, it would be a lot of work to patch these afterwards. It would be so much easier to have a config option and be able to roll it out. And we're like, wow, there is somebody that we've never heard of that has 1,000 virtual clusters already running in production, is very happy with the open source product so far. And now they want to make this change, right? Because it would make their life so much easier. Those are the triggers for contribution, right? But it took that person, you know, 2 or 3 years working, you know, on, on, on their environment and on their actual work to get to the point to now make this small contribution. And we're very thankful for these contributors. So, you know, I reached out and sent him a message and said like, hey, you know, thanks for this, this pull request. That's awesome. By the way, what are you doing with 1,000 virtual clusters, right? And then these natural conversations start happening and you're just kind of learning more about the use cases. And I think part of the open source value proposition is also that people can do that, right? They can just hit the ground running without you as a company ever knowing about them or being involved until a point where they potentially need you, right? Yeah, I think it definitely shows the power of of your open source project if this, this is the type of thing that's possible.

What's the most important thing to get them running easily? You know, no learning curve or very low learning curve. You know, everything is sort of just giving on a plate, just go here, you know, and, and just, just use it, you know, just have a very good sort of adoption, right? So documentation, of course, you know, instantly comes to mind, some type of like a user onboarding process. But from your experience, and maybe you did that mistake with, you know, earlier open source projects, it's like, what are the key things, or what are the musts to actually make sure that your open source is getting adopted quite easily, considering you actually get, you know, people coming to you in the first place?

Yeah, it starts with a good README, to be honest, because that's really like— nobody goes to your homepage, they go to your README first and foremost. Because when— just think about it, somebody is happy with your open source project, there's a very, very high likelihood if they write a blog post about it or they mention it on Reddit or something like that, they're just going to link to GitHub. So people are not going to end up at your homepage trying to understand what the product does. They're trying to do that on the README.

Yeah.

So you need to really make sure to treat your README just like you do with your homepage. You've got to continuously work on it. You've got to make sure it's in great shape. It points people to the right places. It's a starting point, right? It's a one-pager, right? You want to give some concise information. You want to make the case for why they should try this. You want to have a demo. I think we have a little bit of a demo video embedded, right, to show them how it works. And yeah, documentation is probably the second most important piece. As you mentioned, the Getting Started Guide, right? You want people to hit the ground running quickly. And again, then you want people to have a very smooth transition to the enterprise offering if they need to explore it. So for us, for example, to fire up vCluster Enterprise, you run a single CLI command and it starts a 14-day trial. There's a free tier afterwards that you can enter into, but within 14 days you can try out everything in the commercial offering. Without even ever talking to us. Just because you see it in the docs, you want to enable this feature, it prompts you, "Hey, run this command to sign up for the enterprise." It's a very, very light process to get started. Of course, there are certain environments, like we've seen people try it in air-gapped environments and government data centers and those kinds of things. And then yes, they do have to reach out to us because that those specific environments don't allow network connectivity to our license server. But those are the special cases. For most folks trying it out on their laptop, in their Google Cloud account or AWS, right? They should be able to just spin things up and try things out. I think that's really important as well.

How much time do you spend on documentation? How does the process look like? For open source that you make sure that your documentation is on point? You know, I've seen from people doing this manually, having an actual tech writer, so documentation writers, to, you know, to doing things like adding things in the code which generates documentation automatically. But from your approach, like when you treat your open source, how do you make sure your documentation is really on point to get that adoption happening easily?

It's incredibly important. When I started the company with my co-founder Fabian, we were both coding in the early days. I, you know, was always the one that was more responsible for the documentation. And as I shifted out of coding and being more of the CEO for the longest amount of time, I still maintained the documentation. And that's because documentation is so important to the company. We did make the mistake of underestimating documentation for a commercial product. And actually, it was lagging behind the open source for the longest amount of time. Because the company grew, you know, more and more people were interested, the team grew, right. And I just kind of lost track of building the documentation for the enterprise. And that, you know, was a mistake. And we saw that very, very clearly by an increased amount of support requests. Especially for folks that are interested in the commercial product, right? So it should actually be, be better. But it kind of shows you that intuitively when you're working on open source, documentation is first and foremost for you. So we were always optimizing the documentation for the open source piece. Today we have 2 people entirely focused full time on our docs, and that includes writing the docs. Like one of them is purely focused on writing. The other one, that's writing, but also a lot of stuff around docs, like you mentioned, automations, right? Release pipelines, pushing out new versions, versioning the docs, like those kinds of things. Having— we, for example, have snippets in our docs that are embeddable in different places in the docs that come straight from the config files and are completely generated. So we're always up to date, right? It's those kinds of things that are really important to our community members.

Yeah. I mean, yeah, it's like, how else would you expect adoption to take place if people get stuck and they don't know how to get unstuck? It's like such a no-brainer. But at the same time, sometimes you use the tools and you just want to shoot yourself. You're like, I don't have time. Like, why I'm figuring this out? Why it's just not written how to get that done? I get that, but everybody overlooks that. In exchange for the building.

There can always be more, to be clear, right? Like, we spend a lot of time on docs, as I said, like just 2 people full-time focusing just on this. Yeah, but I bet there's probably 10 times more things we could already do, right? It's just, uh, it is a little bit of a bottomless pit. And as your product grows and you're shipping more features, there's just more and more things you could document and special cases that come up and use case-specific documentations. And then you look at things like integrations and oh my gosh, people are trying to use vCluster with all kinds of tools. So it's like a thousand tools on the CNCF landscape that people are trying to hook it up with. That's going to be a never-ending task for, for us. And that's why it is so important to have the sustainable business model behind the company. Because we need to be able to afford this, right? It is better for everybody if there is a company with a sustainable revenue stream who can, you know, invest in these things. Yeah, because there is an ROI to doing that, right? There's faster adoption, there's, you know, less support requests, and like what a non-open source company would look at as well, right? But, you know, for us, We're very clear with our community as well on, hey, we are building a commercial offering. We are a business. You know, we need to generate revenue, but this will benefit you as well as an open source member. Sometimes I talk to folks and tell them, you can help make us successful and that will be beneficial for you because what would happen if we went out of business next year? Would that be detrimental to what you're working on? And if the answer is yes, why don't you help us, you know, by buying the commercial offering, by, you know, looking into that option? And I get it, not everybody, you know, there's always a small fraction of folks that go to the enterprise offering, but maybe there's other things you can do, right? Maybe you can go to a local meetup and talk about how you're using the open source project, and that may lead to, you know, 5 people starting with it, and one of them may have an interest in the enterprise offering, right? It is that kind of logical reasoning. And I think not hiding the fact that we are building a business and that's actually beneficial for everybody that we're building a business. I think that's really important as well, in my opinion.

I love that positioning. Yeah, it's no-brainer. Your success will be equal other people's successes, which they build their projects upon your open source product. So you getting bigger, it's just gonna benefit them as well. So let's close with this one, uh, Lukas. If you would give an advice to someone who's like, I'm gonna build an open source business, how would that advice sound?

Yeah, find the right balance between open source and commercial. Understand the reasoning why you're open sourcing it. If this is a marketing hack for you, don't do it. If you're looking for free engineering capacity, that's not the right motivation.

You're not going to get it.

Exactly. Really understand what your motivation is. What are you trying to get out of there? And speak to people who have built open source businesses and who maintain open source projects and ask them how it really is. And ideally, if you can ask people that also have, just like I did, made a lot of mistakes in this space because it's always easy to look at, you know, a story like MongoDB or something like that, right? And say, oh, look at how that blew up and here's the revenue chart, once they launched Atlas, I'm seeing these kinds of posts on LinkedIn a lot, right? Where people are like, oh, and here's— Exactly. And like, you are only— it's a little bit of a survivorship bias as well, right? You're only seeing the success stories. You're not seeing the thousands of failure stories and pivots and regrets that people have. And, you know, maybe listen to a podcast like this one and many others. Where, where folks openly talk about, you know, what they should have done differently and how they would approach things today. I think, yeah, overall, do your research on open source and be sure what you're getting into. I think that, that would be my biggest recommendation.

Yeah, that's great advice, Lukas. And talking about people who know how to do open source, which is you, tell us how people can find you, how they can know more about Loft Labs, and Tell us what's next for Loft Labs. What, like, what are you working right now? What you're excited about right now?

Yeah, we are working on a really, really exciting new product actually that is going to work incredibly well in combination with vCluster. We're not virtualizing Kubernetes only. We're trying to virtualize the entire cloud-native stack. And part of that means venturing in new areas and seeing, oh, can we virtualize this piece of the stack? Right? So we're announcing something really, really exciting. I can't talk too much about it quite yet. But a lot of engineering effort has been going into this. This is actually our first, you know, purely proprietary product. So we'll see how that goes. This time, it is not going to have an open source component. We'll see how that goes. And if we're changing our minds on this in a year from now, but But for now, this is the path we're taking it. And I'm kind of curious to see how that goes. In terms of how to reach out, obviously you find vCluster on vcluster.com. You find it on GitHub. You can join us on Slack. Just go to slack.vcluster.com. And you find me on obviously the vCluster Slack community. Just DM me, as I said, right? The path is pretty short. But you can also obviously find me on LinkedIn and any of the other social channels. Just connect with me if you have any questions or if this is a topic that is of interest to you.

Thanks, Lukas. And of course, everything is in the show notes. If you scroll down, you'll see all the links. So if you're listening to this right now and you try to figure out how to make an open source project sustainable or just want to build something that lasts, We hope we gave you something to think about over here. If you enjoyed the episode, be sure to subscribe, share it with your founder friend, and send us your questions at masteringtechgrow.com. Lucas, thanks again for being here. This was brilliant. And as always, until the next time, stay safe and see you online.