Today, Madrona Partner Aseem Datar hosts Tigera CEO Ratan Tipirneni. Tigera is in the business of preventing and detecting security breaches in cloud-native applications, and its open-source offering Calico is one of the most widely adopted container networking and security solutions out there. Aseem and Ratan dive into whether or not you should open source, the three business models founders should evaluate when thinking about commercializing an open-source project, how to compete with free, how product-led growth can really kickstart your business compared to traditional go-to-market, and so much more.
This transcript was automatically generated and edited for clarity.
Aseem: I’m incredibly excited today to talk about open-source in the context of one of our portfolio companies, and I’m excited to have the CEO of Tigera, Ratan, with me. So, Ratan, very excited to have you and a warm welcome. Would love to maybe just get a little bit of your background in your own words and tell us how you got started with Tigera.
Ratan: Thank you, Aseem. So first, I have to say I’m very excited to be here. Thank you for the opportunity. My background is — I’m a software entrepreneur. I’ve been working in the Valley for a while, and that’s what I enjoy doing: building businesses and software. At Tigera, we are in the business of preventing, detecting, and mitigating breaches in cloud-native applications. We started several years ago with some really smart engineers and architects who got together and decided to solve some pretty tricky and gnarly problems around container networking and container security. That was the company’s genesis, and since then, we’ve been on a really exciting ride.
Aseem: This is a common pattern we see today — really smart people hunkering down on a potential challenge they see in the ecosystem and going after it. The question that comes to my mind is how should founders, engineers, and those seeing these set of problems think about it in the open-source context? When do you start building something, when you decide whether to open-source it or not, like how do you think about real demand, and what are some of the early signals that folks should watch out for as they’re thinking about going down the open-source path?
Ratan: The best way to get started is to get out of the starting gate, build something, put it out there, and get some conversations going with the community. The conversations are super critical to building that sense of camaraderie within the community and, more importantly, to get some feedback and participation from the community where they feel like the community has a voice in terms of providing feedback, contributions, engaging the community, and really seeing where that goes and letting the community actually steer their project. That’s probably the best way to get started.
Aseem: Are there any specific metrics to look at? Like people track all sorts of things. They track stars, they track the number of contributors, and they talk about how many repos are getting created. What are some concrete metrics to sort of get behind and understand if there’s real demand?
Ratan: Sure. So, I’d say there are probably quantitative and qualitative metrics. In terms of the quantitative metrics, I heard you say the stars — this is a personal opinion — but it’s a vanity metric. I’ve literally seen that being gamed, where I saw one of the founders at KubeCon offer to hand out some gifts for users to go liking some stars.
But signs of daily usage of your software are probably one of the best metrics and most objective metrics you can get. Remember that the metrics are as much for you, as they are to help you build some credibility in the community. You really need to know that someone’s actually using it and getting some value from that.
In terms of the qualitative stuff, it is equally important to have the dialogue and get some feedback from users on how they’re feeling about it. That could give you plenty of clues on perhaps what you may want to build in open-source or perhaps what you want to build in your commercial products. But honestly, just being curious about it and engaging with users at every single opportunity is probably the easiest and fastest way to get some of the qualitative feedback.
Aseem: Continuing down the path of commercializing an open-source project, Ratan, what’s the point you arrive at when you really decide, “Hey, how do I commercialize that?” Is there a stage gate that one should think about? So, talk to us a little bit about that journey and how Tigera got to that stage.
Ratan: There are two parts to my response to that question. First is when you start to think about it, and second is when you actually pull the trigger on that.
When you start to think about it is — you start to think about it on day one, right? Even when you’re launching the open-source, you have to be thinking about your commercial offer also. It doesn’t mean that you’ll launch the commercial offer, and you should not launch it on day one. But you certainly have to be thinking about it because any decisions you make about product functionality and packaging in open-source will have an implication on your commercial product strategy. So you’ve got to do that right away.
The second part of the response is when you actually pull the trigger and when you start to launch a commercial product or monetize it, I’d say you have to wait until you have some minimum critical mass in your community where you feel like there’s enough momentum where you hit escape velocity before you actually think about launching and monetizing your commercial product.
The other interesting concept, at least my mental model, is you have to be thinking about building two separate and distinct operations or businesses from day one. You have to think about building that momentum in open-source, the open-source project, the community, the users, the value they get, the accelerators, and all that. That’s one part of the operation. You also have to simultaneously think about how you actually build a commercial business around that. From a timing, it’s difficult, but you have to be doing both in parallel because if you over-index on any one of them, it may not be an optimal outcome for the team and for the company.
Aseem: Pulling on that thread a little bit, at what point would you say a company is not ready to transition over? At what point do you say, “Hey, you’re not there yet, let’s not turn commercialization on?” Is there a moment like that, or is there a gate that you absolutely must cross, which could be a binary one? Or is this more art and a science to go figure out like, “Hey, do we turn commercialization or revenue on?”
Ratan: One simple heuristic I’ll offer is that if you’re struggling to build community and are not seeing acceleration in the number of users month-over-month, you really have to question whether this model is even worth pursuing. That’s a moment of truth where one may have aspirations of building an open-source-based company and a go-to-market model based on that, but if you aren’t able to get acceleration in the open-source adoption, perhaps it’s not even feasible, and maybe it’s time to go try something else. Be a little bit premature to launch a commercial product to layer on top of the open-source product.
A good time to be thinking about launching a commercial product or figuring out how to monetize your open-source is if you hit a point where you feel like the open-source community is growing. Also, if there’s some word of mouth and a level of acceleration, you see month-over-month in the open-source usage.
Aseem: Shifting gears to a topic relevant to the commercialization chasm is really around business models. What are some of the business models? What are some of the considerations that one must make to transition over to commercialization, especially in the open-source world, that the founder needs to be aware of? How should they think about monetizing?
Ratan: From a historical perspective, there have been three business models which have evolved over time. The first generation of business models in open-source was you give everything away for free, and then you try to monetize it through commercial support. There’s been one company that has done it extremely well, but it’s yet to be replicated since then. I’m not quite sure I would recommend that to anyone at this point. Although I do see some companies in open-source make the mistake of putting everything in the open-source bucket, and, at that point, they have no other option but to try to monetize it through commercial support. That’s pretty dangerous.
I’ve seen someone in our ecosystem do that recently, and that’s a one-way street where you’re eager to build community and momentum. You dump everything into open-source because you want to try and do one better than the other companies in the ecosystem, but you can’t recover from that. Your only option is providing technical support, and it’s not a very defensible way of building a great business. Even if you succeed initially, what you’ll end up seeing is you’ll end up seeing quite a bit of churn in later years. You just will not get that cumulative momentum.
Aseem: How do you compete with free, and how should you think about competing with free? Or is there something where you compete with free that’s viable?
Ratan: I think the broader uber issue behind your question is, “Hey, how is a company able to do this for free?” I would offer to say it goes back to capital markets. Suppose the capital markets are throwing money at companies, and there’s an endless supply of capital. In that case, that is when we saw a lot of these company adopt this approach of putting everything into open-source. Giving it away for free with no accountability, and some of them maybe had unicorn status.
It’s safe to say that those days are past, and we are back to fundamentals. Even if a company does something like that, it will only sustain for a short time. Trying to compete with free by offering more free stuff is a losing battle.
The other part is it also depends on the quality of customers you’re trying to see because the really high-quality logos that you’re trying to build a business on — they actually want to pay you money. They want to see you successful because they understand that open-source companies, they can’t really abuse the system. If they do that, it’s not sustainable for them, and they’re going to end up losing in the long term.
Even if you’re competing for free, I would say that you want to go find customers like that where, even though they may have a choice of something free versus someone else, an open-source company that’s offering a paid version, they know that the right long-term option is the paid version because that’s the only sustainable solution.
Aseem: Absolutely. I think that’s very helpful. Let’s get back on track. I think we talked about the first business model. I know you had a couple of others, so maybe let’s just continue on that path.
Ratan: The second business model, which was tried about a decade ago, was being able to layer on a commercial product on top of open-source. Essentially, you’re selling something open-source, and you have a project that you offer. Then you provide some additional commercial features on top of that that a customer can buy. Several companies have done a stellar job monetizing and using that approach. If I were to pick a few names, GitLab did a brilliant job. MongoDB built a very successful business model using that. I didn’t give you an example of the first generation, but Red Hat is the most obvious example of the first generation of those business models we talked about.
The third generation, which we have seen more recently and has had a lot of success, is offering a SaaS version to be able to offer a service as a commercial product. The best example in recent history that certainly had a big impact on our decisions was Databricks, where they started at the second-generation business model and then they switched to the third-generation business model I talked about and started to offer a service. They’ve seen really, really good success.
Tobany entrepreneurs who starting today, jump to the third generation right away out of the gate. It’s difficult to switch from the second-generation to the third-generation business model I described. If I were starting today, I’d switch directly to a SaaS model because it gives you so many levers and a better ability to experiment rapidly and really sets you up for success if you’ve got this motion of leading with open-source to create a wedge and following through with the SaaS offer.
Aseem: That’s very well articulated, and I’m sure a piece of gold right there for some of our founders as they think through commercializing an open-source project and which model to go back to. I think there’s a pretty obvious one in our discussion, but not a one-size-fits-all kind of thing.
What surprised you as you were building Tigera and going through the motions about commercialization, signing enterprise customers, maintaining the open-source, and working with partners? What’s the one thing that has been a little bit like, “Gosh, didn’t expect that?”
Ratan: There’s perhaps a little bit of a fallacy and assumption about open-source because it’s free that you assume that users will adopt it. That’s just something to rethink.
Another way of saying it is, what is the cost to a user to adopt your software, to install it, to deploy it, to derive value from it, to maintain it, to operate it? You got to think about that entire life cycle. What is the cost involved? And if that’s not a good equation, the odds of you building a great community that is and an adoption base that’s growing rapidly, the odds of that are going to be pretty low.
The kind of rigor any entrepreneur would apply to building a commercial business is you have to apply the same level of rigor to your open-source community. Just because you give it for free, you don’t get a free pass on all those other things.
What makes it challenging is that you’re going to do all that in a very cost-effective manner because, to state the obvious, you’re not getting paid for any of that stuff. Unless you’ve got an incredible amount of leverage in your operating model to accomplish all those things, it’s going to be very difficult to pull off.
Aseem: Well, that’s certainly very true, at least from the perspective of surprises that you want to avoid.
Tell us a little bit about getting scale. I think we all think about new motions around PLG, self-serve channel. Like from an open-source perspective, is there one go-to-market type that works better than the others? What’s your perspective on that?
Ratan: It depends on the space you’re working in, so I’d be very reticent to generalize a single playbook that would work for everyone. It depends on where you are in the stack or what domain you work in. The models work very differently, but since it touched upon PLG, let me talk about that.
I’m a big proponent and a big fan of PLG for a few different reasons. The first is, fundamentally the buying behavior compared to even five years ago has changed dramatically where most users really want to actually try out your product, use it, and test it in production before they decide to make a long-term commitment to that. The best way to make that happen is to offer them a free tier of product that they can activate, start to use, derive some value, and evangelize to others. So that’s the first thing.
The second aspect of buying behavior I feel that’s changed dramatically is that the traditional purchasing model of top-down, with the CIOs making all the decisions, has shifted quite a bit. The power is now in the hands of the people in the trenches: the DevOps engineers, the security engineers, the DevSecOps engineers. They are the first to have an intimate understanding of the challenges, and they are the ones out there looking and shopping for tools. They have a very tight-knit community of peers who they talk to to get information. They’re certainly not talking to famous analysts to get recommendations for any of the tools they use, and there’s a disproportionately large amount of power in the hands of those people.
And the third is a lot of these buyers, the new generation buyers, the DevOps engineers, DevSecOps engineers, security engineers, they would rather not talk to anyone. They would rather go self-serve, educate themselves on the product, and enjoy the process of getting to know new tools. They enjoy the process of going through tutorials, reading stuff, downloading stuff, playing with it, and using it. For all those reasons, PLG or product-led growth is a really natural motion that aligns with that buying behavior.
Now, that’s easy to say. It’s extremely hard to operationalize the PLG model. It is not incrementally harder. It is harder by a few orders of magnitude compared to a traditional go-to-market model. The reason is you may have a lot of warts in your go-to-market model that you can hide using people. In a PLG model, it’s all out there. There’s no place to hide, and so it’s extraordinarily difficult to do that. If you can pull it off, some of the fastest-growing businesses that we have seen — that’s the one common denominator. They’re all using a PLG motion, and if you actually nail that part, the operational part, the business is off to the races.
Aseem: Two interesting things to sort of draw out from that. One is this notion of — so much of PLG is of the essence of how open-source started. It’s community-led growth because you’re letting the community tell you more about what works and what’s not working in the product.
The second thing is in a traditional go-to-market, your limit or your bottleneck is going to be people. In a PLG type of motion, there is no physical bottleneck that you’re going to hit. For better or worse, I think that’s where the fastest growth is going to come from, or that’s where the fastest learning is going to come from.
Ratan: Absolutely. There’s a tremendous amount of learning. I’d flip it around and say there is no single way to do PLG. You have to think about it as a process, a process of learning, and you’re learning through some rapid experimentation. The only playbook is how rapidly you can learn with a series of small experiments, so the solution may manifest slightly differently for each company.
Aseem: So much of what you’re saying is resonating with signals that we see across the board. What is something you wish you knew going into all of this? Is there a fun story there? I always think that there are nuggets of brilliance that come out of this question, so I have to ask you that.
Ratan: You know, that’s an interesting question, so my response may not be what you’re looking for, Aseem. Being an entrepreneur, you have to be slightly insane to be an entrepreneur. So, let me just state that it’s not a path for rational people.
Aseem: So I am taking notes, Ratan.
Ratan: One of the reasons I think people like me chose this path is because what’s interesting on a day-to-day basis and the breadth of challenges that you have to deal with that keep you really in a state of flow and engagement. It’s been a lot of fun decoding everything that we have done here over the last several years. I don’t wake up any day and say, “Hey, I wish I knew this before.” Because if I knew it before, it wouldn’t be fun, and, honestly, I won’t be doing it.
Aseem: I am taking away a “no regrets” learning there, which is fascinating. Ratan, any parting thoughts or advice for founders who are playing in this space, who are thinking about open-source, who are along this journey of decoding, as you call it, like the challenges they’re faced with?
Ratan: Here are a few things I’ll share because we are seeing some of that play out in the ecosystem that we compete in.
The single most important thing is to stick to fundamentals. What I mean by fundamentals is to be clear about who your end-users are, what their pain points are, and serving them high-integrity manner, and everything else will take care of itself. And try to misrepresent things either to users or customers in the short term — it may feel like it’ll help some companies, but it really backfires in a big way in the long term.
For anyone trying to pursue open-source, my advice is to reiterate what I said earlier: they’re two businesses or two operations, so you’re building in parallel, and you don’t get bonus points for nailing one of them. You’ve got to nail both of them together. From a timing perspective, you’ve got to be thinking about both simultaneously.
The third part, which may sound a little redundant, but it is worth stating, is to not over-index on one aspect, especially the open-source. In the early days, especially if you’re trying to come from behind, we are seeing someone in our ecosystem do that where they’re trying to come from behind, and you throw everything into the open-source bucket, and it feels really good for a while. It’s like eating sugar; it’s going to feel really good for a while, and then you pay a heavy price afterward because you don’t really have a repeatable monetization strategy.
Other than that, it’s a fantastic time to experiment with this go-to-market model. If you are, I’d say jump to the third-generation business model, which is to take your open-source, layer it on with a SaaS service, and if you have a strong stomach, try PLG with it.
Aseem: That’s awesome. I think you summed it up really well. Ratan, thank you so much. I’m sure that our listeners will enjoy every moment of this conversation, and so much to learn from this. I’m taking away a few keywords that I will repeat: insane, have the appetite for having too much sugar, and don’t worry about commercializing an open-source project in the sense of being obsessed with it.
Ratan: Thanks, Aseem. It has been fun. I appreciate the opportunity. Thank you.
Coral: Thank you for listening to this week’s episode of Founded & Funded. We’d love you to rate and review us wherever you get your podcasts. Thanks again for listening, and tune in a couple of weeks for our next episode of Founded & Funded, where we’ll get to know Madrona Managing Director Tim Porter in one of our investor spotlights!