Intro

Michael: Hello and welcome to Open Source Underdogs! I’m your host Mike Schwartz, and this is episode 60 with guest, Antti Karjalainen, a co-founder and CEO of RoboCorp.

RoboCorp is a vendor in the RPA or Robotic Process Automation software market. It’s a type of software that allows businesses to automate repetitive and routine tasks typically done by humans through the use of software bots or robots. These tasks can include things like data entry or customer service interactions. If you’ve ever gone to a website and a chatbot pops up – that might be powered by RPA.

As you can imagine this software market is growing rapidly as more businesses are looking to automate their processes and improve efficiency. RoboCorp is a newer business than I thought at first, given how thoroughly they’ve established a leadership position in this very competitive market. Antti has a lot of great insights, so without further ado, let’s cut to the interview. Antti, welcome to the Underdogs podcast.

Antti: Thank you, Mike.

Origin

Michael: So, no founder interview is complete unless we hear the origin story. I take it as a young undergraduate student, you probably didn’t predict your career in RPA. So, how did you get into the industry and how did RoboCorp get its activation energy?

Antti: Yeah. I mean, that’s a long path obviously when we talk about these kind of founding stories. It all started with me just by doing software engineering work after graduating. And I ran a small consulting company around software engineering. And with that, we used to do a lot of Q&A test automation with a project called Robot Framework. It is a python-based keyword-driven test automation framework. I got into that community while using it. It is based out of – well, the project came out of Nokia, so that’s why the Finnish roots.

I got into the community, started doing things around the open-source project, hosting events, stuff like that, and then, I bumped into RPA, which is starting to emerge and take off around 2016 and 2017. And I thought immediately that that has a lot of commonalities with the test automation. In test automation, you obviously drive a system to validate it, and in RPA, you drive a system to perform a business process. So, I thought that maybe Robot Framework could become the leading open-source community for RPA and started on that path eventually after my first company got acquired.

So, a few years later, I’m looking at the market and there’s this big competition emerged, raised a bunch of money, started growing really rapidly, and RPA was the fastest growing segment and Enterprise software for like three years in consecutive.

So, I thought that somebody needs to build an open-source solution for that, and I didn’t see any other person having the right connections to do it, so I decided to start on that path myself and that sort of lead into RoboCorp. I felt that I had to do it in a way.

Product

Michael:  What are the products that RoboCorp sells?

Antti: We sell one product, which is the Control Room. That’s the proprietary component in the stack. That’s the orchestration platform as we call it in RPA. That’s how you deploy the bots, manage them, govern them and manage user rights and so forth. So, it’s really a central piece in how RPA works and how the bots actually get to execute work.

And then, we have a bunch of other components in the stack. You know, namely the code open-source stack, which allows you to build a bot and run it. And then, obviously all the automation libraries that enable you to connect to various applications, from browsers to mainframes, to ERP systems. And then, we have the developer tooling on top of that which creates a good developer experience. So, anything really outside of the core control room platform is open source with us.

Low Code Strategy

Michael: One way that RoboCorp has been innovative I think is through the use of Low Code. And why do you think that Low Code is so critical in your market?

Antti: In RPA, you deal with different sorts of developer personas. Some are very technical, come from a developer background, others might come from a accounting background for instance. So, when RPA got popular, it was marketed as something that anyone can really use to build these bots. But then, as it got adopted into the Enterprise, it sort of went into more complex use cases, more mission-critical use cases. So, it became a automation professional domain.

We started out with the automation professional in mind and built this Robot Framework and Python-based tools for them and got initial success with them, but we soon realized that it’s too different for the developer persona to be targeting.

They expected to have a drag-and-drop interface in front of them. So, we started thinking, okay, how can we innovate and create something that’s actually meaningfully different in that space. And so, we built a local layer on top of our open-source stack, which allows you to create a local solution, but it generates code in the back end. So, we call it “Code Native Low-Code”.

So, you work on this drag-and-drop interface, you build the automation from individual steps, which might be like opening browser, clicking elements, etc., and in the backend it’s converting that real-time in the code. And back, if you edit the code, you’ll see it in the local as well.

So, that was just the market expectation, and we wanted to sort of not be an outlier there to be perceived as more difficult than the competition, while in real life it really isn’t.

But coming from a background where RPA developer might not have actually written a line of code, presenting them with a VS code editor is just too jarring of an experience. But I think we balanced it the right way, where we can still keep the both worlds next to each other, low-code and then pro-code, as we call it here.

And it has been a pretty interesting journey to build something that hasn’t been built before that way.

Community

Michael: Can you tell us a little bit about the community? You mentioned you started with an open-source project in Python – were you able to bootstrap that community into the RoboCorp community? And how is it going building that community out?

Antti: The Robot Framework Community is pretty extensive. I think the project gets around 1.5 million downloads a month from Python package index. So, it’s used extensively in end-to-end testing in Q&A. And initially, what we took out of that was all the integrations that had been built over the years.

So, we get to leverage this massive base of all these libraries that integrate into various systems that Robot Framework was used to test, started out building our own tooling. And sometimes, the test automation community doesn’t really overlap with the RPA community, so we had to start building our own community as well. Sometimes they do overlap. We have customers who are now consolidating their test automation engineering, first with the RPA engineering, for instance.

We have customers who are coming into our products because they know Robot Framework already, and so they’re experienced with the tech and have confidence in it. So, to a decree, this overlap in those communities, it feels like we are building these two parallel communities that overlap in parts – it’s like a Venn diagram in a way.

How Low-Code Impacts Onboarding

Michael: One of the areas I feel RoboCorp is doing a really good job is by reducing the friction to onboard people into both your community and also into the commercial engagement with RoboCorp. And I wonder if low-code is maybe a gateway for people who go into the pro-code area. But can you talk a little bit about how that journey works from getting newbies and getting them in to be RPA professionals and customers?

