Episode 59 – Igor Farinic, Evolveum: Open -Source Software Vendor in the Identity Management and Governance Space


Michael Schwartz: Hello and welcome to Open Source Underdogs episode 59, with guest Igor Farinic, Co-founder and CEO of Evolveum. For those of you who don’t know Evolveum, it’s a European company based in Slovakia that specializes in Identity Management and Governance. This kind of software is used by Enterprises to provision and manage users and their entitlements within the organization, which is of course critical for security. I’ve known Igor for many years. Right before the pandemic in March of 2020, I had dinner with him and his team during an industry conference.

And I was super impressed with their passion and dedication. And I know that this level of engagement comes only with a great leader who builds a strong culture and mission. So, while Evolveum might not be your typical Bay Area unicorn, I think there’s a lot we can learn from Igor and Evolveum. And it was a long overdue interview, so here we go. Igor, thank you so much for joining us today.

Igor Farinic: Thank you for having me, Mike.

What Is MidPoint?

Michael: For those in our audience who are not Identity gurus, what types of challenges does Evolveum MidPoint help themselves?

Igor: There are so many challenges in that digital Identity security space we are selling. For every vertical, it’s a different story. Most of the challenges are pretty common, so you have to connect your source of data, which is usually HR system. Then, you have to onboard your people, persons and transform them into digital identities, and then do something about those – do some application account and so on. That’s pretty common for everyone.


Michael: So, how did Evolveum get started?

Igor: The previous recession actually, we were out of a job, with Radovan. Radovan is fond of the co-founders. We were looking for new opportunities and we had to develop next-generation open-source Identity Management system, but after some time, the company have been on the product. And we were hit very hard. So, actually, we did not have many options left. After some time, we decided to continue developing the open-source code based at what’s already in place. And actually, we helped transformed that and rebranded it into MidPoint. It was natural for us to remain open-source.

Early Days

Michael: Getting the momentum, or like the starting velocity in something like that, is really hard. Did you have some lucky breaks or some initial customers that it really made it possible at the beginning?

Igor: We were very lucky actually. We had like two or three groundbreaking partners and customers that helped us a lot in the early days. Without them, we wouldn’t be here today. After two years, we ran out of our investment money because we were invested by friends and family, especially out of our own pockets. So, thanks to these partners and customers, we were very lucky to start getting first subscriptions money, we took off and, yeah, we are here today.

Market Segmentation

Michael: So, Identity is such a broad horizontal market, does Evolveum segment the market in any way? For example, by vertical market or use case?

Igor: We are building strong partnership network – that is our primary focus, and we are not segmenting directly, but some of our partners are focusing based on some geographical location, some are focusing on some verticals. And also, some of them on different deployment models. Some partners are building a new product or code product on top of MidPoint.

Customer Profile

Michael: Can you talk about the range, some of the vertical segments that you’re serving – what some of the customers look like?

Igor: I would say we can serve all the verticals. Our partners can serve all the verticals. But there’s segmentation, like in the United States we have very strongly academic deployments. And in Europe, there are more verticals that are covered, banking and financial institution, Academia and so on. And governments as well.

Sales Channels

Michael: How do you find customers at Evolveum? And what would you say are the most effective sales channels?

Igor: Our primary focus is, I would say, inbound marketing. We are trying to produce the best content we can. We are publishing everything for free. We are pure open-source software, so, we do various things in open domain, not only code, but also documentation, and all the content is open.


Michael: So, let’s talk a little bit about monetization. What does Evolveum actually sell?

Igor: Primary subscription. Over the last two years, during the Covid, we have transformed 85-90% of our revenue subscriptions. And this is very good for us because it gives us much more opportunity to produce even more content and even more code thanks to the subscription.

Michael: I guess you’re talking about support subscriptions?

Igor: Yes. Support subscription.

Michael: Some people would say that it’s a challenge to scale that business model
because it’s so hard to find good people, and Identity is really a multidisciplinary set of skills – it takes a lot of time to train. What are some of the challenges you see with the support subscription model?

Igor: Yeah. Actually, the only challenge with a subscription model – you have to move forward and start providing value to the customers to get the subscription from them. And to get to that point, you have to deploy the product. We are happy to have so many partners that actually are doing the implementation work for us. As I already mentioned, we have now almost 90% of the revenue subscription, so we are not doing implementation work. Almost no implementation work anymore. Even older subscriptions are thanks to our partners because they are deploying the product for the customers. And we have decided that we have pre-recorded all our trainings and are providing this trainings to our partners for free to improve the knowledge and speed up the process for implementation projects for the customers.

Open Core?

Michael: Have you ever been tempted, or have you ever discussed any ideas to move to open core, to add some extra bells and whistles in a commercial product?

