The HashiCorp Origin Story

Check out our open-source Feature Flagging system - Flagsmith on Github! I'd appreciate your feedback ❤️

Episode Overview

One of the most interesting companies that has come out of the commercial open source community is no doubt HashiCorp. Founded in 2012, the original open source project that they created was Vagrant, a tool for building and distributing development environments. Today, that tool alone has over 20,000 stars on Github and it is one of ~6 products that the company offers. The common thread between their products is that they aim to help engineers with consistent workflows to provision, secure, connect, and run any infrastructure for any application.

In this episode, I was able to connect with Mitchell Hashimoto who is one of the founders and the current CEO. His story was extremely inspiring and I truly enjoyed connecting with him.

I hope you enjoy the interview,

Ben

Episode Transcript

I’m happy to introduce Mitchell Hashimoto to the show. I’m super excited to talk to him because he agreed to come on. Mitch, for those who don’t know you, do you want to explain a little bit more about who you are, your business and your project?

Sure. Thanks for having me. My name is Mitchell Hashimoto. I’m one of the Founders of HashiCorp. We’re the company behind some products you may have heard of like Vagrant, Terraform and Vault, to name a few but about a half-dozen more than that. Our focus with those tools is on infrastructure automation, cloud security, cloud networking, cloud infrastructure. That’s what I’ve been doing for the past many years.

{{divider}}‍

You developed Vagrant, is that right?

That’s right. I built Vagrant while I was in college.

{{divider}}‍

Seeing where we are now, that concept seems fairly prophetic and ahead of its time, a little bit almost.

It was unique at the time. That’s why it ended up eventually hitting a nerve and becoming as popular as it did. No one was isolating environments in that way. I think that was unique. Prophetic is too big of a word to describe what I was trying to do, but forward-looking and next-generation.

{{divider}}‍

Tell me a little about this. Was there anything that you did that sparked the idea in your head?

It’s quite simple. I worked as a junior engineer at the time. It’s one of my first programming jobs with a consultancy that we worked on different projects every couple of months. You might want to hop on and help a coworker with a different project. One of the things I was frustrated with within my work was that my dependencies would get completely overlapping. It’s not like programming language dependencies, but my Apache version or my Ruby version or global dependence would get messed up. What I was thinking was if you think about like a Windows computer or something, metaphorically, I wanted to double-click the customer get their environment. The virtual desktops and stuff were a thing even then, but the other constraint on me as a university student was I had no money.

I needed to do this in a way where I wasn’t paying an hourly fee or I wasn’t having multiple laptops or something like that. Engineering is all about constraints. Within the constraints that I had, I had to figure out a way to do this free and local. At that time, the only free hypervisor that was cross-platform was VirtualBox. I took that one. I was a Ruby programmer. I used Ruby and I started hacking things together to see if I could make this thing work.

{{divider}}‍

What made your open source?

There are a couple of things. One is that open source is I don’t think I would be nearly where I am as a programmer or an engineer without open source because I originally was self-taught. I did eventually go to university for Computer Science. I started programming when I was twelve. My parents didn’t want to spend money on these programming books because they’re expensive. It’s not a book that’s like a novel that’s $10. Programming education book was like $50. My parents were like, “Definitely, not.” I found ZIP files and source code online. I found people uploading Tar or ZIP. I figured that out. I would read source code and that’s how I learned how to do stuff.

It wasn’t a choice in that sense for me because open source was core to how I thought about things. The other side, which is equally very important, especially to the context of our conversation, is that I had absolutely zero intention of ever starting a business in making any money at all around Vagrant. It never crossed my mind. The complexities of building a business around open source were a non-issue because I was not going to build a business around open source at the time.

{{divider}}‍

What changed your mind?

What changed my mind was a couple of years into the project, it started getting popular. Honestly, I went through a phase of burnout because I had a full-time job. I had moved to a new city. I was making new friends. I felt this obligation, that people and issues. Any open source maintainer has felt this before, where even though it’s free stuff, people make it seem like you owe them bug fixes and you owe them features. I felt that burden. I was working and going home. I was starting to work on Vagrant every night like a job from 10:00 PM to 1:00 AM or 2:00 AM with any time that I had. You could see it in the commit history, I stopped working on the project more or less for six months. I realized that I liked the project, it’s just this is unsustainable. Honestly, I felt forced into it. I didn’t start a business to become rich or do anything like that. I started a business because I thought “I love working on these tools, but I need to do it in a much more sustainable hourly way”.

