Business Breakdowns
· Alan Tu
[00:00:00] S1: There are a lot of examples of successful open source projects, and that's one of the magical things of open source is that it does enable a level of adoption. In the consumer world, we talk about capturing magic in a bottle. In the enterprise world and with technology, open source is a really good way of getting just massive amounts of awareness, mind share, and adoption. There are a lot of examples of successful open source technologies, but there are actually not very many examples of successful businesses that have been built on top of open source. And a lot has been made about, Red Hat was one of the first companies that built a business on top of Linux, but the reality is that it's actually one of the hardest things to do. You have to hit two home runs. This is actually one of the ways that Ali explains it: is you need to hit the first home run, which is to develop an open source technology that gets its mainstream adoption. But what a lot of folks don't think about is the second home run, which is, how do you actually build a business on top of it? And part of the problem is that the open source technology ends up becoming one of the business's main competitors because anyone can get the product for free, anyone, including your customers, but also including competitors. They can also leverage that technology, and actually, those competitors that have more distribution, more customer relationships, can actually do a better job of monetizing that open source technology. This is where again, that coming from academia, I think really helped inform the strategy for Databricks, which is the benefit of not being immersed in the commercial market is that you don't have the pre-existing notions of what you should or should not do when it comes to building a business on top of open source. Because again, the biggest example before that was Red Hat, which basically provided services and support for Linux, but that was the main thing. But because the Databricks team wasn't really aware of the precedence, they thought about things in a very first principles way. And when you think about this challenge of, how do you monetize something where there's a free alternative? It's actually a simple answer, and the answer is: you need to create a better product that is worth paying for.
· Matt Reustle, Alan Tu
[00:00:00] S0: Simple answer, maybe not simple execution. [00:00:00] S1: Totally. And part of the reason why it's not a simple execution is that if you've built your brand and gotten a lot of positive feedback for successfully creating the open source technology, it can be weird to then say, "I'm actually going to create a competing product, and I'm not going to put all of the bells and whistles into that open source technology." And for a lot of folks, that creates a lot of tension. You've got a lot of folks in the community that are like, "How could you do that?" There's almost a feeling of betrayal. When you're successful with open source, it can almost be a curse because you become very popular, you're viewed by technologists as someone who's brought this great thing into the world, and then all of a sudden, you need to be willing to be a villain. I think a lot of people have trouble making that jump. But I think again, in the case of Databricks, they just very much realized that there's no way we can compete unless we have differentiation. So, creating that differentiation was just a very important concept. And so, one of the things they did with Databricks, the company, and we can also talk about how they chose the name Databricks, was that they created a new implementation of Spark that was completely proprietary that had a lot more performance and things that enterprises want: reliability, scalability, etc. And they were just very unabashed about the fact that if you want to use this new implementation, you would have to pay for it.
· Matt Reustle
[00:00:00] S0: Is that comparable to the free tier of an LLM versus the pro tier of an LLM today? Just in terms of, you can feel the difference, and not everybody will have used the different tiers, but I'm trying to grasp the differentiation, to your point, needs to be there. It's very easy to describe it when you're signing up for a subscription to a website and it's like, "You get three free articles, but then after that, you have access to our proprietary database for the subscription cost." What comparison would you make, if there is an analogy, for the difference?
· Alan Tu
[00:00:00] S1: I actually think that analogy is pretty accurate, but there are nuances to that. As a consumer, we are used to this construct of there's a freemium version and then we pay for the premium version. And I think that decision about what goes into the premium version is where the nuance is. Again, going back to enterprise, the typical traditional wisdom is, "Oh, well the average developer that's working in their garage, we like that they can use this technology for free. We really want to monetize the enterprises, and so why don't we monetize the enterprise features?" Things like single sign-on and again, governance and security. That actually makes sense. But the reality is that while it is true that enterprises will pay for some of those additional features, how much will they pay for those additional features? And at the end of the day, those additional features are not the core product. So, going back to your example of the LLM, there are different ways of deciding how to paywall product. I think the analogy here would be to say it's, for certain freemium products, you can use it 10 times, but then the 11th time you have to pay. Or in other situations, there's extra features that you have to pay for, and then you have to go to the premium tier. The closest analogy in the case of Databricks would be actually the better model that is smarter and will give you better answers, you do have to pay for. And so, I actually think that comparison is not a bad one when you think about it through the lens of that core performance of the model, not just these ancillary things that you're paying for.
· Matt Reustle
[00:00:00] S0: That differentiation of, it's not added features, the core thing is actually higher quality, is a meaningful differentiator. And this is something, to your point, that every business has to think through. And I talked to many people who want to roll out a premium tier of something, and extra features are just not that valuable and nobody's going to pay for it. I did want to touch on Databricks, the meaning. What's the origin story to the name?
· Alan Tu
[00:00:00] S1: To draw a contrast, there are a lot of examples of companies that have been formed on the back of a successful open source technology that have basically named their companies the technology. So, whether it's Docker, was a startup that was built to commercialize Docker the technology, you can think of MongoDB is another example. In the case of Databricks, the analogous thing to do would have been to name the company Spark. The reality is that there are a lot of benefits to that because again, Spark was a very well appreciated name. The brand and awareness that Databricks, the company, would have gotten from coming out with the name Spark would have been very beneficial, actually. But the reason why they went with Databricks is because from day one, they always felt like it was going to be more than just Spark. Databricks, the way they thought about it, was that there were going to be many, many bricks that you could all be used to apply around this broader problem around data. A simple idea, but underneath the decision to name it Databricks as opposed to Spark is this reflection of this long-termism of thinking about, what is actually going to set us up to become much more over time.