Igor: Not, not really – we have also made a public pledge to stay open. There were some events in the Identity space or there’s some products that started as open-source and they are moving to goal source. That was the time when we have made this public pledge. And actually, I’m also listening to some of your podcasts as well. These are great for inspiration. And I remember there were some previous that some of the products or the other way around all being open-core and starting to open-source everything.

And actually this is the same situation here: to keep different processes or infrastructure in the company. It’s very complex. It’s asking from us to do everything in public space. It’s much cheaper but simple, and so on.


Michael: What about in the Cloud? You know, the other two big business models that we see most commonly are Open Core and Cloud. And I know at Gluu, I would say, every other year, we had a conversation about a Cloud version of Gluu, but what about Evolveum? You mentioned some of your partners are launching Cloud services. But have you considered launching a Cloud-hosted version?

Igor: No. We are having a very close communication with our partners. We are doing a lot of partners webinars. And we have decided that we will improve the MidPoint, that it will be Cloud-ready. And the partners will take over and they will do the operation of the code version of MidPoint. So, we are somewhere in the middle right now – it’s already code-friendly, very code-friendly. It just needs to focus on their long-run upgrades, updates and so on. So, this is to be a result interest in the next LTS version of MidPoint.


Michael: So, building the community is always a challenge in open-source ecosystems. And I’m wondering, are you seeing any contributions from the communities? And if so, in what areas?

Igor: From the early days of Evolveum, community was very important to us and remains very important. No one is contributing to the core of the MidPoint or codebase, but that’s perfectly fine, because we helped many contributions that are outside of the community core. Like, for example, the community is developing connectors. There are so many connectors out there that are open-source. And I’ve been only able to develop community that is making MidPoint as a platform very strong.

We held translation to 18 different worldwide languages, which is great. We are using Transifex platform to coordinate the activity, and most of the translations are up-to-date with each release and 100% translated. So, that’s great. We are saving a huge ton of money on our own translations here.

I would say also the community management is pretty active. Community managements are our best effort channel for us. Now we are trying to have a community that is not only asking questions but actually helping. And we are motivating our partners to help the community. So, that’s very important for us. We have also written and distributed our own MidPoint Identity Management and Governance. And we have also translated this material and people are contributing improvements, I mean language and so on, to the book as well.

For us, even the subscribers are the community because they are primary contributing the money that is paying our builds. And thanks to them, we can build even better products.


Michael:  Just for my own curiosity, I have a question about the language translation – how deep does it go? Are we talking about not just the interface but also the logs and the documentation? And you mentioned the book – are there any places where the translation doesn’t go?

Igor: All user interface. So, it’s not only end-user facing interface but also administrative interface. There are several thousands of keyboards that are being translated. Thankfully, everyone is happy with the documentation in English that we are providing. So, this is not being translated just for the book. The book was translated to a few languages.


Michael: Okay. I’m curious about how you build the team. What’s the geographic distribution sort of the team at Evolveum? And how do you find people?

Igor: We have many challenges over the years to actually build strong team, but now we are very happy with what we have inside the company. And yeah, there are many, many challenges, but what we are focusing right now on, internally we are using Slovakian language and our market is Czechoslovakia – Czech and Slovakian people.
Internally discussing, if we actually change that inside the company and start
hiring in other geographical locations. But for the time being, we have like 26 people working for us in the company right now. And we are preparing for the next round of hiring. And we will see how it goes. If we start hitting challenges in our market, we are ready to transform and start hiring more internationally.

Competitive Threats / Future?

Michael: What do you think are the competitive threats to Evolveum? Is there anything that keeps you up at night?

Igor: Actually, I have a pretty good sleep. I am happy wherever we are right now. Yeah, there are always challenges that we, as a company, would like to start resolving. Because we help resolve the situation, we have a very stable platform, actually provisioning and connectors are stable. So, we are able to do the basic job, we are also in the Governance.
We can do certifications, we can help get visibility of data, people have access, where and why. And now, we are actually opening new streams – it’s not only Cloud on one front. On the other front, we are experimenting with recommenders for various situations. Then, we also started experimenting with machine learning and so long to bring much more benefit to the community.

Advice For Entrepreneurs

Michael: I think we’re sort of coming to the end. And one question that I ask all my guests is, if they have any advice for new founders. I guess I’d like to add to that, do you think that now is a good time to start an open-source enterprise software company? And if so, what advice would you give to that founder?

Igor:  I would say it’s a great time. I have seen a lot of analysis where open-source products are taking over and actually having a great time. I will tell you it’s a great time to start open-source business. And for us, what was very helping in the past, it was pretty common that everyone was expecting open-source codes for free. But we have very strong boundary with our software – you can download it, you can do whatever you want with the software if you follow the license, which is pretty, I would say, great because it’s Apache license and UPL license. But if you start approaching gaps and would like our assistance, we are very strict that we are not doing services for free.
It was very hard in the early days, but over the time when we became a recognized platform, it improved so much that people are not expecting that anymore. And that’s great.