{{divider}}‍

Do you have any ideas at the time how you could monetize it? You’ve got a lot of developers or software engineers using your product. You would think that this is a possible part, although I guess the issue is different with people who were in that position and couldn’t make it work?

I had small ideas. When we started HashiCorp, we weren’t sure if we were going to do the VC route. Initially, we were like, “Let’s make enough money for me and one other person, make it a lifestyle business.” In the realm of a lifestyle business. I felt that people were frustrated with VirtualBox. VMware is a commercial hypervisor. It’s free thing but at the time we’re talking about this, it wasn’t free then. If I built a plugin for VMware, perhaps I could charge for that. It’s fair to charge for that because that’s also commercial, “If you’re paying for VMware, why not pay me for the adapter?” That’s what I did. Within the first six months and starting HashiCorp, I released the VMware plugin. I charged $80 a user for it.

I did a previous thing where I charged $5 for. It’s not related. It’s something else. I remember my then-girlfriend’s father, a successful businessman. I remember him sitting me down and berating me over it because he was telling me, “You can never raise prices, but you could always lower prices. Always make it more expensive than you think it would be.” When I did the VMware thing, I was like, “$20 seems fair.” He’s not yelling, but his conversation was screwing my head on like, “Not $20. Let’s go $80 and see if anyone picks it up.” People ended up having no problem with $80. That was good advice.

{{divider}}‍

For those people who were paying for VMware at that time, they thought it’s nothing.

For the desktop version, the reason I picked $80 was also how much VMware costs. I figured, “If you could pay $80 for that, you’d pay $80 for this.” The people who did complain were relatively few that did say like, “With VMware, I’m getting a whole hypervisor. I’m getting all this technology. Why is this adapter $80?” It’s what I charged. Most people did not complain and it worked.

{{divider}}‍

What time period was this? Were you in the Valley at this point?

I was. I lived in San Francisco. I had moved there 1 or 2 years prior. It’s important to note that I live in LA now. I was in Silicon Valley for only a brief period of time. Most of HashiCorp’s existence I’ve been out.

{{divider}}‍

You were thinking about it as a lifestyle business, but did something kick you out of that trajectory?

There are a couple of things. I did write a blog about this a long time ago, but I don’t even know if it’s still online. One of the important parts of being in Silicon Valley, being in San Francisco, and I have a couple of cousins that are in university that are in tech. I’ve been telling them, “You have to move to San Francisco after college before you have any family or reasons to not live there and then leave if you should leave.” The reason I tell them that is because you are the average of the people around you. They mold who you are. San Francisco made it so normal and almost expected that you would chase a bigger vision and raise VC money to do it. It was as normal as buying bread at the grocery store. It was bizarre now in hindsight.

{{divider}}‍

Did you know that at that time?

Not really. Subconsciously, without people trying I was being pushed to be like, “This $80 VMware thing is too small. Think bigger. How are you going to do more? You could be as big as GitHub. You could do this.” I remember being like, “I have no idea what that means.” It did force me to think about it. When I talked to my cofounder, we had all these other ideas beyond Vagrant. We said, “What if we rolled all these other ideas?” We’re going to do them anyway. We roll them into the same company and our goal should be like, “Why can’t we be the next VMware, Microsoft or the next big company?” It’s ridiculous for two 22-year-olds to say a statement like that, but that’s the beauty of it is that San Francisco makes that okay and makes that a safe thing to say. People don’t laugh at you about it. We went and started raising money and going for that goal. It was environmental. I don’t think HashiCorp may not have been like a VC-backed or big business if we started anywhere else.

“You are the average of the people around you. They mold who you are.”

{{divider}}‍

I’ve spent all my career in London. The reflective is completely true in London, where no one thinks they can be doing that and how on earth could people do that? It’s too hard, whereas there’s a bunch of capital in London. There’s a bunch of very big people, but the mindset still is British. It’s like, “We couldn’t possibly even think about doing something like that.” It frustrates how other people in that are trying to build the politicians and business leaders stuff, but you’re right. You pick it up by osmosis almost.

