 We've got a great keynote lined up for us this year at Scale, so we'll get to Mitchell here. So how many folks out there are using things like Vagrant and Terraform and other open source tooling for managing your cloud or on-prem infrastructure? So that's pretty much the entire room. I get to introduce a lot of folks that have built things I use at Scale during keynotes and other sessions, but I think the last four or five years of my career have been all using things that Mitchell and his team build at Hashicorp. I'm super excited to have him here on stage today. One thing that's been interesting over the last year or so, there's been a lot of kerfuffle about sustainable open source businesses and how do you have a business model around your products when you give all the code away for free. It feels like we're kind of back to maybe 98, 99 again where people are asking how do you do this. They're playing with licenses, they're doing all kinds of crazy stuff, won't point any fingers. But I think what's interesting here is Mitchell and his team at Hashicorp have built a fantastic business and they do it with a very vibrant open source community that it sounds like all of us are a part of. So we thought it would be a great opportunity to show the scale community and the wider open source community what it takes to build a company that can do that without playing some of the licensing games and some of the other things that are out there and to learn a little bit about how Mitchell took his dorm room projects and turned them into something we all use every day. Which I think is a story about a lot of open source projects that we all love seem to follow. With that, I'd like to bring on Mitchell and we'll go ahead and start. Thank you. Thanks. All right. Thank you. Thank you. Okay. So yeah, as he said, I'm going to talk about growing Hashicorp from a dorm room project and that's true. I started vagrant in a dorm room so we'll get going. I'm Mitchell Hashimoto. I'm one of the founders and CTOs of Hashicorp. And for those who don't know, Hashicorp were the creator of a number of tools. So I'm not going to explain what they are, but I will just name them. Vagrant, Packer, Consul, Terraform, Vault, and Nomad. So if you've used any of these, we're the maintainers. I was one of the initial creators of these tools, but most of them have teams behind them now. Some fun facts, just these are vanity metrics that I'm going to share with you, but they're cool. I'm proud of them and it might help just set the playing field of what I'm talking about here. Our tools collectively get 50 million downloads per year, which is quite a lot, and we'll talk about how it's where it started from. Another way to look at it is there's around 5,000 unique external contributors to our project. So this isn't open source that our company is just maintaining. About every release, each release of each of our projects usually has 50 to 100 external contributors. It's a very vibrant open source community. More in the actual usage, over 90% of U.S. financial transactions for a rough definition of it go through our software in some form, so that's very cool. Pedabytes of chat messages for one of the world's most popular mobile chat platforms that I'm sure almost all of you have in your pocket here today are every single chat message is encrypted by Vault, which is very cool. I think this is really fun. There's one spacecraft that I know of that is actually in orbit right now that our software is running on. Very cool. I think there's more, but they won't tell me. But the coolest thing of all, obviously, being here is that all of those projects are open source, and they're open source in the sense that they're Mozilla public licensed. There's not some weird license to them. There's a community. We run a user conference. We have external contributors. You could open a pull request. You could be a core committer if you wanted to. And I think that's really, really powerful. And me personally, I love open source. And so a really quick tangent is that I'm not sure. I won't be hyperbolic, but I'm not sure how. I think that open source is really critical to me becoming a programmer as fast as I did because I'm a self-taught programmer originally. I taught myself. I started Googling and picking up programming. I guess I was altivist at the time. When I was 11 or 12, and I was really, really struggling to learn this stuff. The resources online weren't as good. I was an 11 or 12-year-old, so I couldn't buy books. These book industry books tend to be really expensive. And so my parents weren't enthused that I wanted a $50 book on HTML or something. And I just remember this moment where I discovered a website called Planet Source Code, which isn't open source in the community sense. It's more in the zip up your source code and upload it. And it might be full of viruses, but it's there. And I found this website, and it just blew my mind because suddenly I had these resources where almost anything I wanted to do, I could search up how to build a chat thing, how to build a video game, how to do all this stuff. And I had all this sample source code. And it was pretty bad source code, but it at least taught me things. And so that was the beginning. And then of course I got into open source communities like PHP and Ruby and so on. Now more than to go. But open source has been critical to basically where I am and obviously with the business success too. So today what I want to talk about is sort of this challenge of open source. I think this is how I felt when I started getting into open source as a maintainer, as a creator. And basically what you have, right, is on the left side you have, on the extreme left you have a cool weekend project. Something you built, something that works, something you're proud of. And then on the right side you see these successful large self-sustaining open source projects. Maybe they make money, maybe they don't. And there's just no guide for how to get through that process in the middle. And I don't think every project needs to be the owl, right? If your goals are just to build something fun and have a small community and maybe not even have a community, like you just want to publish some stuff that you built, that's totally fine. But there's also a lot of projects that I think, you know, could be more towards the right and want to be more towards the right. And it's just how do you get there is the struggle. So this is the question mark, question mark. It's the classic like step one, do a thing, like step two, question mark, step three profit, right? There's no metal there. And so hopefully none of you get up and walk away here. But the actual conclusion of this talk is I actually don't know. I don't know what those steps should be. And there's a lot of people. There's a really active area of conversation. I think a lot of us don't know what those steps should be. But what I do have is experience and a personal anecdotal experience. And that's a key thing. So when I was invited to come here and talk to you today, I don't think I'm thinking critically enough about how to make open source sustainable. Like I don't think I'm that person. There's a lot of people that are critically thinking about sustainable open source right now. I am very much distracted by HashiCorp. And so what I have instead is an anecdotal experience about my path through those question marks. And what I'm hoping is I could share that with you. The people who are critically thinking about sustainable open source could pull out the parts that are useful and maybe ignore the parts that are bad. And for everyone else, hopefully it's an interesting story. It paints some color on how things came to be. And I think that especially towards the beginning part, it's going to overlap a lot with a lot of people in the room, which is you just have a project and maybe you want it to be more. And you don't want it to be a big company, but you just want it to be a little bit more and maybe it'll help you out. So that was my disclaimer. Don't think that I'm generalizing my survivorship bias to any project out there. Cool. So there's four key categories that I'm going to try to come back to at various points. And so there's the product of what I'm building, who I'm building for, which changes over time. There's community. So how do you manage a community? That's a very critical part of open source. I'd argue you don't really have open source without community. The financial aspect, that's sort of the whole point of sustainability in our capitalist society, I think. And personal role, because I think this is really important as the creator of a project, as the initial person, how does your personal role change? And so I'll talk about how my role changed. And I think for all the programmers who have their own projects, the question is, when did you stop coding, and when did you start coding, and when did you stop coding again, and back and forth? And so I'll point those out. Cool. And so I'm going to mention it as a timeline. But instead of actual dates, I will give you years. I tried to split the timeline into events because I think that everybody's journey through here is pretty, the timeline is kind of agnostic. You could spend six months until you have a huge success or you could spend six years. And so I'm going to try to do events and do my best to keep it that way. But I'll show you the years that I was experiencing this in. And to start, I'm going to just show you one slide to fast forward to today to give you the state of my world today to see where we're going to talk through to. So today, from a technical side, I already went through this, six projects, downloads, contributors. It's fine. The last bullet point is cool. They don't give us exact numbers, but by our knowledge, we are spinning up over 10% of all cloud workloads with Terraform, which is pretty big across the clouds, which is big. From a people perspective, we have 450 employees. We are a fully distributed or distributed first company. So I live in LA. Our headquarters is in San Francisco, but only about 10% of the company is there. Otherwise, we're in 30 states and over 10 countries and all our processes and the way we work is distributed first, which is, that could be a whole talk in its own. And I'm probably not going to talk about that ever again in this talk. So that's just a cool thing to point out. From the business side, 10% of the global 2000 are paying customers of ours, over 10% now. We are a VC funded company, but for the past few years, we have been putting cash in the bank. So I know there's a lot of stereotypes and there's a lot of really bad VC companies, bad actors, or just like people that like to light money on fire. We are very much not that company. We have no ping pong tables. We have no foosball tables. Well, we're distributed anyway, so we're not going to send you onto your house. But we're not that kind of company. So I talk a little bit about why the VC funding for us was important, but I'm totally open to whatever options people take. So let's start with the inception period. We're in 2019. The inception period was 2009. So we're talking about 10 years here. It took me about 10 years to get to that today that I just showed you. And the inception is really about Vagrant, because that was the first successful project that I had. And that's a key point, because 2009 was where Vagrant was sort of thought of and created. But I started building my own open source projects around 2006, probably. And so that's many years of failure. I never thought it was failure. I mean, I was having fun. It wasn't failure. But it was many years of just not a big success, right? So with Vagrant, the primary concerns when I was starting the project was sort of this, how do I get initial success? How do people even learn about it and use it is one problem. Another one was I wanted to reproduce this feeling of magic. I think that that's a way that people get hooked into projects. And I think the most famous one in recent memory is the Rails 15-minute blog post video. I don't know how many people here watched that and made ridiculous life-changing decisions because of it. I look back and think it's ridiculous. I watched a 15-minute video. And because I watched a 15-minute video, I switched from Windows to Mac. I switched from PHP to Ruby. And I switched from whatever editor I was using on Windows to TextMate. I use Vim now, which is way better. But I look back and I'm like, why did a 15-minute video have such a weird effect on me that I switched operating system, programming, language, and editor? That's wild. So I kind of wanted to reproduce this. I think getting those initial users is really important. And the magic feeling is really important to do that. I was worried about appearing competent. So again, setting the context at the time, I was a college student, undergraduate college student. Vagrant, as many of you know, is built on top of virtualization. Fun fact is before I started writing a single line of code of Vagrant, I just heard about virtualization two months prior to that. I had never even used it at that point. So I didn't know what I was doing. I had not had a real programming job yet. So there's a lot of reasons why no one should have ever trusted me to build Vagrant. I kind of wanted to keep that a secret. And so I was really worried about appearing competent. And then the last thing was, again, college student. I didn't have money to really spend on this project. I think for a college student, having $1,500 in the bank is quite a lot of money. So I wasn't destitute by any means. But having that much money, I wasn't keen to spend hundreds of dollars on this project. I wanted to keep it cheap. But what was not a concern at all? Not even in my mind was making money from the project. And this sometimes surprises people, maybe not in this room. Some people think, but you had to have thought, if this gets popular, it might make me money or something. I promise not a thought in my mind was about making money. I had a problem. I wanted to solve it. I wanted to build something cool. And I would say the only thing I was looking for was some validation. The only thing I thought that I could tie to financials was maybe this will help me get a job when I graduate. That was sort of the only connection I made. Yeah, so the money part comes later. So coming back to these, sort of how I got there. So like I said, the initial success thing, I think you need a wow factor. The magic feeling is the way to get it. So the way that I thought of this, and this is what really guided the vagrant up experience, was sort of this real 15 minute blog post. Again, sort of doing crazy things in my life. But vagrant up was really me trying to build this like, whoa, feeling, right? It was like, you could run one command, everything gets created, you didn't have to touch anything else. That kind of freaks people out. And so I think that at the time there wasn't a lot of projects that put that much functionality into one command. It's not great UNIX philosophy, right? But I think that it's a good user experience, and it's what you want in automation sometimes. And so I packed it in, and I tried to make the home page of a vagrant show to download and run this command. And you're going to have a Linux machine on whatever platform you're running on. And at the time, that was really new to people. So appearing competent, so it was really important to get a logo, a design, like all this superficial stuff. I guess another tangent I'll go on here. I don't have time to go on tangents. Another tangent I'll go on here is my dad's a dentist. And my mom asked him one time why he stresses out so much about people having straight teeth or his patients and me and family having straight teeth. Like, what does it matter? And his response was that it doesn't functionally matter, right? Like, crooked teeth chew just fine. Like, it doesn't matter. But the reality is that the world shouldn't be, but the world is superficial, and they see your teeth first. And so why not just have straight teeth if you can? We live in LA, by the way. And so that was sort of the reason. But I think it goes with this, which is that you shouldn't judge a book by its cover. A great, great project. There's so many great projects. Like, look at DJB's tools and stuff. Like, they just have all-text websites. Like, you shouldn't judge a project by its website by any means, but people do. And so my workaround with this was let me try to look professional. And then maybe people won't dig too deep and realize the fact that I'm a college student. They have no idea what I'm talking about. And that worked. And then the low-working capital. So the original Vagrant logo, bonus points for anyone here who remembers that mascot's name. I paid somebody on DeviantArt $15 for that, which worked out really nicely. For the website design, I followed this open-source programmer who's still very much active in various communities and liked his personal website, asked if I could use it, said yes. I gave him permission for the duration I used that in the footer of Vagrant. So free website design that I thought was good, $15 for a logo, looked professional, wrote a lot of docs, and it worked. So I released Vagrant 0.1 in March 2010, a few months later. And I don't know what slide I have next. No. So I removed these slides. But I think what people expect here is that there was, like, immediate success. And then, I don't know, like, people appeared out of nowhere. Like, there's millions of downloads. I don't know, money started falling out of the sky. I don't know what people think. But I think people think it's like an overnight thing. I think Armand, my co-founder, says it best, which is that Vagrant and HoshGorb in general is the best overnight success that took 10 years. And so, yeah, nothing really happened. There weren't a lot of users, and we'll get to that. But I was actually truly happy. I mean, everything about this launch was great. I got to the front page of Hacker News. Hacker News is all sorts of, like, kind of toxicity nowadays, but it was a nicer place then. It was fun. And I mean, I'd never been to the front page of Hacker News. So getting to the front page was really personally satisfying for me. People in the comments were relatively nice. If you look back at this, they weren't too bad. And IRC was active, so I had an IRC channel. These are fake messages, but the feelings were real. I remember that this is roughly what people were saying at the time. Yeah, there's always the Linux person, right? And then this one actually is real. The username isn't real. I can't remember his username. But this Adam is actually Adam Jacobs, the founder, creator of Chef. He was one of the first people to find Vagrant. And he hopped into the IRC channel. He was probably the fifth person in there. And this is exactly what he said. This is exactly what he said. And I knew who Adam Jacobs was because I was using Chef at my job at the time. And I viewed Chef as one of those OWL projects, right? Like, it was successful. It was big. There was a company I respected Adam a lot. I was a Ruby programmer, so Chef was really cool for me. And having him come in here was just awesome. It made me feel great. Made me feel like I was on the right path. So that was cool. But there was 10 people in IRC. So the key categories here, I mean, the product was just me. 100% me. Community was small, right? There was less than 10 people in IRC. There was maybe a mailing list message every few days or once a week. There was no financial concern whatsoever. And my personal role was everything. But the key point at this point is everything is totally sustainable for me personally. I was happy. The project's in a good place. The people are fun. If I wanted nothing more out of this, this is a healthy place to be. I could keep doing this nights and weekends, and it's not a lot of pressure. And that was sort of the reality at the time. So then the next stage of things is really the open source growth stage, which is 2011, 2012. And this gets into this idea that the expectation of that people think of vagrant when they think, look at HotScript today, is that it just took off right away and everything was great. But the reality was really that nothing was happening. And I really mean like nothing was happening. So for the first nine months of vagrant's existence, there was 500 downloads total. So that's not per release. That's not per month. It's funny, because now that we're VC funded, I've told some VC's this. And they're always like per release, per month. And I was like, no, no, good projects could come out of GitHub or wherever they come out today and be totally flat at the beginning for a lot of reasons. And it could be because the technology is great, but no one's talking about it. No one knows about it. If you cut a tree down the forest, no one's around, it doesn't make a sound, I don't know. But there was 500 downloads total. So it was a failure by that measure, I guess. And so I wanted more people to use it. I wasn't happy with not that many people use it because the people that did use it found a lot of success and thought it was really cool. And so I thought that others would find that too. So my plan was basically to speak at conferences. It seemed like a good way, but it was also this like teeth analogy thing again, which is sort of like, I saw a lot of big projects doing it and it felt like maybe that's a way to fake it until you make it in a sense. It's like, how could I get at a conference and speak about it? There was two problems with that plan. One of the problems was that I had never spoken at a conference before. I'd never written an abstract. I didn't know what an abstract was. I had no credentials beyond that. So again, I didn't have a job yet. And so I didn't see why would anyone even want me to speak at a conference? Ability aside, I didn't even know if I could, but let alone that, why would they? And problem number two was actually financial. So this is where the first, for the first time ever, there was some financial pressure coming in and not to make money, but just to be able to like evangelize my project, I guess. And so traveling to conferences is very expensive, especially as a college student, very, very expensive. And so obviously you get the ticket for free if you speak, I would hope. I've never heard of a conference charging speakers to come, but I hope so. But the travel and hotels aren't typically free. So figuring that out was pretty tough. So what I did for problem number one, what I did was I spent hours and hours watching and reading conference talks and abstracts and just learning what they're like. It's like, it's the difference between writing like a historical essay versus like a creative writing prompt versus like an academic paper. Like there had to be some structure, like some general structure to a conference talk abstract and I was looking for it. So I read hundreds of abstracts, watched hundreds of hours of talks at Ruby conferences and WordPress and PHP, all sorts of categories that I didn't really care about. I was there to figure out how to build a talk, how to give a talk. And so I did that. I submitted nine abstracts and they all got rejected. So I don't know if that was a good strategy. Problem number two on the money side, I started cold emailing companies that were active in open source communities and one of them said yes. I think I put it in here. I didn't put it in here. The company said yes as an engineer. So engineers of Ruby was, or is, I don't know what they do now. They were like a Ruby platform as a service at the time. They sponsored projects like Ruby on Rails, Bundler, some other stuff. And yeah, they, Invager was written in Ruby, which I don't think they would have accepted otherwise. So that was a good reason for that to be in Ruby. But they said yes. So they said they would give me, I forgot what it was, like $2,000 in reimbursement, a quarter or something to do TNE for conferences if I was speaking and if I put the engineer logo as a sponsor and stuff like that. So I said yes, of course. And I started going to conferences. To get problem number one, I started to let local meetups first. I got a little bit more confident. I think my abstracts got cleaner, got a little bit better. And then I started going to small local conferences and then slowly got bigger. But the key point is that it worked. The downloads went up. And so they didn't go up from 500 to 5,000 immediately, but they started trending up. Whereas for the first nine months, they were trending flat, if not like very slightly negative, right? People were falling off. And so the downloads are going up. Again, I was happy. But the challenge now is that things are starting to get demanding. And I'll admit that throughout this whole stage, I didn't think about a lot of things, right? I did what I thought was the right thing to do in the moment, but didn't think what the full blown effect would be. And so this wasn't an effect I thought about. And the effect, the impact was that it started to get really, really demanding because you could grow, but you can't control where it grows to at a certain point. So you can't just say, I want 500 users because that's my healthy point and then stop, right? It's just gonna keep growing. And that's what happened, which is great in one way, but very difficult in another. So at the time, the things that were increasingly demanding was, I was starting to solve problems for others. I wasn't just building things into vagrant that I had, that I needed, which is very personally satisfying, right? Instead, I was building features into vagrant that only others needed and I didn't need at all. And so I started to get this feeling like I'm just doing free work for other people, which was new. The mailing list now is very busy now, so I couldn't respond to all these, but I felt obligated to respond to them, so that was stressful. I'm now speaking at conferences, and so not only am I coding and managing this community, but I'm also wasting, not wasting, it's not waste, but I'm taking a lot of time flying, creating talks. Anybody who's given a talk knows that any talk takes a surprising amount of time to prepare, and so this was really hard. And then costs are going up that I thought wouldn't matter. So with vagrant, I was hosting boxes on S3. S3 I thought was super cheap, never did the math. And then with the downloads going up, we're at $100 a month and then 500, it actually got up to a point where out of pocket, I was somehow paying $2,000 a month in addition to my rent and stuff for this project before I started figuring out how to cover this stuff. So, and I didn't have any other option at the time. Simultaneously to this, I think this is just project stuff that'll happen to almost any project. Simultaneously to this, I thought it would be a great idea under all this pressure to sign a book deal with O'Reilly. So I did that, having never written a book before, so I don't know. I also graduated college and then realized the crushing realities of life. And so I got a job, and getting a job is so much more demanding than being a student. And so having to go to work nine to five, I was actually now working on open source from 8 p.m. or so to like 1 a.m., five or six days a week. And so hints of unhealthiness are creeping into my life at this point, and it's already getting really, really difficult. So yeah, just looking back at those key categories. From a product side, what starts shifting here is it went from really a project for me to a project for the collective, right? Because now problems are being solved that I don't have, and other people are contributing, which is great, but you still gotta review them, you still gotta maintain them. One thing I always say is the merge button is the easiest button to hit. I appreciate all contributions and they're great, but the merge button is in the hard part. It's the years of maintenance that you're on the line for, right? Like the merge button doesn't come with the person contributing, saying like, you all fix all bugs for the next three years. Like no, the maintainers fix all bugs. And so that got trickier and trickier. The finance side, like I said, the costs are starting to go up. And then my personal role is I'm still like coding 95% of everything, but spending just an increasing amount of time. I would say like the personal role is just additive time. I was doing more without becoming more efficient, right? I was just adding more stuff to do. I wasn't balancing stuff out. So yeah, that was the growth period. It was really exciting because things were becoming successful, but also just extremely stressful. I would say this was the most stressful part of the open source growth aspect. So then I decided to found a company. I thought that that, I kind of felt forced into it, to be honest. I didn't see any other way. I saw two choices. It was either stop working on the open source projects or quit my job and they had trade offs, right? Like one side is like work on your passion and the other side is like actually make money. And so I had to make this choice. I chose the passion sort of side of things. I founded the company and my idea originally was to monetize the existing user base and not raise venture capital. So I didn't raise venture capital right away. Hosh Group existed for about a year before I raised venture capital. So the initial idea was just monetize the existing user base. I wasn't going for some crazy acquisition or like millions of dollars or anything. It was like, the motivation really was like, how do I work on my projects? That was pretty much it. So the ideas I had were this vagrant VMware plugin idea or more abstractly like build paid plugins for the open source project. It felt like a clean approach because, I might have slides for this, but it felt like a clean approach because I would use a plugin interface that anybody in the community could use. So I wasn't doing something super proprietary. Even though I was selling something proprietary, it's like you could build it yourself. So that was one approach. The other was doing some consulting for features like having people actually pay me to do the work that they expected of me rather than doing it for free. Non-ideas were support and donations. So support, I mean, there's a bunch of reasons here, but the flat out, like I just didn't want to. Support's not exciting, right? And it's, yeah, I just didn't want to do it. Donations, you know, the platforms didn't exist for donations then. Like things like Patreon and other things like just didn't exist. So it was harder to do donations. Most donations at the time were like PayPal recurring payments or something. But the other thing I don't like about donations is you're at the control of somebody else. Cause usually donations often follow this like power curve of donations. And if somebody pulls their donation on a month to month basis, you could go from being able to afford rent to suddenly not affording rent like that, right? And there's not a lot of personal control. And I wanted a little bit more control of my destiny. And I thought that a clean exchange of like goods or something for money would be a way to do it. So I looked at these top two. The consulting side of things worked for a while. I actually, oh, I said it down here. I was actually able to do around like $150,000 in feature integrations for vagrant in six months. But there's easy wins. So there's some low hanging fruit that some companies will pay a lot of money for that I could do right away. But the problem is those disappear and they're one time payments. And so within those six months, you know, for the first three months, I was like, oh, this is gonna work. And then very quickly nearing the six months, I realized this is never gonna work because you go from having these low hanging fruit that people will pay for to having features that will take a lot of time that people won't pay the appropriate amount for. And so this was becoming very difficult. And I realized very quickly this wasn't gonna be sustainable. But this was really good because what this did in the short term is put money in the bank that I could use to survive basically. And $150,000 is nice, but that's pre-tax. So they're coming. Then there's the vagrant and VMware side. So like I said, this was a clean separation which I liked. I was really, really nervous because I was using the public plugin interface. And I liked that from an open source purity perspective where I'm building something that anybody could build. So if you don't agree with my commercialization, just build it. I'm not gonna sue you or stop you, just have your own project. But I'm gonna charge for mine. The lesson I learned is that the communities at least around our projects were very, very supportive of the commercialization. And I think you should be because if you can't build sustainable open source, it's gonna disappear. Or a bad actor is gonna take over it. Like a big red red logo is coming for you. And so they're gonna come smash your project. And so you really want a way to have the sustainable system and the communities are generous, supportive. So in the six years, this plugin still exists. You could still buy it. In the six years this plugin has existed, no one's really ever built an alternative on their own which is nice. The justification was good, VMware is commercial, this will be commercial. I priced at $79. This is a lesson I learned from a previous side project where I charged $5. Which is that you could always lower the price but you can't really raise the price. And so I started at $79 thinking it was actually gonna be too high and I would actually have to come down to like 29 or 30. Turned out this was great. Everyone bought it at $79. A few people complained but compared to the number of people buying it, it was so low. And I did stuff like free educational licenses and things like that. And this worked super well. So in the first year, this sold $200,000 in plugins. And to this day we still sell it at Hosh Corp actually and we still haven't made this free although we probably will one day just because this is actually still to this day paying like three or four salaries at our company. So this worked pretty well. So yeah, there is money, right? And it felt like a lot of money for an individual but the reality again, the realities aren't as green which is that there's always a burst because there's always a burst of the people that are waiting for this, it's low hanging fruit. And then after you get the easy wins, you realize like why marketing and sales exists and that is a crushing reality. Like you will build it, they will come like not true. And so the lesson I learned is that developers which is the market the vagrant was looking at are very difficult to monetize. And I think this is an important reality because a lot of open source projects target developers. And the reason is that developers don't like to spend a lot of money. There's a very low price tolerance. Like try to sell an IDE versus selling a firewall. There's a very, very different price difference even though IDEs are technically like extremely complex projects. And vagrant is not an ID. I'm not saying vagrant's an ID but the analysts categorized vagrant as an IDE which was pretty annoying. And so this was really hard to do. People at this point sort of generally would say like yeah but there's projects like GitHub. GitHub is a huge company on the backs of developers basically developer success. My argument there is with GitHub you're not buying the developer tool. What you're buying with GitHub is really the social network and the collaboration functionality and not the tool itself. Like Git works just fine without GitHub. You don't pay for Git. There's hosted Git tools everywhere like why aren't you using Bitbucket or some other thing. Like you're using GitHub because everybody's on GitHub. So that's what you're paying for. So the key categories in this initial funding phase where there's no VC funding, initial company phase is that I was spending a lot more time on the product side thinking about how to make money to survive and less about the purity of the roadmap or the open source roadmap. The community was fine at this stage. It was just the same as before. It's growing. I'm struggling to keep up with it all the same. The finance side of things is staying afloat. There was a few hundred thousand dollars in the bank so I felt safe, like totally safe. I was worrying about important but dumb stuff like taxes and how to run a business. And then my personal role was just, again, just thinking more about the business less about sort of the core product development. Okay, so then a year later in 2013 and then talking through the phase to 2015 I raised venture capital. You know, I gave in, I lived in San Francisco at the time getting a lot of emails. I gave in to the emails and I took venture capital and why. So what I wanted was to build, right? Like I wanted to be able to build more things and vagrant was one thing and I was proud of its success and I thought it could be sustainable as a solo endeavor like me myself for a while. I had this best friend who, Armand is my co-founder. We had a bunch of ideas we'd had since college since we started Vagrant of other stuff we wanted to build and I didn't see a path forward, I didn't see a path forward to get there in this solo endeavor. So basically the financial growth was just too slow. We had that initial momentum but there was no, I couldn't see any way that it would grow fast enough where we could actually hire people to work on these ideas. It would have been slow. Like I think on the time horizon of a couple decades, the solo company would have been fine. I was impatient and didn't want the couple decades. At the same time, the product growth was very fast. So Packer bursts into existence. I just kind of skipped over that whole thing but Packer exists. Vagrant and Packer are growing really, really fast and so the money side is like this slow, like very slow like 0.1 slope thing going up and the user growth side is like a vertical wall. It's just jumping and downloads are going up and everything and so it didn't feel like we're doing things right. And honestly, I think the last point is the most important is I felt like I had no other options. I felt like my only options were slog through for 20 years and hope the problems still exist which I don't think they would have. I think someone else would have built Terraform, someone else would have built Vault 6 on. So either slog through for 20 years and hope they exist or raise VC. And I think this last point is sort of the crux of the sustainable open source problem in my mind which is that I should have felt like there were other options than I didn't. So I inherited all the challenges of venture capital just basically for the purpose of I wanted to build more things. Yeah, that was my personal motivation. And so we raise venture capital and 2013 to 2015, we call this the well-funded open source research project phase because we completely threw aside in an imperfect Silicon Valley company style, we completely threw aside any thought of making money and just went full bore, let's just build stuff. So we just hired a dozen engineers, zero anybody else, zero commercialization strategy whatsoever, didn't even think about how we're gonna make money. We're just gonna build stuff and maybe we'll figure it out later which I think is how most Silicon Valley companies work anyway. So we had Vagrant and Packer ready before we got the funding, then we got the funding. And in that two and a half year time cycle we built Consul, we built Terraform, we built Nomad and we built Vault. We also built a project called Auto that we shut down and we also built a project called Surf which still exists and is really important to us but doesn't get to go up here. Yeah, sorry to that thing. But we built all these. So we had a very, very productive two years and there was no way we could have done this without venture capital or an extreme patron. Like you either take money from people where you, you know, the VCs or someone had to donate like a million dollars to us which wasn't gonna happen. So that's sort of the benefit of open source that we had which is, I don't know how else this would have happened. And like I said, I think someone else would have built at least a few of these tools, right? Terraform Vault, Consul, like someone else would have built those. And so venture capital allowed us to build our tools and also personally work on my passion, my ideas, my dream and get to that point. But we knew that a reckoning was coming, right? The whole time there's this thing in the back of our mind which is like, yeah, we're gonna have to figure out how to like not light money on fire eventually. And so the challenge of this time is that, this is again my ignorance prior to taking VC was that I didn't realize how much of my focus would have to be on building a company rather than building a product. So a lot of one of the key pieces of advice I give people thinking about VC now is that you think you take money to work on your passion, you actually take money to enable others to work on your passion. That's sort of how that works. And so I was spending a lot of time hiring, thinking about culture, thinking about what we're gonna work on but not actually being that hands-on keyboard myself. There was multiple products which is a decision that I wasn't ignorant about thinking early on. I knew this would be a hard decision but it's one that I thought was important for us. I thought all these single product open source companies it would be challenging and so we wanted to build a portfolio up front. The challenge is when you have six projects and 10 employees, like looking after all those and growing them is really hard. This is still a problem we deal with today of 400 people because you wanna be able to put like 200 people towards Terraform towards Vault or something but you can't, right? Like you have to always, when you look at spreadsheets you gotta pick and try to keep it balanced. And like I said, we're kicking the money can down the road but we're gonna catch up to that can eventually. So I'm gonna skip this. I think that I explained this all. I would say in the personal role side I'm still coding here but I'm spending so much time in a seen amount of time thinking about people, finances, business plans, talking to VCs, board meetings appeared out of nowhere. So the personal role side of things is probably, I would say coding like two or three days a week at this point and then spending a lot more time on the business side of things. That will eventually drop down to zero before popping back up though. So then we hit the commercialization side which is sort of 2016 to today. And I think this is just interesting if, I think less people want to be here but I think it's still interesting. So the can catches up with us and we have to make money and it's becoming scary if we don't make money for our company. And so the reality that we had, we still have this $80 user VMware plugin thing. At this point it's probably making like half a million dollars a year or something. That's not great because that doesn't pay many people or it pays a lot of people really poorly but we weren't doing that. So this wasn't gonna work. So our old model wasn't going to work. It wasn't as I would say VC scale. Open source users love them. They also self select for free generally as a broad statement here. It kind of reminds me of the iPhone app store or Android app store. Maybe I've never used an Android story. But it's sort of like there's the people that only buy free apps and will never ever buy an app that's even 99 cents and there's people that are totally fine with like a $3 app, right? And there's a huge divide. Like you show a 99 cent app to a person who only does free and it's like the end of the world. Like how could anything be worth 99 cents as they're drinking a coffee, right? And then there's the people that don't care, right? $3, $5, it's a coffee. They have that reality. Open source users are very much like that which is they're super important as early adopters. They're very hard to monetize because there's an expectation coming into open source that you're getting stuff for free. I don't know if that expectation's healthy, but it's there. And so a lot of the questions we ask open source users, would you pay for this? Would you pay for this? A lot of it was like, no, that should be free. No, that should be free. It was hard. And our software, this is an us problem, is not well suited for SaaS. Like you can't really run Vault or Vagrant or these things as like a SaaS product. And so you have companies that can go the SaaS route and that really wasn't an option for us. So the key reality we thought of, and I'll just go through this fast, is that the user doesn't have to actually be the buyer. That's something we realized was that our products were being used at like all these huge companies. Like huge, huge companies were using them, but in those companies, the person using them doesn't actually hold the credit card to buy the software. And so we figured that out. We call this one side the practitioner and the technical decision maker, but that doesn't matter. But what we realized was enterprise. We could sell to enterprise companies because what the open source community is very good at is being passionate and finding a good solution and using what I think is the right solution. I think that's really powerful. And so they could be champions. So let's say, as an open source user, we're not gonna try to sell you. You don't wanna buy anything anyway. We're not gonna try to sell to you. Instead, just try to bring it into your company and we'll work on your boss and we'll try to get them to buy it at a company scale and we'll build features that way so that you don't feel taken advantage of on the open source side. And that was sort of our strategy. And the benefits here is that you monetize companies, not individuals. The nice thing about this is they spend more money. The downside is it takes longer, a lot longer. There's cleaner feature separation. So I think, going into this again, I think a lot of open source founders I talked to say, yeah, but we have 10 million downloads. If we extract just a dollar from each user, that's 10 million dollars. But the cost of that, the challenge of getting that dollar is so high and anything you do is gonna be friction there. So we took the opposite approach, which is like what if we don't ever charge that group of download users anything ever for anything they would want, realistically. And instead we build features that the buyer is gonna want. So examples of that are Invault. One of the, there's not a sales bet, so I'll just give one example. Like Invault, one of the features we sell is the ability to filter replication between regions because as a user, that's not a problem you have until you're really big. And then as a buyer, if you have customers in Germany and your data can't ever leave Germany, that's suddenly like a compliance issue, right? Like you need a control there. And so let's build features that solve for that problem, we call them organizational challenges instead of individual challenges. And let's charge for those. And it's never clean, right? It's never like a clean line. There's always arguments that happen in gray areas. But I would say it's cleaner when you create these two separations that are enterprise on one side, individual on the other. Yeah, our software is considered in a lot of cases core infrastructure, so we weren't selling into teams. Usually like individual teams don't buy Vault from us, the company does because it becomes the corporate security solution rather than the team security solution. And that was a benefit for us in choosing enterprise as a target. One thing that I thought for a long time, and we actually not wasted, but we made a lot of mistakes trying to think we could just do both. Enterprise versus small business. But there's a lot of differences here. So there's a lot of support differences. The expectation of a company is that there's dedicated account managers and 24-7 support. I still will never forget walking into this one company in the Midwest, big company. A lot of you are customers here. And they were choosing Azure instead of AWS. And this is like, Azure's OK now. But this was years ago when, it's great, actually. This is years ago when I will say that Azure years ago was really bad. And it's gotten a lot better. And I just couldn't figure out. I was like, why? Why are you using Azure? And they pointed down a hallway to me. And they said, do you see the offices down this hallway? And they said, every single office is a Microsoft employee that actually provides support here. And so we don't need to call anybody. We go knock on a door and get support. And that's why we're going to choose that. That's an expectation that they're going to have. That's not an expectation that 99% of companies are going to have. Building that versus building a great email support basing is totally orthogonal strategy. Sales, you've got to spend a lot of money on sales. They've got to knock on doors. And then features, every feature you built for one type of user is a feature you don't build for another type of user. So if you choose to target enterprise medium, small business, and open source users, or free users, I should say, that's splitting feature road map across potentially four tiers. And by focusing on one, you could build a great experience for two people, basically. Ideally, you build a great experience for one, but the realities of monetization force us to look at two, which is easier than three or four. So I was spending a lot of time doing company building. I won't go into details of this, but the point is how much non-technical stuff I'm having to deal with at a given moment. We had to hire a CEO. That took 18 months. We had to hire an exec team. Beyond that, you have to build everything above that. You have to think about how you want to market and sell your product, because if you just let people do whatever they want, they'll build something that works, but they don't understand the company as well as someone who's been there for many years. And so you have to spend time with these people. It just takes a very, very long time and a lot of energy. From the product standpoint, we didn't want to build. If you're building all these things up, we didn't want every single road map item to be an argument of whether we should charge or it should be free. So we upfront, front-loaded, building a framework around what it defaults to. So there's basically like a checklist and there's a guide for whether it should be free enterprise. And we use that. And so that just sets the playing field so that every single road map item isn't like getting 15 people in a room that just argue. And that happens once in a while. When you hit those gray areas, it's hours of just difficult conversations of what it should be. So that was really important. Pricing is a really sensitive topic because there are always people that want to buy stuff and it's not priced for them, right? And so we deal with this kind of a lot. So we charge really high for Vault. Initially, it's slowly gone down and I'll get to that. But our initial cost for Vault, which is our first enterprise product, was really, really high and we did that on purpose. It wasn't worth that at the time at all. What we were selling was vision, not what actually existed, right? Because if we sold what actually existed, we'll just make up a number. That would have been a $10,000 a year thing. But when we build the other features, it's a really difficult question to talk to people and say, yeah, you gotta pay us 20,000 because there's these other features now. Like again, you can't raise prices. And so instead we're like, we're gonna sell this thing at $100,000. Yeah, all we're selling you is a UI. But in a year, there's gonna be all these other features. And so you have to sell on vision. That's stressful in a variety of ways. But it's also exclusionary to a lot of people. So there is a lot of small and medium-sized companies that were saying, I actually do wanna buy this, but I'm not giving you $100,000. And you just kinda gotta say no for these reasons that I talked earlier, which is sort of like our sales process, our enterprise thing, the features on our roadmap, they're gonna make you unhappy. You're not gonna be a happy customer. So you're not happy already that you can't afford this, but you're gonna be way more unhappy long-term. So that's sort of by design, when you think about it. And if you, like we're getting to the point where towards the end of this year, we should have pricing for vault public, right? A lot of people say, why do I have to reach out to a salesperson? It's cause of this. And but those people that give you a lot of money early on that could buy on vision and things like that, they're enabling us to slowly lower the price and split it out better to where we expect to actually be able to publish pricing and have, we have self-service trials now, things like that. Like we're getting there, it just takes some time. So key categories here from a product perspective. Now I have to think about these enterprise customers. So that's happening. The community is great. As the financial success sort of started, the really nice thing that came about it was that we were able to afford user conferences. We were able to like spin up dedicated people to meet up groups. I think we're, I mean, I was able to do a lot more of the community that I couldn't justify before we had. It would have been like straight up lighting money on fire before. And now I could justify it to our VCs and so on, which is we're making money and open sources are company. And so we need to invest in these things that don't cost, we don't make money on. So that was really nice. The finance stuff is just a lot of overhead and kind of headache. And then the personal role, so during up until like 2017, there was probably 12 months where my coding dropped to zero. So you stop coding and you're focusing on company building and you're focusing on enabling others, which is really hard because that's all I wanted to do. That was a really sort of hard period of time, but it could come back up and then I'll get to that really quickly and then I'll be done. So at this point, it was sort of relaxing in the sense that there was sustainability in sight. We weren't profitable at all, but like I could see how we could get there and we could sort of free ourselves from various shackles of running out of money. And so this was very calming. This is a weird slide to have, but the first $10 million is weirdly easy for some definition of easy because we spent so many years building open source software and not thinking about commercialization at all, that there's all this sort of pent-up low-hanging fruit of demand to get things done. So you could sort of sell to those group of users that's been waiting. The people that adopt projects earlier are also advanced users and so they're more willing to buy on vision even though your support organization doesn't exist yet or things like that because they're confident they won't need it. And so that helped sort of initially. And these early adopters are also like super champions, right? They're the people that like bleed your community, right? They believe in you so hard that they're willing to take these crazy risks to get these projects into companies. Like it's just think about the risk of convincing, let's say, Global 2000 to adopt Vault three years ago. If we went out of business or if we introduced a vulnerability or something, that was like a really scary thing for a company. And these champions are sort of putting their own jobs on the line to say this. Like if you're the person that's pushing Vault really hard and Vault doesn't work out, that's not gonna look good for you and your company. The opposite's also true, but these early adopters are great at being super champions and we tried our best to live up to that for them. So breaking through that, I mean it's just a ton of stuff, right? So it's just making, actually building a machine. I would say the first like 10 million, you're just scrapping together. You're just, your support isn't that professional. I don't think we have any support people here, but sorry, but I would say like our product itself is also not that professional, right? Like we're just, features are coming in. We don't have standard release cycles. We don't have standard incident response mechanisms. There's no real escalation to get an engineer to help you. I would say every organization of a company is sort of like in shambles because it's not built yet. It's just fake, it's just like there's bits and pieces of people doing their best to make things work, which is nice but scary. So breaking through that is like building an actual machine, like building processes and building systems that work because these customers are gonna need support and they are gonna need training and they are gonna need a lot more hand holding to actually adopt your thing. And they also are not gonna buy something that doesn't actually exist. They're not gonna buy something that's gonna exist a year from now. So that's sort of how you get through there. The point of all this is that there's just a lot that goes into it that isn't technical. I didn't think about that before I got into it. That's been more difficult, but the benefit is as the machine's been getting built, you know, I've been able to spend more time on what I actually wanted to do. So that's the trade-off. So thinking about today, the goals that I achieved that I set out to achieve is that there's a healthy business, the company feels good, there's no tricks involved, we're doing fine. The projects are all staffed, so I don't feel bad about, you know, if there was a period of time where if me or Armand wasn't looking at a project, it just nothing happened. You could actually see it in our changelogs. Our changelogs by projects were like, if you overlapped them, it was a solid bar, but then you could take them apart and they were perfectly separated of when projects weren't getting work at all. They're strong communities. We've been able to bring a lot of that money that we've been getting back into user conferences and sending out swag and all sorts of stuff to try to support our communities, in addition to just having external core committers and all the stuff that an open source project should have. And then personal stability, very important. The goals I failed at that I set out to do, but didn't work out for me. Lower stress, I don't think that worked out. It's different kinds of stress, but it's definitely much higher than in different ways, and so that kind of sucks. Coding, you know, I do less of it. It's kind of like a good thing though, because even if I were to code a lot of our projects, you know, I'm not gonna be there to maintain them long-term and you don't wanna just, you know, I don't wanna be the CTO that just builds technical debt. So that's kind of a good thing. I still do it a lot of my free time though, obviously. And then there's like things that I didn't set out to do or think about, but are unexpected that I'm happy about. One of them is really the cultural aspect. I didn't think that anything we would do at HashiCorp would be that revolutionary from a cultural standpoint. It wasn't really in my mind, but I've heard enough times now that, you know, the thing, having a tau, which you could Google, or the principles that we really live up to, has really built a place that people feel good about, on top of being distributed. And I think that building a healthy working environment where people are happy, as a person who just graduated college, I would have thought that that's what all jobs were like. And I didn't realize that that would be something different about our company. And then pushing distributed. Again, not something we plan to be revolutionary about. You know, I grew up in a GitHub era and so being distributed in the pull request community sense was just a default for me. So it's no mistake that when the company was built, it was built in the GitHub Eskway, not as a company, but as a community. And that turned out to be sort of new and thinking about it. And we've helped a lot of companies get through there and I'm proud of that. And then, yeah, the impact of positivity. I think there's a lot of big companies that I don't know what happens. You just think you're big and you're better than people. And we've always tried to sort of be, you know, positive and optimistic. And you know, we want to be the people, when we first hired our first VP of sales, our VP of sales asked me, what do you want the vibe of the sales team to be? What do you want the sales team to be? And I said, I want the professionalism of like IBM in the 70s, but I want people to have fun. Right? Like I don't want to be stiff. I want people, I want Hash Group people to walk in the door, feel relief that they're professionals, but also feel like there's gonna be smiles and laughs and it's gonna be fun. So I think that that's sort of the gist of our company when we try to be that way. And it seems awesome to me, but I'm super biased just telling you that. But at the end of it, I think this is all way too hard. I would have loved for there to be an easier path just to build the projects that I love to build. I'm super happy that sort of we, our company and our projects are at the state that they are, but my personal motivation is always just to be able to work on my projects, have a good time doing it and not worry about paying rent doing it. And I think for the general case, this is not sustainable, right? You can't expect every open source project to try to do this. And so there needs to be more options. I hope there will be, but I hope even for the VC route, it gets a little clear of things you could do. And that's it. So thank you very much. Cool. Thank you, Mitchell. So we have a couple of minutes for Q and A here if folks would like to ask questions, raise your hand. Somebody with a mic will come to you so that everybody can hear the question. So we have somebody up front here. Justin has some questions. Yep. Just going to sustainability open source. What do you think about VCs that are focused on open source like OSS capital groups that are specifically VC funding for this sort of thing as an open source initiative to sustain them? Yeah, so question is what I think about VCs that are focused on open source. So I think that all VCs would say that they're focused on open source now because open source is sort of a reality. The thing I like about OSS capital and venture capital that are focusing on it purely is that it'll help build up the infrastructure around it. There's things in open source that I don't think I should have to build. And I felt like I had to, which is sort of like, I had to build a website pipeline to publish docs. You have to build a bunch of stuff to release software automatically. These tools are more and more existing nowadays. Like both of those that I just explained sort of exist, but there's no leader. You really should be able to start an open source project and focus on the product and be like, okay, the packaging, the distribution, the website, the doc system, translation, like all these other things are as a service and solved for me. And we're not, the infrastructure for open source isn't quite there yet. Hello. Any other questions? Is this on? Okay. I was wondering how much do you think the growth of the open source community around, particularly the vagrant, but any of the tools is due to like technical excellence versus like marketing and kind of non-technical things? It's certainly mixed. I don't know how to quantify that, but I don't know how to quantify that, but my hope as an engineer is that it's technically based. I think the reality I've felt over the years is that people will adopt stuff that they don't look under the covers. If on the surface it seems to do what it says it will do, they'll adopt some really like vainly-wired duct tape stuff underneath. But I think it's a mix. You gotta get lucky on both sides. If you try to build this perfect, beautiful castle, people aren't gonna adopt it just because of that. You also have to be like marketing it and pitching it and solving real problems. And that's, as a creator, that's sort of frustrating. You hope that you could just build something beautiful and people will just come, but yeah, not that pure. Thank you. You mentioned that there was a list of projects you wanted to build when you were back in dorm root mode and you had to try to figure out how to fund them. Now, you're sort of in a spot now where you are very successful. You probably could work on many more of those projects. Is there something that you were dreaming of that you've still not built? There's stuff we're building now which is still from that notebook. There's stuff we built that wasn't there. So Vault wasn't planned. Vault was sort of spontaneous. All the rest, we actually have it written down. And I still have that notebook. One thing we didn't build that was in there. We actually had a container runtime written down. We didn't call it that exactly, but Docker came out and did that kind of thankfully. We didn't have to do that. Yeah, I don't know. There's stuff in there, but there's really bad ideas in there, right? It's a notebook of ideas and some happen to be good and you're seeing the good ones, but there's a lot that are really bad. Maybe someday you'll publish that. We'll get to read them. It looks like we have one more question and then we'll do a quick wrap up. So I can ask a quick question and then maybe follow up. So how did your parents feel when you quit your job? My parents? Did I say parents? So the real question is there's sort of an understanding or a belief that a lot of entrepreneurs have a financial safety net around them. Did you talk about the role of your parents played in you being an entrepreneur? It's kind of quiet, but we're asking what my parents feel and if I had help, I guess? Roughly? I think I get the vibe. So my parents are very supportive of me starting my own company. The help that I got from my parents was that they paid for college and I think that's a huge, huge, huge benefit. But after that, I mean, even like in college, I paid for my own food, my own books. They paid for the tuition. I paid my own rent, things like that. And then post college, nothing, right? So they didn't write me a seat check or anything. They weren't capable of that. I had to go do that myself. At the same time, I will never make the claim that I didn't have help. I think that the college aspect is a huge, huge aspect. Awesome. Well, thank you everybody for coming out. Before we let you go though, Mitchell, would you want to welcome you to the scale team? Oh, nice. So our tradition is to offer a scale jersey to the keynote speaker. Thank you. So thank you for joining us. Thank you. Nice. Thank you very much. Yep, thank you.