I would also say that if you compare open source to commercial products, then open source is not free. The expenses for open source are different, like for example, you don’t have to pay for the licenses but you still need to find people to pay to do the implementation and deployment. Someone has to do that operation for the solution. And you still shall pay the support. Personally, I myself wouldn’t go into a production where I’m managing maybe 1,000 or 2,000 Identities and actually don’t pay support contracts. Identity is so important for the business that I wouldn’t use that.


Michael: Well, I’m sorry we didn’t have this conversation earlier because we’ve known each other for so long. But thank you so much for being on the show, Igor. And I’m wishing you the best of luck as always.

Igor: Thank you, Mike.


Michael: Thanks to the Evolveum and Gluu teams for helping me to pull this episode together. Cool graphics from Kamal Bhattacharjee. Music from Broke for Free, Chris Zabriskie and Lee Rosevere. If you liked this episode, don’t forget to tell your friends.
And if you’re interested in open source, especially if you’re based in Europe, you should check out the state of Open Source Conference in London, February 7th, 2023. I’ll be there, and I’m even recording a podcast live at the event.

So, until next, time thanks for listening!

Episode 60 – Robotic Process Automation with Antti Karjalainen, Founder / CEO of RoboCorp


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.


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.


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.


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.


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.


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.


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.



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.


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 8th – 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.

Episode 58: Cloud Infrastructure Automation Platform with Armon Dadgar, Co-Founder & CTO of HashiCorp


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.


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.


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.


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.

Episode 56 – Connecting Web3 Blockchains, Federico Kunze Küllmer, Co-Founder of EVMOS


Mike Schwartz: Federico, welcome to the podcast!

Federico Kunze Küllmer: Hey, Mike, thanks for having me today!


Mike Schwartz: Before we dive into Evmos, tell us a little bit about your journey how’d you get here?

Federico Kunze Küllmer: So, I started in Computer Science and Industrial Engineering in Chile. I did a semester abroad at UC Berkeley where I joined this student organization called Blockchain on Berkeley, and that’s where my journey on the blockchain ecosystem but also in the open-source ecosystem started.

After I graduated, I started working on numerous open-source projects like Tendermint, Cosmos SDK, which powers many of the projects that you can see out there, like Binance, Terra, and the entire Cosmos ecosystem. And now, Evmos, which is a project I’m building.

Mike Schwartz: Awesome. So, the topic of today’s podcast is how we can use DAOs to perhaps provide an alternate funding mechanism, an organizational mechanism for open-source projects.

But before we get into that topic, some of our listeners might not know what a DAO is. Can you help give a baseline sort of definition?

Federico Kunze Küllmer: For sure. DAO stands for Decentralized Autonomous Organization. It’s basically – think of it as a corporative or any association of different accounts that live on the blockchain or through different governance mechanisms are able to decide on certain like outcomes or voting certain proposals at the DAOhaus.

They also have like a common shared address where they can, for example, pull their accounts and their tokens, so they can spend on different initiatives. That’s how you can, more or less, create these sorts of autonomous organizations to eventually fund the different public goods and base-layer infrastructure that you’re providing through open source.

Is DAO Discord Group With A Crypto Wallet

Mike Schwartz: One of the founders of a DAO called “Friends-With-Benefits” has described the DAO as a Discord group with a crypto wallet. Is that inaccurate?

Federico Kunze Küllmer: In some way, that’s accurate. In a way that the crypto wallet is here, was that the important component, where every member of this organization has some shares, so to say, so that they can be long in this organization. So, I would say that’s pretty accurate, where every member of the Discord has some share in the organization.

Tokens V. Options

Mike Schwartz: In a traditional company, let’s say, that most of our listeners are familiar with, you issue stock to team members. That stock is normally issued in the form of options. And those options, even when exercised, are subject normally to a fairly restrictive stockholder agreement. So, in this case, it sounds like you’re saying that the sort of members of the team, instead of being issued stock, are going to be issued a token specific to this project. What are the ways that such a token would differ from the traditional options or a corporate equity grant?

Federico Kunze Küllmer: The main difference here between a token and a share in a company is the immediate access to the liquidity, when you have options for a company that is not publicly listed or is not currently raising a fund, like a funding round. It’s really hard to get liquidity for those options once they’re exercised. So, with tokens, you actually have the opposite. When your tokens are vested, you can start selling them in the open market. I would say that’s a main difference.

On top of that, tokens can also have certain behavior, like, for example, you can create tokens that are vested over certain period of time, or like some tokens that are locked for like one year. Like, trying to simulate a one-year cliff they usually have with options, and so on and so forth. So, it’s actually trying to replicate the same behavior that you have right now with options, but on a decentralized way, and actually having those tokens be liquid.