I’m not trying to rag on London or any other cities. At that point, there’s only a handful of cities in my mind where this is even possible. San Francisco being the one I lived in, but the representation in seeing that it’s normal is the difference in a city like that. It’s such an audacious thing. You’ve got to have some comfort that very few people want to be risk-taker, in a sense. San Francisco, for me, somehow made it feel like, “This is not a risk. This is the thing you do.”

{{divider}}‍

You’re working on Vagrant professionally and you’re generating an income from Vagrant. Where does the business go from there?

The VMware thing was very successful. Within the first year, we were able to pay at least one salary. My cofounder and I weren’t paying ourselves. This was going into the bank at the time until we hired someone, but we knew we could hire someone. We then raised the VC capital. Once we raised the VC capital, the whole mission of the company changed. It went from being the Vagrant company to being this big vision that we had. We immediately hired people and started working on the other products that we ended up building. For the first few years, the focus was R&D and pumping out new projects.

{{divider}}‍

Did you know your product’s roadmap? Did you have that mapped right from day one?

We had it mapped out all the way through Vault-ish. Vault ended up changing a lot, but we had it mapped out basically to Vault. We had Nomad in our minds too. All the way up to Nomad, we had it fully mapped out, which is about six products.

{{divider}}‍

In terms of licensing and choosing the philosophy of what’s open and what’s not, what did you use to guide that?

Vagrant is an MIT license there and everything I did was an MIT license. It’s a very liberal and flexible license. When we started a company, I met with a few lawyers and asked them, “Does this make sense? Is there anything else I should be thinking about?” From a legal standpoint, they recommended that the MIT license is fine. The detail does not say. A lawyer’s point of view is like, “If it does not say something, it’s open to interpretation.” If you want it to be open to this forking and to what modification and all that stuff. The MIT license doesn’t have that, but there’s a bunch of other privileges with the MIT license that does say you are or not allowed to do that. People assume you are, but lawyers are like, “You could just easily argue in court that you aren’t. Let’s find a license that’s longer and more explicit.” For us, we chose the MPL license, which is the one that Firefox and all that is licensed under MPL2. We’ve been sticking with that ever since. All our projects are still that.

{{divider}}‍

Can you describe briefly what that does and doesn’t provide?

I can’t even say exactly anymore. It’s been so long. I remember the lawyers assuring me that every privilege was retained from the MIT license, if I recall correctly. The only thing they felt better about in the MPL1, besides the explicit part of it was there’s also explicit wording related to trademarks or patents. That was an important aspect as well.

{{divider}}‍

The products that you had in your roadmap, were things that you chose because you think they felt they needed to exist, or did you choose those because you felt like they were revenue generators?

Definitely, not. We did a good job of not thinking about the business for too long, probably. Armon and I focused on what technology we felt was missing or should exist rather than, “Can I make money?” These are based on our experiences, what we saw around the industry and things like that, but we felt these were holes. We set about plugging them as quickly as we could.

{{divider}}‍

The product that you worked on after Vagrant was Packer. Is that right?

Yes. That is the one that was immediately after Vagrant.

{{divider}}‍

Was this prior to Docker existing?

Packer was released prior to Docker ever coming out. I can’t remember the timing exactly, but it was either before I released Packer or after. I had met with Solomon and he showed me the Docker before it was released. We talked about it. The coincidental sidebar here is Solomon was one of the first people I ever met in San Francisco. The first day I flew to San Francisco, I hadn’t even moved into my apartment yet. I went to work. I knew the company I worked for and I went to lunch. The lunch place I was eating at, Solomon was eating there. He recognized me from Vagrant and introduced himself. He was “just” the founder of Docker at that time. We talked a little bit. It’s a funny random story, but it was before Docker.

{{divider}}‍

Talk a little bit about that because it’s interesting. I was going over the design of Packer before this interview and it’s interesting the differences and the similarities. Are you sad that it fell by the wayside?

Not really. Packer is immensely popular in the right areas. It ended up not being a container tool for the most part, which is a little bit sad, but it wasn’t the goal of Packer. It’s hard to say. I’m happy with where Packer came to. We had a major release of Packer and there are still a ton of features coming out in it.

