Adapting Open Source Developer Products for Commercial Enterprise

Michael Grinich (00:02):

Welcome to Crossing the Enterprise Chasm, a podcast about software startups and their journey moving upmarket to serving enterprise customers. I'm your host, Michael Grinich. I'm the founder of WorkOS, which is a platform that helps developers quickly ship common enterprise features like Single Sign-On. On this podcast, you'll hear directly from founders, product leaders, and early stage operators who have navigated building great products for enterprise customers. In every episode, you'll find strategies, tactics, and real world advice for ways to make your app enterprise ready and take your business to the next level.

Today I'm joined by Armon Dadgar, the co-founder and CTO at HashiCorp. For those of you that are unfamiliar with HashiCorp, they provide infrastructure for developers building cloud software. They have both commercial and open source products you might be familiar with that include Vagrant, Terraform, Consul, Vault, and many others. Thousands of companies today use HashiCorp, including really large enterprises like GitHub, Wayfair, and Shopify. Along the way, this meant HashiCorp needed to become enterprise ready, and that meant building new features for those enterprise customers. We're going to dig into all this and more and talk about how HashiCorp is still moving up market and crossing the enterprise chasm. Armon, thanks for joining us. Welcome to the podcast.

‍

Armon Dadgar (01:19):

Yeah, thanks so much for having me. Great to be here.

‍

Michael Grinich (01:22):

So give us a quick update on HashiCorp. Where is the business and team at today and what's your current focus right now?

‍

Armon Dadgar (01:28):

Very, very high level. We took the company public two Decembers ago, so December '21, and feels like in that transition as a business from kind of called startup mode HashiCorp, to kind of enterprise mode HashiCorp. We're about 2,500 people, 500 million-ish in terms of revenue. So kind of in that transition now of going from, did a lot of non-scalable things to kind of get you to sort of IPO and get you to that point. And now transitioning to what does it look like to be a very repeatable, very predictable enterprise software company at a billion plus in revenue. So that's kind of the transition that we're in the midst of.

‍

Michael Grinich (02:05):

Let's go back in time. Let's talk about the early days of HashiCorp. I know when you and Mitchell were building a lot of open source technology that ended up being the foundation of the business. When did you start commercializing this? Kind of talk about the first steps as you started thinking about commercial customers and then enterprise customers?

‍

Armon Dadgar (02:22):

It was a very long road in between those different phases. So just if I go all the way back and lay a little bit of the timelines, the first HashiCorp product, if we want to call that in quotes, was Vagrant and actually predated the company by a number of years. So that really started as an open source project that Mitchell created back in 2010, 2009/2010. It wasn't until 2013 that we really founded the company and both sort of signed up to HashiCorp full-time. So already had three years where Vagrant was purely kind of an open source project.

And with the start of the company, our view was ‘hey, there's this broader portfolio of tools we want to build in open source, really developer focused’. So for the first few years of the company, it was actually still just a focus on building open source tools, driving adoption of the products and building community around it. So even though we started the company in 2013, the first real, I'd call it, enterprise grade thing that we sold was not really probably until the end of 2016. So there's quite a time lag between when we started and when we first sold our first enterprise product.

‍

Michael Grinich (03:25):

What did that first enterprise offering look like? What did you have to change? If you can say, who was that customer?

‍

Armon Dadgar (03:31):

I'll answer slightly indirectly, which is that we kind of got it wrong in terms of what the product was a few times. And so if I kind of go back and replay history a little bit, at the time there really weren't a lot of good examples of what an open source success looked like. You had Red Hat. They had a particular model where everything was open source, support services, licensing is this kind of a very unique Red Hat model that nobody else had managed to replicate. And so we have to take ourselves back to, there wasn't a Mongo, there wasn't a Confluent, there wasn't these other successful open source companies.

So for us, we kind of grappled with what's the right way to even monetize open source? And we tried a few different things. Initially, probably the first deals we sold were support contracts around open source, so we did a handful of those in the early days. We tried building a cloud-based platform as a service, ill fated, called Atlas that we subsequently killed in 2016. We explored different things like exotic licensing approaches and then ultimately we landed on what became an open core strategy, which we said, ‘great, we have the open source, we have an internal fork, Vault enterprise, add some additional functionality and that's where we go’, we sort of license. But it took us a little while for what that strategy was and there were a few iterations of it because it wasn't obvious at the time.