Token Liquidity

Mike Schwartz: If you get tokens in a DAO, these tokens aren’t necessarily going to be listed on a public exchange, so how exactly would owners of the project tokens get liquidity?

Federico Kunze Küllmer: For example, either you issue these tokens individually to each of the members of the team, so that they can like have different vesting schemes or vesting schedules. So, if you have like an individual joins a company or organization at a given time, you can issue these vesting schedules over time that is publicly available on the blockchain. And you can see the account that says the tokens are being vested over like four years or one year. And then, you can also create these flobots for each of the tokens.

That’s when you issue them individually to each member, and you can also create as you mentioned, like a DAO, that is covering certain rules, where all the shareholders vote to distribute the proceeds or these tokens that the DAO account controls to the different members, according to the different shares they have.

So, that’s like the two ways that you can fund this, as either issue a vesting schedule individually or the tokens individually, or the other option is like have these common wallets, where you create different wallets or proposals, which are voted by each of the members.

Mike Schwartz: Maybe I’m not understanding: if I go to pay rent or buy milk, you know, how do I sell my project token into something that’s liquid like Ethereum or Bitcoin?

Federico Kunze Küllmer: You can do that by issuing the tokens that are native, from the certain project, and usually they were publicly traded on decentralized exchangers or centralized exchangers, like Coinbase or Binance, etc., so you can like actually swap the token if they’re listed. And then, like, thus, bring in some liquidity so that you can trade the token against like another known crypto currency like Bitcoin or Ethereum.

Mike Schwartz: So, what you’re saying is that you could sort of build into these project tokens an automatic conversion feature into something that’s liquid?

Federico Kunze Küllmer: Yeah. Usually, the project doesn’t need to be necessarily the one that is providing this exchange on a decentralized way, but usually rely on other projects that are fully interoperable. If you’re building a specific application, your application can connect to another smart contract that provides this functionality for another digital assets, like Bitcoin and Ethereum, and then you can use that and trade them to fiat, for example.

Mike Schwartz: I see. So, you’re saying that there’s already a generalized token. So, you don’t issue a specific token for your project, but maybe you use a platform that gives you a token that already has the properties. What are some of the platforms that are out there that could do this? Just maybe a couple of examples?

Federico Kunze Küllmer: On Ethereum, the most notable ones are probably Uniswap. You also can find some of the others that are targeting other types. But, yeah, like the main one is definitely Uniswap, I would say on Ethereum. On Cosmos you can find for example Osmosis, which is another platform that supports this.

How To Define The Governance?

Mike Schwartz: You mentioned that in a DAO, you can implement different rules, depending upon the specific goals of your project. I think of that as the governance of the project. It seems to me like it’s somewhat challenging to set up the governance of the project. Where do you start that process? And, you know, while there’s governance frameworks that exist for Discord group participation, are there templates out there or playbooks for open-source projects? And it seems like sort of a difficult problem. And where do you start and how do you define these rules?

Federico Kunze Küllmer: This is a great question. In general, where you can find different governance protocols that are used in these different DAOs, so you can have different types of votes, you can have different type of proposals that you can submit. One is, for example, you can signal certain changes to your community. Like signal certain changes, when I introduce it to your community, how strongly do your community feels about certain topic. And those are, like, just for example, “Do you support us doing this?”

That is actually not caring weight on blockchain itself, but, for example, you can also build some type of proposals that are voted on by every member. You can distribute the tokens from these DAO, or from other community allocated tokens, in order to fund public goods, like open source or other contributions from other external contributors, which has already, for example, like my company was funded through these sorts of like community-allocated grants, through these governance mechanisms.

So, they’re like multiple types of proposals that the community can vote already, and you can find them on Cosmos, which is a Blockchain ecosystem we are in. And on Ethereum, there’s already some smart contracts that support this functionality as well for DAOs.

Mike Schwartz: But digging into it a little more specifically, when you define the governance, are we talking about smart contracts, are we talking about legal documents, are we talking about English explanation of what the rules are for this DAO, or all of the above?

Federico Kunze Küllmer: It’s usually in the set of code, and it’s a smart contract, you would say. And then, you also find another sort of like blockchains that also support governance and the code itself. So, for example, you would submit a transaction with this proposal saying, “I want to fund this team to execute on four different milestones over one year.” And then, this proposal gets voted by the entire community.

And once the proposal passes automatically, because it’s on the blockchain, the governance logic is on the blockchain, it automatically funds the team that was allocated the grant, for example, to complete these different milestones. So, you allocate it automatically, so to say, when the proposal passes..

Allocating Tokens To The Team