{{divider}}‍

I didn’t realize that.

You hit on an important point, which is I don’t think sad is the right word, but sometimes, I kick my feet or throw my fist around in the air. A lot of people, not just us, were close to getting the container solution as well. The reason I got re-introduced to Solomon to show me Docker was because I was talking to someone else and showing him a demo of this LXC-based tool that I was building. It wasn’t anything like Docker. It wasn’t a more Vagrant approach to LXC, but it was a container, and this guy said, “I saw this demo of this other container tool. You need to talk to this guy.” It was Solomon and Docker. There were a few people that were circling around containers being there’s something interesting there. I always say like, “The idea doesn’t matter. It’s the execution that matters. Docker was the one who won an execution.” They get the cake. I’m not saying it’s my idea but I do think we were close.

{{divider}}‍

What was the original goal for Packer? What was the problem you were trying to solve? You obviously wanted to solve it because that was the first one you chose after Vagrant.

The reason we did Packer first was because it started to bridge or getting into more production-oriented tools slowly, but people didn’t see that at first. That was the original idea. One of the problems was people were struggling to build the VM images for Vagrant for dev environments. They needed a repeatable way to make those VM images. The Packer did that, but at the same time, you could use those tools and start making repeatable VM images for production with AMI. It was us leading into that. I don’t think people got that at all because we started coming out with our next products for Console or so on. I remember for the first few months, people were terribly confused, being like, “I thought HashiCorp is the development environment company. Why are they installing stuff on my servers now?” HashiCorp is the runtime company that happens to have developers.

{{divider}}‍

I had to remind myself about the company starting with Vagrant because I think of Terraform first when I think of you guys.

That was a business decision. We always knew we had to get to production because the budgets, the spending, and the money from production workload is like 10 to 100 X more than development environments. We knew as a business, we had to get past our developer tool mentality.

{{divider}}‍

The VC funding that you got, how did that work in terms of the balance between making tools that you think should exist against surviving as a sustainable company?

“San Francisco made it so normal and almost expected that you would chase a bigger vision and raise VC money to do it.”

This is another benefit of a certain type of Silicon Valley mindset, which is that our first couple of investors didn’t want us to make money. They wanted us to focus on building technology. They were like, “Don’t worry about the business. It’s too soon.” It was too long, but we spent the first few years just building products. Around our Series A and Series B, the questions are shifting to, “You have these four already, what’s the plan here?” We had forced us to start thinking about that for the first time.

{{divider}}‍

It’s interesting as well. The products feel like and they’re becoming a little bit more audacious in their scope, especially with Nomad, you’re going up against huge Goliath companies and products. Was that intentional? I can’t imagine thinking, “I’m going to write an orchestration framework at Nomad.”

That was the plan. Contextually at the time, there were a couple of things there. There was a little bit of hardheadedness because we had planned to build an orchestrator like a Nomad since 2012. That was in our mind, a predetermined destiny that we had to do. On the other hand, we have to remember that at the time that Nomad came out, which I think was in 2014 or 2015, Kubernetes was not very popular. It was brand new. We weren’t afraid of any Goliath at the time because there wasn’t one that existed. We felt we had a real honest shot at it. Realistically, we were late. It’s another one of those things where I sometimes throw my fist in the air because if Nomad came out one year earlier, it could be a very different story now.

There are other aspects to that too that we could get into. At the same time, we stayed committed to Nomad, likewise, similar to Packer. We had a release with Nomad. That team is large. I’ve said publicly before that Nomad alone makes the company millions of dollars a year. It’s a successful product and I’m proud of it but I think it could have been a lot bigger, and I wish it was. There was a front-page Hacker News post of someone talking about how excited they were working with Nomad. How it was a breath of fresh air. I love to see stuff like that because I think that there’s room. I don’t want Kubernetes to spear. I don’t care either way, but there’s room for multiple products.