‍

Michael Grinich (04:47):

What do you think is different about building businesses with that open source model compared to other, maybe like PLG or freemium businesses that have this bottom-up motion? HashiCorp had a pretty large community of open source around it when you started. I'm curious if you can talk more about the differences in sort of business model and go-to-market that you've seen with that. You've obviously iterated on this a lot.

‍

Armon Dadgar (05:08):

I don't think open source strategy and PLG are sort of separate. I think about it as open source almost the predecessor to modern PLG. Because if I think about the open source strategy at its core, what it was about was how do I get distribution of a product that's essentially free, doesn't move my bottom line, how many times people download Vault, but it creates distribution, it creates awareness, it creates reach for the product. So in many ways, the strategy actually has very high overlap to PLG. What you want to do is create an experience that's very low friction, that's high time to value, that allows the end user to validate the solution. It solves their problem in a credible way and that it generates top of funnel for you. So if you kind of think about it in that kind of almost abstract way, it is a PLG motion.

What you're kind of doing is creating a freemium version of the product, using that to drive downloads and awareness and top of funnel. I think what's changed with more increasing comfort with SaaS, increasing comfort with sort of cloud delivery is, now as we talk about maybe modern PLG, it looks a little bit different. It might not be open source, it might be closed source and you really have a free tier and people are signing up for that. And I think you've actually seen HashiCorp kind of evolve to that as well. So if you look at our more modern kind of cloud offerings, whether it's Terraform Cloud or the HashiCorp cloud platform. Many of our newer solutions actually look more like that where, yeah, if you sign up for Terraform Cloud, it's not open source under the core or HCP Packer, but there's a PLG motion to it. There's a free tier which says, hey, your first 10 images with Packer are free, and then there's a paid tier above that.

And so in many ways, I think open source was kind of the predecessor to PLG. It solves for many of the same things. I think the best way to think about open source is through that same lens. I think the challenge of it obviously is because the source code is out there, you're in situations where customers can choose to say, ‘hey, I'm going to go build my own scaffolding on top of open source’, where you don't quite have that same dynamic with a cloud-based PLG motion. So I think it does make the sales motion a little bit more complicated. Some of your more sophisticated customers might say, ‘I'm going to take your open source and build on top of it’. But I think the core motivations, the core mechanics are very similar to PLG.

‍

Michael Grinich (07:11):

It seems like your biggest competitor in that scenario is yourself. It is your open source version. You're kind of on both sides of the table.

‍

Armon Dadgar (07:19):

Yeah, that's absolutely true, and I think very often the framing of the conversation with customers and what they need to rationalize is, it's a build versus buy decision. Either I buy the HashiCorp enterprise product or I build and I put a team of 5-10 people on building my own Terraform enterprise or building my own Vault enterprise. It's not necessarily open source versus enterprise. It's buy of enterprise versus build of your own custom homegrown scaffolding.

‍

Michael Grinich (07:46):

What would you say is the right time to go open source versus kind of a close source freemium offering? What type of products do you think fit well in one versus the other? You've obviously explored both and you've succeeded at both.

‍

Armon Dadgar (07:59):

So yeah, it's a super, super good question and I'd say my default these days would actually be, I default people to say, go close source, build a SaaS. Now, I think the exceptions to that, and I think those become the interesting ones, is when should you do open source? I think there's a few interesting cases where one is where your end user, end buyer is a highly sophisticated developer audience. So if I was building a productivity tool, I'm building the next generation, whatever, Asana. My end users, some of them might be developers, but most of them probably aren't. So if I'm building true infrastructure, true developer tooling databases, things where my end users are highly, highly technical, I would have a stronger preference there because I think that community, A, sees value in it being open source, B, they add value back to you because they're sophisticated enough to be able to solve a bug, add a poll request, create a feature, whatnot.

I think the third category would be where you have a very broad integration surface area. The biggest power of open source is the ability to close the gap through integrations. I think Terraform is a good example of this. We have something like 18,000 contributors on an annual basis. A tiny fraction of those work for HashiCorp, but it's because there's so many people are saying, "Hey, I use Terraform. If only I had this integration with my EMC storage controller, or if only I had the integration with what I'm doing with Fastly." And I think you're able to leverage the power of open source to build those integrations and build that surface area in a way that would be very, very difficult in a purely proprietary way. You're not going to hire 18,000 people.

‍