Mike Schwartz: It sounds like you’re saying that the measure of work that we’re going to compensate in the smart contracts for is a milestone, but when I look at an open-source ecosystem, what I see is that people tend to think about the developers, but we also have code reviewers and people who do Q&A and write documentation, and Kubernetes Helm Charts, and triage issues and do outreach.

I collectively call all of these contributors like the open-source creators, if you’re going to do one big grant for, let’s say for a milestone, how do you decide who gets what and how do you make it fair?

Federico Kunze Küllmer: Yeah. This is a great topic that is, I think, very challenging. Because there’s always someone that needs to be like continuously monitoring the milestones and whatnot, and then, also, this visibility of these different grant programs.

Some of these open-source creators, as you mentioned, maybe never heard of these ways of funding through development. Usually, sometimes there could be like one single developer that is creating one single library that is like the backbone of these other different projects. Usually, right now, how it’s being implemented, there is these like committee receipts.

So, instead of distributing the funds directly to the grant recipient, it is distributed to a committee that is composed by two external parties that are reviewing these milestones, so they get approved. And then, you also have one member of the team that is receiving the grant.

So, for example, like two out of three of these members of the committee can like distribute the funds. So, it’s more of like a reputation based, where like these other members of the committee send the tokens to the grant recipient.

Revenue Sharing With Developers

Mike Schwartz: You mention that there was a committee that decides how to compensate the team members. I know I’ve heard of some other DAOs that use something like, let’s say, how many Discord messages you post equates to how many tokens you receive as compensation.

Or, perhaps, how many GitHub issues you complete, or how many hours you work. So, is there any way, instead of using a committee, that you can build some other more intrinsically valuable mechanism to track the contribution of the participant?

Federico Kunze Küllmer: Yeah. For example, one way that we’ve dealt with this problem is by creating what we call a decentralized abstract model. It’s basically a marketplace where developers publish their applications. And then, users, by interacting with them how to pay a transaction fee. And developers get 50% of this transaction fee for every transaction.

So, in the long term, it’s creating a sustainable funding mechanism for them. Or, like, your application is more popular and it’s used by more users – they will pay 50% of those fees to your development team. And that’s how we’re trying to get all these projects funded. It’s by actually having like a way for them to get the proceeds from the users that are interacting with the blockchain.

Initial Funding

Mike Schwartz: That’s interesting because you answered my question in a different way than I anticipated, which brings me into an area that I was going, which is, of course everyone wants to get paid. I think of that as the left side of the equation, developers, or other creators, or community members, getting paid tokens. But on the right side of the equation, we need to actually have people giving money, whether that’s fiat or crypto or something. The value has to flow into this ecosystem.

So, the model that you mentioned is interesting, where you’re saying that perhaps the people who pay for the code, a portion of that code goes to the creators in a community. And by the way, I think you still have the problem of how to split that value between these very different creators.

But tell me, well, maybe let’s go in that direction and say, besides this model you thought of, what are some of the other models, why would companies or people want to fund a DAO? In the traditional corporate startup world, we find angel investors or venture capitalists, or strategic partners who put money into our company, when we’re starting a DAO, what’s the equivalent of that?

Federico Kunze Küllmer: I think it’s all changing the model from value capture to value creation. A lot of these open-source creators actually need funding to finance the engineers in the day-to-day operations of the project. The main thing that you can do that is by creating these sorts of DAOs, then fund these public goods, sort to say. That’s why you can find these public goods in DAOs to fund these like open-source contributors.

Mike Schwartz: So, before I can sell my product, I have to build it. It’s hard writing software, you know that. And sometimes, it takes longer than we think to write this. So, a bootstrap model where we’re directing funds from the output of the software back to developers is great, but only after the product is done and shipped, and people are paying for it because it’s valuable. But what about before that? Or how do you get it started, I guess?

Federico Kunze Küllmer: We, for example, our company got funded through this mechanism. We didn’t have any investors, prior investors before, we created our project. So, we have requested – through our governance proposal to the community of another blockchain, which is the Cosmos hub – we’ve requested funding to basically fund our entire team for a year. And that helped us like bootstrap all the necessary funding to create a company, to hire engineers to basically ship the code that we were meant to deliver with this proposal.

Mike Schwartz: Was this a one-off where there was something very specific to Cosmos Hub, or is there a playbook here for other open-source projects? How does that playbook differ?

Federico Kunze Küllmer: Yeah. And this case was something like specific to the ecosystem itself, because our project was going to attract a lot of developers from the Ethereum ecosystem that already knew how to build smart contracts.But if you try to extend this to a more general case, not necessarily funding blockchains or decentralized applications, you can also find different DAOs that can provide this funding in exchange for — I don’t know, like shares.