Antti: Yeah. For sure, low-code isn’t a big enabler there. You’re not staring at like a blank screen, but you have all these capabilities listed as actions that you can start dragging on a canvas. So, it’s something that pretty much anyone can start doing, and you don’t have to have an in-depth tutorial or training to be able to do that. So, it’s a big enabler.

And also, by the way, we see the test automation community now starting to leverage the automation studio, the local tool as well. It is definitely excitement – low-code. And for good reasons. I mean, you can frame out some solution that you have in mind in minutes rather than learning the syntax from scratch.

And then, when you want to refine the solution, you can go into the code and start customizing it, maybe building custom Python in the creations, Python keywords and so forth. It is actually something that I prefer to use even with my developer background. If I start a new project, I start it with the low-code tools frame it out, get the structure right, and then might go in the VS code and I finish it up. But it’s such a big step up in the ease of getting started that you don’t really need to install Python, bunch of libraries, figure out your Dev environment, all of that – that just goes away. That just gets easy, but both sides of the community, pro-code people and the local enthusiasts like to use it.

Cloud Native Impact

Michael: So, one last technology question. Cloud Native has been a really – I mean, for me at least, it’s felt like a monumental shift in sort of how the customers deploy and operate. And I’m wondering if you’ve seen something similar in the RPA market, where Cloud Native has impacted or open new opportunities for delivery?

Antti: Yeah, definitely that’s a big part of what we do. The Control Room itself that the orchestration platform does, some Cloud Native SaaS solution – that’s something that you can just few minutes click into it and get an account going. That’s a great way to deploy RPA across a number of organizations, a number of different companies if you are a service provider, for instance. Building obvious solutions, you sort of have this single pane of glass that you can operate across.

Now, with RPA is also a double-edged sword. It sort of comes with benefits and the negatives as well. RPA is typically something that you do with applications that might be inside corporate firewalls, inside private Cloud environment. So, the bots actually need to operate typically in on-prem environments. And still, we use a Cloud Native solution to deploy them. And there’s a lot of architecture and engineering questions that we had to solve to make it as secure and robust as possible, to make it happen and be seamless for even the largest Enterprises to be able to adopt it.

Obviously, the benefit is that you get a single version deployment, you don’t have to go through installing a lot of infrastructure to get it started. You don’t have to update versions, you don’t have to maintain databases and so forth, but I think, especially with RPA, since it’s dealing with quite sensitive business processes typically, it deals with sensitive data as well user information, healthcare information, financial information, the security questions around that information are significant, and also compliance. So, that’s one key part of how we architected the Cloud Native products from the beginning, to be able to service on-premise use-cases.

Customers

Michael:  Who are the customers of RoboCorp today?

Antti: We serve a number of different types of customers. First, starting with the Enterprise, we have a number of large Fortune 500s and Global 2000s in the customer base. Some of the public references are companies like Emerson Electric, Ally Financial in the US, and there’s a lot of Enterprise customers that are still not public referenceable. But then, additionally, we have a large base of implementation partners – they have different business models, so they might offer a managed service on top of RoboCorp, where they build business process automation and deploy that across customers. It might be healthcare specific automations, it might be insurance – really any vertical, you name it – and then, there’s the system that created community who offer services on and around RPA.

We cover from mid-market customer base, in broad range of verticals and geographies and all the way to the highest Enterprise tears.

Segmentation

Michael: It’s interesting to hear you say that you had partners who are maybe developing business specific vertical solution and then marketing them – is that a strategy for segmentation or are you trying to identify, my guess, markets that you can deliver business value into and partners who can deliver that?

Antti: Really, it boils down to direct Enterprise customers, and we do get some mid-market customers that are good with us. But then, the partner strategy is really in the core of the company. The opportunity with RPA is so vast, so you can basically imagine any kind of company and they will have use cases for RPA. So, it comes down to whether the customer has a team of their own around business process automation. They might be using API-based solutions, all kinds of intelligence document processing, and together with RPA, to build end-to-end solutions inside a corporation.

Or then, when we go into the mid-market and below, it becomes a use-case driven segment. So, that’s where you need to know the specific ins and outs of, let’s say, mortgage origination. Their partners are better off to serve their own sort of expertise area. It is basically we sell directly to sort of teams inside Enterprise, and then, we have the partner ecosystem to serve on a use-case basis. That’s how we think about it.

Partners

Michael: Are these partners globally distributed?

Antti: Yes, definitely. We basically have partners across all the continents. It is really distributed right now, and there’s different categories of partners as well. Some of them might offer business process outsourcing services, some of them are automation pure-play vendors as we call them. So, they specifically focus on automation services. And then, they are the big force, the accounting companies, so they will typically also deploy RPA with their customer base.

It’s really wide range of different kinds of partners. And within that base, there’s different kinds of business models that they deploy. Everything from reselling into consulting, into system integrator work, into managed services.

Team

Pricing

Michael: Is the RoboCorp team similarly globally distributed?

Antti: Oh, yeah, for sure. We are right now, I think, in nine different countries, about 50 or so people at the moment, adding headcount right now. But we are fully remote company and we’ve been like that from the beginning. So, engineering, typically, is around Europe. And we do have a big base in Finland for engineering, but it is also distributed as a product engineering design. And then, our partner operations are right now led from Europe, and then, the broader go-to-market team is in the U.S. so, sales marketing customer success.

Michael: I always warn founders about how hard pricing is. There are a number of strategies to price I saw in the RPA market – what is a RoboCorp strategy and how long did it take you to get there? Did you get it right the first time and where are you today?

