Welcome to Founded & Funded, my name is Coral Garnick Ducken, I’m the digital editor here at Madrona. This week, Madrona Partner Jon Turow brings us a story about a great partnership forming between two people — who had never even met — when they each find themselves on a mission to focus on what it is they do best. You’ll hear from Hannes Mühleisen, creator of the DuckDB open-source project, and Jordan Tigani, the database leader who saw an opportunity to commercialize it by creating MotherDuck. They share the lightning-bolt moment that led to one of them flying half way around the world to meet – how does this happen, and how do they set their partnership up to be the foundation of a really big business while still supporting the open-source community? Jon gets into all of this and so much more.
MotherDuck and DuckDB have become integral for students of the modern data stack, but this story of inspiration, partnership, and execution is something that builders everywhere can learn from. So, with that, I’ll hand it over to Jon to take it away.
This transcript was automatically generated and edited for clarity.
Jon: Here’s Jon Turow. I’m a partner at Madrona. And I’m just really excited to be here together with my good friends, Jordan Tigani and Hannes Mühleisen. Thanks so much for joining, guys.
Jordan: Great to have the chat with you, Jon.
Hannes: Yeah. great to be here. Thank you.
Jon: So, I want to get into the genesis of DuckDB and MotherDuck. Jordan, you’re the founder and CEO of MotherDuck. Can you tell us what MotherDuck is?
Jordan: Sure. MotherDuck a serverless data analytics system based on DuckDB. You know, we’re a small startup company. We first got our start or even starting to think about it in April of 2022. And were funded by Madrona, among others, a few months afterwars.
Jon: Hannes, can you talk about what is DuckDB? What was the genesis of it, and sort of your part of that story?
Hannes: Sure, I’m happy to. So what is DuckDB? DuckDB is a database management system — a SQL engine. It is special because it is an in-process database engine, which means it’s running inside some other process. It is an open-source project. We have been working on this for the last five years or so. And it’s the creation of myself together with Mark Raasveldt, who was my Ph.D. student at the time. From this word Ph.D. student, you can already deduce that this was in some sort of academic environment. And at the time, I was a senior scientist at the Dutch National Research Lab for mathematics and computer science, the CWI in Amsterdam, which is famous for being the place where Python was invented, among other things. And there, I was in a group called Database Architectures, which has been working for many years on analytical data management engines. For example, they kind of pioneered columnar data representation for database architectures. They pioneered vectorized query execution. It’s been quite influential, let’s say. That’s nothing to do with me. I joined after all these things happened. But I did notice that while there were all these great ideas and great concepts flying around there was really that much in terms of real-world impact. And as a result, people were kind of using, let’s say, not the state of the art, right? I found that a bit sad. So we started talking to practitioners, figuring out where the problems were. And it turned out that this management of setting up data management systems, of transferring data back and forth, was really a concern. And it really didn’t matter how fast the joint algorithm was if your client protocol is horrible. That is, I think, one of the basic insights. People have written hundreds of research papers on joint algorithm, but nobody has ever thought about the end-to-end here. And so, we decided that we’re going to change that, and we’re going to actually look at the end to end and we’re going to bring the state of the art in research to a broad audience. And so we started implementing DuckDB back in 2018, I believe. It’s a bit insanity to say, okay, we are two people going to write a database management system. Like, these are things that usually hundreds of people work on for 10 years. And we have been warned. But I think one of my character traits is to kind of leap without looking sometimes. And that’s definitely an instance of this where I was leaping without looking. You could also say the companies case of leaping without looking, but we can talk about that later.
Jon: So Hannes, one of the things that you’ve shared with me over the time that we’ve known each other is even in those early days, you started to get customer feedback about using DuckDB and how to get it to work. And without leading the witness too much. There was an example of getting this thing to run in an academic compute environment with just all the things that are locked down by IT and the implications of that. Can you share that and how it impacted DuckDB?
Hannes: Yeah, absolutely. So part of the job of a database researcher is to try other people’s stuff. Like somebody writes a paper, maybe they ship some code. In an ideal circumstance, you get to try it. It’s very exciting. But it’s very difficult. Usually. That’s a code that is not meant to be run on like anything else. And then if you are, as you said, confronted with the sort of, absolutely lockdown environment of an ancient Fedora version where you don’t have root and the admin has like a 3-day turnaround, and you just want to try something and see if it’s like not worthless. It’s just completely impossible. And over the years, it built two things. One is an uncanny ability to run things without Docker. So – – prefix is my friend. And the other is, of course, a deep hatred for dependencies. And I think we underestimate the real-world cost of dependencies. It’s something that’s one of my, how should I say this, vendettas, especially given the recent rise of containerization that it seems to be just fine, or you have rust with its cargo thing, which is just fine to add dependencies. It’s not fine. It’s actually a, I like to say, an invitation for somebody else to break your code. But that was another one of these deep convictions that we got in designing DuckDB that can’t have dependencies. That was totally born out of the environment and the design, as you mentioned, of DuckDB as well, like we talked to people in the data science community and essentially listened to them. It’s a very uncommon sort of thing to do for a database researcher, oddly enough. They told us what they didn’t like, and they were also super happy to iterate on our half-baked ideas and give us feedback. So that was really, really valuable in shaking down the early design parameters, if you want, of this thing.
Jon: If I move to the next part of the story, Hannes, here you have this thing that you’ve built that’s really useful, and yet you’re doing a job that you love, you’re a researcher. Did you think about turning DuckDB into a company yourself? How did you think about that? What was the exploration, and how did you land on DuckDB Labs?
Hannes: Yeah, that’s, interesting because it’s a kind of a push-pull thing. So, first of all, in our research group, there has been a precedent in spinning off companies. There was, for example, VectorWise, which is obscure, but it’s the first vectorized database engine that came out of our group that was a spinoff. The CWI is also a place that is generally supportive of spinning out companies. But there was also a lot of pull, right? We had DuckDB we open sourced it in 2019, and then people started using it, and then people started essentially asking us questions like, when can we give you money? it’s an interesting situation to be in. You are in a research institute, somebody asked you, can we give you money? And you have to say no because there is just no process in this research institute to take money. It’s really weird. And I think it was about the same time when the VC started badgering us, for lack of a better word. There was this, endless stream of, “Hey, have you thought about starting a company?” So, we were a bit reluctant at first. I think it took us a couple of months of people asking us whether they can give us money. VC’s kind of asking us, “Can we give you money?” And us sort of think like, “Uh, not so sure. I don’t know.” There’s many stories about what exactly tripped us to do to start leaping. A story I like to tell is that kindergarten in Holland is just so expensive that I had no other choice but to start a company. Another one is that it’s absolutely clear that we needed to spin out in order to actually give DuckDB the room to grow because there’s only so many things you can do as an employee of a research institute. So that started this whole process of then, then we didn’t know anything about starting a company. Right? Like how do you do that? It’s not something they teach you at computer science school. Obviously, lots of discussions followed. Lots of soul searching, figuring out what’s going to be the business model. What’s going to be the process? Who are we going to trust? I think that’s, that was an important first question. Who are we going to trust?
Jon: And you decided, that you want to focus on the technology itself.
And that’s kind of where this landed.
Hannes: Right. But that was the long process. This process was very interesting because we talked to VCs, and they were like, “Okay, so you’re going to make a product, right?” Like, we have piece of software, isn’t that a product? And like, no, no, no, no, no. You have to be a Snowflake. It’s like, okay, but we don’t want to be a Snowflake. Yeah. Well, hmm. Difficult, right? And so there’s, there was a lot of discussions that went exactly like that.
But this idea that you can just be a technology provider of sorts, that didn’t resonate well, I think. And we were really like also wavering a bit on like, okay, they all wanted us to do this, should we really do this? But in the end, we talked to some people that have made database as a service companies. Very successful ones. They told us about their experience with this. They said, okay, this is what you are looking at if you do this. And that was clear that we didn’t want to do that. We wanted to be more open, we wanted to be more flexible. We wanted to not target one particular application area. Because, in our mind, DuckDB has so many different possibilities that going just for one, would be a bit restrictive. And because there were people already that were commercial users that were willing to give us money, we also had a different approach, which we could just say, “Hey, okay, we’ll take their money and, uh, we’ll run the company from that like, in the olden days. And that is still what we are doing. And it’s been, I would say — I’m quite happy with how this worked.
There are some people that we are thankful to that helped us, in the beginning, there was a Dutch entrepreneur that basically turned up with his lawyer, like on day three of this adventure, and said, “Here this is my lawyer. You need to talk to this guy.” And he’s still our lawyer. Right? There’s been, one of your former colleagues, Anu Sharma, who was extremely helpful and supported us in the beginning without any agenda if you want. There, there were a couple of people that have been extremely supportive, and I’m probably forgetting some, but it’s been, a great experience to do this non-standard thing because there were people out there were super willing to help.
Jon: That’s a fun introduction to the first thread. Jordan, can you maybe take us back to when you learned about this thing DuckDB? And what was the light bulb that went off in your head, and what you did about it?
Jordan: Yeah, so I was chief product officer at SingleStore, and we were really focused on database performance, building the fastest database in the world. We were looking at some benchmarking reports that somebody had done, and it had a number of different databases and I saw one that said, DuckDB, and was like, what is that? And why is it so fast? And where did it come from? And so, I did a little bit of poking, and I encountered some of the papers that Hannes and Mark had written. And they just really resonated with kind of the experience I had had over the last 12 years of working on these big data systems, one of which is that most people don’t actually have big data. And that scale-up is actually quite a reasonable way to build things. In SingleStore we were working on these sort of distributed transaction features that were taking a long time to build. And in BigQuery we worked on shuffle in order to do joins or in order to do kind of high cardinality aggregations that were very, very complex, basically relied on specialized hardware, and had big teams of people to work on them. And then in DuckDB, in order to do like these joins, you just build a hash table, and then you share a pointer to the hash table and it’s like, wow, that’s just so much easier. So there was the complexity side of things. There was the scale upside of things that it’s like, what you can do on a single machine is so much more than you used to be able to do. Then there was also the part that Hannes was talking about, which I think people haven’t actually grokked, yet, as the special sauce for what makes DuckDB so awesome. Which is that everybody focuses in databases on what happens once the query starts and until the query finishes. But there’s a bunch of stuff that happens both before and after. So before: How do you get the query there? How do you set things up? And then after there’s, okay, how do you get the data out? And so often, they go through these incredibly antiquated ODBC/JDBC interfaces or a rest interface or there’s the Postgres wire protocol and the MySQL wire protocol. And they’re just not really great. I think DuckDB was one of the first things that I had seen that really focused on the overall end-to-end.
To give an anecdote in BigQuery, we outsourced our JDBC driver and ODBC drivers to a company called Simba. And there was a bug in the outsource driver that added like a second and a half to every query. If your queries are taking minutes and you add a second and a half, that’s not a big deal. But if you want to do some sort of BI dashboards, etc., adding an extra second and a half is terrible. And in fact, there were some cases where it would add tens of seconds or even minutes because if the data sizes were large, they would basically pull through this very narrow aperture of the whole table back. And so, it was unusable for some BI tools.
And the thing is, we had no idea that this was even a problem because all we focused on was, okay, we get the query, we run the query as fast as possible, and then we give you the results. The fact that DuckDB is actually focusing on these kinds of problems, I think, is why it’s doing so well. Somebody Tweeted, “Why is DuckDB so fast?” The reason that DuckDB is fast is because all the stuff that everybody else isn’t paying attention to, they’re actually paying attention to, and so it feels fast.
Jon: There’s two things that really strike me. One is that you, Jordan, immediately imagined single-box execution. Just like Hannes, with a much bigger box. You realized that hosts in the cloud also count as single boxes, and yet so much RAM, so much compute. And, and I guess you’re going to say that comes from the sort of family of origin where you’d been raised at SingleStore and at Google. But the second thing is you, Jordan, I think are excited about doing complementary activities with your day, around team and company and business building with this advanced technology. And so maybe you could just kind of comment about that part.
Jordan: Sure. Yes, I did immediately think of cloud. I mean, I’d been on a, team in Google that was supposed to build a data marketplace, and then we said, well, you don’t want to just download the data. You want to actually compute over the data where it sits because it’s large data. So we built BigQuery, which is essentially taking a service that already existed in Google called Dremel, and we’ve built a product around it. And then at SingleStore, they were in the process of a cloud transition, and I spent the last 18 months taking an on-prem database and sort of building a cloud service out of it. And so, I know the pain of it, I know how it works and that’s just, that’s how my, that’s how my brain works. The other thing is in my career, starting as a software engineer for 15 years, as you move up the corporate ladder, you handle larger problems that have more complexity and more ambiguity. And then, as a manager, it’s another big step beyond that, which is people are more complex and more ambiguous, and getting them to do something is harder. So you have to figure out what makes them tick. How to get things to work, how to get the right output, and then as a manager with larger scope, you end up actually designing. It’s similar to a design problem in software as you’re designing with your organization. Okay, we need these pieces and these pieces, and this is how communication works. And it’s almost like it’s a distributed system. And then sort of moving to product, because then I switched from engineering to a product manager, is like you’re designing in the product space. And the product space is just this even broader palette of things that you can do. Because it turns out what actually matters is how are customers going to interact with something? If you build a beautiful piece of technology that nobody wants, it’s going to be really disappointing because nobody’s going to end up using it.
And so, you’re painting with this broader and more complex and more ambiguous space, and to me, that’s been sort of exciting. Nowadays, even though I love technology and I love to sort of geek out about databases I’m also realizing the thing that gets me excited is building products. That involves not just the tech, not just the architecture, but also all the market, the pricing, the packaging, the customers, all those other pieces that go along with it.
Jon: So, here we are in this moment where you spotted DuckDB. And a light bulb goes off in your head, and there’s a moment where you are so motivated that you get on a plane. Can you tell that story, Jordan?
Jordan: Well, I think I need to back up a little bit because I was really excited about this, and I’m like, Serverless is something that I think is the right way to, build cloud systems. And I felt like a serverless DuckDB should exist. There were so many nice things about it and so many things that other systems couldn’t do, like being able to scale down to zero and pay for what you use, and being able to sort of rebalance and move things around. It reminded me actually, sort of, of BigQuery, but like rotated 90 degrees. Big query was sort of very wide and thin. And then, with this, we could be very thin and deep, But also do the same sorts of things and perhaps be, be even more flexible. So I’m like, all right, it’s been a long time since I’ve coded. So maybe I’ll just sort of hack on this for a little while. And I got about two days into it. And then I asked, a friend and mentor of mine for an intro to Hannes and Mark because I knew that he had been working with DuckDB. The morning I talked to Hannes and Mark, it was like, huh, this seems like it could actually work. They’re not doing exactly what I’m talking about, but they kind of are looking for somebody to come in and build something like this. So that could, that could really work.
And then, in the afternoon, I talked to Tomasz, who was then at Redpoint. I got about 15 minutes in, and he is like, “I like this idea. I want to fund it. Come to my partner meeting.” And I’m like, “What?” I was not thinking of starting a company. I was thinking of learning Rust. That was actually my goal was to learn Rust. The next day I talked to another VC about something totally different, and I ran the idea by them and they said, ” I like this idea. You just had the partner meeting. How much do you want?” And I had no idea what to even say.
The next day I talked to a neighbor met who worked at Madrona. who I’d been meaning to have coffee with, and I let slip that, “Hey, I’ve been thinking about this idea.” And so she brings, Jon along with her to the coffee meeting. And that’s how Jon and I met. And that’s also sort of like within 48 hours kind of realizing, hey, there’s an interesting idea here. The next day I one of my first vacation, post the start of COVID. And I was in Portugal for a few days, and we’re trying to do all this sightseeing, and I’m taking all these calls from other founders, from VCs. I felt a little bit bad for my wife because it wasn’t as much fun of a vacation as it otherwise could be. And then I realized, okay, if we’re going to make this work out the most important thing is I need to have a great relationship with Hannes and Mark, and I need to really kind of see them in person and kind of look them in the eye. So I rerouted my trip, and I came back through Amsterdam. Hannes books four hours and I’m like, four hours — there’s no way we’re going to talk for four hours, and then like five hours later, we’ve been geeking out about databases — it was just sort of a really fun conversation. We’re like, oh, we’ve got to get to dinner, and we had dinner with our spouses. And that was the start of MotherDuck.
Jon: Was Jordan the first person who came to you with an idea to commercialize DuckDB?
Hannes: No, he was not the first person, I’m sorry to say. But how should I say this? He was credible. I think what really made, made you Jordan stand out from anything I’ve heard to this point. And I think also anything I’ve heard since, to be quite honest, is that you came from this background at SingleStore and BigQuery, and in a way, it was a big shock to me that somebody who had this kind of background would consider our scrappy single-node system for, for something serious. And I thought, okay, that was really crazy because we were being ridiculed for not taking distributed systems seriously with DuckDB. People were like, no, this is pointless. But we always thought like, okay, if we are some odd balls in Holland, and no one cares. But then to see somebody like Jordan come and say, no, no, you’re, you’re totally right. This is what we’re going to do. That was shocking. And I think, it really was clear that if we were going to work with somebody that does this, it’s going to be Jordan. That was pretty clear from the beginning. Certainly, after he changed his travels at the last second.
It’s quite funny to hear the other side of the story from you, Jordan, because while I’m aware of sort of the points where you were in contact with me, I had, of course, no idea of the background chatter with everyone else that already was going so far. But when, when we first talked, I was like, yeah, no, we can totally do this. You came over. I think we had indeed we had a good feeling about this. Then it went super quickly, of course. Like this was all in the matter of days. From us saying, yeah, we’ll be on board. It felt like it was minutes after that that things started being like, set up or something.
Jordan: And I was worried I was going to freak you guys out because things had moved so fast. It was like, oh, this intense American is like just cause, just cause we said yeah, it sounds like a good idea. All of a sudden, you’re like, okay, now boom, boom, boom. Here’s the money on the table. And I was kind of terrified that because it was, things were moving way faster than I had expected and was just sort of like riding the wave. I was very cognizant of trying not to freak you and Mark too much.
Hannes: I think at that point, we had spoken to enough Americans. And I have to say my wife is American, so I have a daily exercise in this. But it wasn’t scary, I thought. I don’t know. It seemed so logical and obvious that I wasn’t scared at all, and I don’t think Mark was either.
Jordan: That’s good to hear.
Jon: There’s a certain sort of trust in friendship that’s evidence here, but I want to also pull out this connection that you mentioned to me once or twice, Hannes. The fact that Jordan has not just built a lot of cool stuff, but has built a lot of cool distributed systems that scale out versus scale up. Coming to you and saying, “Hey, scale up is actually pretty cool.” That kind of narrative violation, I think…
Hannes: There was a shock to me. Yes.
Jon: It seems like it gave credibility and also has been an animating theme for MotherDuck. Isn’t that right, Jordan?
Jordan: Yeah, I mean, the recognition that most people don’t have huge amounts of data. Even working on BigQuery, people were not doing big queries. For the most part, they were doing little queries and focusing on getting data in and getting data out, and the user experience of the query and using the system is actually more important than size. And then also, yeah, you can scale up. And then the last piece is — you can always make it distributed. I’m sure somebody, even if we don’t do it, somebody’s going to come up with a distributed DuckDB. We have a bet internally about whether we’re going to end up doing sort of a distributed version of, MotherDuck. My bet is, no, we won’t need it. Other people think that we will, but we’ll see. Like in BigQuery, we had BigQuery BI Engine, which was a scale-up single node system that sits on top of BigQuery storage. And because it had to run in these constrained machines that have to run Google search, there were no big machines, and so we ended up having to build out a scale-out version of it. It took a year and like three or four engineers. It can be done, but, ideally, you wait as long as possible, and so you get as much innovation into the core engine until you have to do that.
Hannes: I think what this biblical transformation from scale out to scale up. The reason why this was so surprising. I think what, what is so, so transformative for us, I think was because our idea of why we wanted to scale up was based on a feeling, I want to say. And the feeling was based on actually using things like Spark and having this feeling that something’s wrong with the world, if this is the best we can do. But this was based on a feeling that scale-up was the way to go. We didn’t have data on this. It was only recently, I think in maybe 2020 or so, that Google published the TF data paper. That actually said this explicitly, like 95 percentile of all our machine learning in job size is like a hundred gigabytes or something like that. But then, of course, Jordan, you also had seen this from the inside. I feel like if you haven’t seen the big data, then probably no one has. So, it made the difference for us from a feeling to something that, was actually a thing. It was a great moment. I would have to say.
Jon: If we go back to coffee, Jordan. The first time you and I met, there, there’s a thought that went through my mind and a question I asked. The thought that went to my mind was that this is almost witty to say, let’s go for, whatever’s the opposite of big data. That’s almost funny, considering the way that so much of our data technology has been designed to scale. And the first question that I asked you was, well, if we change that constraint, and we looked at the world as it is and the workloads as they are instead of how it could be if we waved to magic wand, what can we do that’s possible that wasn’t possible before? Maybe you can share either what you answered then or what you would answer now about that if it’s different.
Jordan: I wish I remembered what I answered then, but it was a rough couple of days. What I think I probably said is, when we started BigQuery, the mantra we used — and it came from the Turing award winner and database researcher Jim Gray — what he said was, “With big data, you want to move the compute to the data, not the data to the compute.” When I kind of described building this system where you didn’t want to just download the data. is because moving the data is so expensive and it’s so hard. And so BigQuery was sort of built around that premise. But then, once you kind of recognize that data may not be that large after all, then how would you design the system differently, and can you move the data to the end user and leverage the compute power that, the end-user has? George Fraser, the Fivetran CEO, just did a benchmarking report. I think it’s just crazy and amazing that the CEO of a multi-unicorn company is running, database benchmarks and doing a good job of it. But anyway, he found that his 2-year-old Mac laptop, not even state of the art, was faster than a $35,000 a year data warehouse. It used to be the laptop was synonymous with underpowered, and nowadays it’s, it’s a huge amount of power. And so, why when you run a query against one of these cloud data warehouses and you wait three seconds for it to run? And meanwhile, everybody else is waiting for that same hardware, and your incredibly powerful computer on your desk is sitting there idle. Why not actually let that computer on your desk participate in that query? A — it’s less expensive because you’ve already paid for that laptop on your desk. B — it’s a better user experience because you can get results back in milliseconds, not seconds. I think there is a new paradigm and a new architecture that can be used. And then there’s further things. There’s edge, there’s mobile, there’s leaving data where it is when it gets created, instead of having to worry about consolidating the data. Like people complain about, okay, why do I have to consolidate all this data in the same place? It’s so expensive to move up. If you can have the compute be anywhere, then there’s so many kind of interesting things that you can do.
Jon: It’s amazing to see that two things can be simultaneously true in this area. The marginal cost of a cycle of compute may be the lowest in a cloud because of the scale and the optimization of that. And, yet, when we dial up the capacity of some distributed system analytics in the cloud, it’s a lot like adding lanes to a highway which produces more gridlock in about 24 months.
Jordan: The reason that adding lanes to highway doesn’t make things faster is because what’s slow is getting things on and off the highway. Getting back to sort of DuckDB is like getting your query in and getting your data out are very often the most important things. And what happens in the middle all converges to the same place over time.
Hannes: Yeah, it is really shocking to see what is possible on laptops. It’s something that we have kind of forgotten about. And, of course, the marginal cost of a, CPU cycle in the cloud isn’t what your cloud database is billing you for it. Right? I think there’s also a big difference between what the cycle costs and what you are paying for the cycle. And I think it is maybe also part of the reason why it is so much nicer to run things locally than it is to go through that.
Jon: Guys, I want to leave this a little bit where we started. T o produce DuckDB and MotherDuck and this really exciting opportunity for your customers, it took each of you doing what it is that you love that is complementary. I think our audience would be interested to hear however many months in it is since that all happened, what it is that you’ve loved or learned from the other person that you’re working with that has helped you become stronger since then?
Hannes: Well, my life has turned around pretty radically since we first spok, Jordan. My life has changed completely from a mostly academic researcher to somebody who is running a, I mean, it’s not a giant team, but it’s a team of competent people that are building DuckDB here at DuckDB Labs in Amsterdam. And my position has changed into something that is much more what Jordan described. And I’m not sure I’m entirely there yet that — this is going to be the thing that I really love doing. But it has changed a lot and it’s been really interesting for me to see how Jordan goes about doing things. Because he’s been, of course, also building his company the last 10 months at a much greater speed than we do, of course. But since this is all so new to me, it’s been extremely interesting and valuable for me to just watch that a bit.
Jordan: On my side, at the end of 2022, I sent a letter to kind of our team and to investors, and I said, if there was one word, to sum up 2022, it’s lucky. I feel just incredibly fortunate that we kind of hitched our star to DuckDB and to Hannes and Mark and their team because there’s such incredible tailwinds that come behind this really groundbreaking technology. And we were in the right place at the right time, and, hopefully, we’re going to have this great partnership going into the future. And one of the things that worries me the most going into that is that we’re going to do something to screw up that relationship. And from other founders and people who have commercialized open-source technology, including the Databricks founder, have shared with me is that it’s going to get hard because your incentives are going to diverge, the things that you care about are going to be at odds. And so, it’s just something to actively maintain. As fortunate as we are, we want to acknowledge that and also acknowledge that in order for this partnership to be successful in the future, it’s going to take, active work and deliberate trust in being willing to say, “okay, Awell, maybe we wanted to do this, but for the sake of the relationship we will take a slightly different approach.”
Jon: Hannes Mühleisen, Jordan Tigani, thanks so much for your time. This has been a lot of fun.
Hannes: Thanks for having us.
Jordan: Thanks, Jon. Thanks, Hannes.
Coral: Thank you for listening to this week’s episode of Founded & Funded. If you’re interested in learning more about MotherDuck, please visit MotherDuck.com. If you’re interested in learning more about DuckDB, visit duckdblabs.com. Thank you again for listening, and tune in in a couple of weeks for another episode of Founded & Funded with Panther Labs Founder Jack Naglieri.
Related Insights