Because sometimes the main struggle right now of all these projects, open-source projects actually, is how to get funding. Some of them don’t necessarily have a business model, but they’re providing this utility that serves, as I mentioned before, it’s like the base layer so many other projects rely on. I think that through DAOs, you can actually create a lot of funding opportunities for all these different open-source projects that can have like a potential impact, not only in blockchain but in the entire open-source ecosystem.

DAO Frameworks

Mike Schwartz: So, there’s a number of platforms out there for DAOs. The ones that I’m thinking of are mostly built on the Ethereum blockchain. So, things like you might have heard of Aragon, or Utopia, or Syndicate, or XDAO, or Colony, or DAOstack, or SubDAO – there’s a bunch of these frameworks or platforms for creating a DAO. Because to create the technical infrastructure for DAOs, for example, the voting or the treasury function takes quite a bit of work and knowledge about how to build smart contracts and how to build this infrastructure. Tell us a little bit about how you build Evmos.

Did you use one of these platforms or did you build your own platform? And what are your thoughts about some of these platforms for open-source projects, maybe more quickly create a DAO to incentivize their creators?

Federico Kunze Küllmer: I’m going to reply first how we build Evmos. We used a framework for building blockchain, because our project is a blockchain that provides a base-layer infrastructure for smart contracts that are fully interoperable with the other ecosystems. So, we’re expanding on, like for example, in our case, like smart contract interoperability.

So, the framework that we use is not necessarily meant for DAOs but to create your own blockchain. Like, for DAOs, or like these open-source funding communities that want to be created through different DAOs, I think Aragon provides like a great framework for you to, like, one-click deploy of Dao in order to create your community.

Mike Schwartz: It sounds like you’re saying that using a framework is a good idea, but you didn’t go that direction because you are blockchain experts. Is that a fair reading?

Federico Kunze Küllmer: Yeah, exactly. We’ve been working on blockchain for the past five years or so. But if other communities that are maybe not as familiar with blockchain and want to create this, the way to go is using one of these frameworks to build different Decentralized Autonomous Organizations, or DAOs, that provide different options for you, like different voting rights, different threshold for voting, or how much quorum do you need to get your different proposals that you have within your DAO, different voting types and proposal types.

You can even have different thresholds, so to say, to send funds from the DAO out to other wallets and to fund the development. So, yeah, I think these are very flexible, these new DAO tools are very flexible for you to upgrade your own value proposition.

Evolving The Governance

Mike Schwartz: So, we’re in early days of DAOs, and it seems like, even if a project decides to use it as approach, they are probably not going to get it right the first time. How do you make your DAO flexible enough? Or do you maybe give it like an end life and say, “Well, this is what we’re going to do for a year, and then maybe we’ll start a new one, based on that experience.”

What’s your advice on? As this technology adapts and we’re learning so much, how do you do something today, and not totally regret it, like in a couple of months that you should have done this thing or that thing?

Federico Kunze Küllmer: The beauty of these tools is that actually you can add more functionality as you go. I think they’re very flexible in terms of like, oh, you misconfigured something or you want to add new functionality, and these tools allow you to do so.

Mike Schwartz: Great, but there’s tools and rules. And when you set up the governance for the project, you’re setting the rules for your ecosystem. And you changed the goalposts, so your team might not be so happy. So, what are the strategies for sort of, on the governance side, for acknowledging that things are changing and you might need to make changes?

Federico Kunze Küllmer: Yeah. I think like involving your community that is part of the DAO is the first step. Because, trying to push for these changes in a unilateral way is more complicated in the long run because you will be seeing us, as I mentioned before, like value extracting, then value creation. Yeah, then creating value for the entire community.

So, I think like involving your community members is the first step to try to do so and try to get feedback from them. And sort of like, if you feel strongly about a certain rule to be implemented or completely crossing out an existing rule that can be eventually updated, or even deleted from your, say constitution of this DAO. Involving the community on like what decisions you should take and how strongly they feel about, I think is like the first step that you need to take.


Mike Schwartz: In “Friends with Benefits”, I heard them talking about seasons, season 1, season 2. So, does it make sense to sort of like have a contract with your community that says, “Okay. These rules are temporarily fixed, and we will revisit them at a certain point.”

Federico Kunze Küllmer: Yeah. I think of seasons are more of like periods in different governments that we have today. So, like, you have the president that is only for like one period or one season in this case. And then, you can go for re-election. Or you can, in this case, if we were trying to compare this with a season of this DAO, it is like, “Oh, do we want to extend these existing rules for another period and then releasing at the end of the period, or do we want to change them completely, or do we want to change a few of them?”

I think it makes sense to have a certain period where you say like, okay, we’re going to take a step back and revisit like all the things that we made during this period. See how we can improve them over time, if we made any mistakes, how we can compensate for them, and like try to release all the changes that need to be implemented for our community to be happy, engaged and incentivized in the long run.