Antti: Oh, man. I mean, pricing is really difficult, it goes across everything really. When I got started with RoboCorp, I started kind of building the vision for the company. Now, we knew that we wanted to be the open-source standard for RPA for sure. We wanted to innovate around how do you build bots, how do you operate and manage them at scale, deploy them at scale, all of that stuff, make it more robust and resilient and faster, all of the technical attributes that you want to have for solution like this.

But then, the second big innovation there was around pricing itself and the business model. RPA traditionally has been really complex in license, and you can imagine this like a large Enterprise pricing scheme, every item has their own price tag, starting from a developer license to a test license, to an orchestrator, to a bot license, to an attended bot license, and you name it.

We wanted to make it really simple. We sort of went back to first principles and started thinking about, “Okay, what is the best proxy for value in RPA?” Traditional RPA will be pricing bot licenses.

So, essentially, you have a bot license that allows you to run one bot at a time. If you want to run two bots at a time, you purchase another license or so forth. And if the bot isn’t doing anything, you are still paying for the license. We thought that the better capture for value is going to be around consumption, and namely the working time of the bot. So, whenever your bot is working, you’re producing value, and so that’s the proxy.

We were the first one to build a consumption-based pricing model. And we did it from the beginning and started building the whole platform with that in mind, that we wanted to get rid of the concept of a bot license and go to consumption. And that still works, people love it. And they like the sort of flexibility of it, they don’t need to know how many licenses they need to purchase in advance. People will have peak demand loads at the end of the month or end of the year, end of the quarter, they will run reports that the bots will do. And those can demand hundreds of these bots working at the same time.

So, it really allows them to think of the processes from the best engineering perspective rather than thinking from a licensing perspective. That was my good starting point, but then comes all the details, like all the small details. Okay, you’re running a bot that needs to work 24/7 with a minute best price that becomes really expensive. So, we needed to add billing caps on a process-by-process level to cap the value at some point.

You want to do parallel execution, these kind of things – there’s different ways to really make it work. When you go into the Enterprise, you get into these conversations of, you know, we are ramping up, we have all these plans for RoboCorp, but we don’t know how much we’re actually going to consume.

If they’re coming from a legacy RPA platform, we are typically two to three times faster to execute, but they really cannot know in advance. So, we need to make provisions for first year, onboarding, ramp up, all that stuff. So, pricing is really, really difficult even though we try to come up with the most simple and elegant pricing scheme possible. And it’s still an ongoing process – we are actually redoing some of the pricing right now as we speak.

Value Prop Evolution

Michael: From the day you started, you had a certain value proposition in mind. And what are the most important parts of that value proposition today that maybe differ from where you originally started?

Antti: You know, we thought out that we will have this more of a bottom-up approach to RPA, where you can simply just download tools, explore them, build something, and then get it into use, into production as a self-service motion. And we thought that that would take us into a growth path.

So, we built the product in a way which allows you to do like full self-service, but then, over time, we realized that in RPA, you typically have a different buyer than the technical user is. And the buyer is very non-technical. So, we needed to start adding a lot of this sort of top-down aspect to the product itself and into the selling motion itself.

You know, in the recent years, I realized aspects of the value prop that we even didn’t fully understand ourselves, things around being able to store the bot code in GitLab and GitHub and user version control, now, the typical low-code solution doesn’t do that for you – it is all a proprietary XML-based model that you operate with, so that really isn’t a facilitate versioning.

When we went in first time and did like larger financial institutions, they told us that, “Hey, we chose you for one reason: because we can actually audit the bots, we can put code review processes around these bots.” And not for the reason of validating that the code is good quality, but actually, validating that the digital worker doesn’t go rogue, doesn’t do things it wasn’t intended to do.

So, the fact that we can do proper version control actually meant proper governance and controls and compliance for our customers – that was a new thing that we discovered some time ago. As we’ve gone into the Enterprise, and we got really good success stories there, things like reusable components across the bots, so you can share code between the bots and build asset libraries that you can leverage in future bots that you build. You don’t need to re-implement all the functionality again and again, like you would do in a more traditional local platform. You know, these things have become more and more valuable over time to ask on the customers.

Advice For Open-Source Entrepreneurs

Michael: I guess, as we tie this interview up, I wanted to get your thoughts on the open-source industry maybe more head large. As a successful founder, what do you think are some of the challenges that other entrepreneurs who want to use open source as part of their business model are facing today?

Antti: Yeah, that’s an interesting question. Now, open source does have many different kinds of business models around it, I think. First of all, understanding what you can do around whether it’s an open core model, whether it’s a support model, or Cloud-enabled model. That’s the choice that you have to make kind of early on as you start building.

Sometimes, open source can be a one-way door. You put something out there in the public domain, you don’t get it back. So, realizing that and being mindful of what you actually put in the open-source side of your business – what’s proprietary, how do you monetize, how do you do that, it’s an important decision. And you know, we’ve seen companies in the last decade or so, going to open source and potentially give out too much of the value prop.

I think Docker has been a good example of that. Now, they’ve actually turned around and doing great, but for a while, insiders I’ve heard saying that we gave out too much, that we didn’t capture the value. So, being mindful of what the customer wants to pay and trying to make it meaningful. You don’t want to build artificial gates.

For instance, whenever somebody’s using our purely open-source stack in a large Enterprise, we’re super happy about it because that’s still using us instead of the competition.

I encourage everyone to use RoboCorp even though you wouldn’t be paying for us – that’s all-net positive to us – but just being kind of mindful of where are the gates around paid, what the value is that you’re delivering. It might be things that are sort of not obvious for technical people, like myself, where it’s around governance and compliance, which is a huge hassle for a larger Enterprise customer.

So, understanding what the intended buyer is willing to pay for is one key part of it. And second is, is there really a open-source flywheel that you can leverage, is there a community building on top of your product committing directly to your product, are you willing to take in those contributions as they come in, how do you control a community roadmap for instance? Or is it more like building a component that then gets integrated into other open-source – I mean, there’s so many different pathways that you can explore and kind of plan for us as you go forward.