Michael Grinich (09:33):

Seems like that open source essentially allows you to create a network effect of that because anybody can tie it in. The more integrations you have, the more momentum you have and kind of becomes the default solution.

‍

Armon Dadgar (09:42):

That's exactly right, yeah, creates that network effect, but I think for that to work you need a problem that would naturally benefit from that.

‍

Michael Grinich (09:48):

I want to ask you more specifically about Vault. So Vault is one of these really interesting products that's kind of storing and managing secrets, but can be used for a lot of different things. Vault has an open source version and I believe also has the cloud SaaS version, which has become very popular and been really successful. Tell me about the origin of that and how you navigated that and moved to this new model which has had great commercial success.

‍

Armon Dadgar (10:10):

It's an interesting question because the way we think about the cloud is it's not a different product, it's a delivery mechanism. And so what I mean by that is we sell to enterprise customers and ultimately the way we view it is we're not the tail that can wag the dog. It reminds me of conversations I had with a lot of these enterprises in 2013, 2014, where they were like, "We're a big enterprise, we're a bank, we're whatever, we're never going to go to Amazon because cloud will never be as secure. It'll never be as performant, it'll never be as X." And at the time I can remember thinking to myself like, "Yeah, yeah, but you think you can run a data center better than Amazon." And so inevitably all of those companies have sort of, over the years, built the comfort to be like, "Oh no, obviously Amazon and Microsoft and Google are going to do a better job running a data center than we are."

And now all those people that were kind of in the cloud never camp have come around to saying, "Okay, yeah, actually we're all going to be multi-cloud." And so when I think about the way we're bringing our products to market, when we had those same conversations with customers back in 2017 saying, "Hey, you want to use Vault enterprise? Great." At the time, they're like, "Yeah, but we need to own it. We need to run it. It needs to be in our data center. We need to operate it because we're going to do a better job than HashiCorp. And this is tier one mission critical infrastructure for us." And I think that's all true. It is tier one mission critical infrastructure and maybe back in 2017 when we were a small startup, they probably would've done a better job running it than us. But I think you flash forward now where we're like, "Hey, we have a way bigger operations and SRE and security team than many of our customers do focused on running something like Vault."

Almost invariably, we're going to do a better job running it than most of them will, but I think there's still a comfort question. We still talk to a large chunk of those enterprises who are like, "No, never. We're never going to consume it as cloud delivered. We have to own it. We have to run it." But we're seeing those attitudes slowly shift. So I think it's very similar to the clouds where it took years and years for the comfort level to be built there, not because the clouds weren't ready, it was more of just a psychological comfort thing. They just thought they weren't ready. There was nothing wrong with Amazon or Azure at the time.

So I think we're going through that same thing, and I think for us, the thinking about the timing of when did we invest in the cloud, when did we start to start nudging customers that way was really more of trying to suss out what's the comfort level of these enterprise customers? Do they feel like, "Hey, we're ready to make that leap. We want to consume this as cloud." And I think where we are now is you're seeing those early adopters saying, "Yeah, you know what? We're just going to use the HashiCorp cloud version because why should we bother?" I think there's still a long tail of enterprises that aren't there on a comfort level, but that's okay. That's why we'll offer it in both these flavors and over time help them transition to cloud because I think inevitably they're all going to get there.

‍

Michael Grinich (12:43):

What have you had to do on the product side to make those customers comfortable with cloud, those enterprise customers? What have you had to evolve in terms of the product surface or functionality to give them the controls or security that they feel like they need to use your cloud service?

‍

Armon Dadgar (12:57):

It's a really good question, and it's interesting because almost all of it is not product feature work. It's almost all what I'd consider product non-functionals. So it's like what people care about is like, "Hey, do you have rich access logs that show what operations you performed against my Vault and when you accessed what or when you performed an upgrade, what internal controls do you have? Do you have the right controls that a HashiCorp employee couldn't access my data?" And then you get into various compliance regimes, "Hey, do you have the different PCI compliance, HIPAA, SOC Type I and II?" So it's all of those kind of almost non-functional requirements.

"What's your DR (Disaster Recovery) strategy? What's your RTO (Recovery Time Objective), RPOs (Recovery Point Objective)?" It's all of those kind of things that I think are what customers ask more about because those to them are about the operation of Vault.