Are Companies Afraid Of Blockchain?

Mike Schwartz: I was just at a conference and I heard somebody say that traditional companies, let’s say, are still afraid of blockchain. You know, they might say that they’re interested, that they want to research, but ultimately, they’re afraid of blockchain. But have you seen any evidence from companies, or do you think it’s fair to say that companies are still terrified or just don’t understand this whole space?

Federico Kunze Küllmer: I think that like expanding this to companies as well is also very beneficial for the entire ecosystem of open-source, like using blockchain too, like us, as an alternative source of funding for the companies that already provide regular payments or subscriptions to these foundations in order to build support. I would say the main challenge here is, once you have enough builders, or enough companies, or enough projects, like subscribing to these DAOs that provide funding for open-source projects is how do you actually distribute those funds, and how then you prioritize different support, so to say, for features that some company might prefer to include, for their own benefit versus other that is also providing that. I think that’s one of the main challenges.

For example, GitHub is already doing that through different sponsor tears, like the higher amount tears usually have prioritized supports and features. And I think that could be built in a DAO for example, so that you can have like prioritized support from the open-source team to your specific company. And I think if DAO were to be built in a blockchain, that will create like more funding and more, I would say, openness also, for companies to adopt this.

When To Get Legal Help

Mike Schwartz: When we’re just in the crypto world and we’re talking about a crypto wallet and smart contracts, we don’t need any lawyers, because this is completely unregulated world.But when we connect to the real world, especially if we’re going to engage companies, we’re going to need actually some type of like legal entity perhaps. And perhaps we’re going to need to get the lawyers involved. You know, I’ve heard finding lawyers who understand this decentralized token-based crypto world is difficult.

Are we making inroads in this area, and at what point do you think that maybe you need to get a lawyer, to look at whether your project’s use of this new incentive model might need some real-world legal guardrails?

Federico Kunze Küllmer: I think the main safeguard towards — like preventing this sort of like extraction of value from these open-source projects is creating the right licenses. I would say like open-source licenses can also, with the help of lawyers that understand open-source licenses, can already create some sort of defense mechanism for you to prevent these cases. And I think there’s already projects in the blockchain ecosystem that have created their own license, preventing others from just like extracting the value that they’ve created through this open-source code. And then, like framing them as it was theirs, so to say. They want to still be open-source, but at the same time, they want some retribution, or they want some like external support.

So, as for licensing, getting a lawyer there on blockchain licensing, it’s like one of the first things. If you’re building an open-source project for the DAO day-to-day operations, you probably won’t need a lawyer to work necessarily on many of the cases, because you can say that, for example, this smart contract would govern your rules or your constitution of the DAO, but not necessarily have someone like enforce certain contracts directly with each of the members of the DAO, because it’s all decentralized, all governed by code.

Evmos Business Launch?

Mike Schwartz: I think this is the longest discussion we’ve had about underlying technology of these podcasts ever. So, I want to like finish the podcast with talking a little bit about Evmos. You’ve put this playbook into action, and where are you now and how is it going?

Federico Kunze Küllmer: It is going great. As I mentioned before, we got these projects fully funded through the open-source community of the Cosmos hub because Evmos was meant to build the base-layer infrastructure. It is fully open-source, and we built up a library that allows other communities or other teams to build smart contract support for their applications. So, we built this with a community grant, and we finally launched two days ago, on Wednesday, 27th of April. Yeah, it’s going well, very smooth, after having a few hiccups in the past.

And now, like everything is running super smooth, and hopefully, in the next few months, we can focus on smart contract interoperability. And of course, this will be fully open source for the teams to benefit. Because like all the other projects in the ecosystem will be able to connect and interact with smart contracts so that you can have your DAO to create this sort of different sources of funding, was isolated in only a single blockchain, but now, with the infrastructure that we’re providing, that is again open-source, you’ll be able to connect these DAOs with other blockchains and other applications out there.

Are Developers Receving Tokens?

Mike Schwartz: The economic model that you described earlier, where value is flowing back to developers – have developers gotten any tokens yet from adoption?

Federico Kunze Küllmer: The adoption model is basically a marketplace between developers and users. In our launch, two days ago, we introduced incentives for users that interact with the smart contracts. And in our next release, which is going to probably be in two or three weeks from now, we’re going to introduce a fee model that is basically sharing the proceeds from the transaction fees with the developers. That is already fully implemented, we’re only running on some internal test through Q/A process. And it’s going to, hopefully, be shipped really soon.

Developer Education

Mike Schwartz: Did you have to educate your team about this new model? Did you have any formalized education or they were mostly blockchain gurus and they understood all this right away?