Closing

Michael: Antti, thank you so much for sharing these thoughts with our audience, and I wish you guys the best of luck in the future.

Antti: Thank you. It was great being here.

Michael: Thanks to RoboCorp for reaching out and the Gluu team for helping me pull this episode together. Cool graphics from Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.

If you’re interested in open source, especially if you are based in Europe, you should check out the State of Open Source Conference in London, February 7th and 8^th – I’ll be there. I’m even recording a podcast live at the event.

So, until next time, this is Mike Schwartz. You are listening to Open Source Underdogs. Thanks for listening.

Intro

Michael: Hello and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is episode 58, an interview with Armon Dadgar, Co-Founder and CTO of HashiCorp, the company behind the Uber successful open-source projects Terraform and Vault.

In addition to writing one of the pillars of cloud infrastructure with over 100 million downloads, HashiCorp IPO-ed in December of 2021, with over 250 million in trailing 12-months revenue.

So, without further ado, let’s just cut to the interview with Armon, and let him tell you about how HashiCorp built this amazing business. Armon, thank you so much for joining the podcast today.

Armon: Yeah. Thank you, Mike, pleasure to be here.

Common Theme Of Products

Michael: HashiCorp has a number of great products, and we could probably fill three thirty-minute podcasts just talking about Terraform, Vault and Consul, but at a high level, what’s a common theme of business problems that these products solve and how do they fit together?

Armon: All of them are coming motivated ultimately by the same problem, which is, how do we actually build modern applications in a cloud environment. It sounds like a simple statement, but once you double-click into that, there’s a reason we have so many products. It’s really looking at, “Hey, if we think about what it means to build a modern cloud application, we want it to be automated in the delivery end-to-end, and we want to bake in security-by-default. We’re sort of changing our application architectures to be much more sort of microservice or smaller units rather than they become monolithic applications.

And so, once you sort of bring all those requirements and you end up with a whole bunch of challenges around, how do I provision that infrastructure, how do I secure it, how do I connect it all together, how do I deploy and manage the runtime of those applications. So, collectively, that ends up being the focus of our broader portfolio.

What Is Commercial?

Michael: I was reading the S-1, there’s a great sentence that describes open-core where it says, “We sell proprietary commercial software that builds on our open-source products with additional enterprise capabilities.” What are some of the examples of those enterprise capabilities?

Armon: Sure. I’ll just pick one product to make it a little bit easier. If we’re talking about our Vault product, as an example, you know, the open-source version really designed around kind of a single-data center, single-deployment use case, if we look at the enterprise features, there is a whole class of them just based around things like multi-data center.

If I want to do replication of my data across multiple data centers, if I want to be able to do a horizontal scale out from just one active node to multiple active nodes and do a sort of a horizontal scaling, if I want to do a disaster recovery sort of a replication, where I have a different hot/cold set up effectively, where I have our hot/warm I should call it, and have a different site that I can flip over for disaster recovery purposes. It’s all of those different kind of capabilities for us, sort of classified enterprise, but you have to have a license too. And that’s why we sort of describe that assignment as open-core approach.

License Enforcement

Michael: With open-source software customers get used to deploying it without any license enforcement mechanism, are you using license enforcement for the enterprise distribution? If you are, how’s that going?

Armon: Yeah. The enterprise binaries for us do require a license. We’ve tried to make it super easy so that operationally it’s not a big lift, as people go from open-source enterprise. So, effectively, you swapped open-source binary for enterprise binary – it’s configured the same operates the same.

And then, alongside the binary, you basically put the license file there. And then, the enterprise version autoloads the file. So, it’s really meant to be a very low lift in terms of doing the transition between them, but we do have a license file and it doesn’t force some level of what’s the term of your license, what’s the maximum number of entitlements. And that’s baked into the license.

Tension Between Free and Commercial?

Michael: Is there ever any tension in the product team when you think of a new feature about whether there should be an open-source feature or a commercial future?

Armon: Occasionally, I think one of the things we did early on, HashiCorp history was to articulate the framework on how do we think about what is open source, first what isn’t. And so, for us, the delineation has always been “if it’s a feature that enables our technical practitioner”, meaning, you’re the end-user of Terraform or Vault. And this feature is kind of core to that workflow of the problem you’re trying to solve with the product. Then, it really should be open source. The tool shouldn’t feel like crippled in any sense to the end-user. So, whether you’re managing one VM or a million VMs, great, it’s not scale limited, or crippled in any way.

Then, on the other side, we have a set of what we call organizational complexity, where it’s really not a feature of an individual user needs. It’s an artifact of running it in a larger organization.

And a large organization cares about things like single sign-on, role-based access control, 2FA, audit logs, security and compliance. Those are not things any individual user would care about, it’s only in the context of an organization that you run into those requirements or those challenges. So, those more cleanly fall into what we would consider enterprise capabilities.

Because we have this framework, by and large most features are pretty clear – it kind of falls into one bucket or the other. Every once in a while, you sort of get that tension of a feature, where it’s not entirely obvious which bucket it should go into, then, it turns into a bit more of a discussion. But for the most part it’s usually clear-cut.

Accounting For Support V. License

Michael: I was looking at HashiCorp FQ, and I noticed that you break out revenues by category and support was roughly three-quarters of the revenue. And I’m wondering if you have customers who are using enterprise features? Is there something about the support subscription that is easier to mark it, or why is that?

Armon: Yeah. It’s a super common misconception when people look at our public filing. And this has to do with sort of the vagarities of 606 accounting rules. So, certainly I’m not an accountant, but at a high level effectively, we sell one product. We sell an enterprise subscription to our software. That has support included. We do not sell support separately. You can’t buy an open-source only support license from us.