I’m talking about a lot of positives. One of the downsides of Silicon Valley mentality is this idea of a winner take all mentality when it’s super not the case. The revenue of Nomad alone and the growth of it is proof that there’s a ton of space. I have tweeted it out before that one of the benefits to us with Kubernetes was that mentality caused everyone else to quit and we stuck around. Docker Swarm and Mesos quit. All these new projects gave up. They had an opportunity. If they stayed in the game, they had an opportunity, but since they left, it made this huge hole where we say, “We’re not the solution at all.” Inside the company, we’re like, “We are the number two scheduler.” We’ll take all the empty void that everyone else left of the people that are unhappy with Kubernetes.” There are a lot of complexities there, but it’s a great project.

{{divider}}‍

How did you decide on the level of abstraction for Nomad? One of the things that is frustrating is Kubernetes solves a lot of problems, but it’s complicated. I feel like probably 95% of stuff, the level of abstraction could be higher. How’d you go around designing at that for that?

We’re still honestly in the process of doing that as a company. I would point to our newer project, Waypoint, as raising that abstraction level to where we start wanting it to be for a developer. When I look at Nomad, Console or Vault, these are tools that we built with the operator or the platform builder first in mind. These weren’t tools that we expected developers to pull off the shelf and use. We expected these are tools that developers consume that are managed by somebody else. You could feel that in all our tools. It has negatives, but it has positives. The platform builders tend to love our stuff because, for that persona, I believe it’s way simpler than Kubernetes.

The whole point of this blog post that was on Hacker News was it’s way simpler. That was a goal. They are piecemeal. You could adopt one at a time. You don’t get every feature and have to think about how everything works together all at once. You can be like, “I need to schedule it now,” Nomad. “I need to find my services in the Nomad cluster,” integrate Console, which is native integration. “I need secrets to grab,” Vault. You go one step at a time which is a very operator-focus thing. If you’re a developer, you probably want everything. It’s more frustrating, but that’s how we think about it. We’re still moving on that path. Waypoint gets closer to what we’re trying to do from a developer workflow perspective.

{{divider}}‍

It was on holiday when you had your conference and you announced Waypoint. I remember spending three hours on the same bedroom my family had gone to sleep because for me, as an engineer, it was like I finished writing a whole bunch of Pulumi stuff to get files migrated from Beanstalk to ECS. I’m sitting there writing these VPC things going, “How am I doing? Why am I doing this?” Most people want to run a server that connects to a couple of databases and can scale.

You nailed the two things that we see that motivated Waypoint, which is one, there’s this fallacy that developers are going to become more like operators. That’s existed for almost a decade. This idea that a developer wants to program or know about VPCs or any of that. My thesis is they don’t. The other side we’re seeing is big companies aren’t moving that way either. Big companies have clear role delineation between the platform operator and the developer. The developer consumes, the platform operator closes. We don’t see overlap ever in this. On the developer side, there has been a growing tendency to not want to manage the platform themselves. Managed Kubernetes servers back to services like Heroku. These platforms are not your responsibility. Someone else manages them.

They don’t want to write ops either. The overwhelming trajectory on both sides is that these are two separate roles. We architect clearly for that, which is we have Terraform, the platform builder their infrastructure side, although a lot of devs use that for forced use infrastructure. We have the more Waypoint-oriented side we’re thinking about coming back to, which is consuming other platforms. Waypoint is almost like given a GKE cluster, ECS, or Kubernetes ECS, or Nomad or any of those. We could give you a consistent workflow to deploy on top. That’s the vision behind it because as a developer, you don’t want to worry about that.

{{divider}}‍

Was that thesis something that you have had in mind for all of the stuff that you’ve been working on about that skill of separation?

It’s something we learned over time. Originally, our thesis was wrong. We thought Nomad would be comfortable enough to be a developer interface as well. We thought the job files, how you invoke it would be easy enough that developers would want to use it, and we pretty quickly realized it wasn’t. I get this feedback a lot, but there’s a certain meeting that stands out to me when I visited a company here in LA. I had some downtime between meetings. One of the engineers walked into the room and was talking to me. I said, “How are things?” I was being polite.

