Why is HashiCorp committed to open source?

HashiCorp co-founders and co-CTOs Armon Dadgar and Mitchell Hashimoto explain why the open source ethos is at the core of their company's DNA.


  • Armon Dadgar
    Armon DadgarCo-founder & CTO, HashiCorp
  • Mitchell Hashimoto
    Mitchell HashimotoCo-founder, HashiCorp


Mitchell: All the major projects that we have at HashiCorp are open source and I think there's a few major reasons for that. For me, personally, there's a personal reason, which is that I am self taught programmer, originally. I went to university later but being self taught as a child, the only way I could get access to code samples and various learning materials was through open source.

So, it's always sort of been a default for me. And as I've grown and matured as an engineer, I found a lot of other benefits to open source. But, that's where it started.

When we were starting the first projects, we both didn't intend to ever start a company around them. There was no monetization goal at all, and so I think open source was an obvious default then. As we built a business, I think there was a ton of benefits that emerged.

Armon: I think in some sense what we've seen over the last few years is, all major innovation in the infrastructure space has tended towards open source. Part of the challenge with infrastructure is it lives and dies by the integration of a huge, broad ecosystem. And so, the challenge is: How do you actually do this huge amount of integration in a totally closed source product?

It's hard to possibly get to that much reach. But with the open source community, what you really enable people to do is scratch their own itch—which is, "Hey, if I have this system I want to integrate with, I'm totally enabled to go and do that on my own." That's been super, super powerful, especially as we look at a tool like Terraform where its integration surface is practically infinite but has something like 2,000 contributors.

So, it really enables us to look at these challenging infrastructure problems which have to touch all these different systems, all these different end points, and do it in a way that we could build a community where people are engaged and helping solve their own issues as well.

Mitchell: I think one of my favorite total coincidences that worked so well for us was: I was in a sales meeting with a prospect and we're having this discussion of why Vault—the security product—is open source. And I couldn't have planned this better—during this discussion we got an email from a major Fortune 500 that we didn't even know was using Vault that was reporting a security issue and they just attached a patch that was like, "Here's a security issue. Also we fixed it."

And then, I just turned the phone around and showed it to that prospect and it was like, "This is why you do security in open source. You get the world's best security teams that we didn't even know were using Vault, finding issues and fixing bugs, not just for us, for the whole community. That's the benefit of open source." That was really cool.

Armon: I think the security community is a interesting example. I think they particularly have long suffered from the ability of closed source software to act as smoke and mirrors. Whereas there really is nowhere to hide with open source. There's nothing you can do and shove it under the covers.

Similarly to your story, I've had one with a customer as well who was like, "I don't believe your claims." And I was like, "You don't have to believe my claims. The source code is available. You could go look at it. You could go run it yourself. You don't need to believe me on anything." So, I think what's super critical as we talk about this mission critical software is how do you as a customer establish faith and trust, and get to depend on the software? I think open source is hugely important for that.

Mitchell: Yeah, I think on the flip side, the benefit in that is, smoke and mirrors is like you can't hide either. So, it's hard for us because you can't. A lot of other companies make a lot of claims that their product can't stand up to and we wouldn't want to do that first of all but we also can't do that because if we make a claim, someone could go look at the source and just say, "It doesn't do nearly what you say it does." It's all just laid out, right there in front of you. So, we have to be pretty authentic with what our sales people say our technologies could deliver because anyone could easily verify all that.

Armon: I think there are many advantages to it but I think, you know, going into it, I think it was much more pure which was: It seemed like the right default way of doing this. And over time, we found that, there's actually all these secondary, tertiary benefits to it and we've stayed committed to the core of the business remaining open source, since.

More resources like this one