So, the disaggregation that you see between a license and support line, whether it’s on our 10-Q or 10Ks or S1, is purely a sort of accounting artifact forced by 606 rules. We’re forced to make some determination on what’s considered license and what’s considered support. And that assessment is actually done by a third party, by PWC for us. So, it’s entirely strange accounting artifact. You actually have to add those two-line items together, because, effectively, we only sell one thing, which is an enterprise skew, and those two-line items are combined.

Market Segmentation

Michael: You know, infrastructure product, that’s very horizontal and has practically universal appeal. It can be both a blessing and a curse, because when your product appeals to everyone, who do you actually market to or sell it to?  Does HashiCorp segment the market, and if you do, does that lead to any schizophrenia for the marketing teams or any of the other teams?

Armon: This is, I think, in some sense the best question. And I think if I could know what I know now and go back to founding HashiCorp again, the most valuable lesson I think I’ve learned — if I go back to early HashiCorp, and you ask me the exact same question, I would have said, “No. We sell to everybody. Everybody is our customer.” What we learned is that that’s a mistake. If you say everyone’s your customers, kind of the same as a nobody’s your customer, frankly.

Because the buying motions, what people want, how you would actually build a go-to-market team, are completely different between saying “I care about the Global 2000.”, the world’s largest enterprises, and “I care about the long tail of SMP.” We have almost nothing in common, frankly, from a go-to-market perspective. So, I think early on, we tried to do both. I think we quickly realized that that doesn’t make any sense.

So, it was really a kind of early 2016 that we made the decision to say, “You know what, we’re going to focus on enterprise as our initial segment.” So, we did split the market and we effectively said, “It’s the world’s Global 2000 top organizations. That’s who we care about from a commercial perspective.” Because that’s going to then tailor what are the products for building, what does our pricing and packaging look like, who are we hiring for a sales and marketing teams. And so, that was roughly our focus from call it 2016 until late 2020, early 2021, when we started actually building a separate commercial focus team to go look at that long tail.

And I think what I tell a lot of founders that I advise is, “Yes, in the fullness of time, you can do both.” Yeah, today HashiCorp does both, but we’re also at over 400 million in revenue. So, it’s a different place to be versus when you’re at zero. You don’t have the people, you don’t have the resources to be able to focus on both those segments at the same time.

And realistically, if you look at even companies like Datadog, at the time of their S-1, they were almost entirely focused of the long tail of SMB. They had very little enterprise customers.

If you look at the number of customers paying over 100,000 dollars is relatively very low. And it was really only post-IPO that they built out a team to go focus on that enterprise global segment. I think there’s an important lesson in there, which is, whether it’s Datadog focused on SMB first, up till their IPO or HashiCorp, where we focus on enterprise up to our IPO. You know, it’s very hard as a startup to do both of those at the same time.

Vertical Segmentation

Michael: Even enterprise is a broad market. I’ve noticed a lot of zero trust marketing. Do you break out even the enterprise segment a little bit more?

Armon: Yeah. Even with an enterprise, we think about it across sort of a — to some extent both a regional split as well as a vertical split. So, by and large, our business today is 85% North America.

We have obviously a small footprint in Europe, and an even smaller footprint in Asia, but we’re very North America heavy. And then, relatively light footprint in certain verticals. We’re over I think certainly the verticals that are more called cloud forward is where we focus.

So, in the early days that was Financial Services, Media, HITEX. Overtime, Retail and Manufacturing became a part of that. Now, I think you have some of the laggards, which is probably energy, aerospace, defense, public sector to an extent. So, some of those I think are just starting their cloud journey versus maybe the financial folks who started it back in 2016.

Distribution Channels

Michael: A lot of times, I asked a question about distribution channels, but HashiCorp has such a dominant position in open source. I almost have to ask it in the opposite way and say, are there any distribution channels other than open source that really are important to you?

Armon: Probably not, to be honest. Probably not. And I think the majority of our business — certainly it starts with open source, but I tell you, our business is by and large, a direct business, meaning, we don’t really go through channels, or partner to a large or meaningful extent.

And I think that’s actually been a shift in buying pattern with cloud. I think a lot of our customers don’t want to be kind of intermediated. They prefer to have a direct relationship with their vendor. And I think that’s been sort of brought about by cloud to a large extent.

Monetization Strategy

Michael: A lot of companies in the open-source space struggle to find the right monetization strategy, especially to land and expand. Did you get it right the first time or were there some important pivots along the way?

Armon: Oh, man, I don’t think we got anything right the first time. In 2015, 2016 is when we really started to do a soul search for what would the commercial sort of nature of HashiCorp be, and at the time, we have to kind of go back.

There was really no examples of successful open-source companies outside of RedHat. I mean, to a meaningful extent. Everybody else, we were sort of in the same cohort along with Mongo, and GitLab, and Confluent and everybody else. So, we’re all kind of figuring it out. Our view is that there’s only so many pads. Obviously, one option was support and services model. More like a RedHat. And I think the challenge there is, outside of RedHat, it was hard to see that scale.

I think RedHat had the uniqueness of the sheer scale of the operating system market kind of dwarfs everything else. So, it was not clear that you could really make that model work. Then, there is obviously open core. And I think there was a question of like, “Would that alienate the open-source community?” That is going to create sort of too much tension with the open-source model. So, it wasn’t obvious if that would work.

You could go with a SaaS model, but again, this is 2015, and if you’re thinking enterprise is your target customer or they weren’t necessarily ready for SaaS, you know, even in 2022, many of our enterprise customers are not ready for our cloud-hosted service.

