Armon Dadgar and Mitchell Hashimoto are long-time open source practitioners. It's that practitioner focus they established as core to their approach when they started HashiCorp about ten years ago. Today, HashiCorp is a publicly traded company. Before they started HashiCorp, Dadgar and Hashimoto were students at the University of Washington. Through college and afterward, they cut their teeth on open source and learning how to build software in open source. HashiCorp's business is an outgrowth of the two as practitioners in open source communities, said Dadgar, co-founder and CTO of HashiCorp, in an interview at the HashiConf Global conference in Los Angeles earlier this month.
Armon Dadgar and Mitchell Hashimoto are long-time open source practitioners. It's that practitioner focus they established as core to their approach when they started HashiCorp about ten years ago. Today, HashiCorp is a publicly traded company.
Before they started HashiCorp, Dadgar and Hashimoto were students at the University of Washington. Through college and afterward, they cut their teeth on open source and learning how to build software in open source.
HashiCorp's business is an outgrowth of the two as practitioners in open source communities, said Dadgar, co-founder and CTO of HashiCorp, in an interview at the HashiConf conference in Los Angeles earlier this month.
Both of them wanted to recreate the asynchronous collaboration that they loved so much about the open source projects they worked on as practitioners, Dadgar said. They knew that they did not want bureaucracy or a hard-to-follow roadmap.
Dadgar cited Terraform as an example of their approach. Terraform is Hashicorp's open-source, infrastructure-as-code, software tool and reflects the company's model to control its core while providing a good user experience. That experience goes beyond community development and into the application architecture itself.
"If you're a weekend warrior, and you want to contribute something, you're not gonna go read this massively complicated codebase to understand how it works, just to do an integration," Dadgar said." So instead, we built a very specific integration surface area for Terraform."
The integration is about 200 lines of code, Dadgar said. They call the integration their core plus plugin model, with a prescriptive scaffold, examples of how to integrate, and the SDK. Their "golden path" to integration is how the company has developed a program that today has about 2,500 providers.
The HashiCorp open source model relies on its core and plugin model. On Twitter, one person asked why doesn't HashiCorp be a proprietary company. Dadgar referred to HashiCorp's open source approach when asked that question in our interview.
"Oh, that's an interesting question," Dadgar said. "You know, I think it'd be a much harder, company to scale. And what I mean by that is, if you take a look at like a Terraform community or Vault – there's thousands of contributors. And that's what solves the integration problem. Right? And so if you said, we were proprietary, hey, how many engineers would it take to build 2000 TerraForm integrations? It'd be a whole lot more people that we have today. And so I think fundamentally, what open source helps you solve is the fact that, you know, modern infrastructure has this really wide surface area of integration. And I don't think you can solve that as a proprietary business."
"I don't think we'd be able to have nearly the breadth of integration. We could maybe cover the core cloud providers. But you'd have 50 Terraform providers, not 2500 Terraform providers."
Colleen Coll 0:07
Welcome to this special edition of the new stack makers on the road. We're here in beautiful Los Angeles had hashey Calm logo, discussions from the show floor with technologists giving you their expertise and insights to help you with your everyday work. Infrastructure enables innovation. hashey Corp provides consistent workflows to provision, secure, connect and run any infrastructure for any application.
Alex Williams 0:41
Everyone here for the new stack makers on the road at hashey comp in Los Angeles, California. And I'm here with Oren dagger, our co founder and CTO at hashey. Corp. Hi armor and how are
Armon Dadgar 0:55
you doing? Well, doing great, thanks so much for making the time being here.
Alex Williams 0:59
Well, I'm so happy to be here. I kind of feel like the new set grew up with hashey Corp. I remember when you launched in 2014, I think one of your first user conference was in Portland. Yeah, where we hail from, and your growth is just been so interesting to watch. And especially looking at from an open source perspective. I wrote a story this week on standardizing industrializing the world of the cloud and how open source is equated with the standardization for hashey Corp. The industrialization really is how you think about companies can go at scale. So once the technologies are standardized, you can then use those technologies to scale your own organization. My question is about how do you manage your engineering organization with a core committer group internally, and an external group who are contributing integrations back into the core? Now? I expect there's a lot of people who, like aren't contributing to the core for external, but then you you do the final approval? Right? How do you think about organizing your engineering team with that approach?
Unknown Speaker 2:11
You know, it's a good question. So I think in many ways, I think we actually look like a lot of our customers. So we organized around effectively five product groups the way I'd put it. So we have our infrastructure team, that's sort of TerraForm. And packer, we have our security group vault and boundary, networking console and an application vagrant Nomad way point. And the fifth group is our Cloud Platform team, right? So very much the enablers of the other four. And they're sort of the internal customers of the platform team, then within each of those groups within each of the application lines, effectively, it's a blended engineering team, right. So part of that might be working on the cloud delivered solution. So it might be working on TerraForm, cloud, part of that team might be working on TerraForm core, part of that might be working on open source providers, like the Amazon provider, or the you know, Azure provider, etc. So it's sort of this blended model within each of the product groups. And then those open source teams are both working on the core themselves, but also acting as the reviewers for the community. So as we're getting pull requests, or as we're getting issues, the engineering teams are directly engaged with the community. And I think that's part of what makes HashiCorp work so well is that our engineering community is very much in touch with the community because they're not sort of abstracted or buffered through some other team, right? They directly engage with our community through GitHub.
Alex Williams 3:22
So how did you cultivate that from the start to be a company that has an approach that is much different than you see, for instance, from the cloud, native community,
Unknown Speaker 3:32
you know, in some sense, I think goes back to me and Mitchell, we're open source practitioners ourselves, right? We cut our own teeth in open source, we learned about building software in open source, we participated in other open source communities. So for us, it felt very natural from the beginning, because we looked at and said, Okay, what are the best parts of open source that we like, right? We like the parts where you're collaborating with people, it has this sort of async global kind of community, the parts we don't like, or where we saw a lot of like, hey, is there a lot of bureaucracy around it? Or is there sort of like, unclear in terms of like, how do you participate or drive the roadmaps of these things? Right? I think we've all seen some of these open source projects end up being kind of a three headed monster, because they're being yeah, there's not a clear direction or driver to it. And I think you see other communities where you have sort of that benevolent dictator for life model, right, that sort of BFL where there's sort of a real clarity and real sort of authority around, hey, here's where the product is going in the direction. And that gives it a consistency of vision. And so we sort of looked at all that and said, Okay, well, it's natural as we build our products that we want to recreate the best parts that we liked in the community. And so I think you see us sort of replicate and build a lot of that within hashey Corp, but it just was sort of a natural outcrop of us being a practitioner.
Alex Williams 4:39
So thinking of your engineering culture, how do you think about then the process of community development and how does your engineering teams play a role in community development?
Unknown Speaker 4:51
Yeah, so the huge part and actually I say goes even beyond community development into the application architecture itself. So even as we think about the Apple case in architecture, I'll talk about TerraForm. To make it simpler, the way we designed it was around this notion of there's this sort of core of TerraForm. That's the heart of the engine, where a lot of the complexity sits. And we understand that like, Hey, if you're a weekend warrior, and you want to contribute something, you're not going to go read this massively complicated code base to understand how it works, just to do an integration. So instead, we built a very specific integration surface area for TerraForm, say, Hey, if you want to do a plug in for TerraForm, to lots of support, some new service, great, we'll have a really well defined plugin, a really well defined SDK. So you can do that in 200 lines of code without having to learn the deep heart and inner workings of how TerraForm works. So that architecture from a software perspective, we call it sort of a Core Plus plugin model. That's the sort of model we use in most of our software. Because then from a community development perspective, it allows us to go do it in a way that's much easier for the community where we say, you have to go learn how TerraForm works. Here's a plugin, here's a prescriptive scaffold, here's some example code on how to do it. Here's an SDK. And then around that, we can actually wrap an official partner development program. So anyone can write a provider and open source and you know, have a community driven, but then if you want us to certify it and go through that, we have a whole process that's well defined around us sort of partnering, I think that will define the golden path is why TerraForm has like 2400 providers today is because it's very, very easy, right? Anyone could go do it in a weekend, right? And so I think we spent a lot of time thinking about it from architecture to process to community, how to make it really easy.
Alex Williams 6:27
So then how does the practitioner get valued?
Unknown Speaker 6:31
I think for them, it's sort of twofold, right? One is like, how do we make it really easy for them to discover all of these things? And to the extent possible, they shouldn't have to write any of this stuff. So for them, it's really a focus on Discovery. It's the TerraForm registries, it's all of those kinds of things. But then it's like, how do we let them scratch their own itch, because inevitably, there's going to be a bug, there's gonna be a feature that's missing, there's some capability they want. And that's where the fact that it's open source, and then there's a really well defined sort of path for them to say, Hey, you want to add this new feature? Great, here's how you can do a pull request and add that em, here's how you can fork it and customize it to fit your need. And there's a sort of a well defined path for them. So it's really about enabling them, whether it's, I'm taking it off the shelf, and that works for me, or, Hey, I need to customize it or build something. And let's make that really easy for you.
Alex Williams 7:13
So then how do you think about your own values as it relates to your engineering team? I was reading about them on your site, and you have values such as pragmatism, for example.
Unknown Speaker 7:25
Yeah, I mean, I think for us, the lesson for us is like, it's very hard to be dogmatic and infrastructure. We looked at him and said, you know, what do we value in a community? We want it to be a very professional environment, right? So we want it to be welcoming of everyone. That's why things like kindness. You know, I think our number two principle, right at the same time, we realized everyone's starting their journey in a different place. So it's hard for us to say, everything should be immutable. Everything should be cattle and not pets. And you know, great, that's nice if you're Greenfield and modern infrastructure, but not everyone is there. So let's be pragmatic and say, Okay, you're coming from maybe a more traditional infrastructure? How do we take you on a journey with us? So I think pragmatism, big part, I think humility is a big part, right? I think, you know, oftentimes, we're learning from our community as well, it's like, I don't think we go in and say hotshots, the only people who know what they're doing and everybody else should follow our lead. It's, let's be humble about it, we have an opinion, we might not have the best opinion, but we're going to learn from our community and and sort of interact. So I think our HashiCorp principles play a big part in the engineering culture and how we sort of engage our community. So that
Alex Williams 8:21
how does that help, for instance, with the cultural aspects of the community, be it the practitioners, the partners, and internally in terms of diversity and inclusivity?
Unknown Speaker 8:34
I think it's made a huge impact. And I think, honestly, one of the things we learned was a lot of open source communities weren't clear about what are their principles? And how do they enforce those norms. And I think you saw them become very toxic. And I think we've seen sort of many, many of those communities where it kind of goes off the rails, because nobody's playing that role. And I think to us, we've always been really clear. And we've, we've sort of been the police of our communities, right? We've said, these are community standards. And these are the standard, whether you're at an in person conference like this, whether you're online on GitHub, whether you're on our mailing list, whether you're in our sort of, you know, virtual communities, and then we enforce them, right, there's people that we have rejected from our communities. Yeah. Right. And I think you have to, because if you don't do that, you enable the worst people to sort of hijack it. And then who wants to be a member of that? We're not the people who are new and coming into technology, not the people who are from diverse backgrounds, right? Because those are the people get alienated. And so I think it's super important for us. It's like you maintain those principles, and you act as the police actively.
Alex Williams 9:30
I'm curious on your thoughts about current trends that we are seeing at the new stack. And one of those trends that we're starting to see discuss more is platform engineering. I'm curious on how you define platform engineering.
Unknown Speaker 9:43
Yeah, that's a great conversation. It's a great topic. Because, you know, in some sense, to me, it takes me all the way back to the conversation of like, what is DevOps? Six, seven years ago? Right, right. And I think at the time there was this view of, it's the unicorn developer, right? They're writing your JavaScript in the morning, they're deploying inference Extra in the afternoon, there's setting security policy in the evening. And that's how you do DevOps as you combine DevOps and security into one or dev SEC ops, or whatever. And my view is like, okay, but that flies in the face of all human progress, right? In the same way, I'm not a truck driver, and an airline pilot and a power plant operator. Those are specialized roles with specialized skills. So to me, I think bringing it back to platform engineering, you start to say, okay, great, my dev teams, they should be really good at Dev. But who should be really good at operating cloud infrastructure, who should be really good at providing a platform capability that my app dev teams then consume? So to me, that's the heart of platform engineering, it goes back to that view that even we have, which is like we have a platform team, their customers are our internal application teams, right? So they operate the HCP platform. They provide the core infrastructure, they provide the chassis for us to deliver cloud services. And then our application teams, whether it's TerraForm, or vault or console, our customers have that internally to build and release their cloud applications. So the heart to me of platform engineering is really saying, I have an internal set of customers, how do I effectively enable them to deliver applications cloud software, without having to go be experts in the underlying infrastructure? Right?
Alex Williams 11:13
Is that an approach you're seeing with customers too? Because when I heard Dave McNally speak the other day, he talked about the identity focus that companies will have when they realize that they're in the cloud, right? They'll realize infrastructures, code issues that they need to think about. They'll think about the services, right. And so you can think about TerraForm, you can think about vaults. And with identity, you can think about boundary and with services. You think about console, right? Platform teams have to then decide what service discovery availability, is there for the application teams. Right? Exactly. Yep. And then the application teams and build out the applications. How do you see security emerging into this then model now? Because now we're thinking about security, baking into that platform engineering concept? Is that correct?
Unknown Speaker 12:08
Yeah. And I think in some ways, the way we talk about it is it's not just security, I think if we look at kind of classic enterprise, there was almost a siloed approach to you have your network team, you have your ops team, you have your security team, maybe you have your developer experience team, and each of these operators in their own silo. And now I think what we're seeing is these platform teams are sort of an aggregation of all of those, right? Because if you think about cloud, you know, before was like, great, I bought my data center, I, you know, I buy my Cisco gear, my networking team sets it up, and then they throw it over the fence, it doesn't make sense to bring up a cloud infrastructure, there's not Cisco gear running, right. And I don't have a separate firewall from my security team to manage. It's all part and parcel of the cloud infrastructure. So the networking concern, the security concern, the infrastructure concern, they've all become one, it's sort of a cloud infrastructure concern. So we're seeing those platform teams take ownership over that broader scope and say, You know what, all of these are logically part of the core platform, these it doesn't make sense to say, I'm going to bring up an insecure cloud infrastructure, and then throw it over the fence to security and say, Okay, now go fix it. Why wouldn't I just bring up a secure infrastructure to begin with? Right, like,
Alex Williams 13:11
let's start from the secure infrastructure, right point of view,
Unknown Speaker 13:15
don't try and bolt it on afterwards.
Alex Williams 13:17
But internally at hashey Corp, do you have a team that looks at other tools out there, for instance, to help manage a developer portal? Or I know you use your own products? But do you also have a team that looks at other third party products, too?
Unknown Speaker 13:33
I would consider all that as part of like that core platform team's responsibility. So yeah, they pull in third party products, like, you know, GitHub, circle, ci, data, dog, right, you know, Artifactory, those all get delivered by them as a service to the rest of our teams. Right? Because all the teams need observability. All the teams need artifact management, right? So they do think about that, and that's part of their charter. But again, for them, it's like, they're not the end customer, then customers or application teams were then building on top of them.
Alex Williams 13:59
My last question, a provocative one. What would hashey Corp look like? If it were a proprietary technology company?
Unknown Speaker 14:06
That's an interesting question. You know, I think it'd be a much harder company to scale and right. And what I mean by that is, if you take a look at like a TerraForm community or vote committee, there's 1000s of contributors. And that's what solves the integration problem. Right. And so if you said, we were proprietary and said, Hey, how many engineers would it take to build 2000 TerraForm integrations? It'd be a whole hell of a lot more people that we have today. Right. And so I think fundamentally, what open source helps you solve is the fact that modern infrastructure has this really wide surface area of integration. And I don't think you can solve that as a proprietary business. Right. Like, I think it's just practically speaking very, very difficult. So I think the challenge for us would be, you know, if we were a proprietary business, I don't think we'd be able to have nearly the breadth of integration. Yeah, we could maybe cover the core cloud providers, but you'd have 50 TerraForm providers, not 2500 TerraForm providers. So
Alex Williams 14:55
how do you stay away from that edge? Because you did end up As an enterprise product, you didn't take away features from the open source product, you added features to it. Is that the solution to always make it additive instead of subtractive?
Unknown Speaker 15:08
Yeah, I mean, I think that's a big lesson. Right. And I think, you know, I think we've certainly never removed anything from the open source game. But we've seen other people do it. And I think one thing you learn is there's an extreme loss aversion. Right, because I think people rightly feel like there was a bit of a bait and switch. And so I think, for us that trust of our open source community has always been paramount for us. So I think what we've tried to do is be really, really good stewards and say, You know what, we're never taking things away. We've stuck with our Mozilla Public License since day one, there's never been a licensing change. And we've been clear to the community on here's the way we think about open source enterprise, our open source is not cripple where it's not vaporware, you want to manage a million virtual machines with TerraForm. Do it knock yourself out. There's nothing that prevents you. But the technical piece is what we solve an open source. The organizational complexity is what we solve an enterprise. So it's like great if you care about compliance problems, regulatory problems, single sign on governance, you're probably not a hobbyist, and you're probably not a startup, you're probably a commercial business that's getting real value out of a solving those governance challenges with a scale challenges. And yeah, those are what we do, you know, in our enterprise product, because we're solving real commercial problems for you. Right, and we think it's a fair value exchange. And I think by having that really honest conversation with an open source community, then it's like, okay, yeah, we get it, we understand why feature x is open source and why feature y is enterprise. And then it's just about building that trust by being consistent. And I think for last 10 years, I think we've built that trust kind of brick by brick. Armour. Thank
Alex Williams 16:31
you so much for your time. And thank you for having us at hashey comp. It's been a great show, and I've learned a ton, so appreciate
Unknown Speaker 16:37
it. Thank you all for being here. Appreciate it.
Alex Williams 16:40
Thanks for listening. If you liked the show, please rate and review us on Apple podcast, Spotify, or wherever you get your podcasts. That's one of the best ways you can help us grow this community, and we really appreciate your feedback. You can find the full video version of this episode on YouTube. Search for the new stack and don't forget to subscribe so you never miss any new videos. Thanks for joining us and see us soon.
Transcribed by https://otter.ai