Mitchell Hashimoto - Founder of HashiCorp, Terraform, and Thoughts of Open Source Monetization

Mitchell Hashimoto - Founder of HashiCorp, Terraform, and Thoughts of Open Source Monetization - https://www.youtube.com/watch?v=vw61iI08iro

All the projects I started ahead of Hashicorp existing, I never intended there to be a business. I never thought there would be a business. I never thought anyone would use them. So I think that a lot of projects start that way. There's no commercial thought or planning involved because the commercial side of it is a side effect of having community success. Hello, welcome to the DevTools FM podcast. This is a podcast about developer tools and the people who make them. I'm Andrew and this is my co host, Justin. Hey everyone. We're really excited to have Mitchell Hashimoto on with us. Mitchell, thank you so much for joining. So you famously started Hashicorp back in, what was it like, 2010, 2012. It was pretty early on. The company legally incorporated. 2012. 2012, I think. 2012, yeah. It's wild to me. Like, I didn't realize how much y' all had done because it's like, I think a lot of people when they hear about Hashicorp, have. Have probably heard about Terraform. Terraform being like this big, profound project that you have done. But like, I remember using Vagrant, like out of college and I didn't realize that, you know, I'd already also built that and that's like, that's a really cool connection. So we're really excited to talk about sort of your early work and Hashicorp and your journey through all this. But before we dive in, would you like to tell our listeners a little bit more about yourself? Sure, yeah, I think you covered the high level, but I'm an engineer by background, engineer by passion. I've always been heavily involved in creating open source software. For the past 10 years, or for about 10 years, I was really heavily into infrastructure software as a focus, but I have work jobs all over. I'm currently working on a terminal emulator. I'm sure we'll talk about that a little bit. But yeah, that's just me personally. That's sort of. That's me. That's awesome. So before we start talking about like Hashicorp, you're also a pilot on the side. So I really love this because my mom and my stepdad are both pilots as well. Just private, sort of recreational pilots. So how did you get into that? I mean, the quick thing is I've. I always was interested in flying. I never looked too deeply into it, so I always thought it was just not realistic or attainable. And I had a friend who had a girlfriend's dad who was a pilot, and that was the closest I personally had gone to a pilot. And I just met him at sort of social gathering once and we talking about it and he really explained to me how approachable it was impossible. And this was well before Hashicorp was sort of, I guess had sort of any financial success. For me personally it was before that. And so it made me realize, oh, I could start doing this now and it's, it's possible. And so I started flying. And what's really interesting to me is flying is fun, it's great, it's. I don't think it's actually too difficult as like, as a process. But what I really got into and I think what attracts so many engineers into flight as well is how you have to have knowledge about all the airplane systems and regulations and things like that. And especially, especially for engineers, like the rules around flight and stuff are actually very calming in a certain way. It's a very rigid system. You know exactly what to expect when you get in there. And it's, it's. Yeah, it's really nice. So flying in general seems like hard and dangerous but like you've gone to the extra level of creating your own aviation software. Like what, what does that even mean? And yeah, yeah, well, I would never ever put my software in a cockpit in flight. All, all the software I've written around aviation has been to help me with pre flight planning, so weather analysis, producing reports, things like that. Basically, you know, when I was going through flight school and then I got my license and I was going through the practice, I just realized I was doing the exact same route tasks in order to pull weather information from here. Certain like reports from various points along flight from here and these were different websites and so I've sort of written some tooling to help pull that down automatically for me. But it's still sourced and know I'm not generating the data and I'm not putting that in my airplane at all. I'm, I'm reading that ahead of time. Yeah, it's fascinating how much like individual flight, like private flight, aviation has like changed because I think about like so my mom started learning how to fly in like 2007 I think. 2007, 2008. Still pretty recent. Yeah, but like since then like it was pretty, it was like pretty manual, a lot of paper and like now like my mom and my step had an iPad and they do all their, their pre flight checklists and you know, the plotting the course and everything like with, with the iPad. And it's like interesting how much has changed in that short amount of time. Yeah, I've only been a pilot now for five years, but their iPads were already prevalent. I actually, I mean there's, you kind of need an iPad. I obviously there's so many ways to fly without an iPad. IPad people did it forever. And when you do your private pilot process, like at least my instructor made sure I never used an iPad. I had to do everything, pen and paper, old school charts, all this stuff. And I think that's really important. But just flying for the past five years, I don't view it as optional equipment anymore. You know, I have my iPad on board, but I also have the same software on my phone. Those are my backups. And when I've done subsequent examinations with the faa, the examiner has been very accepting. I mean like happy. Not in the emotional sense. Just like he consider, he considers the answer correct when he asks what are your backups? And I said, oh, it's, you know, my phone. And then if it's not my phone, then it's the panel. And he's. And it's that order, you know, iPad's number one to me, phone's number two. And the panel actually like the charting data on the plane is like last priority for me. And FAA examiners have been like, great. Yeah, I think so long as you have a plan. Transitioning a little bit. So you write a lot about Zig on your, on your personal blog, which is great. People who haven't read your blog should definitely check it out. So we haven't, we've talked to some people, so we talked to Jared from BUN and we've talked to some people who use Zig, but we haven't went really deep on it. So can you tell us sort of what attracts you to Zig and maybe like some of the projects you've been using it for? Yeah, yeah. And I could cross this over actually a little bit in the Hashicorp because I think my attraction to Zig, I guess has been that I've been looking for a systems level programming language that is expressive enough to be productive and doesn't have sort of a nightmarish build system build environment. And so going back actually a little bit to Hashicorp, when we started Hashicorp, you know, ultimately we wrote everything in Go, but when we first started it, when we were whittling down what sort of technology choices we wanted to make for the software we planned to write, it ended up at the end of that process being GO or C. We were, I and my co founder were very comfortable with C. We had written production quality, server side C for years and it was used at a decent scale like we weren't afraid of any of that but ultimately we obviously went with go. We could go into that if you want later. But Zig is sort of similar to me where I think if Zig existed then and it probably would have to be more stable than it is actually today. But if Zig existed In say a 1.0 form or nearly 1.0 form back in 2012, it might have been a different story. I just view it as a really great successor to C in a being already comfortable with circumstances. I, I absolutely love using Zig and that's, that's where I've really found its niche for me. In your opinion, what benefits does it have over something like Rust? I think there's like superficial benefits for me. I know I started with Ruby and Ruby always had this mindset of programming should be fun and, and I think that's a personal thing. Like I don't think that's a, I think it's a very subjective thing and so I'm not saying that Rust isn't fun but I can absolutely say Rust is not fun for me. I. Every time I've written Rust and I've written small projects, you know, I've never done anything big but anytime I've written Rust or read Rust I read a lot of Rust code. Still to this day I just, I'm not happy doing it. It's not really fun to me and I don't, you know, with Zig, again a personal thing. Just saying for me it's really fun, really enjoyable. I think on the non personal side I think memory safety is really important of course but I also, I, I like having sort of languages that are very linear and I know not know exactly but I have a really good sense of how they're going to transform down into machine code. And I felt like with Rust I felt like I was always programming for the borrow checker and it also wasn't always super clear to me. Maybe this comes, this probably comes with experience but at least as a beginner it wasn't super clear to me how exactly that was going to get lowered into machine code. And with Zig I don't feel that way at all. I feel like every single line I have a fairly intuitive understanding of what kind of machine code that's going to produce. You know the con is that it's not a memory safe language in the same way that Rust is. It's not quite, it's not nearly as bad as C But it's not as rock solid of a guarantee as like Rust is going to give you. And some people view that as a philosophical, like hard line. No, but for me I think it's great. So you've been building some side projects with Zig Recently I've seen you've been working on a terminal emulator. How has that been going and what are some like, challenges of building a terminal emulator? Yeah, it's been fun. It's, it's a, it's a fun project. It's something I never set out, never expected that I would be working on. Even when I first started it, it was a project to learn a bunch of different things, Zig. One of them GPU programming, another just the terminal emulation layer in general. Like I just wanted to learn. I didn't expect that it would become a project that other people used and very feature rich and things like that. And I think as time went on I just realized how much, how much opportunity is to make a better terminal emulator and also like how much opportunity there is to sort of improve, I think terminal emulation at its core. Like not even the app side of it, but like what, what programs running on the CLI can actually do. And so yeah, it's been a lot of fun. There's like 800 beta testers right now. I plan to publicly release it this year. Totally a product of passion. Like people ask all the time, like, oh, did you leave Hodge Script to work on this? Are you starting another company? Things like that. Like, no, not like, none of that, like total passion project, but it's been a lot of fun. That's awesome. Strong believer in having a good passion project. We'd like to thank our sponsor this week, CodeCrafters. CodeCrafters makes programming challenges for experienced software engineers. Instead of spending your weekend grinding leetcode challenges or finding some side project to contribute to, you can spend your weekend rebuilding one of the cool open source technologies we all use and love today. They have a whole bunch of cool challenges, things like build your own BitTorrent, build your own git, build your own Docker, and so many more. They support all the popular programming languages for these challenges. It's really cool to be able to dive into the deep inner workings of these dev tools, unpacking the binary protocols that they use and seeing how they really work. I've gone through a few of the challenges now and I'm always surprised at how simple the binary protocols are. It's really fun to get to unpack the lower level details Another cool thing about it is that it really feels like a community experience. You can see other people's solutions, there's comments, so it doesn't feel like you're learning in a vacuum. It's it feels like other people are there. Besides the content, even the user experience is targeted towards experienced software developers. For example, instead of tying you to a custom in browser experience, CodeCrafters lets you use all your own tools so you can use your ide, a text editor. All you have to do is push up to codecrafters. They run the tests and they show you the results. You really don't even have to go to the website if you don't want to. To try out Codecrafters for yourself, visit Codecrafters IO DevTools FM. There you'll get a 4, 40% discount. You'll be helping out the podcast a little bit too. If you'd like to sponsor DevTools FM, head over to DevTools FM sponsor to apply. With that, let's get back to the episode. Maybe we can like transition here into talking about Hashicorp. Speaking of fashion projects. So you said we'd founded, you'd founded hashicorp back in 2012. What was sort of what were you all working on in the beginning? What did you found Hashicorp to solve? Yeah, so when it, when we, when we initially founded it, we only had shipped Vagrant as software, but both my co founder and I had written down a number of other ideas that we wanted to pursue. So it's always hard to remember the exact list because there's a lot of stuff we didn't end up building. But of what we built pretty much everything up to the, you know, up to now as far as I'm aware. But everything we built was on there except for Vault was a little different. Vault wasn't. We thought Vault like we thought security would just be sprinkled across all the projects. We didn't think we would like centralized secrets in one that ended up becoming more apparent as the right solution when real life hit us. But early on planning, that's how we thought about it. But the real impetus was I we I graduated college, I moved to San Francisco Bay area, worked in the startup environment and I was writing all these sort of handgrown Python based automation infrastructure automation tools and I was going to social events and realizing that everyone else there had the same problems I had. And so that was one thing that pushed me to think, hey, maybe I should start an organization that focused on these problems for everyone else. And then the other thing was that Vagrant already existed and Vagrant was getting pretty popular at the time and it was a total side project. And I was finding myself personally working a normal 40 hour week job that had nothing to do with Vagrant and then going back to my apartment and working, you know, four to four to eight hours sometimes a night on Vagrant and then going to sleep, waking up, going to work and to cycle. And I just, I recognized even then that that was not sustainable. So I that sort of put those two factors, pushed me to start Hashicorp. That's awesome. So back in 2014 you released the Tao of Hashicorp. Can you explain how your thinking at the time influenced it? The thinking was pretty simple. It was, by 2014 we were starting to really hire people, grow quite significantly at the company. I think, you know, around that time we, at least I don't know if it's 2014, but when we started thinking about writing down the towel, we were sort of at the 10 person inflection point in the company. And what we realized was we needed some sort of written down description of culture and what we wanted to find as we hired so that everyone at the company sort of was aligned on more than just, I guess, vibes. And so we, and, and it wasn't just human side, it was really product design was the focus of the TAO originally. It was, you know, as we delegate more people to work on projects and commit and make releases without me or Armand's involvement, how do we make sure that they're delivering software that sort of feels like our software, I guess, more or less. And so the TAO is what came out of that. It was sort of a codification of our design principles when it comes to technology. You know, I find this interesting. I think there's, and especially in that time period. But in general, when I think of about a lot of the sort of great companies that existed, I mean, HashiCorp being one, you know, I think about Heroku and what they did in the early days, I think about Linear today. There's always been this like early, early piece of writing around like who they are and how they operate and what they do or their, you know, theory, whatever. So I mean you had the towel of Hashi Corp and then Heroku. I think famously it was what the 12 Factor app or something related to that was what they did. Linear has like the Linear method, which I think is, is this other piece of instrumental writing. I don't know, I don't really know where I'm going with this. But I think that it is, it is something interesting where like there are these, like really important early works, these early posts that companies write and talk about really like who they are and what they do and just wondering how you kind of get there and like, what that looks like. Like what? What? Yeah, I don't know. I mean, because. So this is 2014, you'd like. You didn't hire someone until you hired like one person. Like a year. A year in. Right. Yeah, about. Right. And then you're starting to hire more. Roughly. Roughly. Yeah, Yeah. I don't know. You know, it's not something I've thought too much about. So I don't. Like, I don't know. But one thing I do know is that I think it felt like, to me, at least, that I had a different approach to what I wanted infrastructure software at the time to be. It feels like today it's sort of hard to look back, and I'm not trying to take credit for this at all, but just the way I felt in that moment versus how I felt today, it feels like today infrastructure software is in a much better place. Even though it's super complicated. Like, I think Kubernetes is complicated. I think that. I think the things that Hashicorp did are complicated. But looking back, what I've said before is that it felt like as an. I did infrastructure management for a company for about two years. And it felt like during that time all infrastructure software was written for the machines first and the people second. And I think possibly due to my background in Ruby as an app developer, and also one thing I've always given credit to is just this short, weird experience I had at the Apple Store as a retail employee, but just the culture that even the retail store at Apple had. I think those two things put together when I got in, when I transitioned into the infrastructure world as a profession, I just thought that the software needed to be flips up, flipped upside down, to be focused on the human side first rather than the machine. And so that, I think is part of what we wrote down in the tao. In a certain part, there's one element of the TAO which ended up being sort of the guiding principle for the entire company, at least the time I was there, which was workflows, not technologies. And it was this idea that we designed. Like one of the first things I did with every piece of software that I designed then and now to this day is, you know, what some people would call readme driven development. Now, that word certainly didn't exist then, but I would actually, and I've talked about this publicly as well, I would create either a bash script or a make file or something where I just pretended the software already existed. It didn't do anything, it just echoed output into the terminal, maybe with some sleeps to make it feel real. But I did that with Terraform. So you know, I could run through like Terraform plan, Terraform reply, I'm running some stuff and I would just sit there usually on an airplane at that time in my life when the Internet was bad and stuff. And I would just sit there and sort of like pretend, put myself in that environment, run these commands and then gauge how I felt. Like, was it fun to use the software? Was it intuitive? What the next step was? What sort of flags am I going to need? What sort of functionality do you think would exist? And that gave birth to sort of what we would then back up into the technology from there. And I think that was a different way of thinking at the time at least it felt different from the way other people were. I think today it feels a lot more. Everything feels a lot more human oriented. Yeah, I love that way of defining software. I have a few NPM packages and all the time I just start with the readme, I start with the API, I play around with it trying to make that feel good and that's when I dive in and try to like actually flesh it out. Yeah. I think one thing that I give Armand credit for bringing to the table is I think I was an extremist throughout this process back when we started the company where I would really start reading and move back. And Armand has a much stronger academic sort of fundamental computer science background and he brought this idea of let's do that, but instead of just working straight back, let's do the same thing. Given that end state we want to reach. Let's talk about sort of the core, I guess abstractions or modeling of the software and. And then let's meet in the middle because a good example I'll just continue to use Terraform is that, okay, we had this CLI that I had designed but then there is this idea of okay, we have, are these little state machines, are they nodes in a graph? What kind of algorithm? You know, given that state machines and graphs are well known things that have well known operations, are those operations useful in Terraform environment? You know, do you need to traverse a graph and then traversal, we quickly realize is exactly how you're going to do apply. That's how that's going to work. State machines like do you have like, does one state machine move at once? Can they move in parallel? Do they have to be aware of each other? Because there's a whole body of research in terms of state machines triggering other state machines and things like that. That's pretty much, at least at the time, all the research we read was how online gaming systems worked were like giant distributed state machines. And so there was a sort of rigorous. That Arman brought to the whole process, which I've taken with me to this day. And basically, when we worked on these projects, we would go on both sides, but we started the core, we started the cli, and we both simultaneously marched towards the middle. And I think the most, for me, in my mind, the thing that stands out the most is Vault. When we did Vault, we finished vault 0.1 in six weeks. And we didn't have a working binary until about two days before we publicly released it. We. We developed it all using unit tests and this design document that we had. And about two days before we. Probably a week before we released it, because we had a bunch of. We had some early security testers, we produced a binary and it worked. And we're like, okay, like, that's interesting that you could have these, like, strong designs on both sides, backed by tests, and move to the middle and actually produce software that, you know, has a lot of bugs but also works. Okay, so you created a lot of tools at Hashicorp. We've talked about a few. Vagrant Terraform. But what was your favorite to work on in the early days? And which one do you think had the most impact on the infrastructure ecosystem? It's probably the same for both. I'm not trying to pick the easy one out. I've always. I've been really consistent in saying that my favorite project ever worked on was Terraform. I also think that it ended up. Of all the projects we made having. And I would say it has a really huge impact on the. On the most people in infrastructure. It does feel like, in terms of actual. Like. Well, no, I think Vault has a comparable impact in terms of actual usage. I mean, it's less exciting to talk about, less people have to know about it, but it is very, very widely used and used to obviously protect some really important pieces of information. So I think that the impact. Vault is huge. But Terraform to me, was always the one I was most excited about. It was also the project that when we started Hashicorp, I had the clearest understanding of what I wanted to do. I tweeted this a few years back But I actually used to have a Tumblr blog. And on my Tumblr blog I posted. This is like in 2010, I posted a blog post where I basically outlined my desire for Terraform and what exactly I wanted it, how exactly I wanted it to work and ask someone to please make it. And no one did. And then we reached this point where I needed it and I was like, well, I guess I'll do this. So I always had this really clear. I published that blog post the day that AWS released Cloudformation, because I saw Cloudformation and I thought it was really cool, but it was not the way I would have done that at all. And so I wrote down, this is a great idea, let's do it this way instead. And that ended up becoming Terraform. Awesome. So you, you spent a very long time at Hashicorp. You were the CEO for a number of years, the CTO for a few years after that, and then you transitioned to being an individual contributor for the last two or three years that you were there. So what was that experience like? And were there any strange dynamics to your reporting structure after you became not the CEO? Yeah, it's. I think so. I started Hodge Corp when I was 22. It was the first startup I had ever like, first venture backed startup, and then only to date, I guess it was, it was my first venture backed startup that I'd ever launched. And the largest company I'd ever worked at prior to starting Hash Corp was about 45 people. And so I had no idea going in, what, what it takes to start a business, what a CEO really does, what, what sort of the responsibilities would be for an enterprise company. We didn't know it, it's an enterprise company, we started it, but as it got there, like sort of all these things. And so, you know, I was a CEO for, I don't know, four or five years. And you know, that was through a few fundraising events and hiring up to maybe 20 to 40 people somewhere in there. I just don't remember the exact number, but 20 to 40 is a solid range somewhere in there. And sort of what I realized was as the company got bigger and as our mission sort of grew and things like that, I started to realize how real the CEO job was. You know, I think in my mind before I thought it was a pretty hand wavy sort of sort of title and that's just my ignorance at the time. And when I started to really realize, oh, this is what a CEO does, like this is what the responsibilities are. And that was at Like a baby level. Right. Like we were a tiny company. But even at that moment I realized that it was not something that I was super comfortable with and it was not something that I derived a lot of pleasure doing. And so to be explicit, like things like executive team building, financial planning, three to five year sort of business outlooks, I could, I could, I could paint, especially at the time, I could paint a ten year technical outlook of what I wanted. But three to five year business outlook was really tough. Things like that and talking to customers and thinking about how to talk about the company in a way that resonated with non technical people, all that stuff was just rough. And so I decided to talk to Armand and we, you know, long story short on that there's a lot more that happened, but just to cap it up really quickly, decided that bringing in an outside CEO would be the best stepping down into a cto. And so then I was CTO for a number of years, Genuinely enjoyed it. I think that there's definitely a parallel universe where I just stayed CTO for very long, much longer time and I'm totally happy. The realization I just came to with the CTO role was I had this thing I liked, but then I had this thing that was pure, 100% love, which was engineering and building software. And so at a certain point with the CTO role, when the company started doing much better, I thought it was in a much more healthy, mature position as a company. I talked to Armand and Dave, our CEO, ended up hiring and just said like, I, I kind of want to take like start, start taking some like more selfish steps. I guess I want to be able to get back to what is just for me personally, my true passion, which was engineering. So then I became an IC and, and the reporting structure was. Yeah, I mean, I'm sure it was weird for a lot of people. It's hard because I don't think anyone told me that to my face, but I tried my best. I thought the culture was in a really good spot where I, I tried my best to be on the same sort of playing field and to never take advantage of my position as founder and things like that. I've said before that it's hard to know what I don't know about how people felt about that situation, but I don't think I did too bad. Yeah, yeah, I thought it was like a really admirable sort of transition to do. And you know, there's this acknowledgement that we end up putting ourselves through a lot of pain for not really just Acknowledging what we actually like and what we actually enjoy. We just like, this is the thing that I need to do. Or like, I feel like I, you know, should be in this place. And you know, there is this nice freedom of just saying, actually, I just love this. I'm just going to do it. One thing I've told people is that like, people are like, how do you know? Like what, how did you define this something? And I always told people like it was engineering or not engineering, I mean, coding. Let's just pare down to coding. Coding was the thing that I always made time for. Even when I didn't have the time I made for it. So, you know, I would sacrifice, I would go to bed and sacrifice sleep. I would work in situations that were not conductive to working. I would work on work, let's say code. I would code on holidays. I remember one time I broke up with a ex girlfriend and I was having a tough time and the first thing I did is I went home and just, I coded for like eight hours straight and shipped a bunch of stuff. And it's like, it's, it's how I had fun, it's how I grieved. It's how like everything around it was like, that's what filled the hole. And so, and to this day I love it. And so that's how I knew it was like I was never making that extra time for the CTO management tasks or sales tasks or things like that. It was even though in the moment I didn't have a bad time doing them, I wasn't gonna make that extra, extra, extra time to do them. And so that was my signal. Yeah, that makes a lot of sense. I was just sort of thinking about that transition in terms of like power dynamics because it's something that I think that especially as founders, it's easy if in, you know, it being your first company too, it's easy not to like internalize like, oh, you know, I'm in a different part of the reporting structure. I have a manager who is like at some point in my reporting chain, you know, and now like they're, they're supposed to be managing me and like how do they do do that? And I don't know. That's a, it's an interesting transition and I think that like something that's always good to talk more about is like how we navigate power structures and organizations because it's the reality of it. So you've helmed a lot of very large open source projects both at work and in your Personal time. What are some things you think about when trying to create these open source projects and foster a community? It's changed. So when I, when I started the open source projects, like initially, you know, early 20s, I didn't think too much. I would say at the very beginning I just published them on GitHub, put a permissive license on them and like, let's go have some fun, like open an IRC channel or something. I think now especially like as I'm starting this terminal emulator, just from my experience, that changed considerably. Like I'm making a much more concerted sort of effort to think about sustainability from the beginning, to think about culture of the community from the beginning and things like that. So for example, culture of the community. I'm doing this very prolonged like closed beta period. And a big part of that is just for my own personal well being. I don't want too much pressure. But another part of that is because by doing this slow growth, controlled growth, I think that you could much more carefully sort of build a community that embodies what you'd like it to be. If a million people show up on day one, it's sort of the wild west in terms of what's the correct behavior and what's going to be tolerated and things like that. But if you sort of slowly grow, then that gets understood. So like, at this point, you know, I've promoted mods in my Discord community and there's a pretty clear understanding of how things are run. And then from the sustainability side, it's, for me it's less about, you know, think, you know, I'm privileged to be in a position where I'm not too worried about supporting myself through this project. That, that's not an intent at all. But I do want to build a project that I could sort of help contributors in some way or help upstream projects. And so I'm actively having the discussion of, you know, people have already asked, even even though it's not public, people have already asked like, hey, can I donate to the project? And things like that. And we're not, I'm not taking any yet. But I have this idea where it's like, even if I don't need help, I depend on a lot of projects that do need help and so can I. If someone wants to help my project, can I pay it forward to those projects and use this as a mechanism to sort of pay it forward. Likewise, if I have someone that's contributing, maybe they're doing it in their free time, that they don't really have a lot of. It's like, can I help them in some way? Where Same thing. Like I don't mind working on it a few hours a night, it doesn't cost me anything. But if there's someone who could be contracting instead and it would be helping their life, could I, you know, help that amount? Like, I'm not trying to pay a full time salary, but I really like, like what the Zig project does actually from a foundation perspective. They don't. They only employ like one person, I think, or two people, but they pay a lot of contributors, about 5, 55 US dollars an hour. You know, it's not. You could contract for much more, but the idea is that you also don't need to make significant contributions for free to this project. Like you can, if it's an approved body of work, you could get a contract at 55 an hour and it's something. And so like I've been thinking about that a lot with, with regards to my project as well. So, you know, it might feel like putting the cart ahead of the horse. It sort of does for me sometimes. But you know, it's, it's something that I now worry about that I don't think I ever would have before. Yeah, that's, that's a cool way to approach it, especially in the JS community. Like there is that problem of the big shiny project in front of all of the foundational projects, kind of just like sucking up all the money. And then you get people like the, the JS core guy who just like can't get anybody to donate to him because they don't even know that they use his project. Yeah, yeah. So this is something, I mean I've, I've, I'm forming a lot of thoughts on. I'm also like, you know, through, through my own project trying to take action. But there's some other people I'm talking to where I'm trying to make this, I don't know, different, change it a little bit. Yeah. So building a business around open source can be challenging. I mean you are fundamentally building a business on the software that is like free and open. But at the end of the day a business has to make money. Um, and so choices like what is the right license when you're starting a project can be important and hard to make. Because when you start an open source project you may just like, oh yeah, I'm just like doing this, I want everybody to have it. And then you end up organically building a business and you realize, did we make the right choice? Did we not make the right choice? How do you think about that today? Yeah, I mean, I think, I think about a lot differently, especially having been an entrepreneur that went through commercial open source like process. You know, I think that I could speak for myself and a lot of other open source creators that I've met, which is, you know, I, and I say this honestly, like all the projects I started ahead of Hashgrp Existing, for example, I never intended there to be a business. I never thought there would be a business. I never thought anyone would use them. So I think that a lot of projects start that way. There's no commercial thought or, or I guess like planning involved because the, the commercial side of it is a side effect of having community success and it's, it's a side effect of, I don't, I think some cases it might be like greed oriented. In my case, it really came down to, and we talked to this, we talked about this recently, but it came down to, you know, I had to make a choice between whether I worked full time on the job that paid my rent or whether I tried to pursue commercializing open source. So I could work on that to pay my rent, but I couldn't do both. Right. Because I was out of time in my day and so I needed a way to sort of live day to day. And so that was sort of my motivating factor. So I think that if you're in the position where you have a project idea and you decide open source is the best solution for that project idea, but you also already know that you want to commercialize it, then I think you're in a much better position to figure out what license you want to do besides licensing. I mean, just like what monetization strategy. Like, do you want to do SaaS, do you want to do open core, do you want to do dual licensing, do you want to do support and services, I think you could come up with that far in advance. Um, the, the, the trouble that I personally ran into and the trouble that I see a lot of people run into is you never ever plan to commercialize. And so you're stuck in a certain path. And you've also maybe by the time you've realized what you want to commercialize, you've maybe, you know, some might say given away too much and then you end up being your biggest competitor yourself. And I think as big of a proponent as I am of open source, I think that's, I don't blame open source or anything like that. I don't think open source is necessarily good or bad about it. I just sort of blame the fact that it's not planned in advance. So you're dealing with the consequences of decisions earlier. Yeah, I think your goodbye letter for Hashicorp really echoes that. At the start, you share an anecdote about how, oh, we were just a couple of teenagers thinking, oh, what if all the big companies used our software and you start in that place of what if we just get it into their hands and you don't think about that future of like, wait, what if that happens and we have to like make a living out of that. Yeah. And it's not just yourself. I think a lot of the pressure that ends up happening if you, if you go the commercialization route and you build a company and stuff, a lot of the pressure you end up happening is realizing that. You know, when, when we started, when I started Hashicorp with Armand, like we didn't care if we failed. We said if we failed, it's cool. Let's, let's just, let's try something audacious because if we fail, we're just gonna, you know, go find another job. And I know finding a job, especially today nowadays is much, much harder. We were in a different economic environment back then, but, you know, that's how we thought as 22 year old kids. Like, you know, it may be a little bit insensitive, but that's how we thought about it at the time and we didn't care. But then you start hiring people and then I remember at a certain point I was having sort of like trouble, you know, I guess sleeping as a very specific thing. But I was starting to have like daily anxiety for a short period of time because I realized in a particular moment when the company wasn't doing very well, I started getting a bunch of anxiety because I realized that there are people that depend on this paycheck for their mortgages and they have kids and I didn't have kids, so I could care less about like failure for me didn't matter, but failure for someone else could really, really affect their life. And so there's a certain point where that hit me and the company itself was struggling and things like that. And I was, I started, it was getting really heavy for a brief moment there. I will say there's a very specific zoom meeting I had where we were trying to find commercial fit for something. And the person I was talking to on the zoom meeting at a very normal working hour was in a like one bedroom apartment with three kids and There was two kids just like screaming in the back and they had like noise canceling headphones on, talking to me. And I remember getting off that meeting and being like, I don't want that person to have any more stress on their life than what I'm already witnessing. And so like, it was moments like that that I think whether it's open source or not, like as a founder of a commercial entity, start being a really big catalyst in how you make decisions. I think, yeah, I mean, I think open source is hard because it's just fundamentally human. Right. It maps a lot to humanity. It's like we do it, we want to build these creative things and put them out in the world so people can enjoy them and use them and then we get validation from that. But then the realities of our own needs and especially, you know, taking on other people's needs as you build a company. And I just, you know, it is a hard decision. It's one of those things where it might not look hard up front, but it becomes important. And you know, I think, you know, there are a lot of, it can be a big source of drama and a lot of other stuff, but I think that people have to keep in mind that it's like a very human thing. And like, you know, it's, I think even the, when people, when companies reconsider license decision or whatever, it's like often needs driven is thinking about like, we're building a sustainable business and trying to build a sustainable business in a competitive market. And the thing is, it's like if you're giving away all your value, as admirable as it is to do that in open source, it's a real consequence. Like, yeah, maybe somebody with three kids living in one bedroom apartment might lose their job because the company's like trying to tighten up on their budget or whatever. And that's a real tangible impact. And it's like, is it worth, as a licensing change worth that? Absolutely, yes. If it means that like people in that organization can keep their jobs. Yeah, totally. I mean the, it's the human cost of these things that I think gets missed sometimes. Yeah, I think, I mean, as a very, maybe overly generic statement, I think whether you're on hacker news or Twitter or something, in my sphere, I don't think this is unique at all to tech. I mean you could, but definitely in tech, I think that people have a tendency to oversimplify decisions. You know, a very reductionist way of thinking about everything. I, you know, I, you know, I want to think that the World is simple and there's very easy decisions to make. But you know, my experience is whether it's, you know, again, not even related to open source, just related to running a business. Almost every decision I made was hard and had nuance attached to it. And that's the hard like the really like stressful part I think of being in that position. I think one I've talked very publicly on before and, and people used to reference it a lot, but it's fairly outdated at this point was when you know, hashgraphs a remote company, remote first company. And I used to get a lot of flack on the regular people being like, oh, but you're not actually remote because you don't hire in this country or whatever and at a certain point you can still find it. I never took it down. I mean it's, it's, it was accurate for the moment. At a certain point I got really fed up because I saw someone else post something remote and someone said that to them and I was like, okay, like I need to set this record straight because. And I posted this comment about the legal complexities about hiring people anywhere and how you can't really. And you know, my point was that, you know, we like to think in tech because the Internet you could, you know, from our countries we could access the world. It feels like, right? Like you just type in a thing and you could go anywhere. That's what it feels like. But then the point I was making was like, you know, the world and from a human hiring perspective is so unequal and so, and we're bound by laws and they hold us back and things like that. And so I think, you know, similarly in every other non HR related decision, I think in technical decisions and things like that, it's never been that easy to make these decisions. Speaking of not easy decisions, picking a license can be pretty hard. Earlier you mentioned that there's some new interesting licenses out that you might have chose back in the day if they existed. So what are these new licenses? I don't know if I would have chosen them, but I think that, you know, I think importantly when I started my open source projects, you know, the only real contenders out there were the very, very permissive sort of set of licenses. You know, you had the gpl, mit, Apache, bsd, you know, the, the old guard so to speak, of open source licenses nowadays. But that was it. There was no, there was no discussion about licensing as a form of monetization. I'll be clear that there was only one dual licensing existed where there was a lot of GPL projects where you could pay money to use a different license that was non gpl. But no one thought at the time. I mean, I don't know today, but definitely a time that was not viewed as a viable venture growth business. It was viewed as a viable like small company viable individual choice, but not as a venture growth business. So it wasn't really a discussion point. I think nowadays you're seeing a really concerted effort towards building out additional licenses with the intention of some sustainability while being able to share source and build communities and things like that. I think there's a lot of uncertainty in that space. Like there's clearly not one that everyone agrees on and it's like the best approach forward or things like that. But yeah, it's, it's. I think it's still interesting to look at. So I'm not sure I would like say I would pick one yet. But I'm just glad that the community as a whole is beginning to. Not beginning, it's been a few years, but is exploring these alternative options with the, with the thought of sustainability in mind? Yeah, absolutely. It's definitely necessary. I mean the pain and the sort of like back and forth that we had is like obvious that like this is an area that just needs more focus and needs more people to try more things. And I'm hoping that we'll like find good like you're building a business, you have an open source product, like here's a good license to like do that and get the best of sort of both worlds. Yeah, to be like on the, you know, I think there's two extremes, right. There's the extreme of like totally like GPL level free and open source. And then there's sort of the side that it's totally closed source, proprietary. And I would hope that even like open source absolute people, I would hope that everyone agrees that we definitely don't want a reality where it's just easier to make everything totally closed source for a business. You know, as a developer that builds on closed platforms regularly, like Mac OS for a large, you know, they have an open source portion but a large part of it. I would, even if I had like very few privileges, I would much rather for example have the source code to SwiftUI than to not have it. And I don't have it. And I constantly have no idea how anything works. And if the docs are lacking, I'm totally screwed. And so I hope we could find some point in that where businesses could be successful. We could remain at the Very least the ability to share source, but hopefully to build a community and share and sort of that success in a bit. But I think it's a really open, active question. Yeah, absolutely. So, last few questions, we always end our segments just like talking about the future, some projection or what's next. So maybe something for you is like you're working on this terminal interview, terminal emulator, you know, putting a lot of time in that, you know, could be something that you work on for a long time. But do you. Is there like some business idea or some like thing that you want to do professionally next beyond the project you're working on? Yeah, not currently. There's no concrete idea. Next. And you know, I hope that I'll work on this terminal emulator a long time. I think that there's a lot of technical opportunity in terminal emulation. Even though it seems like a solved problem, it seems ancient, seems boring. I think there's actually a lot there. I've described it as. It's the, it's the text platform version of the web browser. Like web browsers aren't going away. Not trying to say I'm going to try to kill web browsers, I'm not crazy. But I think that there's space for a solid text UI platform and that is what terminals are, are. But at the same time I've said, you know, terminals don't innovate nearly at this. Like they're at like 0.1% of the innovation speed of a browser. So what if you just like bumped that to 5%, like just a little bit, start introducing stuff. So that's sort of what I'm trying to do. I call it my technical philanthropy. So, you know, I think that in life we try to, you know, do social good and we try to do that in terms of, you know, helping our community and things like that. The terminal emulator for me is like the technical bubble version of that. It's my thing of like, thanks to the sort of the success that I've had in the past and I have more time now can I direct my passion, my energy to help make developer lives better in this like way. So that's, that's sort of how I consider the terminal. But other than that, like I'm someone who can't. I'm not going to. I like to stay busy, I like to work. So there's no business idea I have right now, but I'm sure I'll just continue to stay busy and work. Yeah. It's funny how even the name of terminal Emulators kind of speak to that slowness because like, what are we emulating A thing from the 60s? Like, why is emulation still in the name? Yeah, I've actually talked to some of the community about this, which is like, I think at a core you're emulating some old terminals, but then as you start innovating, is it fair, is it accurate? Fair? Will it upset people to call it terminal emulation? Because you have other terminal emulators out there, like Kitty, Alacrity, whatever. And I'm not speaking for them, but a very justifiable response from them if I tried to do something new would be stop. Because it's, you're not emulating anymore, you're innovating and it's making more work for them and it's going to piss them off. And so I've definitely considered like, what, should I use a different phrasing? Should I try to say I'm not trying to be compatible with other terminals for certain features? Like I'm not trying to force them to do it. Like I'm trying to build this alternate text interface platform or something. So yeah, I don't know. Still, definitely a thought. Yeah, we've definitely talked to a few people working in the space. So one of our early episodes were the Fig founders who ended up selling their company to Amazon which was, you know, they were doing really interesting work and then, and they had plans to sort of rebuild a terminal like long term. And then the Warp founders we had them on and they're doing really interesting work around that. So I think it is a nice space and I'm glad to see people working in it for sure because it's like developers especially spend a lot of time in a terminal and you know, improving that experience is important. So on the podcast we'd love to ask a future facing question about the field the person's been involved in. And you've been involved with cloud and infrastructure for the better part of a decade and some change. So what do you. Yeah, your life for the most part. So what do you think the future of cloud and infrastructure looks like? Is it more complicated or less complicated? Yeah, I think. Okay, so I'm not actively working in this space anymore. That's my disclaimer when I departed Hashicorp. Sort of my thinking on it, and that's my thinking right now is that I think that it has to be less complicated. I think that we went from a place when I started Hashicorp where I felt like there were very limited set of tools that were very constrained and very difficult to use. And we're now at a place where there are a lot of tools that individually are much sort of easier to use, but they have to be glued. You have to glue so many more together to get what you want done. And that feels bad. And so I hope that the future is simpler and sort of reduces simpler in terms of usage, but also simpler in terms of complexity. You know, even using Kubernetes example, I think Kubernetes is fine and great, but I, you know, you. Every time I've used Kubernetes, it's not just Kubernetes, it's like Kubernetes plus like 10 other vendors, projects that are integrated. And that's where it gets really messy. And I think Hashicorpin some extent is part of that problem. You know, you vault on its own, needs a lot of other tools to be used. And so I think there's opportunity there to simplify. And I think that's the future. Some people, when I say that, think that I think the future is just like past, like platform as a service. Like you're just going to have Heroku again. And I loved Heroku and I love some of the newer Heroku like things, but it's so hard to fit a perfect box around everybody. So I still think that even, even if that grows again and captures a large part of a certain part of the market, I think that the other side, the more complicated, snowflakey side, like has to have just simpler, better tooling. Cool. Well, that wraps it up for our questions this week. Thanks for coming on the podcast. This was a really fun getting to see your views on your past decade of work and to talk about what you're working on now with Zig and your terminal emulator. Thanks so much. It was great talking to you. Yeah, Mitchell, thanks for coming on. I mean, your work has definitely impacted everybody who is like basically in this space. And you know, it's interesting for me to talk to you after having like used some of your open source projects at the beginning of my career. It's like, that's such a fun thing. So really appreciate you having me on and it was great. Thanks so much, Sam.