So, depending on where you are in the stack, your customers have either more or less willingness for a cloud managed service. And I think the fourth option we saw was some of these exotic licensing models. And again, we felt like is that high risk of alienating your open-source community and really, most businesses want to entertain something like that – it’s kind of an exotic approach. So, we kind of looked at those four. And for us, and where we were in the kind of space of the market, we said, “You know what? Open core feels right to us.” But we did dabble with these different options, we did build early SaaS.

So, actually, for people who’ve been following HashiCorp for a long time, they might remember we had an Atlas product, which was sort of a hosted platform-as-a-service built around our products. We ended up sunsetting that when we decided to focus on enterprise, because it was misaligned to our target customer. So, we tried to SaaS, we actually sold about – in the early days – we sold support around open source, so we did some amount of support and services.
In some sense, we played with all of the different models except for the exotic licensing, but ultimately decided that open core made the most sense for us.

Pricing Strategy

Michael: Sometimes I joke with people that when you open a pizzeria, you know you’re going to sell by the slice or by the pie, and you kind of know what price, but for something as new as the cloud, all of our previous assumptions were hard to use. Like, per CPU. Well, you are spooling up instances dynamically. So, how did you figure out what was the right unit or what was the right sort of way to measure usage in your open-core platform??

Armon: Oh, man, there’s an underlying assumption that we’ve ever figured it out in there. I think pricing and packaging is such an interesting thing. Because there’s always trade-offs with it. No matter what metric you pick, users will find a way to sort of game it. It always gamifies in some way or another. I think it’s almost finding the least bad is how I think about it. They all have weird trade-offs.

I think with each of our products, we’ve sort of gone through multiple iterations of, is it licensed by the number of users, is it licensed by the number of applications, is it licensed by the number of resources under management. Like, CPUs might be a good example. I think we’ve licensed by the number of requests you make, like API request.

I think we’ve sort of played with all of these. Ultimately, I think, if we pull it back to sort of what are the philosophical goals, I think what we want to achieve is a few things: one is, you want a pricing model that scales with the value our customers are getting out of it. Meaning, I don’t want if my customer 10x-s their usage of it but my licensing stays flat. Otherwise, it’s not a fair exchange of value.

Two, you want the license estimation to be relatively straightforward for your customer. Meaning, when you’re going through an enterprise sales cycle, you don’t want them to have to guess, “Hey, how many API requests do you make within a 200-millisecond bucket on this time, on Tuesday, with your peak traffic??” That’s a very difficult thing for a customer to try and estimate in any meaningful way, to be able to have a sales conversation.

So, those kind of pricing metrics tend to be bad because they introduced a lot of friction to the deal, versus if you said, “Hey, how many users do you think you’re going to have on this?” “Or how many applications do you think would be using this?” That’s a much easier thing for the customer to actually go estimate.

I think once you start to say, okay, we want something that scales roughly linearly with the customers value they’re getting out of it, and we want it to be something that is reasonable for them to be able to guesstimate, as part of a sales cycle, and that they feel is a fair trade of value, those end up being kind of the guiding philosophy. And then, I think “per product” ends up being a slightly different answer for us just because we have a broad portfolio.

MPL License

Michael: I was looking at the Terraform, GitHub – I read the license. I saw that you, actually, personally checked in the license in 2014. And it’s a Mozilla public license 2.0, and it hasn’t changed since 2014. So, I’m wondering if you could share what are some of the reasons you chose that license and how’s it working out?

Armon: Yeah. It’s a great question, and we often get questions about it. So, in some sense, our goal was, we always wanted something super, super liberal rights. Our initial instinct was actually to use like the MIT or BSD licenses. Something that’s basically kind of a “do whatever you want, no warranty is attached.”

Back in 2013/14, we talked to our lawyers, we’re like, “Hey, we want something super open, something that no customer is going to have an issue adopting with.” Because they are going to feel like there’s some ickiness to the license. And we feel like BSD and MIT are the way to go. And the advice we got was, “Those are good licenses. Nobody has an issue with them. BUT, from a legal perspective, they’re viewed as a bit ambiguous.”

Meaning they’re not super clear on does this grant access to trademarks. For example, the Terraform name is trademark. Are we granting access to that trademark – yes or no? We have several patents around some of our products. Are we granting access to those patterns – yes or no?

So, they felt like MIT is a very good but maybe overvague. Where MPO is just as liberal, you can do whatever you want, but it’s slightly more explicit that it’s not granting you license to trademarks, or patents, or any of these other things. It’s just a slightly more explicit license but equally liberal. And so, we’re like, “Great! That fits our needs sort of perfectly.”

I think, in retrospect, the piece that’s still unclear about MPO is some of the community contribution. If you’re contributing code to what are the terms and conditions under which you’re doing it.

So, in the meantime, several years after 2014, we introduced a Contributor License Agreements – anyone who contributes code to any of the HashiCorp projects is required to sign a CLA. And the point of that is just to create that legal concept around, “Hey, you agree that if you’re contributing this code, you’re doing it under the NPL license to this project.” Because it’s not explicit enough, I guess, in the sort of existing NPL and existing workflow.

I think, actually, Apache2, in retrospect, is probably what we would have used just because it’s slightly more explicit. It has the contributor license agreement, a sort of like baked into it, and it’s a very, very well understood and well accepted license. So, we probably would have been slightly differently, but MPL has worked out fine for us.

New Products Are Open Source Too?

Michael: You’ve done your part for open source. No one can deny that. So, my question is, what about new products? Now that you’re launching new products, is there are sort of a discussion about whether or not to make these new products open source?

Armon: Yeah. I think obviously our quarterly products -Terraform, Vault, Nomad, Packer, etc. were all kind of — the era was kind of 2013 to 2015/16 is when we introduced the kind of core portfolio of six products. But I think, even if you look at our new products, the ones we introduced in 2020, Waypoint and Boundary been kind of the two, big new open-source projects, they followed in the same footsteps. They’re both MPL, they’re both open-source from day one, they’re both going to follow an open-core sort of trajectory in terms of how we monetize them.

