[00:00:00] Intro
Mitchell: all the projects I started, Ahead hashicorp 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, planning involved because the commercial side of it is a side effect of having community success.
Andrew: 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 cohost, Justin.
Justin: Hey, everyone. Uh, we're really excited to have Mitchell Hashimoto on with us. Mitchell, thank you so much for joining. Uh, so you, uh, Famously started HashiCorp back in what was it like 2010, 2012. It was pretty early on
Mitchell: the company legally incorporated 2012, I think.
Justin: Yeah. It's, it's wild to me. Like, I didn't realize how much y'all had done. Cause 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, uh, like out of college and I didn't realize that y'all had 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, dive in, would you like to tell our listeners a little bit more about yourself?
Mitchell: sure. Yeah. Um, I think, uh, you, you covered the high level, but, um, I'm an engineer by background engineer by passion. I've always been heavily involved in, uh, creating open source software, for the past, um, 10 years or for about 10 years, I was really heavily into infrastructure software as a focus, but, I have worked jobs all over.
I'm currently working on a terminal emulator. I'm sure we'll talk about that a little bit, but, um, yeah, that's, that's just me personally. That's sort of, uh, that's me.
Justin: That's awesome.
[00:02:02] From Coding to Cockpits: Mitchell's Journey into Aviation
Justin: Um, So before we start talking about like Hashcourt, uh, you're also a pilot on the side. So I really love this cause my, my mom and my stepdad are both pilots as well. Just, just private sort of recreational pilots. so how did you get into that?
Mitchell: I mean, the, 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. Um, and, uh, 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, um, sort of social gathering once and we're talking about it and he really explained to me how approachable it was impossible.
And, um, this was well before HashiCorp was, sort of, you know, Uh, 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, uh, it's possible. And so I started flying. And what's really interesting to me is flying.
It's 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 attract so many engineers into flight as well is, uh, how you have to have knowledge about all the airplane systems and regulations and things like that. And, uh, especially especially for engineers, like the rules around flight and stuff are actually very, uh, calming in a certain way.
It's a very rigid system. You know exactly what to expect, uh, when you get in there and it's, it's, yeah, it's really nice.
Andrew: 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.
Well, I would never, ever put my software, uh, in a cockpit in flight.
Mitchell: Um, all the, all the software I've written around aviation has been to help me with pre flight planning. So, uh, weather analysis, uh, producing reports, things like that. Basically, you know, when I was going through flight school and then, uh, I got my license and I was going through the practice, I just realized I was doing the exact same thing.
Wrote tasks in order to pull weather information from here, um, certain like reports from various points along flight from here. And these are different websites. And so I've sort of written some tooling to help pull that down automatically for me, but it's still sourced. You know, I'm not generating the data and I'm not, um, putting that in my airplane at all.
I'm, I'm reading that ahead of time.
Justin: Yeah, it's fascinating how much like. individual flight, like private flight, uh, aviation has like changed because I think about like, so my mom started, uh, learning how to fly in like 2007, I think 2007,
Mitchell: Still pretty recent.
Justin: 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 have an iPad and they do all their, their pre flight checklist and you know, the, the plotting, the course and everything like with, with the iPad.
Mitchell: 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 are 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. People did it forever. And when you do your private pilot process, um, like, at least my instructor made sure I never used an iPad.
I had to do everything pen and paper, old school charts, all that stuff. And I think that's really important. But, just flying for the past 5 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. What 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, he considered, 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 then it's that order, you know, I've had number one to me phone number two and the panel actually like the charting data on the plane.
It's like last priority for me. And examiners have been like, great.
Justin: Yeah. I think so long as you have a plan, um, Transitioning a little bit.
[00:06:23] Exploring Zig and Terminal Emulation
Justin: Uh, so you write a lot about Zig, uh, on your, in your personal blog, which is great. Uh, people who haven't read your blog should definitely check it out. Uh, so we haven't, we, we, we've talked to some people. So we talked to Jared from Bun and we've talked to some people use Zig, uh, 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?
Mitchell: Yeah. Yeah. And I could cross this over actually a little bit in HashiCorp because I think, um, my attraction to Zig, I guess, has been that, uh, I've been looking for a systems level programming language that is expressive enough to be productive, um, and doesn't have sort of a nightmarish build, uh, system build environment.
And so going back actually a little bit to HashiCorp when we started HashiCorp, um, 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 plan to write, um, it ended up at the end of that process being Go or C, um, we were, I and my co founder were very comfortable with C.
We had written production quality server side C for, uh, Years, and it was used at a decent scale. Like, we weren't afraid of any of that. but ultimately, we obviously want to go, uh, well, you know, we could go into that if you want later. But Zig is sort of similar to me where I think, you know, if Zig existed then, and it, 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, um, in a, you know, being already comfortable with. See, I. I absolutely love using Zig and that's, that's where I've really found its niche for me.
Andrew: Uh, in your opinion, what benefits does it have over something like Rust?
Mitchell: I think there's like superficial benefits for me. Um, I, no, I started with Ruby and Ruby always had this mindset of programming should be fun. And, um, 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 any time I've written Rust or read Rust, I read a lot of Rust, still to this day, Um, I just, I'm not happy doing it. Uh, it's not really fun to me. And, I don't, you know, with, with Zig, again, a personal thing, just saying for me, It's really fun, really enjoyable.
I think on the non personal side, um, I think memory safety is really important, uh, of course, but I also, I, I like having sort of languages that are very linear, and I know, I not know exactly, but I have a really good sense of how they're going to transform down into machine code, um, and I felt like with Rust, I felt like I was always programming for the borrow checker, and it also wasn't always the same.
super clear to me. Maybe this comes this probably comes with experience, but at least in the 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, um, 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.
Yeah,
Andrew: Uh, so you've been building some side projects, uh, with Zig recently, uh, I've seen you've been working on a terminal emulator. How has that been going? And, and what are some like challenges of building a terminal emulator?
Mitchell: that's been fun. It's a, 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, the terminal emulation layer in general.
Like I just wanted to learn, I didn't expect that it would be come 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. Um, totally a project 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.
Justin: That's awesome. Strong believer in having a good passion project.
[00:11:13] Ad
Andrew: We'd like to thank our sponsor this week code crafters.
Code crafters makes programming challenges for experienced software engineers. instead of spending your weekend grinding leak code challenges, or finding some side project 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, get, 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 feels like other people are there.
Besides the content, even these are experiences targeted towards experienced software developers. For example, instead of tying you to a custom in browser experience code crafters, lets you use all your own tools so you can use your ID, a text editor. all you have to do is push up to code crafters.
They run the test 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 code crafters for yourself. Visit code crafters.io/dev tools. Dash FM. There you'll get a 40% discount. You'll be helping out the podcast a little bit too.
If you'd like to sponsor dev tools, FM, head over to dev tools.fm/sponsor to apply. With that let's get back to the episode.
[00:12:40] Founding Hashicorp
Justin: maybe we can like transition here into talking about HashiCorp. Uh, speaking of passion projects. Um, so you said we'd founded, you'd founded HashiCorp back in 2012. Um, what was, what was sort of what we are working on in the beginning?
What was, what did you found HashiCorp to solve?
Mitchell: yeah, so, um, when it when we when we initially founded it, we only had shipped vagrant as software. Um, but, um, both my co founder and I had written down a number of other ideas that we wanted to pursue. So, um, 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. Uh, up to the, you know, up to now, as far as I'm aware, um, but, uh, everything we built was on there, except for vault was a little different. Um, 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, centralize secrets in one.
Um, 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'm, we, I graduated college and moved to San Francisco Bay Area, worked in the startup environment, and I was writing all these sort of hand grown 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 a 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 the cycle.
And I just, I recognized even then that that was not sustainable. So, um. I, uh, that sort of put those two factors pushed me to, um, start Hosh Corp.
Justin: That's awesome.
Andrew: so back in 2014, you released the Tao of HashiCorp. Can you explain, how you're thinking at the time influenced it?
Mitchell: The thinking was pretty simple. It was, um, by 2014, we were starting to really hire people, um, grow quite significantly, uh, 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 on 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, uh, everyone in 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 original.
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, um, 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 tau is what came outta that. It, it was sort of a codification of our design principles when it comes to technology.
Justin: You know, I find this interesting. I think there's, and especially in that time period, but in general, when I think of, 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 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 HashiCorp 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, um, just wondering how you kind of get there and like what that looks like. Um, like what,
what,why, yeah, I don't know. I mean, cause, 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? Is that,
Mitchell: Yeah.
Justin: about right? And then you're starting to hire more in 2014, roughly.
Yeah. I don't know.
Mitchell: you know, it's not something I've thought too much about, so I don't like, I don't know, but I, one thing I do know is that, I think it felt like, to me, at least, that I had a different And Approach to what I wanted infrastructure software at the time to be, um, 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 is how I felt today. It feels like. Today, infrastructure software is a much better place, even though it's super complicated. Like, I think Kubernetes is complicated. I think 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 2 years, and it felt like during that time. Uh, all infrastructure software was written for the machines first and the people second, and I think possibly due to my background and Ruby as an app developer.
And also, um, 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 ups, flipped upside down to be focused on the human side first, rather than the machine.
and so that, you know, I think. Is part of what we wrote down in the town a certain part of the other one element of the town which ended up being sort of a guiding principle for the entire company at least the time i was there which was work flows not technology 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, uh, 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 makefile 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, I did that with terraform. so, you know, I could run through like terraform plan to reply. I'm running some stuff and I would just sit there usually on an airplane at that time of 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, uh, 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 what the way other people were. I think today it feels a lot more. Everything feels a lot more human oriented.
Andrew: 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.
Mitchell: Yeah. I think one thing, um, that I give Arman 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 me 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, given that end state, we want to reach, let's talk about sort of the core, um, uh, I guess. Abstractions or modeling of the software. 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 C.
O. I. 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 terraforms environment?
You know, do you need to traverse a graph and then traversal? We. Quickly realizes exactly how you're going to apply. That's how that's going to work. Um, 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, um, 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 or like giant distributed state machines. and so there was a sort of rigor that Armand 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, um, and I think the most for me, in my mind, the, the, the thing that stands out the most is vault. When we did vault, um, we finished vault 0. 1 in 6 weeks and, uh, we didn't have a working binary until about 2 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, probably a week before we released it, cause 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, um, that you could have these like strong designs on both sides, backed by tests and move to the middle and actually produce software that, that works.
You know, has a lot of bugs, but also works.
Justin: Okay. Uh, so you created a lot of tools at HashiCorp. We've talked about a few, Vagrant, Terraform. Uh, but what was your favorite to work on in the early days? And which one do you think had the most impact on, uh, the infrastructure ecosystem?
Mitchell: And 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, uh, and I would say it has a really huge impact on the, on the most people.
in infrastructure, um, 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, it's less exciting to talk about less. People have to know about it, but it is very, very widely used and, uh, and used to obviously protect some really important pieces of information.
So I think that the impact ball had 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, and this is like in 2010, uh, 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, 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 it.
I'll do this. So I always have 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, uh, that ended up becoming Terraform
Justin: Awesome.
[00:24:34] Transitioning to an Individiual Contributor
Andrew: so, uh, you, you spent a very long time, uh, at HashCorp, you were the CEO for a number of years, the CTO for a few years after that, and then you transition to being an individual contributor for the last two or three years that you were there. So, uh, what was that experience like?
And, uh, were there any strange dynamics to your reporting structure after you became not the CEO?
Mitchell: yeah, it, it's, uh, I think, so I started HashiCorp when I was 22. It was the first, uh, startup I had ever, like first venture backed startup, and then only to date, I guess it's, it was, it was my first venture backed startup, um, that I'd ever launched. And the largest company I'd ever worked at prior to starting Hoshi Corp was about 45 people.
and so. I had no idea going in what, um, what it takes to start a business, what a CEO really does, what, um, 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, um, you know, I was a CEO for, I don't know, four or five years.
And, you know, I, I, that was through a few fundraising events and hiring up to maybe 20 to 40 people have somewhere in there. I just don't remember the exact number, but 20 to 40 is a solid range, um, 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 their responsibilities are. And that was at like a 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 10 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, um, in a way that resonated with non technical people.
All that stuff was just, you know, Uh, and so, uh, 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, um, 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, um, genuinely enjoyed it.
Uh, I think that there's definitely a parallel universe where I just stayed CTO for a very long time. 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 percent love, which was engineering and building software.
And so at a certain point with the CTO role, when the company started doing, um, much better, I thought it was in a much more healthy, mature position of the company. I talked to Arman 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, uh, my true passion, which was engineering. So then I became an IC and, uh, 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 tried my best to be on the same sort of playing field and to never take advantage of my position as founder. Um, and things like that, you know, it's, 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.
Justin: Did bad too badYeah. Yeah. I thought it was like a really admirable sort of transition to do. And, and, you know, there's this acknowledgement that we, we end up putting ourselves through a lot of pain for not really just acknowledging like what we actually like and what we actually enjoy. We just like, no, 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.
Mitchell: 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, let's just pare it down to coding. Coding was the thing that I always made time for, even when I didn't have the time that I made for it.
So, you know, I would sacrifice, I would go to bed and sacrifice sleep. I would, um, work in situations that. We're not conductive to working. I would work on Hall and not work. Let's say code. I would code on holidays. I, I remember one time, uh, I, 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.
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, uh, yeah. 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 going to make that extra, extra, extra time to do them. And so that was my signal.
Justin: 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 and you know, it being your first company to 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 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, cause it's the reality of it.
[00:30:40] Fostering Open Source Communities and Sustainabilit
Andrew: so you've helmed a lot of very large open source projects, both at work and in your personal time. Uh, what are some things you think about when trying to create these open source projects and foster a community?
Mitchell: Uh, it's changed. So when I, when I started the open source projects, like initially, you know, early 20s, um, I didn't think too much, I would say, at the very beginning. I just published, 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, uh, 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, the community, I'm doing this very prolonged, like, close the beta period. And a big part of that is just for my own personal, like, 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 and 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'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. Um, 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, uh, could be contracting instead, and it would be helping their life, could I, uh, 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 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 can 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, uh, you know, it's.
It's something that I now worry about that I don't think I ever would have before.
Justin: Yeah.
Andrew: 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.
Mitchell: Yeah. Yeah. So this is something, I mean, I've, I, I'm forming a lot of thoughts on, I'm, I'm, 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.
[00:34:26] Navigating the Complexities of Open Source and Business
Justin: So building a business around open source can be challenging. I mean, you are fundamentally building a business, uh, on the software that is like free and open, but at 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? Do we not make for choice? Um, how do you think about that today?
Mitchell: Yeah. I mean, I think, I think about a lot differently, especially having been an entrepreneur that went through commercial open source like process. Um, 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 that honestly, like all the projects I started, Ahead hashicorp existing for example, um, 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, the commercial side of it is a side effect of having. Community success. Um, 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, uh, we talked to this, uh, we talked about this, uh, recently, but, um, 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. Um, 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?
Um, besides licensing, I mean, just like what monetization strategy? Like, do you want to do sass? Do you want to do open core? Do you want to do dual licensing? Um, do I need support and services? Um, 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 realize what you want to commercialize, you've maybe, you know, some might say given away too much. Um, 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 necessarily good or bad about it. Um, I just sort of blame the. The fact that it's not planned in advance. So you're dealing with the consequences of decisions earlier.
Andrew: Yeah, I think your, uh, your goodbye letter for Hashacorp really echoes that. Like at the start, you share an anecdote about how like, oh, we were just a couple of teenagers like thinking, oh, what if all the big companies used our software? And you start in that place of like, 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.
Mitchell: 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 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're in a different economic environment back then. Um, but, you know, that's how we thought as developers.
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, um, we didn't care. But then you start hiring people. And then I remember at a certain point, um, I was having sort of like trouble, you know, I guess sleeping is 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, um, 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 was a certain point where that hit me and the company itself was struggling and things like that. And I would. I started, it was getting really heavy for a brief moment there. Um, I will say there was 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 your 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.
Justin: 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, we do it. We want to like build these creative things and put them out in the world so people can enjoy them and use them. And then, you know, we get, uh, validation from that, but then the realities of like our own needs and, you know, and, 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 is 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, you know, When people, when companies reconsider licenses or whatever, it's like often needs driven is thinking about, like, we're, we're building a sustainable business and, 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, it, you know, That's a real consequence. Like, yeah, maybe somebody with three kids living in one bedroom apartment, like might lose their job because the company is like trying to tighten up on their budget or whatever.
And that's a real tangible impact. And it's like. Does it work as a licensing change worth that? Yeah, 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.
Mitchell: Yeah, I think, I mean, as a very, maybe overly generic statement, I think whether you're on hacker news or Twitter or something, I, 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, um, decisions. Um, you know, a very reductionist way of thinking about everything.
I, you know, I, you know, I, 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 every almost every decision. Uh, 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. Um, I think 1, I've, 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, um, you know, has a remote company, remote 1st company and, um. I used to get a lot of black on the regular people being like, Oh, but you're not actually remote because you don't hire in this country or whatever.
And, um, 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.
[00:43:45] New Types of LIcensing
Andrew: speaking of not easy decisions, picking a license can be pretty hard. Earlier you mentioned that there's some new interesting licenses out that, uh, you might have chose, uh, back in the day if they existed. So, uh, what are these new licenses?
Mitchell: 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, there were only real contenders out there were the very, um, very permissive sort of set of licenses. You know, you have the GPL, MIT, Apache, BSD, um, you know, the, the, The old guard, so to speak of open source licenses nowadays.
Um, 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 1 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. Um, 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, um, 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 sustainability while being able to share source and build communities and things like that. Um, I think there's a lot of, uh, uncertainty in that space. Like, there's clearly not 1 that everyone agrees on. And it's like the best approach forward or things like that.
But, um, yeah, it's, it's, uh. I think it's still interesting to look at, so I'm not sure I would like, say, I would pick 1 yet, but I'm just glad that the community as a whole is beginning to not begin. It's been a few years, but is exploring these alternative options with the, with the thought of sustainability in mind.
Justin: Yeah, absolutely. Uh, it's definitely necessary. I mean, the pain and the, 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 a open source product.
Like here's a good license to like do that and get the best of sort of both worlds.
Mitchell: yeah, to be like, on the, you know, I think there's 2 extremes, right? There's the extreme of, like, totally. Um, 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. Um, 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.
Um, you know, as a developer that builds on closed platforms regularly, like Mac OS, um, for, for a large, but, you know, they have an open source portion, but a large part of it, um, I would, I, even if I had, like. Very few privileges. I would much rather, for example, have the source code to Swift UI 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, um, at the very least the ability to share source, but hopefully to build a community and share in sort of that success in a bit.
But I think it's a really open, active question.
Justin: Yeah, absolutely.
[00:47:07] Looking to the Future
Justin: So last few questions, uh, we always end our segments just like talking about the future, um, you know, some projection or, you know, what's next. So maybe something for you is like, you're working on this terminal, uh, terminal emulator, um, you know, putting a lot of time in that, you know, Could be something that you work on for a long time.
But, uh, 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
Mitchell: yeah, uh, not currently. There's no concrete idea next. And, uh, you know, I hope that I'll work on this terminal emulator a long time. I think that there's a lot of, uh, 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. Yeah. Of the web browser, like web browsers aren't going away. I'm 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. But at the same time, I've said, you know, terminals don't innovate.
Nearly at this, like, they're, they're at, like, 0. 1 percent of the innovation speed of a browser. So what if you just, like, bumped that to 5 percent 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.
Um, the Terminal Emulator for me is like the technical bubble version of that. It's my thing of like, um, 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 gonna, 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.
Andrew: 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?
Mitchell: 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, like, 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, 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. So still definitely a thought.
Justin: Yeah, we've definitely talked to a few people working in this space. So one of our early episodes was the fig founders who ended up selling their, their, their company to, uh, Amazon, which was, you know, they were doing really interesting work and then, and they had plans to sort of rebuild a terminal terminal, like longterm.
and then the warp founders, we had them on and they're doing really interesting work around that. So I think it is a, it is a nice space and I'm glad to see people working in it for sure, because it's like, we. Developers, especially spend a lot of time in a terminal and,
you know, improving that experience is, is, is important.
Andrew: 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, uh, what do you, yeah, your life for the most part. So. So, uh, what do you think the future of cloud and infrastructure looks like? Is it more complicated or less complicated?
Mitchell: Um, yeah, I think, uh, okay. So I'm not actively working in this space anymore. That's my disclaimer. Um, 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, um, and, uh, sort of reduces simpler in terms of usage, but also simpler to the complexity, you know, even using kubernetes example, I think kubernetes is fine and great, but I, you know, 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 Hashicrop in 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, um, to, to simplify. And I think that's the future. Some people, when I say that, think that I think the future is just like pass like platform as a service.
Like, you're just going to have Heroku again. and I loved Heroku and, uh, 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, uh, better tooling.
Andrew: Cool. Uh, 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.
Mitchell: Thank so much. It was great talking to you.
Justin: Mitchell, thanks coming for coming on. I mean, your work has, I mean, definitely impacted everybody who is like basically in this space. And, you know, it's, it's interesting for me to talk to you after having like, Some of your open source projects at the beginning of my career. And it's like, that's, that's such a fun thing.
So really appreciate you having, having you on. And it was, it was great.
Mitchell: Thanks so much.