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.
Mitchell Hashimoto - Founder of HashiCorp, Terraform, and Thoughts of Open Source Monetization - https://www.youtube.com/watch?v=vw61iI08iro
Hashicorp가 존재하기 전에 시작한 모든 프로젝트들은, 사업이 될 거라고 전혀 의도하지 않았습니다. 사업이 될 거라고 생각하지 않았죠. 누군가가 사용할 거라고도 생각하지 않았습니다. 많은 프로젝트가 그렇게 시작됩니다. 상업적인 생각이나 계획이 전혀 없죠. 상업적인 측면은 커뮤니티의 성공에 따른 부작용일 뿐입니다. 안녕하세요, DevTools FM 팟캐스트에 오신 것을 환영합니다. 이 팟캐스트는 개발자 도구와 그것을 만드는 사람들에 관한 것입니다. 저는 Andrew이고 이쪽은 공동 진행자 Justin입니다. 여러분 안녕하세요. 오늘 Mitchell Hashimoto님을 모셨습니다. Mitchell님, 함께 해주셔서 감사합니다. Mitchell님은 유명하게도 Hashicorp를 시작하셨는데 2010년, 2012년 즈음이었죠. 꽤 이른 시기였습니다. 회사가 법적으로 설립된 건 2012년이었죠. 2012년이었던 것 같아요. 네, 2012년이죠. 정말 놀랍습니다. 저는 여러분이 그렇게 많은 일을 하셨다는 걸 몰랐어요. 많은 사람들이 Hashicorp에 대해 들으면 아마도 Terraform을 들어봤을 겁니다. Terraform은 여러분이 만든 큰 영향력 있는 프로젝트죠. 하지만 저는 Vagrant를 사용했던 걸 기억합니다. 대학 졸업 후에요. 그때는 Mitchell님이 그것도 만드셨다는 걸 몰랐어요. 정말 흥미로운 연관성이네요. 그래서 우리는 이런 얘기를 나누게 되어 정말 기대됩니다.당신의 초기 작업과 Hashicorp, 그리고 이 모든 여정에 대해 얘기해보겠습니다. 하지만 본격적으로 시작하기 전에, 청취자들에게 자신에 대해 좀 더 소개해주시겠습니까? 네, 대략적인 내용은 말씀해주셨지만, 저는 배경과 열정이 엔지니어입니다. 저는 항상 오픈 소스 소프트웨어 개발에 깊이 관여해 왔습니다. 지난 10년 정도 동안 인프라 소프트웨어에 주력했지만, 다양한 분야에서 일해왔습니다. 현재는 터미널 에뮬레이터 작업을 하고 있는데, 아마 이에 대해 얘기하게 될 것 같습니다. 네, 그게 제 개인적인 소개입니다. 그렇습니다. 그게 저예요. 멋집니다. Hashicorp 얘기를 하기 전에, 당신은 부업으로 조종사이기도 하죠. 저는 이게 정말 좋습니다. 제 어머니와 의붓아버지도 둘 다 조종사거든요. 개인적으로 취미 삼아 하시는 정도지만요. 그래서 어떻게 조종사가 되셨는지 궁금합니다. 간단히 말하자면, 저는 항상 비행에 관심이 있었습니다. 하지만 깊이 알아보지 않아서 현실적으로 불가능하다고 생각했죠. 아니면 도달하기 힘들다고요. 그러다 친구의 여자친구 아버지가 조종사인 분을 알게 됐는데, 그게 제가 조종사와 가장 가까이 접한 경험이었습니다. 사교 모임에서 그분을 만나 대화를 나누면서 조종사가 되는 게 얼마나 접근 가능하고 가능한 일인지 설명해주셨어요. 이건 Hashicorp 이전의 일이었습니다.어떤 재정적 성공을 거둔 것 같았어요. 저 개인적으로는 그 전이었죠. 그래서 깨달았죠, 아, 이제 이걸 시작할 수 있겠구나, 가능하다는 걸요. 그래서 비행을 시작했어요. 그리고 정말 흥미로운 점은 비행이 재미있고 멋지다는 거예요. 사실 과정으로 봤을 때 그리 어렵지 않다고 생각해요. 하지만 제가 정말 빠져든 것, 그리고 많은 엔지니어들을 비행에 끌리게 하는 것은 비행기 시스템과 규정, 그리고 그런 것들에 대한 지식이 필요하다는 점이에요. 특히 엔지니어들에게는 비행에 관한 규칙들이 어떤 면에서 매우 안정감을 줍니다. 매우 엄격한 시스템이죠. 거기 들어갔을 때 정확히 무엇을 예상해야 할지 알 수 있어요. 그리고 그게 정말 좋아요. 일반적으로 비행은 어렵고 위험해 보이지만, 당신은 한 단계 더 나아가 자신만의 항공 소프트웨어를 만들었어요. 그게 대체 무슨 의미인가요? 그리고 네, 네, 음, 저는 절대로 제 소프트웨어를 실제 비행 중인 조종석에 넣지 않을 거예요. 제가 항공과 관련해 만든 모든 소프트웨어는 비행 전 계획을 돕기 위한 것이었어요. 날씨 분석, 보고서 작성 등이죠. 기본적으로, 제가 비행 학교를 다니고 면허를 따고 연습을 하면서 깨달은 건, 제가 같은 일을 반복해서 하고 있다는 거였어요. 그래서정확히 동일한 경로 작업으로 여기서 날씨 정보를 가져옵니다. 비행 경로의 여러 지점에서 특정 보고서를 가져오는데, 이는 다양한 웹사이트에서 얻습니다. 그래서 자동으로 가져오는 데 도움이 되는 도구를 만들었습니다. 하지만 여전히 소스에서 가져오며, 데이터를 생성하거나 비행기에 직접 입력하지는 않습니다. 미리 읽어보는 정도입니다. 네, 개인 비행이나 사설 항공이 얼마나 많이 변했는지 흥미롭습니다. 제 어머니가 2007년경에 비행을 배우기 시작했을 때를 생각해보면... 2007년, 2008년쯤이었죠. 아직 꽤 최근이네요. 네, 하지만 그때부터 많이 수동적이었고 종이를 많이 사용했는데, 지금은 어머니와 계부께서 아이패드를 사용해 모든 비행 전 체크리스트와 경로 계획 등을 하십니다. 그 짧은 기간 동안 얼마나 많이 바뀌었는지 흥미롭습니다. 네, 저는 이제 파일럿 경력이 5년밖에 되지 않았지만, 그때도 아이패드는 이미 널리 사용되고 있었죠. 사실 아이패드가 거의 필수품이에요. 물론 아이패드 없이 비행하는 방법도 많고, 예전에는 다들 그렇게 했죠. 사람들은 오랫동안 아이패드 없이 비행해왔습니다. 개인 조종사 과정을 밟을 때, 적어도 제 교관은 아이패드를 절대 사용하지 않게 했어요. 모든 것을 펜과 종이, 구식 차트로 해야 했죠. 그게 정말 중요하다고 생각해요. 하지만지난 5년간 비행하면서 이제는 선택 장비로 여기지 않습니다 iPad를 기내에 가져가지만, 같은 소프트웨어를 휴대폰에도 설치해 두었죠. 그게 제 백업입니다. 그리고 FAA와 후속 시험을 할 때, 시험관은 매우 수용적이었습니다. 감정적인 의미가 아니라 그는 답변을 정확하다고 여겼습니다 백업이 무엇이냐고 물었을 때 전화기라고 대답했더니요. 전화기가 안 되면 계기판을 사용한다고 했습니다. 제게는 iPad가 1순위, 전화기가 2순위입니다. 비행기의 차트 데이터는 실제로 가장 후순위입니다 FAA 시험관들도 계획만 있다면 괜찮다고 했습니다. 주제를 조금 바꿔보겠습니다. 당신은 개인 블로그에 Zig에 대해 많이 쓰셨는데요, 훌륭합니다. 아직 보지 않은 분들은 꼭 확인해보세요. 우리는 BUN의 Jared와 Zig를 사용하는 몇몇 사람들과 이야기를 나눴지만 깊게 다루지는 않았습니다. Zig의 매력이 무엇인지, 어떤 프로젝트에 사용했는지 말씀해 주시겠습니까? 네, Hashicorp와도 연관 지어 말씀드릴 수 있겠네요. Zig에 끌린 이유는 생산성이 높으면서도 표현력 있는 시스템 프로그래밍 언어를 찾고 있었기 때문입니다. 충분히 표현력이 있으면서도 생산적이고일종의 악몽 같은 빌드 시스템과 빌드 환경이 있습니다. 그래서 사실 Hashicorp로 잠깐 돌아가보면, 우리가 Hashicorp를 시작했을 때, 결국엔 모든 것을 Go로 작성했지만 처음 시작할 때, 우리가 작성하려는 소프트웨어에 대해 어떤 기술을 선택할지 좁혀나갈 때, 결국 그 과정의 끝에서 GO 또는 C로 좁혀졌습니다. 저와 공동 창업자는 C에 매우 익숙했습니다. 우리는 수년간 프로덕션 품질의 서버 사이드 C를 작성했고 이는 꽤 큰 규모로 사용되었기에 우리는 그 어떤 것도 두렵지 않았지만 결국 우리는 명백히 Go를 선택했습니다. 나중에 원하시면 그 이유를 설명할 수 있습니다. 하지만 Zig는 제게 비슷한 느낌입니다. Zig가 그 당시에 존재했다면, 아마도 지금보다 더 안정적이어야 했겠지만, Zig가 2012년경에 1.0 형태나 거의 1.0에 가까운 형태로 존재했다면 상황이 달랐을 수도 있습니다. 저는 그것을 C의 정말 훌륭한 후계자로 보며, 이미 그런 상황에 익숙한 상태에서 저는 Zig를 사용하는 것을 정말 좋아하고, 그게 제게 Zig의 진정한 틈새 시장이라고 봅니다. 당신의 의견으로는, Rust와 비교해 어떤 이점이 있나요? 제게는 표면적인 이점이 있다고 봅니다. 저는 Ruby로 시작했고 Ruby는 항상 프로그래밍이 재미있어야 한다는 사고방식을 가지고 있었습니다. 그리고 저는 그것이 개인적인 것이라고 생각합니다. 즉, 그것이 객관적인러스트가 재미없다는 건 아니지만 저에게는 절대 재미있지 않습니다. 러스트로 코딩할 때마다, 작은 프로젝트를 해봤지만 큰 건 안 해봤어요. 러스트를 쓰거나 읽을 때마다 많은 러스트 코드를 읽어봤지만 아직도 그냥, 행복하지 않아요. 재미가 없고 Zig는 개인적으로 정말 재미있고 즐겁습니다. 개인적인 의견이에요. 비개인적인 측면에서는 메모리 안전성이 매우 중요하다고 생각합니다. 하지만 저는 매우 선형적이고 정확하진 않지만 기계 코드로 어떻게 변환될지 잘 알 수 있는 언어를 좋아합니다. 그리고 그것들이 기계 코드로 어떻게 변환될지 잘 알 수 있어요. 러스트는 항상 대여 검사기를 위해 프로그래밍하는 느낌이었고 항상 명확하지 않았어요. 경험이 쌓이면 나아질 수도 있지만 적어도 초보자로서는 정확히 어떻게 기계 코드로 변환될지 명확하지 않았어요. Zig는 전혀 그렇지 않아요. 모든 줄마다 어떤 기계 코드가 생성될지 직관적으로 이해할 수 있어요. 단점은 러스트처럼 메모리 안전 언어가 아니라는 거예요. C만큼 나쁘진 않지만 러스트만큼 확실한 보장은 없어요. 일부 사람들은 이를 철학적인 경계선으로 봅니다. 하지만 저에게는 그렇지 않아요. 일부 사람들은 이를 철학적 한계선으로 보지만 저는 그렇지 않습니다.좋다고 생각해요. 최근에 Zig로 사이드 프로젝트들을 만들고 계신 것 같은데 터미널 에뮬레이터를 작업하고 계신 걸 봤어요. 어떻게 진행되고 있나요? 그리고 터미널 에뮬레이터를 만들 때 어떤 어려움이 있나요? 네, 재미있었어요. 정말 재미있는 프로젝트예요. 사실 처음에는 이런 걸 할 거라고 전혀 예상하지 못했어요. 시작할 때도 여러 가지를 배우기 위한 프로젝트였어요. Zig도 그렇고 GPU 프로그래밍도 그렇고, 터미널 에뮬레이션 레이어도 마찬가지고요. 그냥 배우고 싶었어요. 다른 사람들이 사용하는 기능이 풍부한 프로젝트가 될 줄은 몰랐어요. 시간이 지나면서 더 나은 터미널 에뮬레이터를 만들 기회가 많다는 걸 깨달았고, 터미널 에뮬레이션 자체를 개선할 기회도 많다는 걸 알게 됐어요. 앱 측면이 아니라 CLI에서 실행되는 프로그램이 실제로 할 수 있는 일들 말이에요. 그래서 정말 재미있었어요. 지금 베타 테스터가 800명 정도 있어요. 올해 공개 출시할 계획이에요. 완전히 열정의 산물이에요. 사람들이 자주 물어보는데, Hodge Script를 그만두고 이걸 하는 거냐, 새 회사를 차리는 거냐 등등. 전혀 아니에요. 그냥 순수한 열정 프로젝트예요. 하지만 정말 재미있었어요. 열정 프로젝트를 갖는 게 좋다고 강하게 믿어요. 이번 주 스폰서에게 감사드립니다.CodeCrafters. CodeCrafters는 경험 있는 소프트웨어 엔지니어를 위한 프로그래밍 과제를 만듭니다. 주말에 리트코드 문제를 풀거나 기여할 사이드 프로젝트를 찾는 대신, 우리가 사용하고 사랑하는 멋진 오픈 소스 기술을 재구축하는 데 주말을 보낼 수 있습니다. 그들은 많은 멋진 과제들을 가지고 있습니다. 자신만의 BitTorrent 만들기, 자신만의 git 만들기, 자신만의 Docker 만들기 등 많은 과제가 있습니다. 이 과제들에 대해 모든 인기 있는 프로그래밍 언어를 지원합니다. 이러한 개발 도구들의 깊은 내부 작동 방식을 살펴보고, 그들이 사용하는 바이너리 프로토콜을 풀어보며 실제로 어떻게 작동하는지 보는 것은 정말 멋집니다. 저는 몇 가지 과제를 해봤는데, 바이너리 프로토콜이 얼마나 간단한지 항상 놀랍습니다. 더 낮은 수준의 세부 사항을 풀어보는 것은 정말 재미있습니다. 또 다른 멋진 점은 이것이 정말 커뮤니티 경험처럼 느껴진다는 것입니다. 다른 사람들의 해결책을 볼 수 있고, 댓글도 있어서 진공 상태에서 배우는 것 같지 않습니다. 다른 사람들이 함께 있는 것처럼 느껴집니다. 내용 외에도 사용자 경험 자체가 경험 있는 소프트웨어 개발자를 대상으로 합니다. 예를 들어, 사용자를 맞춤형 브라우저 경험에 묶어두는 대신, CodeCrafters는 여러분이 모든 자신의 도구를 사용할 수 있게 해줍니다. IDE나 텍스트 에디터를 사용할 수 있습니다. 여러분이 해야 할 일은 codecrafters에 푸시하는 것뿐입니다. 그들이 테스트를 실행하고 결과를 보여줍니다. 원하지 않으면 웹사이트에 갈 필요도 스폰서를 모집하고 있습니다. 이제 본 에피소드로 돌아가겠습니다. 우리가 HashiCorp에 대해 이야기하는 것으로 전환할 수 있을 것 같습니다. 패션 프로젝트 얘기가 나왔으니 말이죠. 당신은 2012년에 HashiCorp를 설립했다고 말씀하셨습니다. 초기에는 어떤 일을 하셨나요? HashiCorp를 설립해서 어떤 문제를 해결하고자 하셨나요? 네, 우리가 처음 회사를 설립했을 때는 Vagrant라는 소프트웨어만 출시한 상태였습니다. 하지만 저와 공동 창업자는 추구하고 싶은 다른 아이디어들도 적어 놓았었죠. 정확한 목록을 기억하기는 어렵습니다. 결국 만들지 않은 것들도 많았거든요. 하지만 우리가 만든 것들 중에서는 지금까지 제가 알기로는 거의 모든 것이 그 목록에 있었습니다. Vault만 좀 달랐죠. Vault는 목록에 없었습니다. 우리는 보안이 모든 프로젝트에 걸쳐 분산될 거라고 생각했습니다. 비밀을 하나로 중앙화하는 것이 더 나은 해결책이라는 걸 실제 상황에 부딪혀서야 깨달았죠. 하지만 초기 계획에서는 그렇게 생각했습니다. 실제 계기는 제가 대학을 졸업하고 샌프란시스코 베이 에어리아로 이사가서 스타트업 환경에서 일하면서 파이썬 기반의 수제 자동화 및 인프라 자동화 도구들을 만들고 있었는데, 사교 모임에 가보니 다들 저와 같은 문제를 겪고 있다는 걸 알게 된 거죠. 그래서 그게 제가 이렇게 생각하게 된 계기 중 하나였습니다. "이런 문제들을 해결할 수 있는 도이런 문제들에 집중하는 조직을 만들어볼까 하는 생각이 들었어요. 그리고 Vagrant가 이미 존재했고 당시 꽤 인기가 있었는데, 완전히 사이드 프로젝트였죠. 저는 Vagrant와 전혀 관련 없는 일을 주 40시간 하면서 정상적인 직장 생활을 하고 있었어요. 그리고 집에 돌아와서는 Vagrant 작업을 하루에 4-8시간 정도 할 때도 있었죠. 그러고 나서 잠자고, 일어나서 출근하고, 이 사이클을 반복했어요. 그때도 이게 지속 가능하지 않다는 걸 알았죠. 그래서 이 두 가지 요인이 저를 Hashicorp를 시작하게 만들었어요. 그게 Hashicorp를 시작하게 된 이유였습니다. 멋집니다. 2014년에 Tao of Hashicorp를 발표하셨는데, 당시 생각이 어떻게 영향을 미쳤나요? 생각은 간단했어요. 2014년쯤에는 우리가 정말로 사람들을 고용하기 시작했고, 회사가 상당히 크게 성장하고 있었죠. 그 무렵에 우리는, 정확히 2014년인지는 모르겠지만, Tao를 작성하기 시작했을 때 회사가 10명 정도의 전환점에 있었어요. 우리는 문화에 대한 설명과 채용 시 원하는 것을 문서화해야 한다는 것을 깨달았죠. 그래야 회사의 모든 사람들이 단순한 분위기 이상으로 같은 방향을 향하게 될 거라고 생각했어요. 그래서 우리는, 그리고 인간적인 측면뿐만 아니라, 그리고 단순히 인간적인 면만이 아니었어요.원래 TAO의 초점은 제품 디자인이었습니다. 우리가 더 많은 사람들에게 프로젝트 작업을 위임하고 제 또는 아몬드의 관여 없이 커밋하고 릴리스를 하게 되면서, 그들이 우리의 소프트웨어처럼 느껴지는 소프트웨어를 제공하도록 어떻게 보장할 수 있을까 고민했죠. 그래서 TAO가 나왔습니다. 이는 기술에 관한 우리의 디자인 원칙을 성문화한 것이었습니다. 이게 흥미롭다고 생각합니다. 특히 그 시기에, 그리고 일반적으로, 위대한 회사들에 대해 생각해보면, HashiCorp도 그 중 하나고, Heroku의 초기 활동이나 오늘날의 Linear를 생각해봅니다. 항상 그들의 정체성과 운영 방식, 그들이 하는 일이나 이론에 대한 초기 글쓰기가 있었죠. 그래서 HashiCorp의 TAO가 있었고, Heroku는 유명한 12 Factor 앱이나 그와 관련된 것이 있었습니다. Linear는 Linear 방법론이 있는데, 이것도 중요한 글이라고 생각합니다. 정확히 어디로 가려는 건지 모르겠지만, 흥미로운 점은 이런 중요한 초기 작업들, 회사들이 자신들의 정체성과 하는 일에 대해 쓰고 이야기하는 초기 포스트들이 있다는 거예요. 어떻게 그런 글을 쓰게 되는지, 그 과정이 궁금합니다.어떤 모습인지, 어떤 건지 말이에요. 네, 잘 모르겠어요. 이건 2014년이었고, 1년 정도 지나서야 첫 직원을 고용했죠. 맞아요, 약 1년 후에요. 그리고 나서 더 많이 고용하기 시작했죠. 대략적으로요. 네, 맞아요. 많이 생각해보지 않아서 잘 모르겠어요. 하지만 한 가지 확실한 건, 제가 당시 인프라 소프트웨어에 대해 다른 접근법을 가졌다고 느꼈다는 거예요. 적어도 제게는 그렇게 느껴졌어요. 지금은 돌이켜보기 어렵지만, 제가 공로를 주장하려는 게 아니라 그 당시 제 감정과 지금의 감정을 비교하면, 오늘날 인프라 소프트웨어가 훨씬 나아진 것 같아요. 복잡하긴 하지만요. 쿠버네티스도 복잡하고, Hashicorp가 한 일들도 복잡하죠. 하지만 돌이켜보면, 제가 전에 말했듯이 한 회사에서 2년 동안 인프라 관리를 했을 때, 모든 인프라 소프트웨어가 기계를 먼저 생각하고 사람을 나중에 생각하는 것 같았어요. 아마도 제 Ruby 앱 개발자 배경 때문일 수도 있고, 또 하나는 Apple Store에서 짧게 소매 직원으로 일한 경험 때문일 수도 있어요. Apple의 소매점에서조차 있던 그런 문화 말이에요. 이 두 가지가 합쳐져서 제가 전환했을 때, 그 두 가지를 합쳐서 제가 인프라로 전환했을 때,인프라 세계로 직업적으로 진출했을 때, 저는 생각했습니다 소프트웨어가 뒤집혀야 한다고, 기계보다 인간 측면에 먼저 초점을 맞춰야 한다고. 그래서 그것이 우리가 타오에 적은 내용의 일부입니다. 타오의 한 요소가 있는데, 그것이 결국 제가 있을 당시 회사 전체의 지침 원칙이 되었습니다. 바로 '기술이 아닌 워크플로우'였죠. 이는 우리가 설계한 아이디어였습니다. 제가 처음으로 한 일 중 하나는 당시와 지금까지도 설계하는 모든 소프트웨어에 대해, 일부 사람들이 'readme 주도 개발'이라고 부르는 것을 하는 것이었습니다. 그 용어는 당시에 존재하지 않았지만, 저는 실제로 bash 스크립트나 makefile 같은 것을 만들어 소프트웨어가 이미 존재한다고 가정했습니다. 아무것도 하지 않고 터미널에 출력만 에코했죠, 실제처럼 보이게 하기 위해 sleep도 넣었고요. Terraform에서도 그렇게 했습니다. Terraform plan, Terraform apply 같은 것을 실행할 수 있었죠. 당시 제 삶에서 인터넷이 좋지 않을 때 주로 비행기에서 이런 작업을 했습니다. 그냥 앉아서 그 환경을 상상하며 이 명령어들을 실행하고 제 느낌을 평가했습니다. 소프트웨어를 사용하는 게 재미있나? 직관적인가? 다음 단계는 뭘까? 어떤 플래그가 필요할까? 어떤 기능이 있어야 할까? 이런 식으로 생각했죠. 이를 통해 많은 아이디어가 탄생했습니다우리가 그 다음에 기술로 돌아갈 내용의 그리고 그 당시에는 다른 사람들과는 다른 사고방식이었다고 생각합니다. 적어도 다른 사람들과는 다르게 느껴졌죠. 오늘날에는 모든 것이 훨씬 더 인간 중심적으로 느껴집니다. 네, 소프트웨어를 그렇게 정의하는 방식이 좋습니다. 저는 몇 개의 NPM 패키지를 가지고 있는데 항상 readme부터 시작해요. API부터 시작하고, 좋은 느낌이 들도록 가지고 놀다가 그 다음에 실제로 구체화하려고 노력합니다. 네. 한 가지 Armand에게 공을 돌려야 할 것은 제가 회사를 시작했을 때 이 과정에서 극단주의자였다는 점입니다. readme부터 시작해서 뒤로 갔죠. Armand는 훨씬 더 강한 학문적인 컴퓨터 과학 기초를 가지고 있었고 이런 아이디어를 제시했습니다. 그렇게 하되 그냥 뒤로 작업하는 대신, 우리가 도달하고자 하는 최종 상태를 고려해서 핵심적인 추상화나 소프트웨어 모델링에 대해 이야기를 나누자고 했습니다. 그리고 나서 중간에서 만나자고 했죠. 좋은 예로 Terraform을 계속 들자면 제가 설계한 CLI가 있었지만 그 다음에는 이런 아이디어가 있었습니다. 우리가 가진 이것들이 작은 상태 기계인가, 그래프의 노드인가? 어떤 종류의 알고리즘인가? 상태 기계와 그래프는 잘 알려진 것들이고 잘 정립된알려진 연산들이 Terraform 환경에서 유용한가요? 그래프를 순회해야 하는지, 그리고 그 순회가 정확히 apply를 수행하는 방법이라는 것을 빠르게 깨달았습니다. 그게 작동하는 방식입니다. 상태 기계에 대해, 예를 들어 하나의 상태 기계가 한 번에 움직이나요? 병렬로 움직일 수 있나요? 서로를 인식해야 하나요? 상태 기계가 다른 상태 기계를 트리거하는 것과 같은 연구 분야가 있기 때문입니다. 그것이 거의 당시 우리가 읽은 모든 연구였는데, 온라인 게임 시스템이 거대한 분산 상태 기계처럼 작동한다는 것이었습니다. 그래서 Arman이 전체 프로세스에 가져온 일종의 엄격함이 있었고, 저는 그것을 지금까지 유지하고 있습니다. 기본적으로 이 프로젝트들을 작업할 때, 우리는 양쪽에서 시작했지만 코어부터 시작했고, CLI도 시작했습니다, 그리고 우리는 동시에 중간을 향해 나아갔습니다. 그리고 제 기억에 가장 두드러지는 것은 Vault입니다. Vault를 만들 때, 우리는 6주 만에 Vault 0.1을 완성했습니다. 그리고 공개 릴리스 약 이틀 전까지 작동하는 바이너리가 없었습니다. 우리는 단위 테스트와 우리가 가지고 있던 설계 문서를 사용하여 개발했습니다. 릴리스하기 약 일주일 전에, 왜냐하면 우리는 많은 초기 보안 테스터들이 있었기 때문에, 우리는 바이너리를 만들었고 그것이 작동했습니다. 그리고 우리는 "오케이, 흥미롭네"라고 생각했습니다. 이런 강력한 설계를 할 수 있다는 것이양쪽 모두 테스트로 뒷받침되고, 중간으로 이동하여 실제로 소프트웨어를 만들어냅니다 그 소프트웨어는 버그도 많지만 작동도 합니다. 네, 당신은 Hashicorp에서 많은 도구를 만들었습니다. 몇 가지에 대해 이야기했죠. Vagrant, Terraform. 하지만 초기에 가장 좋아했던 작업은 무엇이었나요? 그리고 어떤 것이 인프라 생태계에 가장 큰 영향을 미쳤다고 생각하나요? 아마도 둘 다 같을 겁니다. 쉬운 답을 고르려는 게 아닙니다. 저는 항상 제가 작업한 프로젝트 중 가장 좋아하는 것이 Terraform이라고 일관되게 말해왔습니다. 또한 그것이 결국 우리가 만든 모든 프로젝트 중에서 인프라 분야의 가장 많은 사람들에게 정말 큰 영향을 미쳤다고 생각합니다. 실제로 보면 그렇게 느껴집니다. 음 아니요, Vault도 비슷한 수준의 영향력이 있다고 생각합니다 실제 사용 측면에서요. 덜 흥미롭고 덜 알려져 있지만, 매우 널리 사용되고 있으며 매우 중요한 정보를 보호하는 데 사용됩니다. 그래서 Vault의 영향력은 엄청납니다. 하지만 Terraform은 제가 항상 가장 흥분했던 프로젝트였습니다. 또한 Hashicorp를 시작했을 때 제가 가장 명확하게 이해하고 있던 프로젝트였죠. 무엇을 하고 싶은지에 대해서요. 몇 년 전에 트윗한 적이 있는데 예전에 텀블러 블로그를 운영했었습니다. 그 블로그에 2010년경에 글을 올렸는데블로그 글에서 Terraform에 대한 제 욕구와 정확히 어떻게 작동하길 원하는지 설명하고 누군가에게 만들어달라고 부탁했습니다. 아무도 만들지 않았고, 결국 제가 필요한 시점이 와서 '그럼 내가 만들어야겠다'고 생각했죠. 저는 항상 명확한 비전이 있었습니다. AWS가 Cloudformation을 출시한 날 그 블로그 글을 게시했는데, Cloudformation을 보고 멋지다고 생각했지만 제가 하고 싶었던 방식은 아니었거든요. 그래서 '좋은 아이디어지만 이렇게 하는 게 어떨까'라고 썼고, 그게 결국 Terraform이 되었습니다. 좋습니다. 당신은 Hashicorp에서 오랜 시간을 보냈죠. 몇 년간 CEO를 지냈고, 그 후 몇 년간 CTO를 했으며, 마지막 2-3년은 개인 기여자로 전환했습니다. 그 경험은 어땠나요? CEO를 그만둔 후 보고 체계에 어색한 점은 없었나요? 네, 그게... 제가 22살 때 Hashicorp를 시작했어요. 제 첫 벤처 지원 스타트업이었죠. 지금까지도 유일한 벤처 지원 스타트업이에요. Hashicorp 창업 전에 제가 일했던 가장 큰 회사는 직원 45명 정도였습니다. 그래서 사업을 시작하는 데 무엇이 필요한지, CEO가 실제로 무엇을 하는지, 아무 것도 모르고 시작했어요. 사업 시작에 무엇이 필요한지, CEO가 실제로 무엇을 하는지,기업 회사에서 어떤 책임을 맡게 될지에 대해 우리는 처음에 기업 회사라는 걸 몰랐어요. 시작했다가 나중에 그렇게 되었죠. 그래서 저는 CEO로 4-5년 정도 일했어요. 그 기간 동안 몇 번의 펀딩 라운드를 거쳤고 직원 수는 20명에서 40명 사이였어요. 정확한 숫자는 기억나지 않지만 20명에서 40명 사이가 맞을 거예요. 그리고 회사가 커지고 우리의 미션이 확장되면서 깨달은 점이 있었어요. CEO 직책이 얼마나 실제적인 일인지 알게 되었죠. 그 전에는 CEO가 그저 형식적인 직함이라고 생각했는데, 그건 제 무지였어요. 실제로 CEO가 하는 일과 책임이 무엇인지 알게 되었죠. 물론 우리는 아주 작은 회사였지만, 그 순간에도 제가 그 일에 편하지 않다는 걸 깨달았어요. 그리고 그 일에서 큰 즐거움을 느끼지 못했죠. 구체적으로 말하면, 임원진 구성, 재무 계획, 3-5년 사업 전망 같은 일들이에요. 당시에는 10년 기술 전망은 그릴 수 있었지만, 3-5년 사업 전망을 세우는 건 정말 어려웠어요. 고객과 대화하고 어떻게비기술적인 사람들에게 회사에 대해 이해하기 쉽게 설명하는 것이 그런 것들이 정말 어려웠어요. 그래서 저는 아르만과 이야기를 나누기로 했고, 긴 이야기를 짧게 하자면 더 많은 일이 있었지만, 간단히 요약하자면 외부에서 CEO를 영입하고 제가 CTO로 내려가는 것이 최선이라고 판단했습니다. 그래서 저는 몇 년 동안 CTO를 맡았고, 진심으로 즐겼습니다. 분명히 제가 훨씬 더 오랫동안 CTO로 남아있었을 평행 우주가 있을 거예요. 그리고 완전히 행복했을 겁니다. 하지만 제가 깨달은 점은 CTO 역할에 대해 좋아하는 부분도 있었지만, 순수하게 100% 사랑하는 것은 엔지니어링과 소프트웨어 개발이었다는 거예요. 그래서 어느 시점에 CTO 역할을 하면서 회사가 훨씬 더 잘 되기 시작하고 회사가 더 건강하고 성숙한 위치에 있다고 생각했을 때, 아르만과 우리가 고용한 CEO인 데이브와 이야기를 나눴고 제가 좀 더 이기적인 단계를 밟기 시작하고 싶다고 말했어요. 개인적으로 제 진정한 열정인 것으로 돌아가고 싶었죠. 그건 바로 엔지니어링이었습니다. 그래서 저는 IC가 되었고, 보고 체계는... 네, 많은 사람들에게 이상했을 거예요. 아무도 제 얼굴을 보고 그렇게 말하지 않았지만 어려웠을 거예요. 하지만 저는 최선을 다했고 문화가 정말 좋은 상태에 있다고 생각했습니다.제가 최선을 다해 같은 위치에 있으려고 노력했고 창업자로서의 위치를 절대 이용하지 않으려 했습니다 이전에 말했듯이, 그 상황에 대해 사람들이 어떻게 느꼈는지 제가 모르는 점이 있을 수 있지만 그렇게 나쁘지는 않았다고 생각합니다. 네, 저는 그것이 정말 존경스러운 전환이었다고 생각합니다. 우리가 실제로 좋아하는 것과 즐기는 것을 인정하지 않고 많은 고통을 겪게 된다는 인식이 있죠. 우리는 그저 '이게 내가 해야 할 일이야' 또는 '이 자리에 있어야 해'라고 생각합니다. 하지만 '사실 나는 이것을 정말 좋아해. 그냥 할 거야'라고 말하는 자유로움이 있습니다. 사람들에게 말했던 한 가지는 '어떻게 알았나요? 어떻게 정의했나요?'라고 물을 때 저는 항상 이렇게 대답했습니다. 그것은 엔지니어링이든 아니든 코딩으로 좁혀 말하자면, 코딩은 제가 항상 시간을 내는 것이었습니다. 시간이 없을 때조차 시간을 만들어냈죠. 저는 희생을 감수하고 잠을 줄이면서까지 했습니다. 일하기에 적합하지 않은 상황에서도 일했고 일, 즉 코딩을 했습니다. 휴일에도 코딩했죠. 기억나는 게 한 번은 전 여자친구와 헤어졌을 때 힘든 시기를 겪고 있었는데 제가 가장 먼저 한 일은집에 가서 8시간 동안 쉬지 않고 코딩하고 여러 가지를 출시했어요 그게 제가 즐거워하는 방식이고, 슬픔을 달래는 방식이에요 그 주변의 모든 것이 그랬어요. 그게 공허함을 채우는 방법이었죠 지금도 여전히 그걸 좋아해요. 그래서 알게 됐어요 CTO 관리 업무나 영업 업무 같은 것들에 추가 시간을 내지 않았다는 걸요. 그 순간에는 그런 일들을 하는 게 나쁘지 않았지만, 그것들을 위해 추가적인 시간을 내지는 않았어요. 그게 제 신호였죠. 네, 이해가 됩니다. 저는 그 전환에 대해 권력 역학 측면에서 생각하고 있었어요 특히 창업자로서, 첫 회사라면 쉽게 내면화하지 못할 수 있죠 아, 내가 보고 구조의 다른 부분에 있다는 걸요 보고 체계 어딘가에 관리자가 있고 이제 그들이 저를 관리해야 하는데 어떻게 해야 할지 모르겠다는 거죠. 흥미로운 전환이에요 조직 내 권력 구조를 어떻게 탐색하는지에 대해 더 많이 이야기하는 게 좋을 것 같아요. 현실이니까요 당신은 직장과 개인 시간에 많은 대규모 오픈 소스 프로젝트를 이끌어 왔어요 이러한 오픈 소스 프로젝트를 만들고 커뮤니티를 육성할 때 어떤 점들을 고려하시나요? 시간이 지나면서 변화가 있었어요 오픈 소스 프로젝트를 만들고 커뮤니티를 육성할 때 고려하는 점들이 달라졌어요. 제가 처음 시작했을 때는오픈 소스 프로젝트에 대해, 초기에 20대 초반에는 깊게 생각하지 않았어요. 처음에는 그저 GitHub에 올리고 관대한 라이선스를 붙이고 'IRC 채널 열고 즐겁게 하자' 정도였죠. 하지만 지금은, 특히 이 터미널 에뮬레이터를 시작하면서 경험상 많이 달라졌어요. 이제는 처음부터 지속가능성에 대해 훨씬 더 신중하게 고민하고, 커뮤니티 문화에 대해서도 초기부터 생각하게 됐어요. 예를 들어, 커뮤니티 문화를 위해 매우 긴 비공개 베타 기간을 갖고 있어요. 이는 부분적으로 제 개인적 안녕을 위한 것이기도 해요. 너무 많은 압박을 받고 싶지 않거든요. 하지만 또 다른 이유는 이런 느린, 통제된 성장을 통해 원하는 모습의 커뮤니티를 더 신중하게 만들 수 있다고 생각하기 때문이에요. 첫날부터 백만 명이 몰려오면, 올바른 행동이 무엇인지, 무엇이 용인될지에 대해 통제하기 어려워져요. 하지만 천천히 성장하면 그런 것들이 자연스럽게 이해돼요. 지금은 제 Discord 커뮤니티에 관리자들을 임명했고, 어떻게 운영되는지 꽤 명확하게 이해하고 있죠. 지속가능성 측면에서는, 저에게는 이 프로젝트로 생계를 유지하는 것에 대해 크게 걱정하지 않는 특권적 위치에 있어요. 그건 전혀 의도하지 않았죠. 하지만 저는 제가 지속할 수 있는 프로젝트를 만들고 싶어요. 그건 중요해요. 하지만 저는 제가 계속 할 수 있는 프로젝트를 만들고 싶어요.어떤 식으로든 기여자들을 돕거나 상위 프로젝트를 돕는 것입니다. 그래서 저는 적극적으로 논의하고 있습니다. 사람들이 이미 물어봤어요. 공개되지 않았는데도 사람들이 이미 물었죠. "프로젝트에 기부할 수 있나요?" 같은 것들이요. 아직 받고 있지는 않습니다. 하지만 제 생각은 이렇습니다. 제가 도움이 필요하지 않더라도, 제가 의존하는 많은 프로젝트들이 도움이 필요하니까 누군가 제 프로젝트를 돕고 싶다면, 그 도움을 그 프로젝트들에게 전달할 수 있을까요? 이를 통해 일종의 선행을 이어가는 메커니즘으로 사용할 수 있을까요? 마찬가지로, 기여하는 사람이 있다면, 아마 그들의 여가 시간에 하고 있을 텐데 그런 시간이 많지 않죠. 그래서 이런 생각을 합니다. 어떻게든 그들을 도울 수 있을까요? 같은 맥락에서요. 저는 매일 밤 몇 시간 일하는 것이 부담되지 않습니다. 비용이 들지 않으니까요. 하지만 누군가가 계약직으로 일할 수 있고 그것이 그들의 삶에 도움이 된다면, 제가 그 정도를 도울 수 있을까요? 전체 급여를 지급하려는 게 아니라, 정말로 좋아하는 것은 Zig 프로젝트가 재단 관점에서 하는 일입니다. 그들은 한 두 명만 고용하지만, 많은 기여자들에게 시간당 약 55달러를 지급합니다. 더 많은 금액으로 계약할 수 있지만, 이 아이디어는 프로젝트에 무료로 중요한 기여를 할 필요가 없다는 것입니다. 승인된 작업이라면, 시간당 55달러로 계약할 수 있고 그것도 의그래서 저는 제 프로젝트와 관련해서도 그것에 대해 많이 생각해 왔습니다. 알다시피, 마차를 말 앞에 두는 것처럼 느껴질 수 있죠. 때로는 저도 그렇게 느낍니다. 하지만 이제는 전에는 걱정하지 않았을 것들에 대해 걱정하게 되었습니다. 네, 그건 멋진 접근 방식이에요. 특히 JS 커뮤니티에서는 기반 프로젝트들보다 화려한 대형 프로젝트가 모든 자금을 흡수해버리는 문제가 있죠. 그래서 JS 코어 담당자 같은 사람들은 사람들이 자신의 프로젝트를 사용하는지도 모르기 때문에 기부를 받기 힘들어요. 네, 맞아요. 이것에 대해 많은 생각을 하고 있습니다. 제 프로젝트를 통해 행동으로 옮기려고 노력 중이에요. 다른 사람들과도 이야기하면서 이를 바꾸려고 노력하고 있습니다. 네. 오픈소스를 중심으로 사업을 구축하는 것은 쉽지 않을 수 있습니다. 결국 무료이고 개방된 소프트웨어를 기반으로 사업을 만드는 것이니까요. 하지만 결국 사업은 돈을 벌어야 합니다. 그래서 프로젝트를 시작할 때 적절한 라이선스를 선택하는 것이 중요하면서도 어려운 결정이 될 수 있습니다. 오픈소스 프로젝트를 시작할 때는 그냥 모든 사람이 사용할 수 있게 하고 싶어 하죠. 하지만 자연스럽게 사업으로 발전하다 보면 우리가 올바른 선택을 했는지 의문이 들 수 있습니다. 그때 가서 올바른 선택을 했는지 깨닫게 되는 거죠.우리가 올바른 선택을 하지 않았나요? 지금 어떻게 생각하세요? 네, 지금은 많이 다르게 생각합니다. 특히 상업적 오픈소스를 경험한 기업가로서 말이죠. 저와 많은 다른 오픈소스 창작자들을 대변해 말할 수 있을 것 같습니다. 정직하게 말씀드리면, Hashicorp 이전에 시작한 모든 프로젝트에서 비즈니스가 될 거라고 전혀 생각하지 않았습니다. 누군가 사용할 거라고도 생각 못했죠. 예를 들어 Hashicorp가 있기 전에 말이에요. 비즈니스가 될 거라 전혀 예상하지 못했고, 누군가 사용할 거라고도 생각하지 않았습니다. 많은 프로젝트가 그렇게 시작된다고 봅니다. 상업적인 생각이나 계획이 전혀 없이 시작되죠. 왜냐하면 상업적인 측면은 커뮤니티의 성공에 따른 부수적인 결과이기 때문입니다. 그것은 부수적인 효과이고, 일부 경우에는 탐욕에서 비롯될 수도 있겠지만, 제 경우는 정말 다른 이유였습니다. 최근에 이야기했듯이, 결국은 선택의 문제였습니다. 월세를 내기 위해 풀타임으로 일할지, 아니면 오픈소스를 상용화하는 걸 추구할지 선택해야 했죠. 그래야 그 일로 월세를 낼 수 있었으니까요. 둘 다는 할 수 없었습니다. 하루에 시간이 부족했기 때문에 일상생활을 영위할 방법이 필요했습니다. 그래서 그게 제 동기부여 요인이었죠. 매일매일 살아갈 방법이 필요했던 거예요. 그게 제 동기부여 요인이었습니다. 그래서 저는프로젝트 아이디어가 있고 오픈소스가 최선의 해결책이라고 판단했지만 상용화도 원한다면, 어떤 라이선스를 선택할지 더 잘 결정할 수 있는 위치에 있다고 봅니다. 라이선스 외에도 수익화 전략을 생각해볼 수 있죠. SaaS, 오픈코어, 듀얼 라이선싱, 지원 및 서비스 등 미리 결정할 수 있습니다. 문제는 제가 겪었고 많은 사람들이 겪는 것처럼 처음에는 상용화 계획이 전혀 없다가 나중에 특정 경로에 갇히게 되는 것입니다. 상용화하고 싶다는 걸 깨달았을 때는 이미 너무 많은 것을 공개해버려서 스스로가 가장 큰 경쟁자가 되어버리는 거죠. 오픈소스를 지지하는 사람으로서 오픈소스 자체를 탓하는 건 아닙니다. 오픈소스가 좋다 나쁘다 할 게 아니라 미리 계획하지 않은 것이 문제라고 봅니다. 초기 결정의 결과를 나중에 감당해야 하는 거죠. 네, HashiCorp 작별 편지에서 그런 점이 잘 드러납니다. 처음에는 '큰 기업들이 우리 소프트웨어를 쓴다면 어떨까?'라는 십대의 생각으로 시작했다고 하셨죠. '그냥 그들의 손에 넣기만 하면 어떨까?' 하는 생각에서 시작해서손에 들고 있지만 "만약 그런 일이 일어나면 어떡하지?"라는 미래에 대해 생각하지 않죠. 그걸로 생계를 꾸려야 할 수도 있는데 말이에요. 그리고 이건 자신만의 문제가 아닙니다. 상업화 경로를 선택하고 회사를 설립하면 많은 압박감이 생기게 됩니다. 그 압박감의 상당 부분은 이런 사실을 깨닫는 데서 옵니다. 알다시피, 제가 Armon과 Hashicorp를 시작했을 때, 우리는 실패를 두려워하지 않았어요. 실패해도 괜찮다고 생각했죠. 대담한 시도를 해보자고 했어요. 실패하더라도 그냥 다른 직장을 찾으면 된다고 생각했으니까요. 물론 요즘은 취업이 훨씬 더 어려워졌죠. 당시엔 경제 상황이 달랐습니다. 하지만 그때 우리는 22살의 젊은이였고 그렇게 생각했어요. 조금 무신경했을 수도 있지만, 그때는 그렇게 생각했고 신경 쓰지 않았죠. 하지만 직원들을 고용하기 시작하면서 상황이 달라졌어요. 어느 순간부터 저는 잠을 자는 데 어려움을 겪기 시작했습니다. 짧은 기간 동안 매일 불안감을 느꼈어요. 회사가 잘 되지 않던 시기에 특히 심했죠. 갑자기 많은 불안감이 밀려왔는데, 그 이유는 우리 회사의 급여에 의존해 생활하는 사람들이 있다는 걸 깨달았기 때문이에요. 그들은 그 돈으로 주택담보대출금을 갚고 아이들을 키우고 있었죠. 저는 아이가 없어서 실패해도 상관없었지만, 다른 사람들에게는 실패가 그들의 인생에 큰 영향을 미칠 수 있다는 그래서 어느 순간 그것이 나에게 와 닿았고 회사 자체도 어려움을 겪고 있었습니다. 그리고 저는 시작했습니다, 잠시 동안 정말 무거워지고 있었습니다. 저는 매우 특정한 줌 미팅이 있었다고 말씀드리겠습니다. 우리는 무언가의 상업적 적합성을 찾으려 하고 있었죠. 그리고 제가 얘기하고 있던 사람은 아주 평범한 근무 시간대에 원룸 아파트에서 세 아이와 함께 있었습니다. 두 아이가 뒤에서 소리를 지르고 있었고 그 사람은 노이즈 캔슬링 헤드폰을 착용하고 저와 얘기하고 있었습니다. 그 미팅을 마치고 저는 생각했습니다, 나는 그 사람에게 내가 목격한 것 이상의 스트레스를 주고 싶지 않다고. 그래서 그런 순간들이, 오픈소스이든 아니든, 상업적 기업의 창업자로서 결정을 내리는 데 있어 정말 큰 촉매제가 되기 시작했습니다. 저는 그렇게 생각합니다, 네, 오픈소스는 어렵습니다. 왜냐하면 근본적으로 인간적이기 때문이죠. 인간성과 많이 연관되어 있습니다. 우리는 이런 창의적인 것들을 만들어 세상에 내놓아 사람들이 즐기고 사용할 수 있게 하고 싶어 하죠. 그리고 우리는 그로부터 인정을 받습니다. 하지만 우리 자신의 필요와 특히 회사를 세우면서 다른 사람들의 필요를 떠안게 되는 현실이 있습니다. 저는 그저, 그것이 어려운 결정이라고 생각합니다. 처음에는 어려워 보이지 않을 수 있지만, 회사를 만들면서 다른 사람들의 필요를 책임지게 되면, 정말 어려운 결중요해집니다. 그리고 제 생각에는, 아시다시피, 많은 경우 큰 논란의 원인이 될 수 있지만, 사람들은 이것이 매우 인간적인 일이라는 점을 명심해야 합니다. 그리고 알다시피, 이것은, 심지어 사람들이, 기업들이 라이선스 결정을 재고하거나 할 때도, 종종 필요에 의해 지속 가능한 비즈니스를 구축하고 경쟁 시장에서 지속 가능한 비즈니스를 만들려는 생각에서 비롯됩니다. 그리고 문제는, 모든 가치를 무료로 제공하는 것은, 오픈소스에서 그렇게 하는 것이 칭찬할 만하지만, 실제로 결과가 따릅니다. 그래요, 아마도 원룸 아파트에 사는 세 아이의 부모가 회사가 예산을 긴축하려고 해서 일자리를 잃을 수도 있습니다. 그리고 그것은 실제적인 영향입니다. 그래서, 라이선스 변경이 그만한 가치가 있을까요? 절대적으로 그렇습니다. 만약 그 조직의 사람들이 일자리를 유지할 수 있다면 말이죠. 네, 물론입니다. 저는, 이런 일들의 인간적 비용이 때때로 간과된다고 생각합니다. 네, 제 생각에는, 아주 일반적인 말일 수 있지만, 해커 뉴스나 트위터 같은 곳에서, 제 영역에서는, 이것이 기술 분야에만 국한된 것은 아니라고 봅니다. 물론 다른 분야에서도 그렇겠지만, 특히 기술 분야에서는 사람들이 결정을 지나치게 단순화하는 경향이 있습니다.매우 환원주의적인 사고방식으로 모든 것을 생각하게 되죠. 세상이 단순하고 쉬운 결정만 있다고 생각하고 싶지만 제 경험상 그렇지 않습니다. 오픈소스와 관련 없이 사업을 운영하는 것만 봐도 거의 모든 결정이 어렵고 복잡한 측면이 있었습니다. 그게 그 위치에 있는 사람으로서 정말 스트레스 받는 부분이죠. 제가 공개적으로 이야기했고 자주 언급되던 주제 중 하나는 지금은 좀 오래된 이야기지만 Hashgraph가 원격 우선 회사라는 점이었습니다. 그런데 사람들이 "특정 국가에서 채용을 안 하니 진정한 원격 회사가 아니다"라고 자주 비난했죠. 어느 시점에 저는 정말 지쳤습니다. 그 글은 여전히 남아있고 당시에는 정확했습니다. 하지만 다른 사람의 원격 관련 글에 똑같은 말이 나오는 걸 보고 이제 바로잡아야겠다고 생각했습니다. 그래서 전 세계 어디서나 사람을 고용하는 것의 법적 복잡성에 대해 설명하는 댓글을 올렸습니다. 실제로는 그렇게 쉽지 않다는 점을 말이죠. IT 업계에서는 인터넷 때문에 우리나라에서 전 세계에 접근할 수 있다고 생각하는 경향이 있습니다. 뭔가를 입력하면 바로 연결되는 것처럼 느껴지죠. 하지만 실제로는 그렇게 단순하지 않습니다.어디든 갈 수 있을 것 같았죠. 하지만 제가 말씀드리고 싶은 점은 세상은 인재 채용 관점에서 매우 불평등하고, 우리는 법률에 묶여 있어서 제약을 받습니다. 그래서 저는 HR 외의 모든 결정에서도 마찬가지로 기술적 결정이나 그런 것들에서도 결정을 내리는 게 결코 쉽지 않았다고 봅니다. 쉽지 않은 결정 얘기가 나왔으니 말인데, 라이선스 선택도 꽤 어려울 수 있죠. 앞서 말씀하신 것처럼 새로운 흥미로운 라이선스들이 나왔고 그 당시 있었다면 선택했을 수도 있다고 하셨는데, 그 새로운 라이선스들은 무엇인가요? 제가 선택했을지는 모르겠지만, 중요한 건 제가 오픈소스 프로젝트를 시작했을 때 실제로 고려할 만한 선택지는 매우 관대한 라이선스들뿐이었다는 거예요. GPL, MIT, Apache, BSD 같은 오래된 오픈소스 라이선스들이 있었죠. 하지만 그게 전부였어요. 당시에는 수익화 수단으로서의 라이선스에 대한 논의가 없었습니다. 분명히 말씀드리면, 이중 라이선스는 하나만 존재했는데 GPL 프로젝트에서 돈을 내면 GPL이 아닌 다른 라이선스를 쓸 수 있었죠. 하지만 당시에는 아무도 그렇게 생각하지 않았어요. 지금은 모르겠지만 그때는 그게 사업 성장의 viable한 방법으로 여겨지지 않았죠. 벤처 성장의 실행 가능한 방법으로 보지 않았어요.사업이었죠. 작은 회사나 개인이 선택할 만한 viable한 옵션으로 여겨졌지만 벤처 성장 사업으로는 보지 않았어요. 그래서 실제로 논의 대상이 되지 않았죠. 요즘에는 추가 라이선스를 개발하려는 진지한 노력이 보이고 있어요. 이는 지속 가능성을 염두에 두면서도 소스를 공유하고 커뮤니티를 구축할 수 있게 하려는 의도입니다. 하지만 이 분야에는 아직 많은 불확실성이 있다고 봅니다. 모두가 동의하는 하나의 최선의 접근법은 명확히 없어요. 하지만 여전히 살펴볼 만한 흥미로운 주제라고 생각합니다. 아직 하나를 골라 추천하긴 어렵지만, 전체 커뮤니티가 이런 대안들을 탐구하기 시작했다는 점이 좋습니다. 사실 시작한 지 몇 년 됐지만, 지속 가능성을 염두에 두고 이런 대안들을 탐구하고 있다는 게 기쁩니다. 네, 정말 필요한 일이죠. 우리가 겪은 고통과 논쟁을 보면 이 분야에 더 많은 관심과 시도가 필요하다는 게 분명해요. 좋은 해결책을 찾을 수 있길 바랍니다. 비즈니스를 구축하면서 오픈소스 제품을 가지고 있다면, 양쪽의 장점을 모두 취할 수 있는 좋은 라이선스가 있으면 좋겠어요. 네, 두 가지 극단이 있죠. 하나는 GPL 수준의 완전히 자유롭고 오픈된 소스이고, 다른 하나는 완전히 폐쇄적이고 독점적인 소스입니다. GPL 수준의 완전히 자유롭고 오픈된 소스가 한쪽 극단이고, 다른 한쪽 극단은 완전히 폐그리고 오픈 소스를 절대적으로 지지하는 사람들조차도 모두가 동의할 것이라고 생각합니다 우리는 비즈니스를 위해 모든 것을 완전히 클로즈드 소스로 만드는 것이 더 쉬운 현실을 절대 원하지 않습니다. 알다시피, 저는 Mac OS와 같은 클로즈드 플랫폼에서 정기적으로 개발하는 개발자로서 그들은 오픈 소스 부분이 있지만 대부분은 클로즈드입니다 제가 아주 적은 권한만 가지고 있더라도 예를 들어 SwiftUI의 소스 코드를 갖는 것이 그렇지 않은 것보다 훨씬 낫습니다. 하지만 저는 그것을 가지고 있지 않죠. 그래서 어떻게 작동하는지 전혀 모릅니다 문서가 부족하면 완전히 곤란해집니다. 그래서 비즈니스가 성공할 수 있는 어떤 지점을 찾을 수 있기를 바랍니다 최소한 소스를 공유할 수 있는 능력을 유지하고, 가능하다면 커뮤니티를 구축하고 그 성공을 어느 정도 공유할 수 있기를 바랍니다. 하지만 이것은 정말 열린 활발한 질문이라고 생각합니다 네, 맞습니다. 자, 마지막 몇 가지 질문을 하겠습니다 우리는 항상 미래에 대해 이야기하며 세그먼트를 마무리합니다 앞으로의 전망이나 다음 계획에 대해서요. 그래서 아마도 당신에게는 터미널 인터뷰, 터미널 에뮬레이터를 작업하고 계시죠 거기에 많은 시간을 투자하고 계신데, 오랫동안 작업할 수 있는 그런 프로젝트일 수 있겠네요. 하지만 혹시 현재 프로젝트 이외에 다음으로 하고 싶은 비즈니스 아이디어나 전문적으로네, 현재로서는 아닙니다. 구체적인 아이디어는 없어요. 다음으로, 저는 이 터미널 에뮬레이터를 오랫동안 작업하길 바랍니다. 제 생각에는 터미널 에뮬레이션에는 많은 기술적 기회가 있습니다. 해결된 문제처럼 보이고, 오래되고 지루해 보일 수 있지만 말이죠. 실제로 많은 것들이 있다고 생각합니다. 제가 설명했듯이 이것은 웹 브라우저의 텍스트 플랫폼 버전입니다. 웹 브라우저가 사라지지 않을 것처럼요. 웹 브라우저를 없애려는 게 아닙니다, 그렇게 미친 건 아니에요. 하지만 견고한 텍스트 UI 플랫폼을 위한 공간이 있다고 생각하고 그게 바로 터미널이 하는 일이죠. 동시에 제가 말했듯이, 터미널은 거의 혁신하지 않습니다. 브라우저의 혁신 속도의 0.1% 정도에 불과해요. 그래서 만약 그걸 5%로만 올린다면, 조금이라도 시작해서 뭔가를 도입한다면 어떨까요. 그게 제가 하려는 거예요. 저는 이것을 제 기술적 자선 활동이라고 부릅니다. 우리는 삶에서 사회적 선을 추구하려 하고, 우리 공동체를 돕는 등의 방식으로 그렇게 하려고 하죠. 터미널 에뮬레이터는 제게 있어서 기술적 버블 버전의 그런 것입니다. 과거의 성공 덕분에 이제 시간이 더 많아져서, 제 열정과 에너지를 개발자들의 삶을 이런 식으로 더 나아지게 만드는 데 쏟을 수 있을까 하는 거죠. 그래서 터미널에 대해 그렇게 생각합니다. 하지만 그 외에는, 제가48:58.960 --> 49:02누군가 할 수 없는 일을. 나는 하지 않을 거예요. 바쁘게 지내는 걸 좋아하고 일하는 걸 좋아해요. 지금 당장 사업 아이디어는 없지만 계속 바쁘게 일할 거예요. 그래요. 심지어 터미널 에뮬레이터의 이름조차 그 느림을 말해주는 게 재미있어요. 왜냐하면 우리가 60년대의 것을 에뮬레이션하고 있잖아요? 왜 아직도 에뮬레이션이란 말이 들어가 있을까요? 네, 실제로 커뮤니티의 일부 사람들과 이에 대해 얘기해봤어요. 기본적으로는 옛날 터미널을 에뮬레이션하지만, 혁신을 시작하면 그게 공정하고 정확할까요? 터미널 에뮬레이션이라고 부르면 사람들이 화낼까요? Kitty, Alacrity 같은 다른 터미널 에뮬레이터들도 있잖아요. 그들을 대변하는 건 아니지만, 내가 새로운 걸 시도하면 그들이 당연히 할 수 있는 반응은 "그만해"일 거예요. 더 이상 에뮬레이션이 아니라 혁신이고, 그들에게 더 많은 일을 만들어내고 화나게 할 테니까요. 그래서 다른 표현을 써야 할지, 특정 기능에 대해 다른 터미널과 호환되려고 하지 않는다고 말해야 할지 고민했어요. 그들에게 강요하려는 게 아니라 대체 텍스트 인터페이스 플랫폼 같은 걸 만들려고 한다고요. 아직 모르겠어요. 여전히 고민 중이에요. 네, 이 분야에서 일하는 몇 사람과 얘기해봤어요. 초기 에피소드 중 하나는 Fig 창업자들이었는데, 결국 아마존에 회사를 팔았죠. 그들은 정말 흥미로운 일을 하고 있그들은 장기적으로 터미널을 재구축할 계획을 가지고 있었습니다 Warp 창립자들을 초대했는데, 그들은 그 분야에서 정말 흥미로운 작업을 하고 있습니다. 좋은 분야라고 생각하고 사람들이 그 일을 하는 것을 보니 기쁩니다. 개발자들은 특히 터미널에서 많은 시간을 보내기 때문에 그 경험을 개선하는 것이 중요합니다. 팟캐스트에서는 그 사람이 관여한 분야에 대해 미래 지향적인 질문을 하고 싶습니다. 당신은 클라우드와 인프라 분야에 10년 이상 관여해 왔습니다. 네, 거의 평생 동안 말이죠. 클라우드와 인프라의 미래가 어떻게 될 것 같나요? 더 복잡해질까요, 아니면 덜 복잡해질까요? 네, 제 생각에는 먼저 제가 더 이상 이 분야에서 일하지 않는다는 점을 밝힙니다 Hashicorp를 떠날 때의 제 생각은 지금도 같은데, 덜 복잡해져야 한다고 봅니다 제가 Hashicorp를 시작했을 때는 매우 제한된 도구들이 있었고 사용하기 어려웠습니다 지금은 개별적으로는 사용하기 쉬운 많은 도구들이 있지만 원하는 작업을 수행하려면 더 많은 도구들을 연결해야 합니다 그리고 그것이 좋지 않게 느껴집니다. 그래서 저는 미래가 더 단순해지기를 희망합니다 그리고사용 면에서 더 간단하고 복잡성 측면에서도 더 단순해집니다. 쿠버네티스를 예로 들면, 쿠버네티스는 좋지만 제가 쿠버네티스를 사용할 때마다 쿠버네티스만 있는 게 아니라 쿠버네티스와 10개 정도의 다른 벤더 프로젝트가 통합되어 있습니다. 그래서 매우 복잡해집니다. HashiCorp도 어느 정도 그 문제의 일부입니다. Vault만 해도 사용하려면 많은 다른 도구가 필요합니다. 그래서 단순화할 기회가 있다고 봅니다. 그게 미래라고 생각합니다. 일부는 제가 과거의 PaaS로 돌아가자는 뜻으로 이해하는데, Heroku 같은 것을 다시 쓰자는 게 아닙니다. Heroku를 좋아했고 새로운 Heroku 스타일 서비스도 좋아하지만, 모든 사람에게 완벽히 맞는 박스를 만들기는 너무 어렵습니다. 그래서 그런 서비스가 다시 성장해 시장의 일부를 차지하더라도, 더 복잡하고 특별한 요구사항이 있는 쪽에서는 더 단순하고 나은 도구가 필요할 것입니다. 복잡하고 특별한 요구사항이 있는 쪽에서는 더 단순하고 나은 도구가 필요할 것입니다. 좋습니다. 이번 주 질문은 여기까지입니다. 팟캐스트에 와주셔서 감사합니다. 지난 10년간의 일에 대한 당신의 견해를 들을 수 있어 즐거웠고, Zig와 터미널 에뮬레이터에 대해 이야기 나눌 수 있어 좋았습니다. 정말 감사합니다. 대화 나누기 좋았습니다. 네, Mitchell, 출연해 주셔서 감사합니다. 당신의 작업은이 분야에 있는 모든 사람들에게 확실히 영향을 미쳤죠 그리고 제 경력 초기에 당신의 오픈소스 프로젝트를 사용한 후에 이렇게 당신과 대화를 나누는 것이 참 흥미롭네요 정말 재미있는 경험이에요. 저를 초대해 주셔서 정말 감사합니다 좋은 시간이었어요. 정말 고마워요