I expected him to say like, “Things are fine.” He got specific. He’s like, “Things are way too effing complicated.” I was like, “What are you talking about?” He’d worked at a Java-based company for twenty years. He’s like, “Twenty years ago, I wrote Java code. I ran Maven, and we’re done. You get a jar, and you’re done. Now, I write Java code, run Maven, run a Docker file, write Kubernetes, and I have to know what these things are. I hate it. I just want to run Maven.” That stood out in my mind because he had so much energy around this argument. It stood out in my mind like I being a developer too, I want to hit the run button and see it run. I don’t want to worry about the details, but I’ve also been a platform builder. When I’m on the platform, build their side and I put that hat on. I want to care about the details. I want to build a good platform. That was one of the many learning experiences in my mind that framed HashiCorp’s view on this stuff.

{{divider}}‍

It’s interesting that you talk about the winner-takes-all mentality because it feels like the industry has backed itself into a little bit of a corner around Kubernetes because as an engineer myself and now we’re writing operators to get our platform easily installed available on open shift, and you don’t realize how far down the rabbit hole you can go with that. I wonder if things might back up and people realize that it’s not the right tool for a very large number of things. It got validated by AWS and by there, being services on GCP. It’s almost ironically if AWS would have picked up Nomad and provided the services to manage Nomad, that would be helpful.

I don’t know what the right solution to that is because I feel like, to some extent, Kubernetes and a number of other technologies are now in the period where it’s similar to how people used to say, “No one ever gets fired for picking IBM or Word.” It’s almost like people look at stuff like Nomad or look at stuff like not using a scheduler at all and they say, “Maybe this is a good idea, but Kubernetes is a safe choice.” I can always say like, “That looked like the best choice, even though it wasn’t necessary.” That’s a hard mentality to get out of, which is where we’re at. We’re picking on Kubernetes, but I think that’s true about various things nowadays.

{{divider}}‍

How come Waypoint was filled out in the order it was? Could you have done it earlier?

We wanted to. We’ve had the idea for Waypoint for a long time. For those who have followed HashiCorp history a little more closely, you could see the first failed iteration of it, where we learned a lot from not to repeat the same mistakes, the first failed generation, this tool Auto that we released alongside Nomad. We ended up shutting out the Auto project down very quickly because we realized there was a mistake, but we want to think about it. Some people have said our Waypoint is like Auto 2.0 or something. Some people have said, “Waypoint is like Auto 2.0 or something.” The big mistake that we learned from that I point out is that Auto tried to manage production infrastructure for you. Waypoint has the mentality of bringing the platform to us, but you still manage it.

Auto had the mentality of I’ll deploy our outs, but also I’ll deploy the platform, which it completed the two roles and that was the whole thing. It completed the platform developer role, which is they’re separate. Waypoint is very much in the developer workflow role. That was the big one. Your question of why we didn’t build it sooner was we got sucked into an important problem of building the business is what we had to do. We were 4 or 5 years old by then. We had to build up the commercial side of the business and reinforce our existing products. We were starting to get this mentality, which doesn’t exist nowadays. We did a great job of stopping this.

We started to get some mentality where we were releasing many products that people were saying, “HashiCorp is releasing stuff and then abandons it.” Luckily, I think that’s gone. We have full-time teams around everything, but we didn’t want people to think that that was not our plan or goal or what we want to do. We were like, “We have to slow down, build the business, build the teams, build the roadmaps, build the stability and then move on from there.” We didn’t feel comfortable moving on until 2020.

{{divider}}‍

How’d you go about managing your open source communities? Most of the people I speak to have one project or have one GitHub page. You have a whole bunch. What tools do you use? How’d you do that as a business for many large open source project?

It’s a menagerie of things. The thing about open source communities is once they get big enough, you get such a diverse population there that the way they want to participate and consume things, you end up having to do everything. We have big GitHub issues that we’re active in. We have a forum. We do one-way live streams and collaborative community town halls. You have to do everything eventually. One thing that I always remind our developer advocate, our maintainers, all that stuff is that when you’re a leader in an open source community, a parliament member or congressman-type of metaphor there of the thing, you are there at the will of the community. If the community is very unhappy with how you’re doing things, they have the right to fork. That is always sort of the protected right that open source has. I always try to encourage us to do our best, to listen to people, to make sure that even if our business has a different idea to consider ideas from the community, and we’ve done a pretty good job of that. We’ve had some tense issues for sure. Everyone would, but for the most part, we’ve run the projects well.

{{divider}}‍