Federico Kunze Küllmer: It’s a complete novel way because it’s never been introduced before in the entire ecosystem. Usually, the proceeds don’t go to developers even though you are interacting with their applications on their smart contracts. Their proceeds would usually go into the miners, securing the blockchain.

So, we had to create an internal specification, an internal memo, and architecture decision record from an engineering point of view. And then, like, finally create like a blog post meant for the general audience about this token model, for how to incentivize developers, how to incentivize users through this new model that is completely innovative in the space.

Details Of Evmos Blog Explaining Model

Mike Schwartz: Would you say that that blog post has enough detail to serve as a real playbook or template for other open-source projects to replicate what you need to do?

Federico Kunze Küllmer: Yeah. If you go to https://medium.com/evmos , you can find the blog post about the token model on how  this fee mechanism works to share the transaction fees. And if you go to our documentation under https://docs.evmos.org/ , you can also find the technical specification of how to implement this and how this works at a technical level on the different concept it has. So, then, as an engineer, you can also learn more about like how it works under the hood.

Evmos Governance

Mike Schwartz: Is the governance also defined somewhere where people can say, you know, what are the rules that they set up for Evmos? And maybe I can adopt that for my ecosystem.

Federico Kunze Küllmer: So, we share the same rules as the entire Cosmos blockchain ecosystem. And you can also find some documentation guides, and FAQ is also in our documentation, if you go to evmos.dev, about how governance works, how the voting procedure works, what are the different like governance proposals, etc.

Why Cosmos V. Ethereum?

Mike Schwarz: Cosmos versus Ethereum. Why did you choose Cosmos?

Federico Kunze Küllmer: So, Cosmos, first, is for fully sovereign interoperable ecosystem of applications. So, instead of having to share the same blockchain space, as you find in Ethereum, you can sort of like create your smart contracts in there, and they can interact with them, but they’re isolated in the same machine. And what you want sometimes, as an application developer, is to have your own community, is to have your own ecosystem.

But you want that ecosystem to also talk to other blockchains or to other applications, so that you can like connect, and create value, create different sort of like use cases that weren’t impossible before. So, Cosmos allows you to basically create these applications that are fully sovereign in the sense that they have their own voting mechanism, for their own community, but they’re at the same time fully interoperable with other blockchains in this space.

Cosmos Compromises

Michael Schwartz: A lot of people talk about like the properties of blockchains, like decentralized, fast, and sometimes they involve also compromises. You know, when you get one thing, you have to give up another. Can you talk a little bit about what are the compromises that you make on Cosmos would you say?

Federico Kunze Küllmer: Yeah. So, the main thing is composability, which we solved now with Evmos that we launched two days ago. So, composability stands, like you have someone else builds an application for you. You have all the base-layer infrastructure and you want to deploy just your application, you don’t want to deploy like a full blockchain, which you need to build like, I don’t know, like a business development team.

You need to build miners to run on your blockchain, you also need to create like a marketing team and all that stuff. Maybe you just want to deploy your application and see if other users interact with it. You want this application to also interact with other applications. I think that’s a main trade off.  On Cosmos, before Evmos, you didn’t have that functionality to deploy applications that were interacting with each other. And then, the other thing is developer manager.

I think a lot of developers go to Ethereum, even though their transaction fees are higher, and they don’t have fully interoperability solutions or sovereign solutions like Evmos has. So, they have like way more developers, for example, than you can find on Cosmos.

Advice For Entrepreneurs

Mike Schwartz: Awesome. So, this has been a really great conversation. I know we’re a little bit over on time, and I think it’s such a deep topic. Before maybe to wrap up, if you have some final advice for open-source founders or entrepreneurs out there, what would that be?

Federico Kunze Küllmer: The first thing is to look for different alternatives out there. If they’re not super familiar with any specific project that is funding this, but I think like funding this through a DAO, if you are a small developer, you can easily get like a grant on all these communities to create base-layer infrastructure or applications for libraries that can help these different blockchains. And I’m also available on Twitter for you to like DM me, and we can talk about your specific needs. You can find me on https://twitter.com/fekunze?lang=en on Twitter.

Mike Schwartz: Federico, this has been really fascinating. Thank you for answering a lot of my very basic questions and being so patient, and best of luck with Evmos. It sounds like you’re doing really great work, so thank you again.

Federico Kunze Küllmer: Thank you, Mike. This was super interesting.


Mike Schwartz: That’s it. Special thanks to the Evmos team for helping us schedule and promote this. Cool graphics from Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.

Mike Schwartz: I wanted to get this one out as soon as possible because the business model is so innovative.

Watch your feet for more episodes. We will probably resume next year. I have a list of companies and leaders that I’d like to interview. I wanted to get this one out as soon as possible because the business model is so innovative. Thanks for listening. And please reach out to me via the website if you have any ideas for the show.