Solving Universal, Persistant Problems With David Aronchick  ## Metadata - Author: [[The Business of Open Source]] - Full Title: Solving Universal, Persistant Problems With David Aronchick - Category: #podcasts - URL: https://share.snipd.com/episode/99ba49a8-9295-41ce-9e75-bd39ba202544 ## Document Notes ## Highlights - **Why Kubernetes Succeeded** - Kubernetes succeeded due to right timing and ecosystem alignment, not just better technology. - It allowed gradual cloud adoption by reusing existing resources and infrastructure efficiently. Transcript: Emily O'Meara Let's start not at the beginning, in the middle. Let's start in the middle. What do you think now with the benefit of hindsight made Kubernetes so successful? David Aronchick I think it's an interesting question. I you know um i would argue i mean first it's difficult to overstate the value of getting enough of the right players to collaborate together right i have many friends at amazon and i say This is all love in the world, but at the time, 2015, they could not have been less interested in helping Kubernetes out. And in fact, just about every year from 2014 on, Amazon would come out with something that was not intended to be a direct competitor to Kubernetes, but was a competitor to Kubernetes. And they would say, oh, no, this isn't a competitor, so on and so forth. And you understood why, right? They had this wonderful API for EC2, and were doing just a bunch of really interesting stuff, but they were all about, like, look, if you're not on AWS, you're just not part of our world And so you've got to move that way um everyone else out there was like a we would rather people not be building against the ec2 api right um because one person one eight company in the world Controls that so let's back off of that And two, no matter how fast Amazon wants everyone to move to Amazon, it will never be fast enough. And so we're going to need a solution where it lets people be cloud native with the tools and the resources and the investments they already have. And Kubernetes offered that, right? It let you, in a pretty straightforward way, repurpose existing VMs or hardware or data centers or whatever it is. Without having to replatform everything, you could do really small motions in that direction, but still do it on-prem and without going all in. But then the moment you did decide to, like, okay, that workload that was there, and we're now going to the cloud, we can do that because we've already done a bunch of the work, just to get In place that kind of efficiency of being cloud-, now moving to the cloud is much easier, right? Our workloads are containerized, they use 12-factor techniques and so on, and they're immutable. So it was a nice stepping stone along the way, rather than asking someone to eat the entire buffet at once. And all of that together, plus the fact that Google, certainly Google, but other folks as well, had been building this way for 10 plus years. Again, there are zero lines of code shared between Borg, which is Google's internal orchestration engine, similar to Kubernetes, and Kubernetes. Zero. But the concepts are all there. And it is very, very common that people who were in Google would leave and say, oh, I really missed that. And Kubernetes also gave them an angle to do that as well. So, you know, I think if I was to put it on one thing, it really was a combination of the big player in the room was asking people to take a little bit too big a leap. And it was familiar for a lot of people who really wanted that experience again. And those two together with the right time, right place, let people adopt it very, very quickly. It's ([Time 0:03:51](https://share.snipd.com/snip/62008a9c-0a7d-4807-a948-47812f0cf5a5)) - **Luck and Timing in Tech Success** - Major tech successes often hinge on timing and solving universal problems. - Past projects like VMware succeeded similarly by meeting needs as the industry evolved. Transcript: Emily O'Meara Interesting that you say right time, right place, because it makes me wonder how much of what makes Kubernetes, or what made Kubernetes a success was things that people did, like decisions That were made, and how much was it was the right time, right place for this thing? David Aronchick Very significant amount of luck, very significant, right? So if you go back to the, you know, arguably largest open source project in history, right? Linux. It just so happened to be at a time when hardware was becoming much, much cheaper. And it was weird you would have to go to whomever and buy a a um you know os license right um so it kind of filled that gap then you look at um you know this isn't really an open source thing but It is a transition if you look at VMware, right? Same deal. Like, people are like, wow, you know, I have this really, really, really big machine, and Moore's Law keeps making it cheaper. But I don't want a single operating system on it, right? I want to put many small operating systems on it. VMware happened to be there at the right time, right place. And again, this is one of those things where the industry is moving. Arguably, it's not the solution, though these solutions were the best ones for a bunch of reasons each time. But we're looking at it with hindsight, right? At VMware's time, there were half a dozen different virtualization solutions, and they just happened to be the right time, right place, right go-to motion, right everything, right? You look at whatever, 2004, right? People are like, wow, now I have all these machines, and I'd like to do some data processing over them. Google publishes MapReduce. That's what they were using internally. Hadoop comes up and does it there. 2012, 2013, Google had already been containerizing stuff for 10 plus years. They already had a solution. I don't know if it's still available. It was called Let Me Containerize That For You. I think it was like L-M or something like that. Open source GitHub repo. You can go looking for it. I'm sure it's out there. But it wasn't enough because Docker had to come along and get the API right and get the developer experience right. And so what I'll say is that this stuff just happens over and over and over again. And Kubernetes wasn't even close to the first orchestration system, right? Lots of other people were out there just doing it. And while I would love to claim even, you know, 1% of the credit for Kubernetes, like you, I have to say, like there was just a lot of stuff coming together that enabled it to work. And certainly with my current business, right? I'm making that bet. I'm saying, hey, you know what? Data is growing so big. Networking is not keeping up. There has to be a system that makes it much easier to manage all this data everywhere, where people, yeah, want to cut their observability bill in half by 50% by simply respecting networking Or make it easier to manage the, you know, for every one, I like to say for every one, you know, virtual machine or machine you have out there, you're probably going to have a thousand other Devices or other computer-like devices that you're going to have to manage. And you've got to figure out how to like build a system that supports that. So I'm making that bet on it right now. The speed of light's not getting any faster. Data is still getting very, very expensive and growing and regulations are growing you've got to have a platform that's also that am i gonna be right i don't know i'd like to think so um But you know could someone else come along and like you know look back at me and say oh you know what um the the back of yao that was like or expanse so that was like Mesosphere, right? Which again, amazing, amazing work, just happened to be like slightly off and, you know, didn't have the same kind of commercial success that Kubernetes did. ([Time 0:07:56](https://share.snipd.com/snip/28b54063-adbb-4a78-a3ee-3c062af6097c)) - **Build to Immutable Truths** - Build products addressing immutable, universal truths rather than transient technologies. - Solve problems that persist over time to reduce pivots and improve long-term success. Transcript: Emily O'Meara Other side of this coin, obviously, and you're talking about hindsight, is how do you see with foresight what that opportunity is going to be? And of course, the challenge here is you can't just see what the opportunity is right now, because it's going to take you some amount of time to build whatever thing it is that's going To meet the need. So how do you build something that's going to meet the need that will exist in a year for example so my biggest thing is i like to build into immutable truths right and so if you said um you David Aronchick Know uh whatever, Gemini. I think they're the new state-of Gemini, right? He said, I'm going to go build a wrapper for Gemini because it's the solution, right? Open source wrapper or product, whatever. It could be closed source. It doesn't even matter. That's not immutable, right? Gemini is not going to be the best. I guarantee there are very, very smart people at what do you call it. At some point in the next 12 months, Gemini will not be the state of the art. It just won't, right? That's the way it works. So that's a very dangerous thing. When you're building on stuff that can change reasonably, then that's risky, and you have to be much more responsive. If you instead choose more universal truth and build into that, I think you're going to be much more likely to both solve a real problem, if that universal truth is a problem, But then Also that when you pivot, you will have to pivot, you're going to have to pivot less. So I'm building into three universal truths that I see right now. Universal truth one, data is growing everywhere. Not really a dispute. But what I'll say is there's a subtlety to that, and it is that data is growing everywhere outside your data center. Gartner already says 65% of all data is created outside of a traditional data center today, and I think it's going to go way, way, way, way out. By that, I mean, okay, I have an office building and it's got 10 security cameras in it. Every bit of that video being collected is being generated outside, quote unquote, of a traditional data center. So now I have to figure out how to do any kind of processing over that data, right? And that can happen on the camera or on the office building or whatever, but it's not happening, you know, in Iowa. Okay. So that's universal truth one. Universal truth two is speed of light. It's not getting any faster. So like in 10,000 years time, it's still going to be, you know, 49 millisecond ping time between Boston and LA. Nothing you can do about that. Just full stop. So if you want to do things that take less than a second of round trip, you better figure out a new solution, right? So, and even if that wasn't the case, even if the speed light was getting faster, networking is not keeping up, right? So, like, when you look at data growth versus network growth, due to a whole bunch of reasons, network growth will never keep up with data growth. Never. It's just not possible. So that's immutable truth two. The immutable truth three is that regulations will only grow. Okay? So simply moving the data makes things more insecure, makes you more restrictive to regulations, makes you, you know, all these various things. And you're going to want to move less data, right? So those are the truths that I'm building into. Now, there are other truths that I want to get to, like, you know, developer experience matters, user experience matters. And those are all like ingredients that you sprinkle in. But that's what I strongly recommend for people. So if you're building the next great designer platform, just as a sake of argument, right? I saw someone, Penpot at the Open Source Founder Summit, which is an amazing conference. Everyone should go next year if you haven't been. You know, he and I were talking, and he was like, oh, you know, we're building this because, you know, designers and the creative team and the marketing team have trouble collaborating, Right? And that's going to be universally true forever, forever, right? So building into those problems is something that is you know that's what you should be building into right pick a problem that that has that space and so on um uh there was a thing that I uh um i i love called the request for startups it never really works but like i want someone out there in the world to build a solution that wires together apps, for example. I keep threatening to do this in my copious free time. But the ability, I hate that in Instagram, I get restaurant recommendations, and then I get something else on TikTok, and I get something else on Conde Nast, and I get something else On Infatuation, and I'm like, ah, I just want one, you know, I want to see all those things, and then I want to record that, right? Now, does that mean I'm going to build using a particular AI or a particular ML or a particular this, a particular app or whatever? No, no, no, no. What you need to build is what's the problem? Well, I get a lot of sources, and I want to place it in a solution, right? And or not that's open source or commercial, as long as you're building into the problem and the problem is forever, you're going to be fine. You're going to be able to navigate and so on. So it goes back to your question. With the benefit of foresight, if I do nothing else but solve a problem in the world, I'm going to be in decent shape. ([Time 0:12:18](https://share.snipd.com/snip/55fab57f-66b7-4ff6-8444-a78134358eb4)) - **Naming Bacalhau Anecdote** - Bacalhau, the open source project behind Expanso, was named after the Portuguese word for cod. - The name originated from a team's Slack conversations about the compute-over-data architecture. Transcript: Emily O'Meara So let's talk a little bit about open source and business specifically. Why, when you started Expanso, did you decide to build it around Bacalao, which I'm probably mispronouncing? David Aronchick No, you're getting it exactly right. By the way, do you speak French? Yes. And Spanish. Emily O'Meara Is it named for the dried fish? David Aronchick So the story behind Bacayau is we were in Portugal at the time and we were talking about this new architecture called compute over data, right? Because this is the general concept. But we were in Slack, and we're just constantly texting each other, and we keep abbreviating it COD, C-O The Portuguese word for COD is Bacto. I have learned that just about every Mediterranean culture, no matter what their language, they have something like Bacayau named in their language. So sometimes it's spelled with an O, sometimes it's spelled with a U, so on and so forth. And I actually, I speak French, but I actually don't know. Like, is there anything close in French for cod? I don't know. I don't know. Anyhow so why did we start well look remember what i said about baccalao and expanso generally is you know it's got to live everywhere right and that means different operating systems And different execution profiles and different this and different that and so it's gotta be pluggable um and unfortunately pluggability um doesn't like though you can build a plug-in Architecture i think that that's not going to get close to what you need and so we launched it as open source as a community because we knew and this is happening right we got to appear on Some uh particular you know video system on a chip or a satellite platform or this or that like there's just so many different areas of these challenges and if we tried to build a company That supported all of them ourselves, that would not work. Now, you know, the follow up question is getting back to the business of open source, there is a phenomenal talk by Adam Jacob, co founder of chef, who I just encourage everyone who is Even remotely close to open source to go and watch it. Is this a podcast that I can use curse words on? Emily O'Meara Yes. David Aronchick So the talk is called Sell That Shit for Money. Or if it's not that, that's certainly what you hear. And it is so clean and clear and descriptive about it. And I strongly encourage that. I strongly, you know, I'll go check out System Initiative, which is an incredible company, and they're doing great work, because they also have an open source FAQ. Walk away from is code is open source. This all is in the Apache 2 MIT license. Code is open source. When you do work on top of that code, you can sell that for money, right? Now that work doesn't have to be substantial, right? It could just be compiling and creating an S-bomb and putting up your name behind it and things like that. But that's enough. It really is. And people give too much away right now. Again, that is not to say I'm holding back anything. If you want to go to Bakayau tomorrow, fork the code, never look back. More power to you. Please go do that. I encourage you left, right, and center. ([Time 0:18:31](https://share.snipd.com/snip/7c9b81d9-dd3b-4777-9696-342680f97911)) - **Sell Binaries, Keep Code Open** - Sell compiled binaries as the commercial product while keeping code open source. - This model enables revenue without restricting code access or contributions. Transcript: David Aronchick Is this a podcast that I can use curse words on? Emily O'Meara Yes. David Aronchick So the talk is called Sell That Shit for Money. Or if it's not that, that's certainly what you hear. And it is so clean and clear and descriptive about it. And I strongly encourage that. I strongly, you know, I'll go check out System Initiative, which is an incredible company, and they're doing great work, because they also have an open source FAQ. Walk away from is code is open source. This all is in the Apache 2 MIT license. Code is open source. When you do work on top of that code, you can sell that for money, right? Now that work doesn't have to be substantial, right? It could just be compiling and creating an S-bomb and putting up your name behind it and things like that. But that's enough. It really is. And people give too much away right now. Again, that is not to say I'm holding back anything. If you want to go to Bakayau tomorrow, fork the code, never look back. More power to you. Please go do that. I encourage you left, right, and center. But that said, you can't call it back a YOW. We own the trademark. And you can't use our pre-compiled binaries. In our pre-compiled binaries, we have an S-bomb. We know what our dependency tree is. We do a bunch of work behind the scenes in our build tree and so on to make sure everything is ship shape. And there you go. That's the product we sell that from the first binary we sell that everything else is um but the code is all open source so you can go check it out we don't have anything we don't have anything Hosted we don't i mean we have a cloud offering but it's all the same code you could run yourself but i think that kind of separation is so critical because otherwise people get to this Oh well what what are you selling? Are you selling services? Are you selling support? No, we're selling the binary. And to be clear, this is the exact same thing, the exact same thing that Oracle and Microsoft and you name it, you can go right now. If you go buy a developer license, you can go on the MSDN network and get the source code for SQL Server. Tomorrow. Tomorrow. You can compile it yourself. You can run it yourself. That's part of the deal. I think, actually, I don't know. I'll be specific. I don't know what the license is, but you can certainly compile it yourself, right? And you can certainly look at the code. Does that mean you have a license for SQL server? No. No, you do not. Same thing with Oracle. Same thing with a million other things out there where they're like, hey, look, we're going to open source the code because that's not where the goodness is. And it's true. That's not where the goodness is. So there's the code, which is open source. And this is something I strongly recommend everyone do. It's what Red Hat did 25 years ago. The code is open source. The stream, the project, everything, you know, that where you are naming it behind a company is commercial. ([Time 0:21:13](https://share.snipd.com/snip/bee485de-5913-4846-8803-83c07818afa1)) - **Open Source as a Channel** - Open source projects are powerful marketing and community-building channels. - Success depends on resonating with users and enabling them to become advocates. Transcript: Emily O'Meara So let's try to dig a little bit deeper into this. I mean, what do you see as the biggest opportunity that you get from having and from being open source in terms of being able to grow the business? David Aronchick So, I mean, first, there is a it's difficult to overstate as a marketing and community building and things like that perspective, right? You know, people want to give back. But the idea that they're giving back into some, like, black box that they never see value out of or anything like that, you know, that hinders people's adoption and things like that. And we really do want to build a strong community around this. It will take time for people to adopt and use and test and so on and so forth. So, you know, that's a big thing that we need people approaching this and being willing to contribute upstream and feeling like they're part of the community and so on. Yeah, that's a really big component for us. Well understood nowadays that it makes it much easier for you to get into certain organization sizes. Especially if you're like, well, is this company going to go out of business? What happens? How big a risk am I taking here? So on and so forth. Yeah. So that's a really big thing as well. And the many eyes makes all bugs shallow is difficult to overstate as well. You know, I've had people like, find things, look at the code and say, Oh, you know, this is missing a flag, or this is missing a this. You know, it's not common, but it's nice to have people care enough and want to contribute enough to go and do that. And so, yeah, that's exciting as well. Emily O'Meara You said it's difficult to overstate the marketing and community building value of open source. Can you go into that a little bit, especially because some people think this is like an incredibly cynical way to look at open source as a marketing tool? David Aronchick I mean, I would just really strongly disagree with that. It's a channel. Everything's a channel, right? How I get things out to the world is a channel, no matter what. And I don't care if it's the most commercial thing in the world or the most free love and kindness and thing in the world. Like, these are channels to get things out there. And your success depends entirely not on what you say, but how well that resonates and how quickly people become your advocates. Because you will never achieve the kind of leverage you need if you're the only one speaking. Peace, love, and happiness stuff, don't get me wrong. I am entirely behind that. And if that's good for you, you're one of the rare ones. Now, mind you, one of the rarest ones is also the most popular, right? We already mentioned Linux, that's GPL. GPL is challenging to make a business around. It's not impossible remotely, but you have to do a lot of work to separate what you offer versus the GPL and so on. That's why so many folks have gone to Apache 2 MIT. And I'm not going to get into a licensing argument. All sorts of things, subtleties around that and so on. You choose whatever is right for you. But just to not treat open source for what it is, which is a way to get your message out, a way to encourage people to contribute and aggregate, like demand and user requests and bugs and Things like that. I just think that, you know, I don't know what the alternative is, right? ([Time 0:29:38](https://share.snipd.com/snip/8419fa49-0ec9-4119-9264-d7b3730fb9c0)) - **Prioritize Early Go-To-Market** - Invest heavily and early in go-to-market strategies to scale effectively. - One-on-one selling does not scale; create mechanisms for wider engine feeding. Transcript: Emily O'Meara So let's go ahead and wrap up pretty quick here. But one last main question, which is, if you had to give one piece of advice to yourself three years ago when you were starting Expanso, what would it be? David Aronchick I think probably the biggest thing is just you can't overestimate the challenge of go-to And, you know, every time I sit down and talk to people on a one-on basis, they're like, I totally Understand what this is. This is going to be great. And we're going to use this here and here and so on. And that's great, but it doesn't scale. Because like all people, I have 168 hours in a week. I occasionally need to sleep and eat. And outside of that, this kind of one-on motion, whether or not it's commercial or open source or anything, is just not scalable. So figuring out the ways to get the engine feeding itself, you cannot spend enough time doing that, especially up front. Hire for it, beg, borrow, steal, whatever. There are no silver bullets. There aren't even like 100 lead bullets. There's like 100, you know a million wooden bullets right like and that you just gotta fire keep firing and yeah i'd probably do that like i would i would dedicate far more to that early On far more um it's just again you know i i keep waiting for someone to say you know what this really i don't understand what this purpose of this project is or i don't understand what this Idea is i have all these conversations i don't think i'm that convincing but everyone who i walk away with is like totally understand this is gonna be great um and again they could be being Nice or whatever. Maybe I'm just really convincing in person. But based on the number of times I hear that, I would expect, you know, I'm not going to say we should be Kubernetes big, but like, yeah, closer rather than less. ([Time 0:41:47](https://share.snipd.com/snip/88a27fc2-d22a-40ea-b8d3-f45041a90a44))