"Does it have feature X or Y?" It's like, "Well, yeah, I mean there's feature parity between them, if you're happy with the product, self-managed, it's the same product on the cloud." So it's not a feature question. It's more about these non-functional requirements. And that's a big lift, I'll be honest. And I think that's a hard thing when you're a small startup. These enterprises have a very high bar because of all the regulatory sort of challenges they have. Those get sort of inherited. As the vendor you inherit all of their challenges, all of their complexity. I'm not going to say it's easy to go deliver these environments that meet all of those requirements.

‍

Michael Grinich (14:19):

Can you talk a little bit more about the commercial structure that you've evolved to? Earlier you mentioned that you guys did support contracts and then you did kind of exotic licensing, different structures there, and now you've been moving to this pure SaaS model for some of your products. What is your current frame for how to structure commercial agreements with these bigger customers when it's not someone just putting in a credit card and just buying a few seats? How have you had to adapt that for those types of customers?

‍

Armon Dadgar (14:46):

Sure. Yeah, I mean, to your point, we've tried everything. Where we've landed now is effectively, there's kind of, I'll call it two structures. There's kind of, I'll call it our current structure, and then there's sort of where we think our future state is. So the current structure is very much sort of an annual licensing entitlement based approach. So you might say, great, I want entitlements to Vault. Effectively, we price on sort of two dimensions. There's a platform fee and then there's a unit of value, which for us is the number of applications connected to Vault, right? Same thing for Terraform. There's sort of a platform and then there's the number of workspaces or call it applications that you're managing with Terraform. And so that way basically we can start with a smaller contract, say, great, I maybe have one Vault cluster and 50 Vault clients. And then as you expand to say, hey, I'm going from one data center to 10 data centers. I add more of the platform, and as I go from 50 apps to 500 to 5,000 apps, I'm going to add more on the second dimension.

And so I think what's nice with that is a certain predictability for customers. They understand, hey, how many applications have I integrated, their cost sort of scales with the value they're getting, and it's a relatively understandable metric. It's usually an annual entitlement. If customers decide they're adopting faster than they thought, they can always add more entitlements as they go. So that's kind of the classic approach. Very, I think, well understood, well aligned to how enterprises to buy and budget and think about things. Now, I think the disconnect is in a cloud world, people are used to now thinking in a very different way. The clouds have made us think about a consumption-based model rather than an entitlement based model.

So I think as we're transitioning to being more of a cloud business, we're also moving towards enabling a consumption-based pricing model. So we refer to as sort of flex pricing, or you might say, okay, I actually want to commit a million dollars to HashiCorp cloud, but I'm not buying any particular product. I'm just doing a million dollar commit. And then I might say, great, I'm going to burn down that million dollars with $10 an hour worth of Vault and $20 an hour worth of Console and $30 an hour worth of Terraform based on my usage. And then that's priced, you can think about the water meter. So okay, the more Vault clients you have running, great, your per hour charge goes up. The more things talking to Console or so on and so forth, the more resources you're managing with Terraform. So I think over time, and I think that's going to be a gradual shift for us, we move from sort of an entitlement model, which is well aligned particularly for self-managed customers to more of a consumption model, which is more aligned to sort of a true cloud.

And I think particularly for us, because we had such a wide portfolio, that enables us to be able to then expand from single product, multi-product in a lower friction way. I think the challenge of entitlements is great. We go through all this work, you bought your Vault entitlements, now we got to have that conversation all over again with Terraform and then all over again with Console versus I think if you say, great, you committed a million bucks and now you can kind of burn it down at a variable rate, you're not forced to go through procurement every single time, and I think that's very much what the clouds have got us used to. You don't buy EC2, you don't buy S3, you buy Amazon, and then you spend it on whatever you want.

‍

Michael Grinich (17:47):

What's driving that transition as you see it in the market or at Hashi? Because I've heard about this credit model, I think this is how Snowflake charges for a lot of their product today. Is this something that's being driven by your customers or you're driving this forward in terms of how you want to grow the business structure?

‍

Armon Dadgar (18:02):

So it's a bit of both. So if I sort of talk about it from our perspective, selfishly, the selfish side of it is it's a lower friction for us as the customer goes from product A to B to C. We don't want to have to go through procurement every time that we do that. So for us, selfishly, it's sort of a lower friction way of doing it. I think from the customer side, I think for them what they've realized, what the cloud providers, the nice thing about consumption, is that you are perfectly aligning your spend to the value you're realizing. And what I mean by that is if I'm running 50 VMs on Amazon, great, I'm going to pay 50 times, you know what I'm going to pay if I run one VM versus in an entitlement game, and there's always this guess ahead, you're saying, okay, I bought 50 VMs from Amazon, but oops, I only need to 30, so I ended up overpaying.