In terms of having technical contributions or code contributions, that must be a fairly uphill task for such deep technical projects that you are working on. The other interesting thing about this show is how common the story that the contribution is generally on around code and racing issues, bug reports, documentation, but not code. Do you have an active open source pull requests situation or is it mainly people who are being paid by the company?

A lot of people are being paid, but we have a very active request for our community. I do think what’s interesting, and I do point this out to people, is that for the most part, contributions across all our projects for all history, like before we were going to company contributions, to the core of a product is very rare. It happens once in a while, but it’s very rare. However, contributions to the plugin ecosystem are predominantly contributions and not paid people. The obvious example I give is Terraform, which is we have around 200. HashiCorp only maintains 5 and the other 195, we don’t even have commit rights. They’re community-based. However, if you look at Terraform Core, there are probably less than 10 people in the world that regularly contribute to that and maybe 9 of them are HashiCorp employees.

It’s not what we’re trying to do, but that’s how it is. I always use the example of looking at something like the Linux Kernel as well, which is the Linux Kernel being orders a magnitude larger. If you look at the core schedulers, interfaces and file systems in the middle, the number of contributors pales in comparison to the number of contributors to drivers, application and all the user space. Drivers are still Kernel space around the thing. This seems to be a pattern in an infrastructure open source where the core is relatively a small group of people.

“Very few people want to be risk-takers.”

{{divider}}‍

Has that informed your product design in terms of doing that? The other thing that I always feel for you guys when the AWS Conference comes around and they announced another fifteen projects and someone there who’s got to go and map out all the Terraform stuff, but you’re chasing AWS on that side.

We’ve had this mentality for years, even since Terraform. We’ve tried to make it clear and easy to see where that Boundary is. The very approachable side of the Boundary and then the very, “Here is the dragon side of the Boundary.” Terraform is the one where we took it in that another step and nailed it because the first version of Terraform, which barely anyone ever used, but had a difficult to plug interface due to time constraints. One of the first things I did in 0.2 was introduce this framework, which is still in use nowadays many years later. Internally, I like it privately. We never documented it.

I called it the rails for Terraform providers because it made it easy to write a provider or a resource to a new cloud that I was like, “This is very approachable.” It clearly was because a lot of people ended up writing providers. I boiled it down to, “All you had to do was write a function for create, read, update, delete in isolation.” Write those functions the orchestration of how they get called, how the data is stored, how we determined diffs and all the Core handles it all for you. People who had never written were saying, “I could make the right calls to create, read, update, delete,” then it was magic. Everything in Terraform works. That’s informed how we build plugin interfaces from then forward.

{{divider}}‍

Did you realize how big Terraform would be while you were building it?

I thought it was a good idea. I was excited about it. I had no idea it would be as big as it is nowadays. However, it’s also a good story because it was such a failure for about a year. For the first few releases, it barely worked. There was that problem, but there was also the commentary of like, “Even if it did work, HashiCorp will never be able to keep up with AWS.” There was also the commentary of like, “This is going to be solved by someone. You don’t need infrastructure anymore because this is going to be solved by containers or Chef or Puppet are going to do this instead.”

There was another commentary, which was they were talking about MultCloud and it was a total force. There was all this stuff fighting against us and there was a board meeting we had with the company where we discussed no longer investing in Terraform or like, “This project is going to be a minor project. It’s not going to be super successful.” I don’t know what triggered the change, to be honest, but at a certain point, they started to be an inflection point. It’s almost like compound interest at that point. It started building at a non-linear scale. It’s popular nowadays, but it’s interesting. I always say that because we have new projects like Waypoint. Some people new to the company are like, “It’s four months old and doesn’t have a million downloads.” It might have a million now, but they think like that. I’m like, “Slow down. Things take a long time to be ready. It’s okay.”

{{divider}}‍

Have you found that a bit frustrating that you’re not able to isolate what it is that causes that inflection or recreate it?

It does. As an engineer, we look for logic, reason and everything. I would be lying if I didn’t say I spend a stupid amount of time thinking about what the things were that made it take off like a rocket ship. I don’t know.

{{divider}}‍

I’m trying to remember because at some point, we hadn’t heard about it, and all of a sudden, it was like the de facto that you used to do that stuff.

That’s how it feels to me too.

{{divider}}‍