And I think, for us, we talked about this in the S-1, there’s sort of this core flywheel of our business, which is really about sort of winning the practitioner heart and minds with open source. And there is the foundation of how we then build an ecosystem around the tooling, which, then, is how we go and win the enterprise customers.

I think that core motion hasn’t really changed for us, and it really starts an open source. There hasn’t really been a change in our strategy. And sort of in that sense, it’s kind of more of the same, even though our newer products are five, six years after our initial tranche of product.

When Does Open Source Make Sense?

Michael: So, let’s say entrepreneur walks up to you at a party and he says, “I’m working on this piece of software, should I open-source it?” What do you say?

Armon: “Oh, that’s a good question. I actually think the answer is, it depends. And I think what it depends on is, where do you sit in the value chain. And what I mean by that is, I think infrastructure and developer tooling in particular benefits quite a bit from open source.

Because I think that is an area where people want to be able to customize that you’re selling to a highly technical audience. If you think about the people who are the buyers and users of our tools, they’re highly technical, they are Dev teams themselves. You benefit from that effect because they want to be able to customize and contribute back, etc.

Now, when I look at some of these other projects, where we’re going to go creative, an alternative to whatever, Facebook or Instagram, and it’s going to be open source, your target user is my mom. Like, my mom is not going to contribute back to that project. She might be an end-user of it if you’re successful, but she’s not going to contribute. She doesn’t know what GitHub is.

In that sense, would you benefit at all from it being open-source? Maybe, to the extent there’s a community of people who want to work on your company for free and their spare time, sure. But I think in practice, the answer is no, probably no real benefit to that.

I think that it varies quite a bit on who is your customer, what’s the vertical, where do you sit in the value chain. I think the closer you get to developers as your end-user and your target audience, then I think the more you benefit from open source.

Governance?

Michael: Has HashiCorp ever considered moving to a more democratic governance framework? Right now, it seems like most PC back software companies that are achieving high growth have very little desire to give up any control over the product or the future of the product, but there is something to be said for having a governance process, with the ecosystem and the community sort of gets a say. Would that ever be considered?

Armon: Yeah, that’s a great question. I think we’ve considered, and certainly I think there’s a number of great foundations, whether it’s Apache or Linux Foundation or CN/CF, there’s a number of these larger kind of foundation vehicles that you could join. Practically speaking, we’ve never considered it. And I think it comes back to number of reasons. For us, it’s always been that we’ve wanted to kind of have tight control over the destiny of the projects. That’s always been super important to us. There’s always been a reluctance for us to kind of move away, if you will, from the benevolent dictator for life model that I think has served us relatively well.

Tao Of HashiCorp

Michael: I saw Tao of HashiCorp in your S-1, and I was wondering if it’s the first time that the word Tao has ever been used in S-1? And can you tell me a little bit what is the Tao of HashiCorp?

Armon: Sure. We published this document a long, long time ago. I think back in 2013 when we first started the company. And I think what we wanted to do was make really explicit what were the principles that we think about infrastructure management has.

Some of this probably sounds stupid in 2022, but we have to remember the state of DevOps tooling, as we call it today, was very different back in 2013. So, for us, it was a bit of a declarative statement of principles where we said, “Hey, we think everything should be driven by infrastructure as code, for example.” We think everything should be designed around the idea of sort of microservice architectures at the time.

It’s a bit more technical jargon around communicating sequential processes, but effectively, the idea of sort of network agent model with API driven interfaces. And so on and so forth. There’s a number of principles that we sort of outline in there, where immutability is actually a good example, where we talked about kind of immutability.

Today, a lot of these things seem almost obvious. You’re like, “Yeah, things like infrastructure as code obviously, and immutability.” In 2013, none of those things were obvious. Nobody did infrastructure as code. Like, people point and click on the Amazon console. Nobody did immutability.

This was the heyday of Chef, and Puppet, and CFEngine, and people ran config management in production. So, I think a lot of the principles of the time were very contrarian, but we wanted to be very upfront on, “Here’s our views on how infrastructure should be done well at scale, in a disciplined way.”

And by the way, these are the principles around which we’re building our products. So, in some sense, it was meant to be a design ethos for the products themselves. I think people often comment that even other very different products in our portfolio – they all have a common look/feel ethos, and that’s sort of not accidental. They’re all built around the same ethos that we sort of outlined.

Ecosystem

Michael: I’m interested in the ecosystem. I’ve seen for some open-source companies, like, take for example Automatic, the company behind WordPress, that the ecosystem really can be critical. Can you talk a little bit about how the ecosystems evolve and who are some of the most important ecosystem partners, and what open-source companies can do to sort of design ecosystem development into their business model?

Armon: I think actually first ecosystem is super important. I think you know going back to that kind of flywheel we talked about in the S-1, piece one was when the practitioner, piece two was, standardized the ecosystem. And I think every year, internally, when we articulate our company goals, those are our three North Stars. It’s when the practitioner standardized the ecosystem enabled the customer. And so, all of our goals actually derived from those three North Stars on an annual basis.

It’s something that we spent a lot of time thinking about. And I think it decomposes into number of different areas. One is, to your point, from a product architecture perspective, what can we do to encourage it. And I think something we were very deliberate on with our products is this notion of a core plus plug-in model.

If I take Terraform for example, there’s the Terraform core, which is the main engine that does the graph processing, the workflow, all that fun stuff. And then, we have a very well-defined plug-in model with an open-source SDK that allows anybody to basically create their own Terraform provider. And a few hundred lines of code, you can integrate it with pretty much any API you can think of. So, that plug-in model then enables any one of our community members, anyone of our technology partners to go create an integration with Terraform.

