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,