Have you got a plan for the future? You said you were worried about working on trying to consolidate the products. Would you like to try more things?

There are more things we want to do, but the big initiatives of the company, keeping in mind that all our products have full-time teams. We’re going to keep having improvements in all our products. The new stuff that is big for us is cloud services. We’ve announced Console and Vault as a service on AWS. We’ll extend that to more clouds in the future, but continuing to get all our products available as a HashiCorp managed pay-per-hour service.

That’s a big focus of the company right now. We’re moving quickly on that. Waypoint is a new project that we’re focused on. Boundary is this other new project that is more security-oriented that we’re very focused on. Both Waypoint and Boundary have a huge opportunity in the next couple of years, probably. It will take a couple of years for them to hit their stride. Those are the big things that we’re focused on, and we’re in a similar position where we have other ideas, but we’re going to hold onto them while we do these other things.

{{divider}}‍

As a Python developer, do I care about Boundary or is it something that just happens?

We’re not in its current phase. It matters what tooling you’re using, but our goal with Boundary, especially once we have it in a cloud platform, is to make it easy enough to give you that access to click a thing in your menu bar, get SSH into a server. You never had to worry about the passwords, keys or anything. You proved your identity already by being logged into the app. That’s where we want to get to and we’re not quite there yet. Boundary is getting a lot of interest because the operator side is a problem they acutely have. That’s where it’s best suited for nowadays.

“The idea doesn’t matter. It’s the execution that matters.”

{{divider}}‍

Are there any things that you think the industry is talking about or missing that you’re like, “Why isn’t this a bigger deal?”

Not really. We’re in a weird phase because there’s a lot of new stuff happening. There’s a lot of fatigue at the same time. Stuff-like service mesh is very mature. Whether you’re looking at ours, Console, or another competitor version. They’re all getting very mature. However, people are tired of adopting new things. They are relatively complex in a sense. Stuff like that fights against it. I don’t think people are unfairly not looking at it. I’ve said this for a couple of years now, so maybe I’m wrong, but we’re in a phase where we have to simplify. That doesn’t mean to get rid of old stuff. It means abstract above Kubernetes, abstract above the service meshes, unify them together. We’re at a point where we have to bring everything together for the end-user and make it simpler. In their current state, it’s fine for a platform builder-type or operator-type person, but the developer interface has to be a lot simpler.

{{divider}}‍

There’s a friend of mine who a bit later in life decided they wanted to become a software engineer. I was trying to explain to him how you deploy an API or something. It was thinking back to what you would do many years ago. It’s astonishing how complicated it can be now which I don’t quite understand why because we’ve got all these things that we can build on top of. Building a product like Waypoint must be much less work now than it was many years ago. I can never quite understand why delta files won over buildpacks because as an engineer, buildpacks seems so much more in line with what I need.

What I’ve said before, both publicly and privately, is for whatever reason, maybe there’s more money there who knows what it is, but since Heroku people have focused on almost democratizing that technology from an operator point of view. It’s been 100% step one. Everyone agreed step one was like, we need the building blocks that Heroku built-in private, and we need to get those out there. That was Docker, Kubernetes, our tools, and all that stuff. What we completely missed the boat on or maybe on purpose, was that easy developer deploy interface on top of it but a lot of people are coming back to it.

{{divider}}‍

Do you think life is going to get simpler for a software engineer?

The descriptions I’d get are they’re still closed platforms which are weird, but I’m hoping we could be a more open one with something like Waypoint. If you look at stuff like Vercel or Netlify, we’re coming back around to focusing on that easy interface or even look at patterns like get offs are picking up now of getting back to get pushed and do deploy onto the right branch. There is a lot of pressure and a lot of tools building around, but we are going to get there.

{{divider}}‍

We’re big fans of Vercel. It’s crazy how they are provisioning an SSL certificate setting the DNS for you easily. It feels like magic when it’s in 2021, and that shouldn’t be hard. Is there any website you want to pick up or contribute or you want to say thank you to or new projects you want to push?

No. I think we’ve done a good job of talking through all that stuff throughout the course of this conversation.

{{divider}}‍

I want to say thank you to you and to the company because we use your tools every day. They’ve really helped. Thanks for that and for your time.

Thank you very much. It’s been fun.