Same sort of a thing with Vault, it has a core engine, and then, it has this plug-in ecosystem that allows you to create a plug-in for authentication or plug-in for dynamic secret management, or database credential rotation, etc. And these are all well-defined plug-in interfaces.

So, that is a product architectural decision, where we want to make it simple to create these plug-ins, and kind of keep them a little bit arm’s length from the core, so that you can come in and write this without knowing how Terraform is. You don’t have to be an expert on the Terraform codebase to go write one of these plug-ins. Same with Vault.

Then, on the other side, very early in the company’s history, we invested in a technical alliances function. So, the goal of that team was to go and do exactly standardize the ecosystem. It was tied to that North Star, which is, “Hey, go talk to the critical technology partners, and encourage them, and help them to hold their hand on doing those technical integrations with our products and building that ecosystem around us.” So, that was a very deliberate focus of that team, and we still have a large technical alliances team that does that.

And the third part of your question is then, who are the folks that we really think about as influential. I mean, it goes without saying, the hyperscalers, given the space we are in, so we spent a lot of time with Amazon, Microsoft, Google, Alibaba Huawei, you know, the hyperscalers that you would expect.

And then, beyond that, it’s a very large ecosystem of probably 200, 300 technology partners, obviously not all of them equally important. But, you know, if you think about infrastructure as code, great, how do I have tight integration with all of the version control and CI vendors. Let’s get GitHub, GitLab, Circle CI, Atlassian, etc., who are the key people in that space. And then, for our runtime products, you care about observability.

Okay, so who are the people there? New Relic and Datadog, you know, AppDynamics, and so on and so forth, Splunk, Sumo Logic. I think in each of those categories, where we know our customers are going to want critical integrations, there’s probably the top three to five vendors that account for the majority of that market.

And so, you really want to go spend time with all of those vendors to make sure, great, no matter what product of ours you’re adopting, the observability integrations are already there, the authentication integrations are already there. The version control integrations are already there. You add all those things up, and you end up with a lot of partners that you spend time with.

Challenges For Open-Source Companies

Michael: We’re getting to the end, and I want to zoom out a little bit. What do you think are some of the biggest challenges facing open-source startups today?

Armon: I think one of the biggest challenges of the open-source landscape has shifted a lot. And what I mean by that is, when we started with HashiCorp there, the “incumbents”, if you will, were all proprietary commercial software vendors. And I think there’s a truism when people talk about startups, like the challenge of a startup is always, as a startup, you need to find distribution faster than the incumbent can copy your innovation. And that’s always been true. Because the incumbent, by definition, is going to have way larger distribution than you will. But you are innovating them on some dimension. Naturally, it starts going to be more agile. That’s always been the race.

I think when I look at early days of HashiCorp, the innovation for us was not just on the product. It was that hey, we can get a massive distribution advantage through open source by going direct to our end-users and getting that virality of sort of use. Obviously, there’s always a cat and mouse between startups and the incumbents. And I think the incumbents, to a large extent, have figured out that that asymmetry exists with open-source.

So, whether you’re competing with Microsoft, or VMware, or whoever it is that in your category is your incumbent, they, by and large, figured out that this asymmetry is this. And I think many of them have worked to neutralize that asymmetry. And whether that’s by them embracing open source in some sense. Take a look at the platinum sponsors of the CN/CF, you might notice something – none of them are startups, they’re all the incumbents of sort of the old world.

Because they’ve all figured out that they’re exposed to that sort of asymmetry, and so, how did they close some of those gaps. I do think it’s changed the game a little bit because I think that challenge is now how do you get that distributional advantage, without sort of allowing the incumbents to copy the innovation. I think that’s a real challenge. And I do think it requires a different level of creativity. And I think to a large extent, it’s about shifting a little bit of some of that two more of these cloud services. I look at folks like Databricks and like what are they doing really well.

Yes, it’s open source at its heart, but that’s really not their distribution channel. Their distribution is actually much more power through their ease of use of their SaaS and having sort of a freemium product LED growth model on top of the open source. And I think that’s very different than the HashiCorp approach, circa 2015.
I do think there’s this constant evolution and cat and mouse. And I do think, to a large extent, the incumbents have become aware of that asymmetry.

Advice For Entrepreneurs

Michael: So, personally, startups are an emotional rollercoaster, especially tech startups – do you have any closing advice for entrepreneurs who are just starting on that journey?

Armon: Oh, yeah. It is a roller-coaster is an understatement. Roller-coasters tend only to last a few minutes, these last a decade plus. It’s a hard question. I think the biggest thing is, make sure you’re truly passionate about the space, because there is going to be so many obstacles and so many downs. It’s not going to be an easy smooth ride. And I think what makes it the going possible is that you have to have a sort of a deep underlying passion for the problem space that you find yourself in.

I talk to a lot of founders, they’re in it because they think, “Hey, this is going to be a good space to make a quick buck in or something like that.”
And almost inevitably, they get burned when the going gets hard. Because they don’t actually care about the buck. So, I think if you aren’t truly passionate about it, it can be hard to make it all the way through the marathon. Because it is a marathon, it is not a sprint.

Closing

Michael: Armon, thank you so much for sharing all of this advice and wisdom, and congratulations on HashiCorp. It’s an unbelievable accomplishment. I can’t say congratulations enough, but thanks again for joining us.

Armon: My pleasure. And thank you for the kind words, Mike.

Michael: And thanks to the HashiCorp team for helping to schedule Armon for this episode. Cool graphics from Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.
We are going to publish two more episodes this year. I won’t announce the guest yet, but they’re really fantastic. And if you want to say hello, I’ll be attending the “All Things Open” conference at the very end of October in North Carolina. And I hope to see you there. So, until next time, thanks for listening.