There's a misalignment in terms of what am I paying versus what's the value I'm actually realizing. I think as customers also increasingly transition their business models to SaaS or to sort of a subscription, then what it allows them to do is map their COGS one to one to their top line. So you can say, hey, for every new $1 the customer gets in incremental revenue. I know that I'm spending 18 cents on cloud and HashiCorp and Datadog and all my vendors, so it allows them to have that much cleaner mapping. I think when they were in sort of a hybrid world, it was sort of awkward, like if they were selling something that was a perpetual license or you're manufacturing, you built a truck, but then you have this sort of variable OpEx cost, there's sort of a mismatch in business model, and I think as all of those companies are transforming themselves, it's like, "Hey, well we're a subscription business. Our cost should look like a subscription that's variable as well."

So I think you get it on both sides. I think customers like the value alignment. I think they like the fact that they can connect their top line revenue to their COGS in a more linear way, and then I think it's nicer for us as a vendor as well, especially when you're multi-product, it reduces some of the friction there. So it's both sides.

‍

Michael Grinich (19:56):

It seems like kind of the final evolution of SaaS in a way to be that finely metered to be able to tie everything back to COGS and have that level of detail across the whole business. I don't know, there's a beauty to that, I guess.

‍

Armon Dadgar (20:06):

There is, and you know what the funny thing is? Almost inevitably, you can almost feel it starting to swing back because the downside to these models, and I think people don't talk about them enough, is that they actually lose predictability. It's very hard to actually predict, what's my Datadog spend? What's my Snowflake spend? What's my Amazon spend going to be two years from now? I think we're going to go down this path, but almost invariably I feel like you'll see a swing back for what enterprises will want. At the end of the day, you can't have it all. You can't have per-meter perfect flexibility, but then also have perfect predictability. These two things are fundamentally in tension with each other. So to me, my guess is the steady state is you'll have both, and it will depend highly on the business model and nature of your customer, which model they prefer.

‍

Michael Grinich (20:50):

Last question for you before we wrap up. What advice would you give entrepreneurs just starting out this journey, building product, and thinking about going to enterprise and how they're going to scale up and commercialize?

‍

Armon Dadgar (21:02):

If I could repeat the HashiCorp journey, it would be to really understand my customer and what I mean by that is, it sounds so stupid and obvious, but I think for many years we struggled with, “Is it an enterprise buyer? Is it a SMB buyer? Who is it in these organizations that we're targeting? Is it the developer who's really the buyer? Is it the VP of infrastructure? Is it the CIO?” So I think really understanding who that buyer is in a fine grain, who's that persona? Then will let you understand what is the value proposition they care about. Because the developer's going to care about a very different thing than a CIO cares about. It's also going to change your pricing and packaging. It's also going to change your go-to-market motion of how do you get to that person. If your goal is to get to the developer, it's a very different motion if your goal is to try and get to the CIO.

So I think being really crisp on who that persona is, what they care about, what's the value and how do you charge for that, that makes sense to that persona, and then what's your motion that lets you get to them? I think that clarity of that will save you so much time and thrashing, and I think for us, we didn't have that. I think part of it was it evolved over time and it changed and there was a certain naivete of being a first time founder and not asking those questions. But I think once we had that clarity, then it's like, okay, everything else downstream of that becomes so much more obvious.

‍

Michael Grinich (22:17):

Armon, thanks so much for joining us today, sharing a bit more about HashiCorp. This has been great.

‍

Armon Dadgar (22:21):

My pleasure. Thanks so much for hosting.

‍

Michael Grinich (22:28):

You just listened to Crossing the Enterprise Chasm, a podcast about software startups and their journey moving upmarket to serving enterprise customers. Want to learn more about becoming enterprise ready? The WorkOS blog is full of tons of articles and guides outlining best practices for adding features like Single Sign-On, SCIM provisioning, and more to your app. Also, make sure to subscribe to this podcast so you're first to hear about new episodes with more founders and product leads of fast growing startups. I'm Michael Grinich, founder of WorkOS. Thanks so much for listening and see you next time.

‍