Mike: Hello and welcome to Open Source Underdogs! I’m your host Mike Schwartz, founder of Gluu, and this is episode 70 with Patrick Backman, General Partner, CEO and Co-Founder at OpenOcean, and Co-Founder of MariaDB.

This episode uncharacteristically diverges from the normal format. It’s more of a general interview than a discussion on the business model of a specific company. We recorded it a few weeks back on March 1^st. The release was delayed because I wanted to prioritize Kevin Muller’s pitch for attending the Open Source Founder Summit in Paris this coming May.

And if you’re on the fence about the Founder Summit, there’s still time. Last night, I had some barbecue with Frank Karlitschek, founder of NextCloud, and he told me that NextCloud did 80% growth on a revenue base in excess of $10M. So, if you want to find out how we did that, and you have the resources, go hang out with him and lots of other talented founders in Paris at the Open Source Founder Summit.

And, as this is a bit of an unconventional episode, maybe now is a good time to set some expectations for The Underdogs podcast for the next couple of years. My plan is to complete around six episodes per year for the next five years and finish at around 100 episodes.

The 100th episode will be Gluu, and you’ll find out how I was able to put all these years of feedback to work in my own startup.

I’ll be recording in person at FOSDEM, SO-CON and All Things Open. If you feel like your startup should be on the Underdogs podcast, or you have a suggestion for a startup that I should reach out to, send me a message on LinkedIn. I’m always on the lookout.

The other reason I’m slowing down is that Emily Omier’s podcast The Business of Open Source is doing a great job, documenting firsthand accounts from business leaders in the open-source world.

If Emily’s podcast existed in 2018, I might not have even started Underdogs. So, if you haven’t listened to her podcast, you should add it to your queue. And thanks Emily for all the hard work, a lot of logistics preparation and post-production work goes into each episode, so 200 episodes doesn’t just happen without a lot of commitment.

With that lengthy intro behind us, let’s finally get back to the interview with Patrik Backman. He’s a bit of walking internet history. And it was a lot of fun to get an opportunity to chat with him, so here we go. Patrik, thank you so much for joining us today.

Career Overview

Patrik: Yeah, it’s a pleasure, thank you.

Mike: Maybe just for the audience you could tell us a little bit about your background, and how you ended up entering the database business.

Patrik: I started actually out of school, out of university, I got recruited into MySQL, or MySequeL, as they say in the US, in 2003, and then I worked six years as part of MySQL database company. From couple of million in revenue, or almost 100, from 50 people to about 600, and then, in the last couple of years, I was part of the management team, I run a large part of product development, and also some business development.

And then, following the MySQL time, we exited to Sun Microsystems in 2008 for $1 billion – that was a great achievement, at least in the European, so to say, start of ecosystem. Following that, we started exploring how to build a venture-capital business. And parallel with that, we co-founded a company called MariaDB, which is a successor company to MySQL. But since 2011, I’ve been operating as a general partner, together with two other partners with OpenOcean, which does kind of invest in the early-stage data software in Europe.

Years at Sun

Mike: I have a Sun Microsystems’ coffee cup. I’m just curious, as somebody who had actually worked at Sun for a while, if you could talk a little bit about what was Sun like?

Patrik: It was quite a remarkable journey. After being acquired by Sun, I was part of the Sun for almost a year, and also part of the integration kind of tasks force to integrate the MySQL company into Sun Microsystems. But I think there was extraordinary talent around engineering overall in the business – it was of course a huge company – 35,000 people – but extraordinary talent, especially a software team which I met a lot, however, the commercial side was quite awkward to me. At the time, much of the philosophy seemed to be — what I noticed was that software was open-source, and for free. And then, the point was to sell hardware.

So, me coming in, with MySQL and still thinking that, ‘hey, it’s an interesting scaling business, there’s a lot of good ways to make business around open source’, Sun didn’t really have that mentality. And we were quite a lot discussing their how could kind of the commercial side be developed around the open-source products that Sun had and many, many great ones.

But then, I think the business side of that was a bit lacking, and they never really got to build that out – the company almost went into insolvency, or big difficulties, and then Oracle acquired it at a quite low price.

Inevitability of Oracle Owning MySQL

Mike: Do you think it’s somewhat ironic that Oracle, the prototypical commercial database company, ends up owning MySQL in the end?

Patrik: Well, what I’ve heard, and this is just ,of course, a rumor – so, “maybe” what people suspect – but I heard rumors that Larry Ellison always kind of wanted MySQL, to have control of it, because it was so popular and it had such a huge impact in the database industry, in terms of popularity, and in terms of power in the web and internet overall.

So, I think there was even some rumors that Oracle even earlier tried to get their hands on it, so to say, one way or the other, especially Sun Microsystems acquisition. Supposedly, it was much tied to the fact that that way they got control over MySQL.

More restrictive licenses resulting from Foss strip mining

Mike: I want to Pivot to MariaDB. I spoke with Michael Howard in 2018, and he was promoting BSL, or Business Source License, which HashiCorp later adopted also after a billion downloads of Terraform. Do you think that companies moving to these new restrictive licenses is a signal that the industry is standing up for itself, and that it’s sort of growing tired of the exploitive use of its software?

Patrik: Yes, absolutely. I think it’s a clear signal. At MySQL, 15 years ago, there was this — maybe today it seems naive thinking that ‘hey, if AWS, for instance, and Google, and Facebook use a lot of MySQL, somehow it will drive a commercial relationship down the line’, which is kind of beneficial to both parties and grateful for everyone.

However, it never really got there. It turned out that nowadays AWS has millions of these installations for their customers, and making a lot of money on them, but still paying really nothing for it. So, it has been clear that big players out there, they really want to use open source as far as they can for free, but themselves making a lot of money on it.

As this has become very evident that money will easily come to this popular open-source platform, then the restrictive license is what you need to go for, so to say. You need to be smart about your licenses so that it drives things to your business needs. Then, a question comes up, of course, for founders out there: what is the business need and the business ambition that the founder has, and different licenses serve different business models.

What is the best open-source license?

Mike:  So, let’s say I invent a new database called PigeonDB, and I want to license it somehow. Well, MariaDB used BSL licensing. Did that work? Like, what license should I use?

Patrik: As a founder, if you want to build a small kind of services business, you can use a free license as you want, very permissive. In that way, it gets maximum popularity, and spread, and awareness and adoption. Then, you can sell some support, or some fixes, or some advisory, or consultancy to users out there. And that’s a good business. You can even hire a few people, maybe tens of people, making even a few millions a year, and that’s a nice lifestyle business. That is a perfectly safe and good choice to make.

However, if you want to do more of a product-oriented business and earn licenses, or earn kind of product revenue for your product, then you need to have some restrictions on that distribution that you have. And I think that MongoDB is a perfect example of that. In popularity, I think MySQL and even MariaDB might be even more popular than Mongo. However, Mongo is making much more money than MySQL or MariaDB for that matter. So, having a restrictive license that prevents, so to say, kind of AGPL preventing the big player from just kind of hosting their own service database services and taking all the money for it.

Do we need a new open-source movement?

Mike:  Bruce Perens at State of Open mentioned the idea that maybe we need a new category of licenses. Do you have any idea if we did, what that would look like?

Patrik: I don’t know directly. I think there’s a good variety of licenses, and of course, one could always write their own, so to say, business source license is a new one created at MySQL and used at MariaDB. What open-source movement kind of have tried to do, or have done for 30 years, is collaborative work around software – it’s mostly the licenses have focused on one downloadable kind of software package that you take and install, and use kind of standalone, or in a combination with other software.

Now, most companies around open source, and also elsewhere, are making money by providing a service online. So, it’s a software service online, a cloud service. And somehow, it’s interesting that, in my mind, there’s a lot of enterprises combining open-source software, using it in their cloud setting for their own needs, but this glue – how they put things together, how they manage it, and so forth – this glue is typically proprietary.

Either they make it themselves, buy some proprietary by someone else, or buy this glue, so to say, from others, and somehow, an openness on this kind of glue between software and how it’s used in a cloud setting, maybe there could be some open-source movement on that. But that probably requires a whole new way of thinking. This is just an early thought, but something I’ve been pondering about.

Is Open Source a Tragedy of the Commons?

Mike: We have a professor here at UT Austin, who’s compared open-source software to a tragedy of the commons. Typically, in a tragedy of the commons, there’s a “freeloader problem”, where the freeloader is causing the degradation of the resource. I kind of argue that, well, what if the resource here isn’t just the software – because there’s no incremental cost to copying the software – but what if the incremental cost is actually maintenance of the project. Because for infrastructure projects like databases, what people really want is a stream of updates to the dependencies.

So, I’m wondering if you could sort of comment on the idea of like, is this “tragedy of the commons” analogy useful, and how do we avoid freeloaders?

Patrik: I mean, it’s built into the model that is open source. If you provide it with a permissive license, then people can use it for free and take benefit, and even maybe in a business way, in a wrong way so to say, take benefit of it, and so forth. But I think what should be recognized, and understood, and respected is that, indeed, anyone building software, even providing a free and open-source software, they should be allowed to have a credible and sustainable business model in order for them to be able to maintain and further develop it. But, then, it’s about what kind of balance you want to strike with what is free and what is commercial, and that’s where the license comes in.

Can the Government Help Fund Open Source Infrastructure?

Mike: There’s over four million open-source projects now. If you add up all the packages, and the repos, and especially the MPM repositories – excluding GitHub, who knows what it is if you include GitHub – there’s so much diversity in open-source projects. It seems like what you’re really saying is not that open source in general should have a business model, but certain types of infrastructure.

The government, let’s say, was going to fund open-source infrastructure to sort of address this freeloader problem – how would they know which ones to invest in?

Patrik: I don’t really know if that can be steered by government, or by any kind of regulating body, or any smart individual in that sense. I believe in the free market that there’s a lot of people can develop, and release, and provide software under different licenses and commercial models, and that it can be free or commercial, or closed-source or open-source. But in the end, it’s up to anyone in need of a certain solution then to decide what they take and on what premises.

I mean, someone might be okay to take something free and be ready to maintain it themselves, and not care about it if there’s a commercial side to it, or a company behind it, or even a developer behind it. Or vice-versa: someone wants to pay something for strong assurance that it’s managed by a company, and resources, and everything.

Beware VC Advice

Mike: I always caution founders that the advice you will get from venture capitalists is the advice of how do you make this into a really high-growth business.

Patrik: Yes. I could also give advice on how to just get maximum spread in different ways. However, what we, of course, think about as venture capitalists is that we try to find those businesses and help those businesses, or founders, that really want to build something significant in terms of a business and not just in terms of following.

Community Lead Growth?

Mike: What I’ve noticed is a trend towards something called community-led growth, where the company raises a bunch of venture capital. And then, they start an open-source project, and try and find a really devoted group of super fans who love what they’re doing, and then they look for a monetization strategy out of that. Have you been seeing that model more, and do you have any thoughts about is that going to lead to high- growth companies, or is it just a risky investment?

Patrik: Well, it is risky, it can work, but it’s often hard. I think specifically what is hard is that those founders, who are able and skillful enough to create a super-quality software that spreads and becomes open-source kind of very, very popular, the way to make money is often: yes, you can do an open-core model and have some commercial features, so to say.

And there’s a few examples of who have succeeded. I mean, Gitlab, and so forth, have succeeded in building kind of more than 100 million in revenue, but no one has really done with open-core kind of billions in revenue. And today, the way to really make money is by providing a cloud service – that’s what Mongo is doing very successfully, and many others.

And to build the challenge for those founders who create a very popular software distribution, kind of open-source software distribution, the mentality, and mindset, and skill set for building a cloud service is very, very different from building a great piece of software that you provide for downloading open source. So, often, the challenge is, and the risk is, how do you bring in that skill if you want to build a very large business.

Should Governments Use Open Source?

Mike: Patrik, you’re in Helsinki in Europe, and there’s a lot of innovation towards let’s say driving digital public infrastructure in the government. Should the government use open-source software, and how should the government consume and procure open-source software?

Patrik: That’s a good question. I think that open source really matters in infrastructure – to go back to the Oracle example, I think what enterprises, but also governments, should think about when it comes to infrastructure, you don’t really want to rely on something, like, a core piece of your infrastructure, where the provider can come every year and ask for 20% more in pricing, and you have no way to circumvent that.

So, a critical piece of infrastructure is, you shouldn’t have a lock-in closed-source component and the company that can squeeze you behind it. So, for infrastructure, it really matters, and then, how they should procure it – there’s always this software kind of service providers consultancy houses that still are needed to kind of sell it, in this way or another.

Yes, maybe the pieces can be free, but someone needs to help glue it all together, and help serve it, and help support it, and so forth. I think the biggest problem really is not in the nitty-gritty details of how government should buy these things, but actually in having a smart, technical person who is skilled in this kind of software, who knows what they’re doing.

Most things that could go wrong in my mind, when government buys software, be it open-source or closed, is that there’s incredible stupidity in the world – they try to, without really understanding the software, they try to do a long list of requirements. And then, the big software house, with maybe 20-year-old software, is the only one who has the resources to really answer all those zillion questions and come up with a packaging that serves all those needs. And then, it costs a billion to implement. It’s just crazy that these things happen with public money.

How to get the word out that open source isn’t free

Mike: I bet you’re talking about Western governments too, having challenges in operation of IT. How do we help all these other governments who want to implement, and we’re telling them to use open-source, but how do we communicate to them that we also need updates of the software, we need maintenance, and we need innovation in order for them to really make these ecosystems work?

Patrik: I must say I don’t know how to inform them, but this notion of “things should just be free”, yes, it certainly exists out there, and most companies want everything to be free, and the government. However, inside IT people understand that nothing is free – you need maintenance, you need support, you need help, you need people around any software to operate, and run it, and of course, improve it, but how to inform and educate people, it’s a good question that I don’t know how to answer.

Is now a good time to start a software company?

Mike: Last question, is now a good time to launch a software startup?

Patrik: Well, absolutely. It’s just tremendous what opportunities are out there. I think we have only scratched the surface of what data software can do, for instance, in all enterprises, in all businesses, in all functions, and probably in society, there’s processes and functions that can be digitalized, automated, optimized and improved. We’ve only seen the beginning of that. And of course, with hyper on AI, it’s a much broader thing than that.

It’s like everywhere in business, in functioning governments, in society, you can start tracking data, gathering data cheaper than ever before, put it together, build algorithms around it very easily to get intelligence out of it, get predictions out of it, get things optimized and automated – I think it’s very fascinating how the world can be improved in so many ways, using software in the future, and in the near-term actually. I think it’s a great time right now to think about wild ambitious ideas and work to implement them.

Close

Mike:  Patrik, thank you so much for joining and sharing all that experience with us.

Patrik: Thank you so much. It was really a pleasure.

Mike: And thanks to Alexander Izza from Resonance Public Relations. Cool graphics from Kamal Bhattacharjee. Music from Brooke For Free, Chris Zabriskie and Lee Rosevere. Next episodes will be recorded at the All Things Open Conference in downtown Raleigh, October 27th – 29^th, 2024. This is one of the best open-source conferences in the US, so please join us if you can.

Until next time, thanks for joining.

The post Episode 70: Early-Stage Venture Capital, OpenOcean, with Patrik Backman first appeared on Open Source Underdogs.

Mike: Hello, and welcome to Open Source Underdogs! I’m your host, Mike Schwartz, Founder of Gluu, and this is episode 69, with Kevin Mueller, Founder and CEO of Passbolt.

Passbolt helps teams securely share secrets, which could be passwords, API credentials or cryptographic keys. It’s one of the few open-source projects in the privileged access management category.

I had the honor of meeting Kevin at FOSDEM in Brussels, although we recorded this episode remotely on Zencastr, auspiciously on the ides of March. So, without further ado, here’s the interview.

Kevin, thank you so much for joining us today on Open Source Underdogs.

Kevin: My pleasure.

Founder Summit

Mike: Before we start the official podcast, I see that Passbolt is one of the sponsors of the Open Source Founder Summit that’s coming May 2024, in Paris. Can you say a couple of words about the event?

Kevin: Yes, absolutely. This is an event that we are co-organizing with Emily Omier. We decided to co-organize this, and basically, to make this event happen. Because we realize that in the open-source world, a lot of funders are not talking to each other. And we basically go through the same hardships, we have the same difficulties, and some of us have some learnings that others don’t. And very unfortunately, and I don’t know for which reason, open-source funders tend to do their own things and not to speak with each other.

So, this would be a fantastic opportunity to put a bunch of open-source funders in the same room and talk very honestly, transparently, without having the need to sell their business ― it is basically open-source funders with open-source funders ― and talk about the hardships they are going through, talk about the problems, the solutions they found, in a very transparent and good atmosphere.

This is the purpose of the event, and I have to say that it’s going quite well. We have already sold all the early-bird tickets, and the event will be happening in May, in Paris. And from where we are, it looks like there will be at least 50 open-source founders in the room so far. So, it’s quite promising.

FOSDEM

Mike: Awesome. So, pivoting back to the podcast, a question for you: did you attend FOSDEM as a student, or as a young person?

Kevin: Yeah! It’s a really good question! I think the first edition of FOSDEM I participated into was ― let me think, in 2000, and I was still a student back then. And I think FOSDEM for me was like Meka of open source, and it was such a privilege to go there. I remember, when I first presented at FOSDEM, we met with the Richard Stallman, Maddog was also there, so, yes, definitely, I started going there as a student.

Origin Story

Mike: How did you go from an attendee of FOSDEM to a founder of an open-source software start-up, and did giving out free swag at FOSDEM this year bring it full circle for you? Or was it more like the “lunatics are running the asylum now”?

Kevin: That means it is very pleasant now to participate at FOSDEM as a founder of an open-source project. I think we went a long way from an open-source enthusiast, when I was a student, to being an open-source founder. Basically, the story is, I’ve always been an open-source enthusiast, not only me, but me and my co-founders.

And my first open-source project was, I think I made it back then when I was 16 or 17 years old. It was a PHP script to browse a file directory but installed as a web app on a server. And it found a bit of adoption back then, I kind of forgot about it. I started my entrepreneurial journey quite early in my life. It happened that, at 23 years old, I stepped in India for an internship. And then, I didn’t leave India for 15 years. And the reason why I didn’t leave is because, when I stepped there, I realized that there is so much potential in that country – everything had to be done.

And I decided to create my first company over there. My first company was a web agency, and we were basically developing web projects or web-related stuff from India, but for French-speaking companies, because I’m French ― you’ve probably figured it out from my accent. And the point that French-speaking companies had with Indian outsourcing is that in India people don’t speak French, and French people are terrible in English. So, even though there was a lot of hype with outsourcing in India, these two could not collaborate with each other. That was the purpose of my company.

And the positioning was quite spot-on because there was A LOT OF French companies, trying to outsource to India at that point, which means that very quickly, we were able to grow the company, and we went from me alone to Remy, which is my current co-founder at Passbolt, who also joined me in this venture, and we grew all the way to around 75 people in the company.

We ran a bunch of other things in India: we created three companies in total. One was also a product company, where we were teaching French online ―very few people know that, but French is actually the first foreign language that is spoken in India, because English is not a foreign language.

We had launched this platform, it became quite successful – we had a few hundred thousand of students that learned French with our platform. And it kind of gave us the taste for building products.

As you can see, none of the things we are doing are related to open source. But when open source came back in the picture for us was actually when we were growing our web agency. Inside the web agency we were developing, we were working with a lot of different customers, a lot of different projects. And one of the pain points that was occurring all the time was the password pain point. So, typically, whenever we are onboarding a new project, the first thing that the customers would do, would be to give us all the passwords and the credentials that we will need in order to do our job.

And most of these guys would send us these passwords by email, or by Slack, or through other channels, which is quite insecure, but to tell you the truth, we are not that much bothered with security ― we are more bothered about the productivity issues that are related to, okay, the password manager is getting those passwords, then he needs to distribute them to the team. How is he going to do that?

So, we tried a lot of things: we tried spreadsheets obviously, we tried emails, then we tried KeePass. And we really loved KeePass because KeePass is a fantastic open-source software. Very simple to install, all our developers had it, it’s considered secure, it has been audited, it is ANSI compliant, and so we loved it for all these reasons. Also, for the fact that you can organize your credentials, and folders, and subfolders, with granularity. So, you can basically follow the same hierarchy, the same structure as your customer project. But where we were very frustrated with KeePass was with the collaboration – we did not want to share the entire KeePass file with the entire team.

Because this gives security problems, but also it is very difficult to have only one file that scales with different people. What happens in practice is like each person will make a copy of the file and start using it independently, and then you end up having 5 or 6 files that have their own life, with the different set of passwords in it, and you don’t have the source of truth any more.

So, Passbolt was built in this context. We wanted a software that has the same properties as KeePass ― basically, that is open source, that is secure, that provides you granularity in a password organization, but on top of that, we wanted a multi-user/collaboration feature.

Actually, the first version of Passbolt was not called Passbolt. It was called absolutely nothing because it was an internal project, and we built it for ourselves, we started using it, and we were really happy with it. So happy that we started sharing it with the customers, partners that were asking for it. And when we realized that a lot of other companies, or people like us, had the same problem, this is when we decided to make a separate project out of it.

And one of the reasons why Passbolt is open-source today is because, very early on, when people were asking us to share the project with them, we were not sharing it― very naturally, we gave them the source code, we explained them how to install it. And after a few months, we started receiving emails from companies who had never heard of us, people in the US, people at the other end of the world, were pinging us for feature requests, or bug reports, and then we realized, “Okay, my God! There is a bunch of traction behind this thing. People are really talking about it. And because we were already sharing the source code, we decided to keep doing it and keep it open source.

Positioning

Mike: So, there’s a lot of password managers out there in the enterprise space, how do you position Passbolt as a product that’s selling to enterprises against all the other options that are out there?

Kevin: I would say this goes back to the origin of Passbolt. The reason why we built Passbolt the way it is, is because we are a technical team. So, the first version of Passbolt as a password manager was basically the password manager for technical teams first. And even today, the way Passbolt is used it is usually adopted by the technical team first. And they adopted it because of three specific aspects of the solution that are really important to us.

The first aspect is collaboration. In Passbolt, you can share passwords very quickly, instantly. With two clicks, you can share one password with one user, or you can share an entire folder with a group of users.  And then, there is inheritance on the permissions management system, and then you can audit also your permissions, you can see if there is something weird happening with the sharing, or password that has been shared that should not be shared ― all this is what I call the collaboration layer of Passbolt, which goes much further than most of the other solutions in the market.

And actually, technical teams enjoy a lot of these aspects, because technical teams are the ones we need to share passwords on a daily basis. And they need to share passwords because they are managing a large number of systems. And it’s not always possible to create one account per user ― actually, it’s almost never the case. You end up sharing the server accounts, or any type of credential you have with other people from your team. And you need to do it fast, and you need to do it securely. So, this is what Passbolt does for you on the collaboration front.

And the two other pillars of Passbolt are basically security and privacy. One of the problems of the existing solutions in the market is that they were initially built for a consumer. If you look at 1Password, if you look at Bitwarden, if you look at many others, including LastPass, the first version of their software was not for team use, or it was not for enterprise use. It was a consumer application, very monolithic ― basically, how can I help end-user open the vault, put this password in it, close it, and then access their credentials when they need it. And they are doing this extremely well.

But then, later on, they realize that, okay, of course there is a market in the price segment. So, a lot of these solutions built their Enterprise layer/collaboration layer as an afterthought. And the result of that is a clunky synergy between the collaboration and the security part of the software. Most of them had to do trade-off on the security. And because Passbolt was built to be enterprise-ready, from the ground up, we could really give it a lot of thought about the security model.

Typically, one thing we decided from the beginning was that the solution should be fully end-to-end. Another thing that we decided was that it is not enough to have just a username and a password to sign in on the solution, to basically authenticate, or to encrypt data ― we decided that no, we need a private key, we need a separate private key on top of the username and the password. And it’s a bit similar to what the crypto ledger’s solutions are doing. Or for example, MetaMask – if you want to connect to MetaMask, you need to have a separate private key that you import in the extension.

We wanted a similar security model, and this is what we did. The security model of Passbolt right now is based on the private key. This is the second pillar. And by the way, this is why we are getting a lot of traction, with a lot of privacy or security conscious organizations, such as national security agencies, or governments – a lot of them are telling us, “Yes, we are choosing Passbolt because you guys are the only ones with this type of security model that is fully aligned with our enterprise requirements.”

And the third pillar of the solution is privacy. Privacy means a lot of things. And I would say open source is included in this privacy pillar. It is the capability the solution gives you as a user, or a customer, to control your data. So, with Passbolt, you can self-host the software yourself, you can download it, install it fairly easily. We have a lot of Linux native installer packages. Basically, you can install it on Debian with apt-get, we are compatible with RedHat, we are compatible with most of the Linux distros there in the market. We are Kubernetes ready, we are providing Helm charts – we make it very easy for you, as a developer, to install it on your server. Then, obviously, the code is open source. So, no need to mention that, but anyone can audit it.

And this is important for a lot of software. But when it comes to cyber security, this is probably where it’s most important. Because it’s not enough to say, “My software is secure.” You want to make sure of it. There is nothing better than open source to prove that, “Yes, your software is secure”, because it’s not only you auditing it ― the entire community is auditing it. That’s how we ensure the privacy pillar of the solution.

Monetization

Mike: What’s the monetization strategy?

Kevin: We have a several type of customers. And I would say, with Passbolt, everything starts from the community ―we have Passbolt CE, as Community Edition, which is, in a way, Freemium, because in open source, it’s not as simple as that. It’s basically your free software that is, free (as in free beer) and free (as in freedom). So, anyone can download Passbolt CE, install it on their server, and start using it. There is absolutely no tracker, we do not ask any questions, we do not know what people are doing with the software ― we just know that they are using it.

So, as of today, on Passbolt Community Edition, we have around 300,000 daily active users. And that’s all we know about them ― we just know their quantity and nothing else. Basically, what’s happening is, because Passbolt is built for collaboration, the people downloading and using Passbolt Community Edition, they are using it at work, not for personal reasons. Because it is not B2C solution, it’s only B2B, only made for teams and businesses.

What’s happening, very organically, is, that once they install it, they start inviting other users, and very quickly, they go from 5, 10, 20, 50, 100. A lot of them will remain at maximum 5 to 10, or 20 for the small teams, and that’s completely fine. But a bunch of them will actually scale their usage. And once they reach 100, 200, 500 users, then their requirements become a bit more sophisticated.

For example, at 500 users, you might want to have SSO in your solution to a Single Sign-On, because it’s a nightmare for all our users. And it will give you support if you do not have an SSO plug-in, or you really want to connect the solution to an active directory, or to any type of directory, in order to make the provisioning easier for your users in your groups. Or maybe, you will have more need for compliance, in which case, you will need to generate more rapport from the solution, or to export your logs.

So, all these features are basically plugins that we are selling in the paid edition of Passbolt: we have two paid editions, we have Passbolt Pro, which is the paid self-hosted version. It is the same thing as Passbolt CE, but with more features, more enterprise features and also Premium support. Basically, they have someone to talk to in the case things go wrong.

And then, we have Passbolt Cloud. Passbolt Cloud is the same as Passbolt Pro, which is basically Passbolt with more features, but designed for people who do not want to do self-hosted. Or maybe, sometimes they have tried to self-host, and they didn’t manage to do it. Then, they’re asking us to do it for them. So, these are two products. The product currently, the paid product that has the most traction for us, is the Pro Edition.

Open Source vs. Commercial Features

Mike: Well, I think you already covered what’s open source and what’s commercial. But what about in terms of looking at your investment in R&D? At some point, you’ll have to invest R&D hours in building open-source features, and then some of that effort also has to go to the commercial plugins. Let’s say, how do you balance in your organization those investment priorities?

Kevin: Absolutely everything in Passbolt is open source. Even when we build an enterprise plugin and an enterprise feature, it is also distributed under an open-source license. And all license is AGPLV3. That’s the license we use for our source code.

For us, it’s like whatever we do is open source ― it’s not even a question. That’s the philosophy behind the product. And then, how do we decide what goes in the Community Edition, or what goes in the paid editions ― well, we follow a very simple mantra.

We know that people using the Community Edition are usually smaller teams. Because larger teams in larger organizations will want to secure the software from a business standpoint. The way we split the features is very simple: what we put in the Community Edition are features that allow smaller teams to gain productivity in their password management. So, obviously, this includes the security aspects, and security is never a trade-off. It’s available in all additions, but productivity is what we are focusing on in the free edition of the software.

Then, for the Enterprise Edition, we are focusing more on compliance and scalability. So, scalability -typically 500 users. I will need more organizational features because of such a large volume of passwords. For example, I need to be able to tag this password in order to add one more dimension.

Scalability is, as I mentioned, I want to plug it to an active directory, I want to do provisioning, I want more logs. So, this is what we provide in the paid edition. And how we decide to split the features ―whenever we have a request coming from the community, or coming from our existing customers, we just all sit together at Passbolt, and we decide on, “Okay, what problem is it actually fixing? Is it productivity, or is it scalability and compliance?” And this is how we do the splits. And we do it very transparently ― all the time, we have a discussion going on with the community, and we announce things beforehand.

How Does Open Source Add to the Business Model?

Mike: It sounds to me, like, open source for you is a distribution mode:  it gets your software shelf space, it gets your product into the hands of organizations that might need it. And then, you’re creating a funnel from that towards enterprise customers. But do you see open-source contributions from developers? Do you guys write all the code? And am I missing something about how you view the importance of open source in the open-source community to the business?

Kevin: Open source is definitely an alignment that we have with all users. And it’s not always the case for open-source projects. For example, if you build an open-source CRM, the fact that your software is open-source, you will probably not talk to the commercial economic buyer at the other end. But in our case, our person has bits on the economic front, or in the free users front, the community front, they’re all technical.

We are speaking on a daily basis with system administrators, DevOps, head of IT, CEOs―these are type of personas that are very sensitive to open source for all sorts of reasons. Because of control, for some of them. For others, it is because this corresponds to the stack that they are using on a daily basis. They’re already on Linux, they’re already using GitLab. And they consider that open source is a bit like a fair trade of software. It has moral values, and they want to go for it.

For some of them, it’s also because of security reasons. Because they consider that when a software is open source, it has some interesting security attributes. I would say that there was a natural alignment for us to make this open source and to bring the open-source values, as part of the marketing message and the value proposition of the software.

Then, in terms of go-to-market, obviously the same dynamic is happening. Because what we see clearly at Passbolt is, most of the search engines related visits, coming to our website, come because of open-source password manager keyword. It happens that there are a lot of companies that have already detected that they need a password manager, so we do not need to tell them ― they understand their need, they understand that they want to centralize, organize, share their passwords, but they have also identified that they want to do it in an open-source way. Hence, they end up on Google and they type open-source password manager. And then, obviously, the offer is fairly limited right now.

There is like Passbolt and Bitwarden. But if you want another price solution, then you are going to look into the specifics of the solution. And in this case, I would say Bitwarden is probably more oriented towards consumer and we are more oriented towards Enterprise and really privacy conscious organization – that’s where they decide for which one where to go.

Pricing

Mike: It’s one thing to know that people really want your product, and it’s another thing to know how much to charge per it. It’s really hard to get pricing right. I’m wondering if you got it right in the early days. And if you didn’t, how did you finally get enough data to get it right?

Kevin: I think no one gets it right from the first time. Our mistake at Passbolt has been like with many other open-source companies: we priced it too low at the beginning. And by the way, I didn’t mention that, but Passbolt was not supposed to be a commercial product from the beginning. When we started working on it with Remy and Cedric, my co-founders, we were comfortable, we had a bit of money to invest in this, and we wanted to have fun building it and really build a great product. But our idea was, let’s build a great product, put it on GitHub and let’s see. And basically, what happens is, once it was on GitHub, we had a bunch of traction – we had a very good traction, a lot of feedback. Organically, some companies started asking us if we had something to sell.

And they were like, “You know, we are ready to pay for this feature because we really need it. Now that we are scaling, we have 100 people on your software, we need more, we need premium support.” So, people started telling us by themselves what they needed in terms of features and in terms of offering. That’s how we went from being completely free to having a paid version.

And we had no clue about like how much we would charge for it. We asked the people that were asking for features. But people are never going to tell you openly, “This is my maximum budget.” So, they will always tell you ballpark figure, but probably on the website. And when we started charging for Passbolt, initially we charged 1 dollar per user per month. And this was fairly low. And to be honest, I think it played against us in the sense that Passbolt was not really perceived as a high-end solution in the security field.

Because price has an influence on how people position the product in their head, how much value they think your software is going to bring to them. So, obviously pricing it too low doesn’t necessarily play in your favor. And I think this is something we see very often in the open-source world. There are a lot of projects that are pricing their solution extremely low because they think they are competing on the price, while, most likely, they have a lot of other attributes to compete on. And this is something we’ve realized quite long after at Passbolt.

From then, we also followed what our competitors were doing. And obviously, we had less features, but probably stronger foundations in our software ― we knew because people would tell us all the time, like they would adopt Passbolt because of the security reasons, because of the security model, because of the collaboration layer. And we knew that they would consider Passbolt to be mature enough for their use.

From there, we decided to iterate constantly on the pricing. Now, once a year, we are basically changing our pricing, increasing it a bit more every year. And we are being quite vocal about it. It means we are informing our customers in advance. We’re having a discussion with them, with the ones who do not necessarily agree. So far, all our price increments have been received quite positively. Some of our customers have even asked us why we waited for so long to increase the pricing, and congratulated us because we did it. I think it’s a very positive signal from them.

Lead Gen?

Mike: It sounds like you’re in a very horizontal market, like the market for customers and organizations that need passwords is, like, everybody, but do you segment the market at all? And other than, let’s say the open-source channel, are you doing any other lead gen in any other segments of the market?

Kevin: No. All our traction and all our customers, as of today, we have around 1,500 customers, the industries where we have the most traction are basically public institutions, universities, and a lot of IT companies or IT teams – this is definitely the biggest sector for us. They all came organically ― we never had to do marketing, we never had to do outbound sales, and we tried it. Because we are a VC funded company, and when you get VCs on board, one of the first thing they tell you is, “Can you scale this thing?”

And it’s very difficult to scale words of mouth, but you can say you can scale your sales organization by adding a bit more outbound sales here, and some more outbound marketing there ― these are all the things we tried. But what we realized on the line is that the cost of acquisition for outbound sales, or outbound marketing, were through the roof, compared to what we can get organically through word of mouth and people who are really happy about the solution.

So, now we’ve completely stopped doing it. We do not do any artificial lead gen, we don’t do any lead gen campaign. The only thing we do is, we focus on building the greatest product we can, making sure community is happy. And what we see in practice is, whenever we deliver a nice feature, a feature that has been a long demanded, or there was a lot of traction in GitHub, immediately it has an effect on the lead generation and people purchasing the solution.

Supporting Old Versions

Mike: Pivoting back to technical question for a second. You mentioned that you have a Community Edition, and one of the challenges we found at Gluu is managing and patching the old software becomes sort of a drag like ― it’s fun to write the new stuff, but nobody wants to patch your version from like six years ago. What’s your policy on how long you’re going to support and continue to patch these older versions of Community Edition? Is it more aggressive, let’s say, than your policy for enterprise customers, with regard to the length of time of support?

Kevin: It becomes a burden, you’re right. But our policy is to make it work as long as possible. So, sometimes we are very surprised, we jump in support calls and realize that some of our customers, or users, have not upgraded their Passbolt for 3 or 4 years, and it keeps working. It’s a bit bumpy, not everything works, but most of it works. So, obviously it doesn’t really incentivize them to upgrade. And you really have to tell them, like, “Look, you should upgrade it, you’re going to get more stability, but also, you are going to get A LOT OF new features.”

And I think this is the main reason at the end why they are doing it. Currently, we don’t have anything built in the software to push people to upgrade to a newer version. And I would say, obviously it gets complicated. It is the way we develop, because then we had reasons to prepare for so many use-cases and so many versions of the API. But it’s a security software. We have to keep it working. It’s our philosophy―we have decided that we’ll do our best to keep supporting all versions of the software no matter how old they are.

We do not do telemetry at Passbolt, which means, we do not know what is in the park of software. We do not know what versions are running out there. So, then it comes to communication. Before we introduce breaking changes, we get very loud about it. We keep sending emails, we keep sending announcements on the community forum. And we pray that everyone has the information at the end and will decide to upgrade.

Is Cloud Better For Customers?

Mike: Is that sort of an argument for people using the cloud service?

Kevin: Well, obviously it’s easier for them, but then it depends on your requirements. If you really want to have something behind your firewall airgap, then you don’t have the choice: you need to go for self-hosted. I mean, what happens in organizations, what we see a lot is, initially, you have a system administrator who knows very well how to do self-hosting. He has everything on track, he’s doing his job, but then, the team changes, the system administrator changes. And then, there is a new guy that comes that does not know how to maintain the software properly. And this is when it gets complicated. Because it’s probably not on his radar, he needs to upgrade the version to a new one, or even that he has anything to do at all.

I mean, this is where we have to be smart at giving the information and be in touch with them, but obviously it’s not always possible. So, yeah, there’s a bit of complexity here.

Future of Passwords and Passkeys

Mike: I think we all agree that passwords aren’t going away for our generations, but killing passwords has become a meme. Does it feel a little bit weird being in a business, where like the common wisdom is you should be killed?

Kevin: Yes. Obviously, it’s not pleasant. We have this joke internally, where sometimes we are comparing ourselves to floppy making companies. A lot of floppy CDs, they all disappeared, but then, you still had a few vendors providing floppy discs because the demand was always there.

I think password is much bigger than that. We don’t think passwords are going anywhere, at least for core audience, the technical teams. Obviously, for non-technical users, that’s what is at stake―removing the passwords. And if I was the CEO of the company, that’s definitely what I would focus on: how can I remove the passwords from everyone.

In any case, at Passbolt, we do not consider this to be a problem. We’ll keep focusing on main use-case of the solution, which is, managing passwords inside technical teams first. And on top of that, our plans at Passbolt are definitely to go towards the passkeys management, and basically, Passbolt is already really good at managing private keys.

Because, as I mentioned earlier, this is core to our security model. That’s what Passbolt knows how to do: we take a private key, we put it in the browser extension, and then from there, we manage authentication and encryption scenarios. If you look at passkeys, it is not far from this principle. It’s almost exactly this principle.

We are already working on features inside Passbolt to help organizations manage passkeys, and we have a lot of customers that are actually waiting for this feature, how to federate their passkeys and add more permission control on top of it.

So, the conclusion: we do not worry about the future without passwords, passwords will keep being there. And for the ones who want to get rid of their passwords, we will have features for them, to implement passkeys and make sure that those passkeys are working properly and rotated when they have to be rotated, and so on.

Closing Advice For Founders

Mike: Kevin, any final advice for software founders who want to use open-source as part of their business model?

Kevin: Talk to your users. It’s really important. I’m saying this because we are advising a few companies, and obviously, we meet with a lot of other open-source funders. And it is very common to see technical founders just being obsessed with coding and technical performance on the platform, to the point where sometimes they forget the value proposition for their users and customers, and I really think it starts from there. We also did the same mistake. I’m not saying that we are better than them, but if I wanted to help an open-source founder save time, then, it would be, talk to your users and understand their use-cases first. Tech comes next.

Mike: And attend the Open Source Founder Summit in Paris, in May of this year.

Kevin: Absolutely.

Closing

Mike: Kevin, thank you so much for joining us today.

Kevin: Thank you, Mike, my pleasure. Thanks for the invitation.

Mike: Thanks to the Passbolt team for all their collaboration. Cool graphics from Kamal Bhattacharjee. Music from Brooke For Free, Chris Zabriskie and Lee Rosevere. If you are wondering why this episode didn’t feature Patrick Bachmann of Open Ocean, tune in next week. I prioritized this episode because I wanted to get in the reminder about the Open Source Founder Summit. Patrick – next week.

So, until next time, thanks for listening.

The post Episode 69: Kevin Mueller, Co-Founder / CEO Passbolt first appeared on Open Source Underdogs.

Mike: Hello and welcome to Open Source Underdogs. I’m your host Mike Schwartz, founder of Gluu, and this is episode 67 with Peter Farkas, Co-founder and CEO of FerretDB.

Why FerretDB and not PigeonDB? That’s a very good question. Whereas pigeons are underappreciated for their speed and resiliency, ferrets are fierce and furry and loved by everyone, except Rudy Giuliani.

Mike: A MongoDB API, with PostgreSQL storage, Ferret is a database platform that seems to have a similarly wide appeal. I guess, the 800-pound gorilla in this market is MongoDB itself, with around $35 billion in equity market cap. But in addition to MongoDB, Amazon has also implemented a Mongo conformant API that uses some kind of Amazon storage.
Is there a room in this very competitive and well-capitalized Mongo Cloud database ecosystem for a scrappy start-up with a good technical idea and a track record of reliable operation?

I recorded this episode at the State of Open Conference, or SoCon, which is the largest FOSDEM fringe event. If you can make it to SoCon, I highly recommend it. Unlike FOSDEM, it’s a more traditional event with badges and keynotes, and registration, and coffee, or tea, if you’re British, and after the chaos of FOSDEM, it’s a nice change.

So, this year, SoCon rented around five media vans specifically to record podcasts. So, thanks a lot to conference organizers, it was a pretty great idea. And there’s a picture of Peter and I, donning the Underdog’s headsets on the episode website. Well, with that unusually long intro, here’s the interview.

Origin

Mike: FerretDB was founded a little more than two years ago, you were probably thinking about it for a while before that. What was the spark that led you to actually take action and start the thing, and was the plan always to start a business around FerretDB?

Peter: MongoDB decided to leave its open-source roots around 2018, and all of the co-founders of FerretDB have open-source databases for close to a decade. Peter Zaitsev, one of our co-founders, maybe more, maybe 20 years. After MongoDB went public with SSPL and their departure from open source, we’ve been waiting for a couple of years whether there will be a fork, or if the community is going to do something about it, and nothing really happened.

There was no Fork, there was no OpenTofu reaction to MongoDB’s move. And in 2021, we’ve just decided that something needs to be done. That was the time when we started FerretDB as a side project mid-2021.

Project Launch

Mike: FerretDB has over 8K stars on GitHub, which is fantastic, that’s a lot. How did you go about promoting the project to the developer community to build that kind of support?

Peter: That was the beauty of FerretDB. When we started the project, we were not sure whether someone is going to be interested at all. Since there was no OpenTofu like reaction to MongoDB’s departure from open source, we were not sure whether the community even cares.

If you take MongoDB, there’s not a lot of community around the product itself, in a sense that most of the community consists of users rather than developers of the MongoDB codebase. So, we were unsure what will be the reception. And when we started working on FerretDB, again as a side project, we just created a tech demo, we published it on GitHub, and I think, the first 4K stars came in around two days.

So, we did not do promotion, and we did not expect this kind of outpouring interest in FerretDB. And I think part of the reason why the interest was high is because we’re building on Postgres, and the Postgres community really feels strongly about open source and about open-source databases, and they want Postgres to succeed in various different use-cases, such as document database or MongoDB-compatible use-cases. So, I think that most of the support came from the Postgres community initially.

Product Roadmap

Mike: So, what product features do you see as the most strategic to develop this year, or in the near term? And how do you think these features will help the business?

Peter: As much as it sounds crazy from someone who leads a VC-funded start-up, we are not really concentrating on the business part, because we know that the business success comes after strong adoption and ways to utilize FerretDB in meaningful larger use-cases. So, the most important to us is to increase compatibility with MongoDB. We want the user experience to be seamless, in a sense that if you use a certain tool, or framework with MongoDB, you need to be able to use that with FerretDB as well, without modifying anything in your code.

That’s our goal. But this is definitely not easy. There are a lot of features in MongoDB. Some of these features are not used by many, but would still be used by a very popular framework, and then we need to pay attention to that exact framework to make sure that, for example, Meteor utilizes Oplog, which is a duplicated feature in MongoDB itself.

We need to be very conscious about developing features, which would result in many developers being able to use FerretDB in place of MongoDB, through their favorite framework, through their favorite tools. What’s more important for us is to work with the community on establishing an open standard around document databases.

So, we don’t want to chase MongoDB with their features for eternity, that’s impossible. What we want to do is, we want to work with the existing MongoDB alternatives to establish an open standard, similarly to how SQL came to be, where, if you use SQL, you can query a Postgres database, you can query MySQL database, and any other relational database out there.

And when it comes to MongoDB, there’s no such standard – the best you can do is to become MongoDB compatible. But, it’s like saying that MySQL is IBM DB2-compatible. Do we say that ever? No. It supports the SQL standard, implemented it, and that’s why you can use SQL across the board, with relational databases.

So, we want to reach the same situation with document databases, where it’s no longer MongoDB-compatible, it’s compatible with an open standard.

Value Proposition

Mike: Do you actually have customers who’ve raised their hand and said, “I want to pay you guys for your services?”

Peter: Yeah. We were very lucky. I think, right at the second month, we were bringing in revenue, and that was reassuring feeling that this is something which is sustainable.

Mike: What was the value proposition for those customers?

Peter: I think that the value proposition here is that many customers have existing Postgres infrastructure, and they also have MongoDB. And they need to maintain the internal know-how about these very different databases, they need to pay services for both. And they can just combine the two databases into one and care only about Postgres, run FerretDB on top of it, and they end up with a much simpler infrastructure.

Channels

Mike: Is the open source really your only channel? Do you do any other marketing?

Peter: We are, I think, 80% engineering, and then, we pay attention to channel partners – those Postgres providers who are interested in providing further services to their customers. We don’t run an expensive marketing machine. And we feel that we don’t need to, at this point. We have enough on our plate, on our road map to care about.

Priority of FOSS v. Commercial

Mike: It looks like a relatively small team right now. How much of your time does your team spend on R&D, versus providing services to customers? Because there’s always some friction when you’re providing services – are you working on the product or are you helping customers. And those things can collide. How much time do you spend actually on R&D?

Peter: Initially, we signed a contract, which took away some of our focus from R&D itself, because that customer wanted us to develop features which were not on our road map. And right now, what we are focusing on is to team up with customers who need services and features in close connection to what we have on our roadmap.
Meaning that it’s more like a reprioritization of R&D, instead of going entirely different direction with our development efforts. I believe that with this approach we were able to – this is a ballpark number – but I think 80-85% of our time is still spent on developing FerretDB. Sometimes in relation with what our customers would also want us to do.

Community Contributions

Mike: Have you seen any material code contributions from the community?

Peter: Yes. We had a lot of interesting surprises like that. First of all, there are a lot of individual contributors. And we really like them, because they also want FerretDB to succeed, and they are invested. We have four or five new contributors every month.

The most surprising were the likes of SAP, for example. One day, we just woke up to SAP pushing code in our repo, and that was great. Because that meant that it’s not only FerretDB incorporated developing FerretDB, but others who are interested in creating compatibility with their own products and MongoDB using FerretDB. That was also a very reassuring moment that it’s not only us who want to make this happen, but some key players in the industry as well.

Monetization

Mike: I see you’re offering Services, or we talked about that – it sounds a little bit like Percona in a way, which, I guess, makes sense, because I see Peter Zaitsev is also one of the founders. Is Services the main way you intend to monetize? And what are some of the trade-offs you anticipate with this monetization strategy, versus, let’s say, licensing or Cloud, which are the two most common monetization strategies for database vendors?

Peter: We do Services because we know how to do that. I think that’s the short answer. So, working at Percona really taught us how to provide great services to demanding customers. That doesn’t mean that we are not looking at other sources of additional monetization. We are planning to roll out our managed service. So, we will have a cloud-based offering.

The reason why we think that is important is because, if you take a look at the SSPL license, it positions MongoDB Atlas and some of MongoDB partners as the sole providers of services around MongoDB or a MongoDB-compatible database. And we want to challenge that. So, first of all, we want to enable other providers who did not get a seat at the table with MongoDB Inc. to provide services for MongoDB users with FerretDB, but we also want to do our own cloud service offering. And that’s something we are working on, and it’s definitely a challenging task.

Back to your question, Services is just the easiest way of putting an open-source project onto a sustainable trajectory.

Governance

Mike: You say you want to be an open-source alternative to MongoDB, but how do I know you won’t change the license after the project gets some adoption? The project and the trademark is controlled by your for-profit company – why should we trust you?

Peter: So, Mike, would it make any sense to do the same thing as MongoDB? I mean, trust will be required. I’m not going to state, “Hey, trust everyone blindly.” I think whenever you choose a provider for an open-source offering, I think trust is definitely going to be one of the items you need to think about. But doing the same thing as MongoDB in FerretDB situation is just pointless. I don’t think that the market would react in any kind of positive way to that. It’s not something we can afford to do.

Mike: Also, you say that now, but after a billion downloads and you go public, and Pete Farkas is not CEO anymore – the new Pete Farkas might feel differently. Have you considered, for example, Postgres, I believe has a foundation, the Linux foundation is great, there’s several other foundations you could look at – why not contribute the code and make a community governed so that both the trademark and the code are really protected?

Peter: It’s in the works. When we started FerretDB, the traction was not enough to even sit down with the rest of the industry and talk about these things. What I can say at this point is that it’s in the works, so it is going to happen in some shape or form. We don’t expect the market to blindly trust FerretDB, we don’t want to do the same thing as what MongoDB did, we trust the existing mechanism of the open-source community, which is available to us to take care of this. So, we sat down with many in the industry in the MongoDB alternative markets, and we are actively trying to figure out a way on how to increase this trust.

So, FerretDB is not going to be the only company you can get FerretDB from – that’s not our goal. What is going to happen after we do an IPO, for example in 10 years? That’s a question I get surprisingly often. And from my position right now, this is very hard to imagine, but let’s take the example of HashiCorp.

It’s obviously really bad what happened. And the CEO departed shortly after or before, I don’t remember. They did not agree with the direction seemingly. Or just had enough of this whole ordeal of deciding whether HashiCorp is an open-source company or not. But what’s interesting about this situation is that we need to ask the question: Did HashiCorp provide value to the open-source community, or users, in general, in the decade, or I don’t know how long they developed the software?

If you ask me, I think they did. I think they did provide a lot of value and OpenTofu is free to take that over and develop it further. So, it’s not all bad in my opinion. On the other hand, I also would have preferred if they stayed open source and proved the market and proved investors that an open-source company, like HashiCorp, can still exist without changing the license. That would be my preference as well.

Investment

Mike: I have to apologize I haven’t been able to do all my research yet – I heard you mentioned “Venture Capital” – have you raised Venture Capital, and if so, why or why not?

Peter: We absolutely did not plan to raise Venture Capital. Because, first of all, all of the co-founders at FerretDB are coming from a bootstrap background, completely opposite of a VC-funded start-up. And then, after the GitHub project became popular, we started getting a lot of offers from investors, and we rejected a lot.
Before talking to our current investors, the reason why we rejected the initial offers of the investors we got in touch with is because they did not understand open source.

For example, some investors were like, “Okay, and when are you going to change the license?” And that’s not a good start. But there are investors who understand open source, and there are investors who are patient enough that they give the chance FerretDB, or some other company in open source, to provide value to the community, they understand that it’s not all about the license. There are successful open-source companies which took VC investment, and they are looking at those examples instead of, “Hey, how many licenses did you sell last month?”

After meeting investors like that, we were confident that this was the way for us to go. We needed a lot of capital to hire our current team – ten people as of now. And we also needed a lot of time. An open-source project, in order to get the necessary amount of traction – and I’m not talking about GitHub stars – I’m talking about real traction, like the number of contributors, that’s a much more meaningful metric here in terms of measuring contribution.

So, in order for that to happen, you can do all kinds of marketing, and outreach, and developer advocacy, but what you need first and foremost is time, time for the market, time for developers to understand what this is, time for them to hear about it, and then, you have real traction. For that, you need runway, we are already two years old, still running on our initial round. And without taking investment, this wouldn’t have been possible.

Partnerships

Mike: Do you see any partnerships with other business, or organizations, as critical to your success?

Peter: Very much so. Because as I mentioned earlier, the whole point of SSPL is to make sure no one provides MongoDB as a service. Since FerretDB can enable cloud providers and Postgres as a service providers to do just that, these partnerships with them are very important to us. And we are working with many of these companies to roll out FerretDB as a service.

If you take a look at our social media, we are full of these articles or videos, where Supabase, or UB cloud, or Scaleway, or CVO, or some others, decided to try out FerretDB, make it part of their offerings maybe and see where that leads to.

Next hire

Mike: It sounds like you’re being rather capital efficient, in terms of hiring and building the team. What do you think are the most important roles for you to fill in the next year or two?

Peter: For the initial years, R&D is the obvious reason why you would want to hire. So, you hire engineers, you hire very capable technical people, but as the product matures and as there are more users, you need more service-oriented people, salespeople, marketing people – and this is what we are seeing as the next evolution of FerretDB as a team, where we have more people who support the business side of things.

And by supporting the business side of things, we increase the sustainability of the project itself. We are really talking about a project and a business next to it. These are really two separate things in my mind: FerretDB as a project and FerretDB as a business. And for the last two years, we were focusing on the project. And as the project evolves, we will need to focus on the business.

Mike: Maybe just to make it a little more specific, what’s the next “hire” you’re looking for in the executive team?

Peter: The next hire would be sales, I believe. Simply because pricing and coming up with terms for a contract is definitely not something which I, as a service-oriented person, or engineers developing the software, should come up with.

Advice for Founders

Mike: You’ve been involved in a couple of start-ups. I saw you founded more than one company. My closing question is, do you have any advice for new entrepreneurs who are launching a business around an open-source software project?

Peter: I think that the best advice I could give, especially talking to some founders just starting out, is to try and solve a problem, rather than to find the technology you fall in love with. Solving a problem is a lot more important than what is going to give you traction, that’s what is going to give you opportunities. If you just find a cool technology you want to play with, let’s say AI. Okay. But what are you going to use AI for? That’s the question. AI – that’s not a product, that’s not something you can do anything with, or your customer would be able to do anything with. What is the problem that AI is going to solve, or your new database is going to solve. I think that’s the real question, and not all founders raised this question initially, I believe.

Why Ferret?

Mike: Okay. I said it was the last question, but I’m going to ask you one more question. Mongooses, they’re kind of badass, they fight cobras, and ferrets are kind of cute and cuddly – are you sure you want to be a ferret?

Peter: The story of ferrets and why ferret, that’s the second most common question I am getting. It’s just insanely hard to find the domain name, let’s face it. We were ferretdb.io, not even .com. Just recently, we’ve been able to get the expired domain ferretdb.com, because there was a database of various kinds of ferrets at ferret db.com. So, it’s insanely hard. I think the naming of the companies by far my least favorite thing, and I would not tell you the truth if I would tell you that we had this concept initially.

Because none of us are native English speakers, but after naming FerretDB FerretDB, we found out that to ferret out is something that exists in the English language, meaning to carefully search for something.
And I think that’s just a great name for a database in the end. Because that’s what the database does. So, FerretDB? FerretDB it is. I don’t think it’s rare to find weird animal names in open-source anyway.

Closing – Credits

Mike: Peter, thank you so much for spending time today. I love what you guys are doing. And thank you for sharing your experience with our audience.

Peter: Thank you so much, Mike. It was an honor to be here and hope to talk to you soon.

Mike: Thanks to the FerretDB team for the cool stickers and the social media retweets. Cool graphics from Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere. Special thanks to Alex Izza from Resonance Public Relations for the logistical help. Actually, Alex has suggested two more interviews, which you’ll hear in the next two weeks: Solomon Hykes, founder of Dagger and formerly co-founder of Docker, and Patrik Backman, one of the co-founders of MariaDB and an original team member of MySQL.
Hopefully, I’ll have that out in the next week or so. Until then, thanks for listening.

The post Episode 67: Document Database FerretDB with Peter Farkas, Co-Founder/CEO first appeared on Open Source Underdogs.

Mike: Hello and welcome to Open Source Underdogs! I’m your host Mike Schwartz, Founder of Gluu, and this is episode 68 with Solomon Hykes, Co-Founder and CEO of Dagger, but also formerly the co-founder and CTO of Docker.

Back in February, I recorded this episode at the Civo Navigate conference in my hometown of Austin, Texas. If you want to hear the latest and greatest cloud native stuff and meet companies like Dagger, you should check out Civo Navigate. It looks like they are planning a US and Europe event each year.

This episode is a little on the long side because we cover some questions, relating both to Dagger and Docker. But if 45 minutes aren’t enough for you, there are a bunch of other interviews with Solomon, so just check the interweb.

And with that said, let’s just cut to the interview, so we can get to the main attraction. Here we go.

Y-Combinator Playbook?

Solomon, thank you so much for joining us on Open Source Underdogs.

Solomon: Thanks for having me.

Mike: I’m just going to dive into this with Dagger. Your approach seems very YC to me – who are the developers in pain that build Dagger?

Solomon: Yeah. Dagger came out of a process of talking to a lot of software teams about their pain, and the pattern we saw emerge was the problem of the deployment pipeline. You know, CICD, everything that happens after your code’s ready. But before your application is live, everything in between is just, painful, painful and complicated. And so, we’re focusing on making it a little less painful, a little less complicated. So, it is very YC, it’s the standard Y-Combinator playbook.

Community Lead Growth

Mike: What is the Daggerverse and Daggernauts, and what do you mean by community-led growth?

Solomon: Daggernauts are people who think of themselves as part of the Dagger community. Community is — I mean, it’s an overused word, but it’s really important to us, community-led growth is our business strategy. And the idea is, if you build a product for developers, and those developers are excited enough about it that they will not only use it, but show up on an online chat server to talk about it, come to meetups to talk about it, write blog posts about it, tell their friends, help each other – they become more than users.

You need a new word for that, so we use the word community, and then we market the product together. Sometimes we sell it together, and we write software for it together, so that that can become a way to grow as a business. It’s hard to do correctly, because you have to be authentic, you can’t fake it. Because a community will only form if there’s actually something in it for them, and it can’t be just transactional – they have to feel valued, respected, but when it does work clicks, then it’s very powerful.

Monetization?

Mike: As I understand it, you have an open-source project under the Dagger GitHub – your trademark – and your strategy is to monetize by selling a maybe cloud-controlled plane or dashboard, where enterprises can really see value. Am I on the right track?

Solomon: Yep, totally. Open-source engine, optional proprietary control plane.

Mike: What is the business value that enterprises are actually seeing, where they decide, “Okay. I want to go with the commercial offering.”

Solomon: Well, first of all, the commercial offering is very new. Our priority is adoption of the engine. If an enterprise can use both, that’s great. If they only use the engine, and they need to take a little more time to evaluate the commercial products, wait for a feature to be available, then, that’s totally fine. We’ve designed it that way.
For example, our cloud product does not have a self-hosted version yet. 

So, some customers do not care, and they’ll buy it today. And others are waiting for this self-hosted version. When we talk about the business value of Dagger, we’ll talk about the whole of the platform, open-source engine cloud for the buyer. Either it solves a business problem for them, as a complete platform, or it doesn’t.

Unique Features

Mike: There’s a number of tools in this area already, who are those super fans who say like, “I know about all that other stuff, but that’s not for me. I really need this Dagger.” Who are those people?

Solomon: Usually, in every software team, there is at least one person who’s the designated DevOps person, they’re the person who will have to fix the build, or make it faster, get the CI pipeline going, sort of support the developers in shipping. And then, over time, as the team grows, you’ll have more than one.

And in larger enterprises, you’ll have entire team, platform team, DevOps team, whatever – those people are typically the people who will get excited about Dagger because it makes their job easier.

Developers we help indirectly, the DevOps people we help directly. The main reason they get excited is because we don’t force them to throw away what they have, will improve the stack they have incrementally their terms – that just makes everything else easier.

Prioritizing Core v. Commercial?

Mike: Is there ever any friction when you’re figuring out how to allocate scarce resources at Dagger, on, “We should work on this core feature that is in the open source, or we should work on some features that improve the cloud offering, which will help us monetize.” And how do you balance those?

Solomon: Yeah, it does happen all the time. In fact, we’re small enough that it happens even within the open-source engine. Also, right now, we’re at an inflection point, where the core product is done – well, it’s not done, but it’s well-defined, and it’s well understood. And we have a community of people who are using it and want to use it more and more, which means they’re reporting bugs, they’re asking for features – there’s an incremental roadmap that we’re executing on.
Meanwhile, we’re building out this commercial product, which is, like I mentioned, it’s much newer, and it needs a lot of work. Resource contention is a problem. I don’t think we’ve found the solution. Honestly, focus is our friend here. For example, I mentioned we’ve prioritized adoption of the open-source engine.

So, to be honest with you, over the last six months, I think we got a little bit too ahead on the commercial products. We approached it like we could build both at full speed in parallel, but then we realized, when we looked at what people were asking for on both sides, we realized, okay, we can build both, but we cannot build both at the same level of priority. So, we’ve changed our text slightly, and we’ve decided to make it clear that we are prioritizing the core open-source engine at the moment.

And with the resources they are left with, we’re developing the commercial product. But we’re narrowing the scope of the features of the commercial product – in practice, that meant going from two flagship features to one flagship feature in the commercial product, for example. I think it’s just mostly being realistic and also being flexible adapting to changing circumstances.

Community v. Monetization?

Mike: I’ve noticed that with a number of start-ups, their initial focus is really on getting adoption and getting those super fans and then figuring out monetization later. I’ve also had guests who said they should have thought of monetization from day one and built around that. Where do you come out on that?

Solomon: I think there’s a balance to be found for sure. For example, I’ve just said, we had to sort of scale back a little bit on developing the commercial product. I’m still very glad we started developing it early, and we’re validating it, whether there is something that anyone is willing to pay for, and also, a million details along the way – how much to charge for it, is it cloud or on-prem, what market are we competing in, who are our competitors.

The clock starts the day you start building it. And I do think completely putting off even thinking about it for potentially years can be a mistake. So, we were pretty deliberate about starting early, but then, once you’ve started, you got to manage your priorities – that’s our approach.At Docker, it was all on community and think about monetization later for sure. And it worked. I’m not surprised when you say some people regret not working on monetization sooner. I completely understand.

Why Trademark is important

Mike: Actually, I would like to dive deeper into the monetization because that’s really interesting, but before we even get there, maybe just any thoughts about the use of the trademark, and how you’re approaching Dagger differently from a trademark perspective.

Solomon: At Docker, we underestimated the importance of protecting your trademark when you’re building an open-source platform. Ironically, the best example of doing that right is also the same company that abused our trademark the most – namely RedHat. RedHat really is a great model for how to be extremely open on your code. Red Hat has always been serious about open-source licenses, opening up even proprietary products from companies that they bought. They would open up the code. They really walked the walk on copyright on the license of the code itself, but the way they made it work is they’ve always been extremely strict and enforcing the use of the RedHat trademark.

It is the best model for an open-source business. The stricter you are on the trademark, the more open you can afford to be on the code. In practice, that means this is open source – you can fork all of it and redistribute it. It’s all fair game. You can take all of it or modify it and redistribute your modified version. But you can’t call it in our case Dagger, you have to call it something else.

Ideal Use of Trademark

Mike: What was the impact on Docker as a result of people, or organizations, using the trademark?

Solomon: The problem was the kleenex problem basically, that Docker washing became the problem. As Docker popularized containers, and containers became the hot new thing, Docker became the hot new thing, and the Docker brand became very valuable. You know, the whale logo, everything associated with it – something new, something exciting. This community that was just blowing up – we had I think 120 meetup groups around the world, hundreds of thousands of people physically coming every week to just show each other a cool stuff they were dealing with Docker.

That brand was basically very valuable, and anyone, any vendor could just take it and say, “Oh, yeah, we do that.” Of course, it meant that Docker as a business did not enjoy as exclusive a competitive advantage as it deserved.
And also, over time, it hurt the quality of the experience, because you could go to a random vendor and they tell you you’re getting Docker. So, you install their thing, and you think you’re getting Docker, but you’re getting some weird Frankenstein product that maybe there’s some Docker inside it somewhere.

But the experience is not up to my standards, or the standards of the Docker team. So, you’re going to walk away disappointed, it didn’t work properly, it wasn’t compatible. They said it would be portable, but it only works on this vendor system, whatever the problem is. And now you’re going to associate that negative experience with the Docker brand. So, losing control of your brand is a really terrible thing to experience. The way to not lose control of it is to enforce your trademark in a very strict way.

Mike: Although Dagger is open source, you don’t want anybody doing Dagger hosting, or introducing a Dagger powered product. What about the hosting side? We’ve heard a lot about open-source data. If somebody used just Dagger hosting, we’ve seen WordPress hosting here in Austin – where are the limits, or where are the boundaries?

Solomon: Our approach is, if you think Dagger hosting is a great thing to do, come talk to us, and we’ll partner. Actually, we’re having conversations now that actually becomes forcing function for designing it. Okay, let’s talk about what does Dagger hosting mean actually. What that experience will be is not as straightforward as hosting a database. There are questions of what’s going to run on the client, what’s going to run on the server – those things are still being worked out. So, now we get a chance by forcing people who want to sell hosting for Dagger to come to us.

Now, they’re part of the design conversation, now these potential partners, we are showing them the architecture we have in mind, we’re showing them the feedback we’re getting from our community what they want.

And now, we’re all going to design this together. And if it still makes sense in the end, and they’re still interested, then they’ll get a license to use a trademark. Or they could just say, “You know what? This is great. We don’t need your brand, we just want the code, and we’re just going to do hosting, or something – they change the name, and then they can host it now, they don’t need our permission for that. Keeps us honest at the same time.

Mike: Because they have the right to use the software.

Solomon: Exactly. Because it’s actually open source. There’s no special license or anything.

HashiCorp shows system worked?

Mike: There’s another company I thought you were going to mention when you mentioned RedHat, and I think RedHat’s also underappreciated. But I was thinking of HashiCorp. They actually did and continue to do a very good job of defending their trademark – TerraForm.

However, they did run into some friction with the community. Because, after a billion downloads of their software, they changed to a non-OSI approved license. And there was some blowback from the community. And I think they broke a social contract in a way. By your definition, they did it right, but is there anything they could have done better?

Solomon: I think that episode with HashiCorp was actually very useful for start-ups like Dagger that are earlier in the journey. We’re telling the markets, “Here’s our open-source product, here is our business model around it. And it’s a sound model, and you can trust us that everyone wins.

RedHat was very useful in standardizing part of that model. Okay, RedHat has opened everything, and they’ve been very strict on the trademark. And they’ve been successful, so that helps us make our case. But one question we can’t answer with only that example is, okay, but what if later you change your mind, what if later the founders leave, and the professional CEO takes over? Or, what if you sell? And you can’t say, “No, we won’t.” I mean, because you don’t know. And that’s what happened to HashiCorp.

And what’s wonderful about this example is that it turned out okay for the customers. Because what’s happening now is, there was a fork, it’s run by a foundation. Now, there’s one more option. After HashiCorp made this decision to break the social contract, basically they were punished or rewarded, depending on how you look at it, with a community-run alternative, which customers can now choose to switch to at any time.

Now, I get to say, well, we don’t plan on doing this, there’s no good reason for us to do that, but just in case, a few years in the future we change our mind for whatever reason, here’s what will happen: we’ll get forked, there’ll be a community-run alternative, and you’ll get to use that. So, it’ll be fine.

Mike: So, the system worked.

Solomon: Yeah. I think the system worked. I have no clue if in the end, this is good or bad for HashiCorp, if they made a mistake, or if it’s not that important. I mean, I don’t really have an opinion on that, but I know it helps us make the case for our model now.

Do we need a new OSI model?

Mike: We’ve recently attended SoCon, the State of Open Conference in London, and Bruce Perens gave a talk, where he suggested we need a new open-source definition. And we see open-source companies moving to other types of licenses that are slightly more restrictive. Do you have any thoughts about whether maybe we need some innovation in this area?

Solomon: I think we do. Honestly, the elephant in the room is this battle over what’s open AI – well, there you go [laughing], that’s the problem right now. What does it mean for AI to be open and what happens when the closed vendor has opened in the name, and then you have open-source models that have a closet says, you know, Apple can’t use it, or something. Neither open AI, nor so-called open-source models today, meet the OSI definition of open source. Is that okay or not, that’s the debate. But I think given just the enormous attention on AI right now, if anything causes the state-of-the-art in this area to change, it’s going to be that.

Every other ongoing point of contention is dwarfed by the focus on AI. That’s my opinion. Maybe that’s an opportunity to leverage that attention and that desire for change. And that those tensions channel it into constructive changes to the standard. It’s dangerous, because maybe what ends up happening is the standard shifts in the wrong direction.

It’s possible that we regress, that we actually instead of getting incremental improvement on the current OSI model, maybe we lose benefits of it that we take for granted at the moment. And on top of all of that, even the definition of software itself is called into question. Like, what if all the software is generated by a model anyway.
So, I’m glad it’s not my job to figure that stuff out. I’m glad I’m not the expert.

Does Open Source Pattern Match with a Tragedy of the Commons?

Mike: A professor here at UT, and we’re recording this at University of Texas, Austin, wrote a paper comparing open-source to tragedy of the commons. She asserts that actually open-source economics pattern matches with some of the things that go wrong in a tragedy of the commons and proposes some remedies.

Solomon: I completely agree with that analogy, but I also think it’s getting applied wrong. Because common use of a limited resource – that needs to be replenished, the land. But software doesn’t need to be replenished – it doesn’t matter if one person downloads it, or 10,000 people download it. The bits themselves, once shipped, are not a resource that needs to be replenished. But the maintenance effort, the support burden is. And so, I think the grazing is not when you download the open-source software and then you use it without paying back. I think that the grazing happens when you’re filing a bug on the GitHub repo, and you’re expecting a maintainer to read it and then answer your question.

Or, you are sending a patch that you really need to see merge for your own downstream needs, and you need a maintainer to review it and give you feedback on it, ideally merge it yesterday. That’s grazing.

So, the resource, the equivalent of the land is not the software. I think the equivalent of the land is the people maintaining it. Because those maintainers behind the scenes are burned out. They are holding the world on their shoulders, and a lot of times they’re volunteers. But even if they’re paid, we’ve had people burn out of Docker because the world showed up, and they all wanted the Docker engine, and they wanted this new thing merge, and they needed this bug fixed, and they all needed it yesterday. And some of them were very demanding.

And some of them had millions and millions in contracts on the line, and RedHat was a culprit in that, for example. And we had people burn out not just from Docker, but from tech. Because they just cannot take it. You know, I have great hair now, and I didn’t when I started as a maintainer of the Docker project. We need to solve that. And I think tragedy of the commons is a perfect analogy there.

How to Maintain a Mountain of Open Source?

Mike: You mentioned open AI, and when I look at open AI, I see that it’s built on a mountain of open source. But they have the connection to the customer, which gives them that sort of last mile that enables them to extract value. What I’ve noticed is that there’s an inexorable stream of CVEs. That, because my software is built on a mountain of open source, some of those dependencies are always getting a rear patching once a month, just to keep up with it.

And I think the expectation for an open-source project is not just that it’s open source, but almost like this social contract that you will continue to patch it forever. And when the next log4j happens, we expect you to do it tomorrow.

 Solomon: I agree. Yeah, that’s part of the problem. It’s like an open-source project is a service. The unspoken contract includes everything you’re talking about – ongoing maintenance, ongoing support, ongoing operations of the project itself, running the CI pipelines for it. There’s no system in place for doing that in a sustainable way. I think it’s an unresolved tension in our industry today.

I just think sometimes we go down the wrong rabbit hole, trying to solve it, because we just frame the problem – it’s not a software piracy problem, the problem is not that people are using the software for free to make money because that’s normal, that’s expected. If someone has to wake up at 4:00 a.m. because a really terrible security vulnerability was just discovered and they have to patch it because only they know how. And they were volunteers, and they have billion-dollar companies depending on it, and the billion-dollar companies are the ones calling them – that’s not okay. That’s like fundamental problem for everybody involved. And that’s an actual real-life scenario. That stuff happens. So, yeah, we got to figure that one out.

Lessons from Docker Monetization Battles

Mike: Yeah. This is a global problem, and it’s really hard to solve global problems. I’m going to switch back to Docker, and again, excuse my ignorance, I’m not a Docker expert, about the history either, but one thing I have noticed is that they seem to be doing a little better now.

Solomon: Oh, yeah, yeah.

Mike: And so, monetization and pricing you mentioned, I wasn’t even going to ask you about your price journey for Dagger because it’s too early. Whatever you think of now probably is going to change. But you do have some interesting perspective, I think, on having this incredibly, maybe epically, record-breaking popularity in terms of who loved the software, but then also challenges around monetizing. And then, also now, the ability to see what they’ve done. And I’m just curious if you had any thoughts on what they’re doing now?

Solomon: Of course. A very common thing I hear is, “Docker struggled as a business because they gave too much away for free.” And I really think that’s wrong, meaning Docker was correct to open source, and it never had to be backtracked. Docker never had to change its license and anything while I was there, and after. At no point did Docker have a regret open-sourcing something – there was no temptation to walk it back. I think that’s a victory.

And second thing, there were many, many opportunities to monetize on top of this immensely popular open-source project. And many companies successfully did that, pretty much the whole tech industry made buckets of money off of Docker, except for Docker, for a long time. And that’s not anybody’s fault other than Docker’s.
Docker failed to build a commercial product that was exciting enough for people to buy. That’s the reason Docker struggled. It was purely an execution problem. It was ours to lose, and we screwed it up. And all this typical startup failure ways lack of focus, which comes from an inability to say no to something, so you can actually focus on other things.

And it’s just lack of discipline on hiring and expenditure and strategy. So, ultimately, instead of shipping one great commercial product, we shipped eight average ones. If you look at the numbers, if you go up to the point where Docker got closest to that, and it got recapitalized and split in two, and the commercial part got sold off to Mirantis.

And the core assets, the brand, the open-source tools, the developer tools lived to fight another day. By that point, Docker had spent 300 million dollars to build a 60-million-dollar business. The math doesn’t work out. So, yeah, that was the main reason what caused Docker to be successful now, is a very simple – they had to downsize, sell off that failed enterprise business, they were left with the open-source Docker engine, Docker Hub and Docker for Mac, these desktop apps install Docker on your desktop. The simplest thing in the world. It just so happens that when we shipped that back in 2016, we did not make it open source. So, we have this really easy Mac application: click, click, you got Docker. We bundled that as a binary, and we did not open source it, and nobody cared. And it was free. And then, one day Docker said, “You know what? This application is still free unless you make this much in revenue as a business, and then you have to pay us now.”

And that was it. That turned Docker into a successful business pretty much overnight. So, not sure what lesson to take from that. The product that we ended up monetizing successfully in what, 2020 let’s say. It had been there for four years. You just had to put a price tag on it.

YC Twice?

Mike: So, you’re a new entrepreneur. Are you going to recommend going through the Y- Combinator?

Solomon: Yes. 100%.

Mike: On your second start-up, did you go through YC again?

Solomon: I did.

Mike: Can you talk a little bit about why? Like, you knew everything from the first time around, why did you do it again?

Solomon: It’s a complicated answer. The shorter version is, I joined a little bit later. It’s three of us co-founders at Dagger. My two co-founders, Sam and Andrea, they were first employees at Docker. They left, and they started something new. And I joined a little bit later. The reason I joined later is because I was taking a break, and I was a visiting partner at Y-Combinator for one batch. If you do this thing, they invite entrepreneurs to be a partner for a little while. At the same time, they were asking me the exact same question you asked me, “Hey, should we join YC?”, and I said, “Yeah, you should join YC totally. You’ll meet new people, you’ll get a lot of help.”, because they were first-time founders.

And they ended up assigned to me, so I was their partner, one of their partners. We spent a bunch of time together at YC. I was a partner, they were founders, and we talked about their idea what to do. And then, we got excited about it together. And at the end of the Y-Combinator batch, I joined as a founder, which means that now we’re a YC company, but like technically, I did not go through YC as a founder of the first time, if that makes sense. I did not have the opportunity to make that decision. But if I had had the opportunity, I would have done it.

Because I had been through YC, but my co-founders hasn’t. So, as a group of founders, we had not gone through it together. And that’s very valuable. And also, YC got better over time. New partners, new programs, new resources, and more importantly, more alumni.

So, the other founders in the batch are some of the smartest people you’ll meet. Being surrounded by other founders and talking about your founder problems with them, and then staying in touch and growing your network that way and helping each other after you leave Y-Combinator. That’s incredibly valuable. I always tell everyone, you should join YC if you can. And if you’re an outsider, or a first-timer, then even more so.
And if you say, “Okay. I’m a second-time founder, I’m not going to do it.”, I’ll still say you should do it, but I understand the way you’re not doing it. If you’re a first-time founder, there’s no reason not to go through YC, if you get a chance.

Advice for Open Source Founder?

Mike: Last question. Do you have any final advice for founders who want to use open source as part of their business model? Just some quick advice.

Solomon: Yeah. I would think of it as a tool in your toolbox, as a founder. It can be the perfect tool, or it can be the wrong tool. It really depends on your product, your positioning in the market, your strengths as a founding team. So, I would not blindly apply a playbook. And I would always make sure that if you’re open sourcing something you know why, especially for engineers, engineer founders.

There’s always a pressure to open-source everything, because you want to be loved and respected by your peers, giving things away. Open source is just a shortcut to that. Sometimes, the right answer is to not open source something to withhold it. And sometimes the answer is to open source. It really depends on the situation. So, be strategic about it, my general advice.

Closing Credits

Mike: Solomon, thank you so much for sharing all this with our audience, thank you so much.

Solomon: Thank you.

Mike: Thanks to the Dagger team for volunteering Solomon, to Alex from Resonance Public Relations for suggesting this interview, and to the CIVO Navigate team for the logistical help with the recording schedule.

Don’t forget to check out CIVO Navigate next year if you want to learn more about cloud native technology.

Cool graphics from Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere. 

Next episode, in a slight divergence from the format, we’ll hear from Patrick Bachmann of Open Ocean, in his role as Venture Capitalist that funds high-growth open-source software start-ups, informed by his roles at MySQL and MariaDB.

Until next time, thanks for listening.

The post Episode 68: Solomon Hykes, Co-Founder / CEO Dagger first appeared on Open Source Underdogs.

Intro

Michael: Hello and welcome to Open Source Underdogs! I’m your host Mike Schwartz, and this is a special episode to promote the inaugural Open Source Founder Summit, which is happening in Paris, May 27^th and 28^th.

Talking about this event is Emily Omier, host of The Business of Open Source Podcast, and along with Luxembourg Passbolt, is providing the initial activation energy to get this new institution of open-source entrepreneurial collaboration off the ground.

If you haven’t heard of Emily’s podcast, you should add the Business of Open Source to your favorites’ list right now. She’s recorded more than 200 episodes in the last 4 years. So, if you listen to all of them, I guarantee you’ll be much more prepared for your start-up journey.

Why Launch the Open Source Founders Summit?

Mike: Okay. Here’s the interview with Emily, so she can fill you in on the rest of the detail and why she’s interested in doing all this work to make this event happen. Emily, thank you so much for joining us on Open Source Underdogs today.

Emily: You’re welcome. Thank you so much for having me, Mike.

Mike: The reason I thought this would be a good idea is because I heard that you’re organizing a new conference. Maybe you can tell us a little bit about why you’re doing this?

Emily: Yeah, that’s an excellent question. So, the conference is called Open Source Founder Summit, and we can also have a long argument about semantics about whether it’s a conference, or a summit, or whatever it is.

A retreat, the rationale, or the motivation behind this event is several fold. I am a positioning consultant for open-source companies. I go to a lot of open-source conferences of all kinds, including actually a couple that are focused on business. And I always felt that there wasn’t any events that sort of represented the entire breadth of open-source businesses.

So, there was actually a specific conversation that I had with somebody before the Heavybit DevGuild’s conference focused on open source last May, and in this conversation, this other person was talking about how there’s no unicorn open-source companies in mainland Europe.

And I said, “Well, what about Odoo?”, which people don’t know about it is an open-source company that’s based in Belgium, that has 2000 employees around, and in fact, actually does have a $2-billion valuation. But anyway, this person I was talking to was like, “Oh, no, no, Odoo is a unicorn.” I actually didn’t have the numbers there with me, so I was like, “Okay, whatever. I’m not sure.” I didn’t argue back.

But it got me thinking about the fact that Odoo, which you may have noticed, is like one of my favorite open source-companies success stories – it’s totally left out of a lot of these conversations because a) they’re in Belgium, which is like fabulously uncool, it’s like as far away from the tech centers as possible. Maybe not quite, but it’s like, they’re in Europe, and they’re not even in Berlin or London – they’re in Belgium.

They’re not Dev tools, they make business applications, or like an open-source SAP, and so because they’re not Dev tools, they’re left out of a lot of the conversations about open source.

They didn’t go public, they did get some venture backing, but most of it was a while ago. They’re a profitable company. Basically, like they’re a company that I think most founders would consider a massive success, and yet, sort of left out of the conversation.

I was feeling like a lot of non-Dev tool open-source companies were left out of the conversation, a lot of non-venture-backed open-source companies were left out of the conversation, and it just seemed like there should be a place to get open-source founders together that was going to represent sort of all the different voices of open-source companies.

I’m going to add one more thing, which is, that, in general, I think a lot of conference talks are not super actionable, and I wanted to create a conference that was going to have content that was really actionable for people.

What is the format?

Mike: I was thinking about this last night, and I was wondering what the format is going to be. Because almost all the founders could probably be speakers. So, what do you envision the format to be, and how do you see this differing from, for example, I interviewed Joe Jacks a couple of years back, when he started, or launched the Open Core Summit – how do you see it being different? And what do you think the format’s going to look like?

Emily: First of all, this is a small event, so, maybe 6 years from now, this will be a bigger event – we’ll see. But we have a maximum of 100 people. So, that, in and of itself, is a different format from a lot of events, but we do have a couple of speakers, we have 10 that we’ve reached out to and are sort of the main speakers in the mornings.

But there’s also going to be lightning talks and breakout workshops. And the hope is that everybody who wants to do either a lightning talk, or to moderate a workshop, a breakout workshop, will be able to do so.

Another thing that’s different about this conference is that it’s invite-only, it’s curated. You can request an invite, BUT that means that only people that we, the organizers, feel like have something to contribute to the conversation are going to even be in the room. And this, I think, is very different from a lot of conferences where anybody can buy a ticket and show up.

Why Paris?

Mike: We didn’t mention the dates. I believe it’s the last week in May, in Paris, but maybe you can tell us a little bit about why Paris, and how’s the weather in May in Paris?

Emily: The dates are May 27th and 28^th. I am an American and I do live in Paris, so yes, part of why it’s in Paris is because it’s convenient for me. I am organizing this conference with somebody else – his name is Remi Bertot, he is the founder and CTO of Passbolt, which is a security-first open-source password manager.

They are based in Luxembourg, so Paris isn’t terribly inconvenient for him either, but I actually think doing this conference in Europe is also just in and of itself a good idea. Or I will say, particularly not in Silicon Valley.

I feel like part of the goal is really to create community among open-source founders and have this broader conversation. If you are a founder and you live in San Francisco, it’s much easier to find community and to know other open-source founders, whereas if you live even in a place like London or Berlin, it’s actually quite a bit harder to find that community.

And one of the goals here is to create community among open-source founders. And I should mention that our real hope is that this isn’t just a one-off event, but that it sort of becomes something that’s both an annual event that happens every year, but also that there’s sort of a community that brings people together throughout the entire year.

So, yeah, I think having it in Europe as a way to, again, bring more types of open-source companies, who don’t fit the mold of just like your standard Dev tool venture-backed Silicon Valley company, I think it makes a lot of sense.

Mike: And the food’s going to be really good.

Emily: I didn’t talk about the weather. The weather is usually quite good in Paris in May. Bring your spouse, bring your spouse!

Who can attend?

Mike: Yes, that could be one of the selling points. And a quick pitch. I heard you mention that Remi from Passbolt is going to help you organize this, and Kevin Muller from Passbolt, we’re arranging for him to be on The Underdogs podcast. So, sometime in the next month or so.

That’s another great company that people don’t know, all the time based in Europe in the security space. If you’re not a founder, is there any room for non-founder who else might want to attend this event?

Emily: Yeah. If you’re in a leadership role at an open-source company, you should come. We are calling it Open Source Founder Summit, but basically, if you lead marketing at an open-source company, you lead product at an open-source company. Even if you’re not a founder, this is like a place for you to be.

I just didn’t want it to be like 50% investors, for example, or 50% people who are going to be trying to sell to the founders. You don’t have to just be a founder, we do vet people, so you can’t just go to the website and buy a ticket – you might have to make a case. But, like I said, if you’re in a leadership role, it’s just going to be me, sending you an email with the ticket link.

Takeaways from Podcast

Mike: Some of my listeners might not know that you host a podcast called The Business of Open Source has more than 200 episodes, which is amazing. Can you tell me a little bit about the podcast and sort of your journey with a podcast, what you’ve learned along the way?

Emily: Yeah, sure. I do host the Business of Open Source, I take a pretty broad mandate on talking about the business of open source. So, I talked to founders, but not only founders, I also talked to other people in leadership roles, I talked to investors, I like to talk sometimes to big companies, and there’s actually some interesting things that I’ve learned from having so many conversations with people.

Actually, I think that this is one of the reasons why I’m so excited about having like a slightly wider lens on open-source companies.

First of all, I think there’s more business models for open-source companies and people sort of realize it a lot of times. I almost feel like we talk about open core and SaaS as if they’re the only options, but they’re not. And I think that it’s really interesting to talk with people who are trying to sort of novel ways to monetize open source.

Another takeaway I have is that it’s really good to sell to the government. If you’re an open-source company, governments really like transparency and being able to run their code on-prem, or run their software on-prem and stuff. So, that’s definitely a takeaway.

Some other takeaways — I actually did a talk about this at OpenCore Summit in December — another takeaway that I have is that open-source companies can be really hard mind games. Not just for founders. I think this is really underappreciated actually. Because it can be really hard to hire people who have experience with open-source companies.

If you’re starting an open-source company yourself, you hire a salesperson for example, and that salesperson has never worked in an open-source company, doesn’t really know what process is like.

And it’s different, and they’re going to have more of a learning curve than they expected, and there’s going to be all this weird stuff about like losing deals to your own open-source project that’s going to mess with their head. And it’s just something to be aware of, I think. If you’re running an open-source company, think about, is this a mind game for yourself, but also what about the team.

Still Learning after 200 episodes?

Mike: So, along the way from doing this podcast, what I’ve discovered from doing my own podcasts is that open source is way more nuanced than I thought it was. And did you think you knew a lot going into the podcast about open source, and have you been surprised, and are you still discovering new stuff even after 200 episodes?

Emily: I did not think that I knew a lot about open source when I went into the podcast. I mean, I’m constantly surprised. Sometimes by really dumb stuff, like, somebody mentions a project, and I haven’t heard of it, and later you are like, how the hell did I not hear about this. Like, you really feel like an idiot. That still happens to me. Stuff just like ideas, or concepts, that haven’t come up before. Yeah, I’m always learning. And I would say this, sometimes people have asked me, “What’s your secret for staying up to date?”, or whatever. It’s like the secret is the podcast. I do really enjoy doing the podcasts, and I learn a lot from it.

Focus of Consulting?

Mike: Okay, maybe one last question. Because I think you said you are an open-source positioning consultant, can you tell us a little bit about exactly how you help companies, like what does your consulting work revolve around?

Emily: That’s a really good question. I am a positioning consultant, and I work with open-source companies. And fundamentally, a lot of my work revolves around helping companies a) figure out how to place their entire company in the marketplace and b) figuring out how to manage the relationship between their product and their project. Both things are really critical.

So, a lot of people think about positioning, and they think about marketing. This is actually false, so positioning is fundamentally about understanding your place in the ecosystem you’re working in, even which ecosystem you want to be playing in, and then, understanding the differentiated values of your project and of your product, understanding the difference between the two.

And that is going to have cascading effects through your product roadmap, your project roadmap, your whatever marketing you’re doing for each of those things, and whatever you’re doing for sales for those three things.

So, I think of product sales and marketing as like the pillars of go-to-market, and that’s what I help companies figure out. But because I specialize in open-source companies, it’s largely about being really clear on the nuance difference between project and product.

Final Thoughts

Mike: A lot of people don’t know that the reason I started this podcast was to help other founders not make the mistakes that I made in starting my open source, and getting a lot of the things that you’re talking about confused, or not positioning well. So, I think there’s a lot to learn. I would encourage everyone to think about attending this conference. And with that, Emily, any last words you want to add?

Emily: Come to the conference May 27 – 28. If you want to lead a lightning talk or moderate a workshop, we need to know by March 15^th. You still have to buy a ticket if you do so. Because, again, everyone who’s coming, has something to contribute, and we actually hope everybody is either doing a talk or leading a workshop. But we have to have a schedule in place, and it takes some time to do that.

Anyway, we want to know by March 15th if you’re interested in doing that. But, yes, come – Paris is beautiful in May. The event I think is going to be really awesome. There is nothing like it anywhere in the world, so come.

Closing

Mike: Emily, thank you so much for sharing all this info. Best of luck. And I wish I could be there, but I’ll certainly be following online.

Emily: Excellent. Thank you, Mike.

Mike: The website is 05f5.com. May 27th and 28^th, in Paris.

If you’re an open-source leader, it’s a great opportunity to learn from and with your peers and have epic bragging rights about being at the first Open Source Founder Summit.

Cool graphics from Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere. 

Next week, Peter Farkas, Co-founder and CEO of FerretDB. Until then, thanks for listening.

The post Episode 66: Open Source Founders Summit 05f524, with Emily Omier, Founder first appeared on Open Source Underdogs.

Mike Schwartz: Hello and welcome to Open Source Underdogs! I’m your host Mike Schwartz, and this is episode 65 with Nick Schrock, Founder and CTO of Dagster, a platform that helps companies create data pipelines, which is critical to transform and update data in order to make it useful, for example, to generate reports, content, or other actionable information.
Dagster might not be a blueprint you can emulate. Like all start-ups, there are some hard to replicate serendipity that enables Nick and his team to build this amazing company. But as Machiavelli says, “Great leaders need both – fortune and virtue.” In other words, you need to be good at what you do, i.e. virtue, but they also need some good old-fashioned luck.

But what separates a really successful founders, like Nick, is the ability to harness fortune and virtue and combine it with some deep insights about the market, and turn it into a profitable and fast-growing venture not easy to do.

So, with that said, let’s cut to the interview, and let Nick tell you, in his own words, how Dagster evolves.

Early Career

Nick Schrock: Great to be with you.

Mike: Nick, thanks for joining us today.

Mike: Can I just go back a little bit and ask you to share some of your story about how you ended from going from the University of Michigan Computer Science to working at Facebook? So, that early period – how that happened?

Nick: Oh, I wasn’t expecting to talk about the preface book days. I’ll do the quick version of that. I graduated from Michigan in 2003, and I actually went to work at Microsoft, right out of school. And Microsoft’s a great company, and they treated me well, but… 

And actually, the division I was in was the developer division. And I thought that they were just extraordinarily talented, but at that time of my life, that wasn’t for me, in terms of working at a big company.
I wasn’t actually sure if I wanted to do software anymore, so I went to the London School of Economics for a year, because I thought I might want to go more into finance, or even government service – you know, I was a young man kind of searching around.

But I ended up getting back into software. I worked for a healthcare start-up out of Ann Arbor, which is where Michigan is, for what – 2 and a half years.

And then, I went to Chicago to try to do a start-up. That was very quickly spun down because me and a friend, who had worked in the finance industry, we wanted to do it, but then, it was about 6 months before the financial crisis.

So, that was incredibly poor timing. I spun that down, and actually, turns out a friend of mine, who I knew from Microsoft, kind of heard that was on the open market, and he just reached out and was like, “Hey, I’m working at Facebook, it’s really a special place. You should consider looking at it.”

And I was looking at staying in finance in the Chicago area. And I flew out to Facebook, and it’s just the vibe difference between a place like Facebook and a hedge fund in Chicago cannot be overstated.

You know, everyone at Facebook was young, super excited, idealistic, the office was incredible – there was just all this energy versus all these miserable people working in the hedge fund. So, the choice was obvious from there. And then, off to the races after that.

Why was Facebook so innovative in 2009-2015?

Mike: So, what was it about Facebook in 2009 that made it such a hotbed of innovation? Like, what new problems were they trying to solve?

Nick: The engineering-driven culture there, combined with the actual product that was being built. So, the product grew at unprecedented rates, it was used in unprecedented ways and was data intensive also, in kind of an unprecedented way.

We were forced to kind of do a lot of innovation on the fly in incredibly constrained environments actually, both in terms of resources, timing – you know, we had to get stuff to work. And I think that it is true that those constraints do breed innovation.

And that time of period was interesting because in 2009 – how to put this – we weren’t really taken seriously as an engineering organization, I felt. And then, fast forward say 4 to 6 years, and we were taken very seriously as an engineering organization.
It was really cool to participate in that. And in the end, if you look at the output from that eng org at that time, it really is pretty extraordinary in terms of what systems were built internally as well as what was open-sourced.

Technical Origin

Mike: So, few years back in 2018, after being at Facebook for, I guess, maybe 8 or 9 years, you decide to start a company called Elementl, which becomes Dagster Labs. Can you talk a little bit about how that came about?

Nick: Near at the beginning of my tenure at Facebook, I helped create this team called Product Infrastructure, whose mission was to make our application developers more efficient and productive. So, concretely what that meant is that we build internal frameworks and abstractions for the engineers who actually built the site and the mobile apps to build product.

That team did a lot of great work, and we ended up externalizing about a bunch of that work in the form of open source. So, React came out of that group – I had nothing to do with React, but kind of the people across the hall from me, so to speak, produced React. And that obviously went on to be an extremely successful open-source framework. And then, what I’m personally more affiliated with is, I’m one of the co-creators of GraphQL.

I’ve lived and breathed developer tools for a long time and also seen the impact that open-source adoption at scale can have. So, that was definitely on the mind when I left Facebook in 2017, and figuring out what to do next.

And in fact, I was going around the Valley and talking to companies, both inside and outside the Valley actually, about what their biggest technical liabilities were.
And this notion of data, an ML Infrastructure kept on coming up over and over and over. And I decided to dig into this, and very quickly I discovered that this area kind of pattern matched to what I care about and the types of problems I want to work on, typically the things I like to work on is to share a bunch of properties.

One are just engineers in pain. Like their dev workflow is broken, they have bad abstractions, they’re not productive, and purely because of tooling and abstraction reasons – that actually kind of makes me angry and frustrated on their behalf. And on a personal level, I feel that is really motivating.

Second involved finding – yeah, I like to call it like “a problem that matters”. I like working on really broad horizontal problems that could potentially have impact on millions of developers, kind of core essential problems that matter.

I was data engineering adjacent at Facebook, I wasn’t a practitioner. Data pipelining is extraordinarily important actually. People like to dismiss it as data cleaning, or they are kind of data janitor work, but when I looked at it, from kind of fresh perspective and I really thought about it, I was like, listen, data pipeline, they produce these assets, these data assets that drive all analytics, all the dashboards that you work with, all the ML models.
And if you really think about it, these data assets drive a huge proportion of human decision-making and automated decision-making in our entire society. Who gets mortgages or not, how do we price health care, what kind of news do you see – these are fundamental essential things, and it needs to be built on solid foundations.

And the fact that it – in my opinion – like, it was not built on the appropriate tools and processes, and everyone felt it was like chaotic and out of control all the time, was deeply disturbing. So, things were fundamentally, and still, in some ways, are fundamentally broken in data ML engineering. So, that’s really motivating.

Another thing, another property is that I like working on technologies that are sort of a strategic point of leverage in an organization. GraphQL fits that bill. Because if you kind of can intermediate all client-server interactions with a common software layer that has rich scheme information and stuff like that, it’s like an enormous point of leverage for tooling.

And in the data space, I quickly gravitated towards the orchestration layer because I felt it had the same properties. You know, orchestration orchestrates data pipelines. That means, it invokes every single runtime, it touches every single storage system as a result. And then, likewise, any practitioner that wants to put a data asset or pipeline into production has to interact with orchestrator in some way shape or form. So, a strategic point of leverage, I thought that was super, super industry.

And then last, like some feeling that you have a technical insight that’s novel and interesting, and that’s kind of how we got to this notion of — at the beginning we called it Software Structure Data Sets, but now we call it Software-defined Assets in data pipeline.

And the basic idea is that instead of just writing a bunch of imperative tasks to string stuff together, you instead think about it, you write a software representation of the data asset that you end up wanting to ship to production and be consumed by our downstream stakeholders.

So, that was a very long answer, but I found a problem that kind of checked all the boxes, for what I like to work on. And it’s not just checking boxes – if those boxes are checked, I’m like deeplypassionate about it. That’s kind of how I got here.

Business Origin

Mike: You started working on this problem at Facebook, but then you said at some point, you sort of hit this critical mass of like pattern matching, like you said. And you’re like, “Okay. I’m going to start actually a business. Maybe in Silicon Valley, it’s not terrifying, but it’s a big step.” How did that actually work? When did you decide, “I’m going to start a company.”?

Nick: It’s funny. I’m struggling to recall exactly when it happened, but I knew founding company was definitely something I was very interested in doing. Both in terms of working on a product, but also building a culture, and especially engineering culture.

In terms of company building, that part was very motivating. In a lot of ways, I was talking about how I thought the kind of the output and culture of early Facebook engineering was pretty extraordinary. And replicating the good parts of that in an independent organization was super appealing to me as well.

I think I just started talking to people and my message and the problem I identified really resonated. And then, I was talking to some investors, actually not with the goal of doing a fund raise – it’s kind of funny how it works like that – but there was like, “Nick, you want to look at data pipelining, with your background and, you know, work on something, that we should really think about formalizing this with some capital and a company, so you can accelerate your progress.”

It’s one of those things that almost just kind of happened. And I’m a big fan of, “Be an opportunistic.” It’s also true that from the time I left Facebook, I knew that founding a company had a lot of appeal to me.

Transition to new CEO

Mike: One of the podcasts previous guests, Sytse Sijbrandij, once asked me, “Do you love the product, or do you love the business?” And it’s an interesting question. I think I know were you following that spectrum. And can you talk a little bit about how you came to work with Pete Hunt, the current CEO, and do you have any advice for founders on how to navigate when there’s a pivot in the leadership?

Nick: I might like the business more than you would expect. I obviously – I don’t want to put words in your mouth – but I’m assuming you think I like the product more than the business. Actually, I did a bunch of economics and business in college and then the grad year in LUC, and I thought about doing MBA, so I’m definitely a business-minded. I imagine I annoy our FinOps people because I always like dig in about all the financial metrics and whatnot.

Yeah, we can get to Pete. I knew Pete from the Facebook days. He was one of the co-creators of React. We didn’t work really in-depth with each other then, but we met each other socially and through each other’s work, and really kept in touch for a long time after Facebook.

He wrote a small seed check into the company. We also collaborated actually on some podcasts because we were kind of obsessed with this Facebook engineering culture, and we actually put together a podcast series, Software Engineering Daily, with like 15 ex Facebookers, and we learned a lot about each other during that process.

Pete had started a start-up and sold it to Twitter, and he was working on Twitter. And I was also talking to him on and off about the business. And I was in the market for a head of engineering in early 2022, and Pete and I discussed it. And I was privileged enough to bring him on board. And given his experience, formerly being a CEO of a Dev tools company, he had built a marketing organization, and the sales organization and scaled to $5 million ARR.

I knew he was going to be much more than a head of engineering – I even had super high expectations for that – but he really dramatically exceeded those expectations. And I think, it became very obvious to me that he was just way better operationally than I was, in terms of like the mechanics of management, organization building, managing marketing, managing sales – he had done it before, and it was pretty clear.

I, at the time – just to be transparent – I was solo founder CEO, I moved around the country a couple times, I had 2 little kids. Now they’re 2 and 4, but I’ve also started a family during the course of this journey – I just needed like a co-founder figure to share the load.

Because I didn’t have the time to work on what my superpowers are, which is kind of this cross-product of Engineering, Dev Rel and Marketing I think is where I excel. And the other stuff is like, he could do a much better job with that. So, it just made a ton of sense.

I think I’m very lucky in that I don’t think it’s a repeatable process for a lot of founders to do what I did. Because you need that other human, who you know well, who would have been I think if Pete had his own company at the time, we might have just co-founded something from day one, and had like enormous trust context in – like, the transition to bring him in and then move him to the CEO position was like super smooth. I think it was like super obvious to everyone they knew it wasn’t going to be like this massive culture shift. Because like Pete and I are still aligned on so many issues.

I think the entire team was super excited about it, and the transition was really smooth – no leadership changes, no attrition, the company started performing better. I think it was obvious pretty quickly that that is the right move.

Monetization

Mike: So, diving into the business a little bit, how does Dagster monetize? I see a cloud offering, is there also a license enterprise distribution?

Nick: No. We only do a cloud product. So, just for context for the audience, Dagster is a data orchestration platform. And you can think about it like, you write data pipelines in this Python framework for building data pipelines and orchestrating, meaning, ordering computations and modeling the assets that get produced by those computations.

You can install it open source, and people have deployed that to production – a ton of people, I should say we have thousands and thousands of users – but the cloud product allows us to do a ton of the hosting on your behalf.

Most of our enterprise customers have this hybrid product, where we host the control plane, which you think about it like everything is complicated – the metadata database and long-running processes that monitor things and whatnot. Then, they run their actual compute, it’s their data pipelines and their infrastructure.

So, yeah, there’s a cloud product you sign up for, we can host a bunch or all of the compute. And then, also, we add enterprise features on top of it – SSO, alerting, gobs and gobs of features that generally deal with complexity in the Enterprise that companies typically pay for.

So, that’s our primary business model: you sign up for Dagster cloud, you swipe your credit card or talk to our sales people, and you can have the best experience of a data orchestration platform in the world in our opinion.

Why sell small customers?

Mike: I noticed that Dagster sells to small teams – like you said, you can sign up for like 100 bucks – and also to large enterprise. I’m wondering does the small teams’ business actually add up to real revenue, or is it just a pipeline for enterprise customer?

Nick: I think in terms of what investors care about, and what the long-term trajectory of the business is, we certainly conceptualize it as mostly a driver of pipeline – yes – but a broader adoption as well. So, there’s tons of users that use our hosted product that wouldn’t use our open-source product. And simply because they don’t want to host their own computing infrastructure, which is totally reasonable.
So, I guess, if you kind of boil everything on the business, yes, there is – it is a source of enterprise leads, for sure, but it’s also a source of more adoption, which means more people talking about the product. More people having being passionate about the product.

Because an underlying flywheel adoption is also essential for the long-term commercial success of the company.

I think like that’s the most interesting component of it. It used to be, say 10 years ago, that you’d have an open-source product and you’d be like really pulling teeth to use the commercial or the hosted product.

I think the pendulum is really shifted now, where tons of people wouldn’t consider adopting an open-source technology if it didn’t have hosting options. Just because of the way that the entire world has shifted towards more hosted services, which is I think a win-win for everyone involved.

Pricing

Mike: One of the underappreciated challenges of a tech start-up is how to price your offering. I saw a note on the pricing page about an old plan and a new plan. The new plan’s a little complex – not being an expert, I couldn’t really quite follow it. Can you talk a little bit about the pricing journey and where and why you ended up where you are?

Nick: Totally. I like to say, if building an infrastructure company were a video game, pricing is the final boss. And that actually even undersells it. Because iterating on your pricing model is a continuous process, where you have to make sure that it’s working for everyone involved, that we can run a healthy business and that the customers feel like they’re getting a fair deal in terms of — because in the end, they need to get more value than they paid for.

You are correct to point out that the initial pricing was simpler than the current model. Initially, we started out where we wanted to have like no seats limit and just charge on consumption. I felt that a very fair way of doing consumption was to just charge on the number of minutes your pipelines run.

So, the issue with that – and I think this is a good takeaway for your audience – is that customers have to morally accept the pricing plan. Like, it has to make sense to the underlying way that they think. And the problem in a data pipeline solution, if you’re charging by, say by runtime, is that frequently what you’re doing in orchestration is that you are like calling out to Snowflake or Databricks or some other heavyweight computational system that does all the heavy lifting of the compute.
So, from the standpoint of the customer they’re paying us just to kind of wait for an API call to complete. That shifts the mind of the customer to think of us as just a compute hosting service.
And if you’re just doing that, the value proposition of our product doesn’t make sense.

So, the pricing impacts the way that the customer perceives the value of the product, which is obvious when you say it out loud, but isn’t obvious when you’re kind of in it.

We’ve really stepped back and looked at this – the real value in an orchestration system is in the kind of the control signals and the metadata. Like, concretely, you open up a orchestrator, or our orchestrator, and you see all these fancy Gantt charts of what’s going on, you have a ton of visibility, and then the words that our users often use is, “Ugh! Dagster is like the single pane of glass that consolidates my entire data platform, I have visibility into all this stuff.”

So, that’s where they perceive the value. They do not perceive the value like it’s a hosted compute service. That had the benefit of being simple, but didn’t actually align with the product value that the users perceived.

We switched to charging based on metadata and control plane events that drive our UI. I think the other thing is that for founders in the audience is that you have to have a pricing model that works for sales. And early on, you don’t have enough data to know how much consumption there’s going to be for a customer, for like say the next 12 months. And with the way sellers work, they have to hit their ARR number ― that adds up to their quota, that determines whether they can feed their children or not. So, it’s very important to the sales team.

We had to also add sort of a per seat component that effectively acts as a platform fee for our enterprise customers that allows us to kind of project and forecast ARR that would be appropriate to the value it’s going to deliver to the customer.

You also have to think about the internal incentives and how it’s going to work for sales people, who are reliant on selling your product in order to send their kids to college.

Why Audience Selection is Important?

Mike: I am going to pivot a little bit back to tech for a second, but really more to talk about the open-source community. What’s interesting about Dagster is that it reminds me a little bit about the battle between Perl and Python. They were open-source tools in your area that existed before, but they were a little bit hacky or more challenging.

Can you talk about what are some of the challenges of building an open-source community in an already competitive market, where you needed a lot of features just to get the baseline of functionality? And then, how did you focus on either getting new, or getting some of the developers to switch into your platform?

Nick: You need to make sure that you have an audience that cares about what you care about, and it is very differentiated on that dimension, to the point, where they are willing to take a risk to bet on you, to work around missing features or missing integrations that might exist in a more mature solution. So, identifying that small subset I think is extremely critical.

There’s now, I think, a kind of standard reading for Silicon Valley founders, which is Peter Thiel’s book Zero to One. And he talks about how you start with a small market and then dominate it, and then move on to progressively larger markets. And I think that really, really resonates with me, especially in developer tools.

One kind of approach – and this is kind of the nature of tools that I like to work on too – is that what you can do is pick the audience that you think has the most leverage in the organization. And for us, it’s like the data platform engineer. Like, there’s engineers whose entire job in life is to serve stakeholders who build data pipelines on top of a data platform that they build.

And a huge part of that is setting up a great developer workflow with CICD and testing, so you can actually maybe know if you’re going to break something before you push to production, which is very frequently not the case in data pipeline.

I think our early audience was really people who really got it that testing, and fast feedback loops, and developer life cycles, is like the baseline foundation of productivity. And productivity is just huge in working in the software. Because productivity is not just about doing tasks more efficiently, it’s about making an entirely new things possible.

So, yeah, I guess I kind of went for a field there, but to circle back to the beginning of the question, I think it’s audience selection and being deliberate about that, it’s really what’s important.

Governance

Mike: Recently HashiCorp has changed their license, and I see that Dagster’s published in its own GitHub repo, so you’re under the Dagster repo. Dagster is your trademark. How can you assure the community that if the board decides to sell the company to Oracle, for example, that they won’t change the license immediately? And have you considered moving the Dagster open-source project to community governance and making it safer to use for the future?

Nick: As someone who’s gone through a foundation process for another technology, we moved GraphQL to its own open-source foundation with community governance. I have a pretty deep understanding of the trade-offs here. I think it’s a question of maturity and life cycle. The risk that you said exists. There could be a boardroom coup, and I’m out and Pete’s out, and then, we’re sold to Oracle or something.

By the way, the probability of that is approximately zero, but let’s theoretically do it. And then, Oracle could change the license―that is possible. I don’t think that’s a realistic risk in any sort of near-term.
So, if we had community governance, it would eliminate that risk. However, community has a ton of it overhead. And where does the beginning of our journey for innovating, and we want to be able to move quickly and respond to feedback quickly, build features, have complete control in that way.

And that’s definitely the right trade-off for us right now. Compare and contrast that to the GraphQL story, with GraphQL, we open source the spec, a document that was meant to be very stable from day one, and evolved pretty slowly over time. So, in terms of the technical artifact there, it actually matched like having a foundation process and governance over it made a ton of sense. But for Dagster and the immediate future, we’re having more centralized control, and increased pace of execution definitely makes the most sense to us.

2023

Mike: I’m going to move to a temporal question about 2023. A lot of tech companies struggled in 2023. The Times reported that 3,200 venture-backed tech companies went out of business in 2023. Of course, I don’t know how many normally go out of business, but still it seems like a lot. I was wondering, was 2023 a good or a bad year for Dagster? Did you buck the trend and grow 100%, or did you also feel pressures on budgets from enterprise customers?

Nick: We had a great year. So, not only did we grow 100%, we grew 400%, and our NDR was north of 150%, which means, our existing customers were also increasing their contract sizes. I feel great about the business, especially being able to grow this quickly in this environment. I am also grateful that we didn’t raise round of financing in a wildly inflated valuation, with too much capital in the FED bubble in 2021.

Because, at the time, certainly, it was frustrating – a bunch of my peers were  — you know, all of a sudden, the CEO has a billion-dollar company, even though they in reality weren’t that far along in the journey.

Now, I think a lot of those people kind of are in a pretty tough spot, and they’ve had to do layoffs, and it’s painful. We kind of stuck to our fundamentals there, so, I feel very good about it.

I still think the pain is going to be very real for the industry through 2024, maybe even into ’25. Because, yes, there’s an advantage to raising a bunch of capital too, in that you have a long runway. A bunch of these companies, they have so much cash on the balance sheet, and the interest rates have gone up that their interest is actually a meaningful source of income too.

There are more waves of company death coming in ‘24 and ’25, I guess I’ll put it that way.

But we’re in a great trajectory, and I think we’ve raised an appropriate capital to the progress in the business. And we were able to raise a B in 2023, which was a very challenging process, but it felt great to be able to do that. Not many of the companies were able to do that.

Open Source R&D v. Commercial R&D

Mike: Here’s a question, and it’s a little bit about engineering priorities: you have an open-source project of which your team contributes a lot of code to, and you also have a commercial cloud product. Can you just talk sort of at a high level, from an R&D perspective, like how much of your budget gets invested into your product versus how much gets invested into the open source? And how do you balance those priorities?

Nick: It’s actually hard to tease apart. Because, if you’re an engineer who is working on a feature that will have manifestation in cloud, often you’re kind of spanning the entire stack and like working on the open source, but then also working with some proprietary features. So, it’s difficult to cleave it that way.

The other thing is that we reorganized the engineering, the R&D organization around company objectives fairly frequently. I actually can’t give you a precise number at any point, or historically/cumulatively, about how much we’ve devoted to both open source and the cloud product specifically.

I guess what I’ll say is that we still invest a ton of our eng resources. I would say like 40% of engineers effectively work exclusively on the open source, and then there’s another tranche that kind of spans the entire stack, and then there’s another tranche, like people who work on our cloud platform, and all the DevOps and SRS work around keeping that alive and operational.

I don’t know, I guess you can call 50/50, but it’s actually really difficult to put it even semi-processed number on it.

Dog Years

Mike: Well, it sounds like it’s really been an amazing journey. And I’d like to remind you that it really hasn’t been that long either. Only 2018 doesn’t seem that long ago to me.

Nick: Well, it seems like a long time to me, man! That’s the old joke. It’s like dog years in a start-up, one year feels like seven. I have to pinch myself. I only moved away from the CEO seat like 15 months ago or something. And it feels like a lifetime.

Founder Advice

Mike: We covered a lot of topics, but I guess, my last question is, is there any advice you have for entrepreneurs, who are launching a business around an open-source software, product or project?

Nick: I think one of the things that founders need to think about — I mean, this could be an entire hour podcast about all the advice that I would say, but couple things to think about: one is, know when to go slow and know when to go fast, especially when you’re talking about so-called “one-way doors” in Jeff Bezos speak, where you’re making decisions that are either extremely costly or impossible to undo. Company branding is challenging to change in terms of the specifics of open source and dev tools, API decisions, especially in open source, last forever. You need to be deliberate on that.

And a commercial product, you can actually iterate extremely quickly. So, I think it actually is important to kind of have two cultural muscles. One is much more upfront design-oriented and collaborative with community, and deliberate and thoughtful on API design, but you still want to have that super-fast feedback and development when you’re developing the commercial components to your product that are hosted.

The other thing I would optimize for – if I was traveling back in time and talked to myself – is optimize for getting yourself into a situation where you can have a super-fast feedback loop, with early users and customers, where you still have the opportunity to change things, and do so quickly.

If you’re in a super-fast feedback loop with a single customer, you can make API changes much more easily. And the ideal situation still is, if you are working on a technology internally at a company, where you have access to all the code that uses it, that is just super valuable.

You’re also basically getting a seed round for free, because, often you’ll have people around you, and you’ll be working on it.

So, I don’t think I truly internalize what an advantage that was, to have it done the core R&D internal at a company. Yeah, I think like there’s a little more resistance now to open source the internal tech with kind of — it’s a less idealistic environment these days. But those are kind of the top-level things that come to mind.

Closing Notes

Mike: Well, great. Thank you so much for taking time out of your day, Nick, and best of luck with Dagster Lab.

Nick: Thanks. It was really a joy to be on this podcast. Thanks, Mike.

Mike: Special thanks to the Dagster PR team for reaching out and helping with logistics. Cool graphics from Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere. Next episode recorded at the State of Open Conference. Peter Farkas, Co-founder and CEO of FerretDB. Hopefully, I’ll have that out in the next week or so. So, until then, thanks for listening.

The post Episode 65: Scaling Data Pipelines with Nick Schrock, Founder/CTO of Dagster Labs first appeared on Open Source Underdogs.

Mike: Hello and welcome to Open Source Underdogs! I’m your host Mike Schwartz, and this is episode 64 with Idit Levine, Founder and CEO of Solo.io, an API Gateway and Service Mesh company with a product called Gloo – not to be confused with Gluu – the company that I lead, who sponsors this podcast.
I’ve been trying to get Idit on the podcast for many years ever since I spoke with her at an Open Source Conference in 2019, and finally, her PR agent reached out to me a few months back, and, of course, I agreed immediately.

Solo is not your typical startup journey, it’s sort of a miracle it got off the ground, but once it did, they didn’t waste any time – they’re already breaking 10 million in sales.

To avoid spoiling the story, I should just stop here, so let’s cut to the interview.
Idit, thank you so much for joining us today.

Idit: Thank you so much for having me, Mike.

Did Solo Join an Incubator?

Mike: My first question, and this is sort of a different one, but it’s something I’ve been thinking about, is when you first started Solo.io – which was not that long ago, I think five or six years ago – did you join an incubator and why or why not?

Idit: I did not. I wasn’t even aware that they exist, honestly. When I started the company, what I knew is that I had some “technical” friends that I knew that I can start it, and basically started doing this – the software was more about the technology. So, I needed to learn that while I was raising money, and so on.
Honestly, Mike, I think the first VC that I met, they asked me about a pitch, and I asked, “What is a pitch, what am I supposed to do?” I really didn’t know much, I needed to learn.
I wasn’t aware of a long incubation, definitely not in those days, because it’s not very popular.
I just basically started the company around software and just tried to get some money in order to kind of like bootstrap the company. But that’s basically the things I would do. Honestly, mainly because I wasn’t aware of it.

Mike: Do you think if you could do it again, you’d use an incubator?

Idit: No. Now, I feel that they learn so much from those processes. I think it’s very good if a first founder maybe is not aware of a lot of stuff, that’s really helpful to be kind of like protected by team that has done it before and knows how to help you and guide you.

Today, I think I learned enough of the process, and I’m doing it for a while right now. I made a mistake, I learn from them, so now, I’m feeling that I’m more free to actually do it myself again, if I need to.

State of Company at Seed Funding

Mike: At the time you raise your seed funding, was the open-source project started, did you have any technology, did you have any initial customers or team? Like, what was the state of the business when you closed, let’s say, that seed round?

Idit:  No, there was nothing, honestly. Before that, I worked in the EMC. Part of the EMC, my job was to basically do cool stuff on open source. I was in business, I was in the city office, and my job was to basically, if I had a new technology and we had to figure out how we can play that. Basically, we did a lot of open source and invent development. We immediately knew that we were playing back then, in Kubernetes, Mesosphere and Mesos, and all that great kind of technology. Docker was just a new thing back then, so, again, playing in that ecosystem was immediately a thing that we’ve done.

When I started the company, there were two things that I started pitching in the beginning. The first thing that I was pitching was unikernel. It took me a few months to understand that that’s something that I would not be able to ever raise money on. Probably for good reasons.

By the time we were at home, I was pretty bored, so I built another open-source project called Squash. And that was an open-source project that related to debug microservices in Kubernetes.

And that was relatively successful project, but mainly, as I said, I think that there is a good money on it because the work that I was doing before in the open-source, I literally built a reputation of someone who is capable of doing a cool project.

How Many VC’s Pitched?

Mike: How many VC’s did you pitch in your initial seed funding round?

Idit: Oh, man, a lot. I mean, as I’ve said, again, you remember, I was on the east coast, but once I decided to do it seriously, I left the EMC, and then, I basically went to the west coast, where there is VC that is more in that space and that, yeah, I got a lot of those, a lot. I think like every founder as well.

Products?

Mike: I don’t want to go too deep into the tech, but when I look at the Solo website, I see there are a few products. I am wondering if there’s like an 80/20 rule here, where one of the products accounts for 80% of the revenues?

Idit: We don’t have 20/80, actually, that’s interesting. I think it’s probably 50/50. And the reason is because of the packages, a lot of time we’re selling them together. If you look at all the projects, the main two markets that we’re going after is, the Gateway and the Mesh market. We started with a Gateway mainly because the Mesh wasn’t — you know, we couldn’t sell it.

So, we started from the Gateway, and we knew that this is kind of like an entry point and kind of like a stepping stone to a Service Mesh, so that felt very in the area. And I believe that in the future the Mesh will grow more.

First Customer

Mike:  So, one of the challenges of a start-up is always the first customer, especially if you’re selling in the Enterprise space. How did you convince this customer to be first? What did they actually buy? And whatever they bought, does that resemble your current offering today?

Idit: Yes, actually, as I said, we started selling the Gateway, and that was a flagship product of the company. When we started, basically what we did is, we had three design patterns in a way. I didn’t do it the regular way, we did it from open source. We didn’t go and talk to customers and say, “What do you want us to build?” And then, we built it. We were more like, we’re in the open-source and kind of like say, “Okay, that seems like the right thing to do.”

Kubernetes came, you needed a new API Gateway, you wanted probably an Envoy – that’s what we believed people wanted – and then, we went to pitch.  And a lot of those customers came to us from the open-source community.

So, we learned a lot from that process. What we did, and we did it differently, because we are coming from open source, we basically managed all our relationships with our customers through Slack. Then, understood what we need to do in order to make that very, very successful in their infrastructure. And we basically got all those requirements and built them into the product. It’s very different to build an open-source project versus an Enterprise environment.

Value Prop

Mike: So, what would you say is the most important thing that motivates your customers to buy your product?

Idit: I think that today Solo is kind of like three things that we are very good at. Number one is, we really, really understand the marketing really, really well, and the technology in it, so we know what’s coming up. We know what is 20 and what is not, we’re looking at adoption – we really understand that very well.

So, we always compromise with the customer that we will bring them to the edge of the technology. If there is a new technology that is relevant, we’ll probably put it in our product. I think that’s one thing that customers like, so the perception of Solo is that it is an innovative company, which it is – it’s what we are.

The second one I think is customers in sales, which was always one of the things that is the most important to us. This work with Slack, when I started it, everybody told me that’s not going to scale. And surprisingly today, when we have hundreds of customers, it is still scaling, and the technology itself, if you look at it right now, there was a lot of shifts in the market in terms of the infrastructure that you’re running, most likely running in something like Kubernetes.

So, it makes sense that you would have a Cloud native Gateway, and when you start scaling and scaling and scaling, it makes sense that you will take care of something like MPLS and Security and Zero-Trust and Observability, and all those microservices – it’s just that this is the needed technology when you are going to scale. And that’s where the market of microservices like Kubernetes is right now.

Is Solo a Distribution of existing Open-Source Components?

Mike: Solo is an interesting company in that, in a way, you write software, you write a lot of software. But you also have a curated distribution of open-source components that you give your customers a control plane to manage and take advantage of. So, it’s not just the software that you’re writing, but without Envoy and without Kubernetes and without Cilium, you really maybe couldn’t even build a product. So, do you think that maybe this is a new model, where you add a little software on top of this huge curated distribution of other very complicated components?

Idit: Instead of creating the open-source project – we do have one, for instance, Gloo Edge is a technology that is an API Gateway based on our technology, and it is based on Envoy. I think that what we were good at was identifying, pretty much at the beginning, which of those technology would be better on Envoy, when honestly Envoy was relatively a very small community no one really knew about it, and NGINX was the chosen proxy.
We chose Istio, even though we could have competed like everybody else and tried to build a better service mesh, but I knew that that will be the choosing mesh, even though when we looked at it, it was pretty messy, and we knew that it would take you a while to get there.

I was very, very aggressive to my team saying we are not going to be competitive, we are going to use that.

And the reason is because the software that wins is not always the best software. It is the software that most people are leaning to because they will make it eventually the best software. And I think that that was something that Solo has recognized very well. All that technology, all those products that we are doing is basically we are building – and I will not say a little – we are building quite a lot of logic, ease of use and enhanced technologies on top of those — let’s call it basic component that you need.

There is a lot of complexity actually in the control plane, way more than in the data plane, for instance. But, yeah, as I said to you, this is my model, hopefully sellers will succeed with it, but yeah, I believe that open source is building an amazing technology, and that we should leverage the best.

We are also contributing a lot of those technologies. I mean, if you look at the Istio right now, the new thing that we did with Ambient that we and Google contributed to it, it’s mainly we are the main contributor to it. And Istio, we are contributing a lot to it, we have a full team that is responsible to contribute to it. If you look at this, probably I think the most engineers that are working today on Istio are coming from Solo.

How to Decide What Features Are Open Source?

Mike: I was looking at the open-core model, but I’m actually more curious about, there’s always this friction between what do we put in the community version and what do we open-source. What’s the decision process behind deciding whether a plug-in will be commercial or non-commercial?

Idit: In the beginning when we started, we had nothing, we put everything in the open source, but then at one point, we understood that that’s a problem. Because eventually, somehow, you’re not going to exist as a company if you are not going to make a little bit money at least. So, we needed to figure out that what we’re putting on to double it will make sense, we are not hard to open source because it’s very important to us that open source will be successful.

It’s why we continue contributing constantly to the open source, but we also need to make sure that we will have something that differentiates it on top of it. And the decision in the beginning when we thought about it, the Enterprise feature that people actually really, really wanted to have a provider helping them was security or stuff that will let that do. You know, Enterprise feature like HA.

So, that’s the stuff that we put in Enterprise. The question is, you are usually around technology, would it make sense to be in the core open-source project because that is where it belongs. It’s kind of like a core feature, or it’s actually an extension to that open-source project.
And therefore, it’s going to be that Enterprise edition. To us, it was very important that the core should be open. That’s the way we’re doing it.

Pricing

Mike: I always worn entrepreneurs that pricing is one of the most challenging aspects of a tech start-up in particular. Can you share maybe some of the lessons you learned about how to price in the first few years, did you get pricing right initially, did you have to do a major pivot – what was your experience there, and do you have any lessons learned in pricing?

Idit: As I said to myself, okay, maybe the real unit of contribute for instance in the Gateway is supposed to be the API call, but honestly, that will take a lot of time for me, and it’s also going to be a pain for my customers, so how can I still value how much they use it, without actually interfering too much with the customer and with my engineering team.

And what I came with in the beginning is that the data plane is usually a good assumption, because if you have a lot of call, you’d probably want to scale that data plane. And in the data plane, it’s easy to call, the customer tells me I have five clusters, this is a data plane I am using – it is very easy to measure it and if people use it more, that’s fine.

So, that was the beginning. When we added the service mesh, there was a way more data plane and there was also a way more potentially change. Because you have cycles, and the cycle is basically going directly with the application, the microservices. The microservices going up and down, so very hard to basically figure it out. We needed to change that model and we went to the cluster model.

We said, just let’s keep it simple, we don’t want it – again, it’s all about keeping it simple. That’s what was important to me. I don’t want my customer to need to have a PhD in order to understand the way we were pricing.

That’s what I did. And again, it’s probably cost me some money. I probably left some money on the table and that was fine. But again, it was all about and it is still all about Solo as the partnership. It’s all about the relationship that we have with our customers, it is a real partnership, we are seriously the extension of their team.

But, you know, stuff changing all the time, so you always need to adjust. And honestly, you are learning that from your customer. So, for instance, what we saw right now is that some of the customers that are basically using us, it is more like advanced development center kind of thing.

Innovation centers like city offices or the innovation center on the ITN, and when they are starting, usually what they want, their job is to basically build something to offer to the businessmen. So, the question is, the money is not going to come from them, you cannot expect them to have tons of budget to pay you to run it.

So, what they really want is more of the consumption model. What they want is to create something and get the platform available everywhere, without paying millions of dollars, but then, they will basically enable teams to come after. And that’s different. The model should be different, it can be how much clusters you’re running. Because it could be that you’re running an empty cluster in the beginning. So, we needed to adjust based on the customers. So, it’s always moving kind of like we are learning from the customer how we can make it better.

But again, to me, the way I’m looking at this and that’s always my motto – whether it is truthful building, writing software or selling product – I want to take the challenges on my team. For instance, I prefer right now to build a sophisticated metering that will make the best customer end-user experience for my customer, even if it’s harder.

How to Maintain High Growth

Mike: You know, I was reading an article, and it said that you were projecting five to six times growth for the next year, what is a key to obtaining this high rate of growth? How is that possible?

Idit: First of all, the market – and that’s very, very important. Like for instance, when we started, we had the Gateway that was very popular and everybody needed it, and then the Mesh came, but it took us a while until Mesh would be everywhere. Right now, there is a lot of stuff that is going really, really well for us, and that’s what is allowing us to go.

What number one is, for instance, that is still going to the graduation. So, we actually choose the right service mesh, and not only this, it is going right now to graduation which has shown maturity.
So, that by itself means that there is more demand from the market. You just need to have the right market product to sell, and when a customer wants it, it would be really lazy to grow. But I’m not going to say that there are no challenges, in economy, it could be that we have an amazing product, we have tons of money – that’s not really helpful if our customer doesn’t have money. They’re not going to buy it. Again, that point – you need to make sure that the product is a necessary, that people will need to spend money for it.

Just, again, listen to the market, make sure that you have the right market fit, which I think is the most important, thinking about the packaging, make it very, very easy for people to consume your product.

Metrics and Data?

Mike: You’ve mentioned that you’re data-oriented, and I’m wondering, what are some of the most important metrics that you track?

Idit: This is a good question. I mean, if you ask my CFO, who is a very, very data-oriented person, a lot of the metrics that is running is metrics is numbers – how many VCs we are doing, how much of it is in production and that kind of stuff. Data that I’m looking at is different than the data that my CFO, the metrics that they’re looking at. I think in every business, it’s all about people, it’s all about the people in the business, it is all about the people in the market. Why has AWS decided to do this, why has Google decided to do this, what’s going on inside this organization – all this information is not metrics, but it’s data that you need to collect in order to make the right decision.

How do I predict it five or six years ago that there is going to be a lot of clusters and that people will need a service mesh for each and Istio will be that service mesh. That was pretty crazy to do five years ago.

But I had enough data that would lead me to believe, a lot of data that would lead me to believe that this is the direction that we need to go. So, we do have the metrics of how many customer success, otherwise you cannot scale – you need to know when something is wrong and, you know, big enough organization right now that “I’m not everywhere and I don’t know everything anymore.”

What Gives You Joy as CEO?

Mike: What gives you the most joy as a CEO?

Idit: It is always your job to basically kind of like try to cover the gap that you have in the company. As in the beginning, we had engineers, but we didn’t have anybody to do evangelism, and kind of like after that, we grow, and then we got that evangelism, so I’m not doing evangelism anymore. You are always doing more stuff, and to me, the way I’m looking at this, honestly, when I’m waking up in the morning is, what is the next fire that I need to put off, like where do I have a problem with, what is not working well the way it is working right. It is seriously like that’s how you should think about it – where is the next fire will come from and how am I covering it.

And to me, I’m a person that is easily being bored, so, I like learning, I like seeing what the problem is, I’m dangerous in every position in the company, potentially. I’m dangerous enough now after six years that I learned all of those.

So, I think that, the fact that it’s never boring, but I wish it was a little bit more boring. I mean, I heard a joke from someone that said, “A founder that started a company in the last five years, what did they need to overcome?” We needed to overcome Covid, we needed to overcome the SVB with the Silicon Valley Bank fall, we needed to overcome the fact that all our competitors suddenly could have raised 100 million dollars, you know, like crazy variations with seed money.

And so, there was a lot to overcome since then and it is never boring. And I think that as someone that likes challenges, that drive “I want to be the best, I want to win.”, so, that’s what I’m enjoying.

And I’ve got an advice from Diane Greene, who was the founder of VMware. And she was one of the people that started Google Cloud, so, one of the feedbacks that she gave me when I started. She basically said to me, “You can decide which type of CEO you should be.” Keep the stuff that you really like to do or you really feel that you’re a huge differentiator. And my guess is, it is that technology is the strategic, that is my strength.

And bring strong people next to you to cover the stuff that you can give away. So, my advice is to go to market. That to me is kind of like the way I’m looking at this, but honestly as a CEO, you really do a lot of the stuff that you don’t want. I mean, your job is to fix the problem or to cover stuff and to enable the other teams. If I need to help my engineers, I will do that if I need. You know what I mean? I will do everything I need to enable the team base. That is I think very important.

What Advice Would You Give Yourself If You Could Go Back in Time?

Mike: If you could go back five years or six years and give Idit some advice, what would that advice be? It doesn’t have to be at the very founding, it could be in the early stages too.

Idit: Wow. I learned so much. It’s very challenging to run a big team and make everybody aligned. As the company’s growing more and more and more – that’s become more than another. I think that the advice that I would tell my younger Idit is basically, just follow your instincts, listen to people, but eventually, make your own decision. I think the thing that I was doing wrong in the company was, a lot of times, I’d hire a leader for market and he’d go to market. And I knew that this is not my strength.

So, even though I didn’t believe always that what they thought were doing is wrong, I let them do it because I said, “Look, they are the expert. I’m not an expert in marketing, so let them do this.” I paid a big price for it because I felt that actually a lot of times, they were wrong and it’s within the company.
So, I think that what I learned today and why I think that I would be a better leader than I was back then is because I’m going to die or succeed on my mistake, honestly. Because there’s nothing faster than us to come and take responsibility for someone else’s mistake.

Again, it doesn’t mean that you’re not going to listen, but after all the data at the beginning, if you believe, like trust your instincts, don’t assume that someone else knows your business better than you. I think that this is something that I made a mistake a lot of time, actually multiply times. Before I said, “Okay, that’s it.”

Close

Mike: Idit, thank you so much for sharing all that experience and know-how and best of luck with Solo. Although it doesn’t look like you need it, you look like you’re doing amazing, so, congrats.

Idit: You always need more luck, but thanks.

Mike: Special thanks to Idit and the Solo team for reaching out. Cool graphics from Kamal Bhattacharjee. Music from Broke for Free, Chris Zabriskie and Lee Rosevere.

Next episode’s expected Jan of 2024, an interview with Nick Schrock of Dagster. I’m slowing down a little bit, but I’m still trying to do four episodes a year.
Don’t forget the State of Open Conference is returning to London, Feb 6^th and 7^th. So, until next time, this is Mike Schwartz, and thanks for listening to Open Source Underdogs.

The post Episode 64: API Service Mesh with Idit Levine, CEO and Founder of Solo.io first appeared on Open Source Underdogs.

Mike: Hello and welcome to Open Source Underdogs! I’m your host, Mike Schwartz, and this is episode 63, with Liz Rice, Chief Open Source Officer at Isovalent, the software startup behind Cilium, an eBPF-based Networking, Security and Observability project. 

This episode was recorded in early February at the inaugural State of Open Source Conference or SoCon, which was held in London at the QEII Center in Parliament Square. The force of nature behind SoCon was Amanda Brock, CEO of Open UK and editor of the essential book Open Source Law, Policy and Practice, 2nd edition. Check it out on Amazon if you’re an open-source founder. Don’t miss SoCon next year in 2024, especially if you’re already in Europe for FOSDEM.

If you think eBPF or enhanced Berkeley Packet Filter sounds like a geeky low-level technology that you don’t need to know about – well, you’d probably be wrong. It enables developers to safely write code that runs in the Linux kernel. And safely is the key word here, because if you crash the Linux kernel, everything on the whole server goes down, all the containers, and everything else running on that server.

However, by exposing the power of the Linux kernel, developers can write code that runs faster and consumes less energy, and faster and cheaper has always been an attractive feature. Cilium combines three products into one. It’s like an old-fashioned firewall, an API Gateway and Wireshark, and it’s Kubernetes pod aware. It’s used by a number of successful products like Teleport for access management or Solo.io Service Mesh.
Simply said, eBPF is going to fundamentally change our infrastructure.

I met Liz at the SoCon conference, and after learning a little about Cilium, I was really impressed, and I asked her if she would come on the podcast, and luckily, she said yes. So, here we are with the interview.

Mike: Liz, thank you so much for joining me today.

Liz: Thanks for inviting me.

Tech Overview

Mike: As I understand it, Isovalent leverage’s a kernel technology to build a product called Cilium Enterprise. The upstream Cilium project on GitHub has over 22,000 commits and 14,000 stars – these are really impressive numbers for a project that started in 2016. How did this happen and how does this relate to the origin story of Isovalent?

Liz: Yeah. So, Cilium is built on a platform called eBPF, which is the kernel technology that you referred to. And eBPF allows us to run programs that are triggered by events that happen in the kernel, and those events could be Network packets, they could be a system call being made by user application – pretty much any sort of event in the kernel can be used to trigger an eBPF program.

Cilium was the first networking project to take advantage of eBPF. And it was always designed with the idea of container networking in mind. And the folks who started it are the founders of Isovalent, as well as being the originators of the Cilium project. So, Thomas Graf, Daniel Borkmann, who’s a kernel maintainer looking after eBPF, within the kernel.

And eBPF and Cilium, particularly eBPF in Networking and Cilium, kind of grew hand in hand since 2016 thereabouts, as we – the many, many contributors to the Cilium project – as it grew and as it gained functionality, sometimes that’s required additional capabilities in eBPF.

So, it’s been really almost like a long game. I think when Daniel and Thomas and Dan, the CEO, when they were first thinking about using eBPF, it was such a cutting-edge kernel technology – nobody was using it in production.

You know, when we add something to the kernel today, people won’t be using it in production for probably three, four, five years to come, so really, anticipating what the future was going to be.

I first saw Thomas presenting Cilium and the underlying eBPF technology back in 2017, and at the time I thought, “Well, this is revolutionary, this can change so many things.” Because not only can we see Network packets being manipulated by eBPF programs, we’ve also got this incredibly performant way of observing those Network packets and reporting on them that we can use for observability tooling. And like you mentioned network policy – we can implement network policy in eBPF.
Just making policy decisions about whether an individual Network packet is permitted or denied by policy, based on Kubernetes identities – this is the other real strength of Cilium.

It knows the Kubernetes identities, the labels of every pod. And so, you’re no longer just looking at network flows in terms of IP addresses and the port numbers you’re actually looking at them in terms of “this is a flow between service X and service Y.” It is so much more meaningful for a Kubernetes’ user.

Why the name Cilium

Mike: Just out of curiosity, do you know what Cilium means?

Liz: I think they’re little hairs in the inner ear – I’m not entirely sure why that was used as the name for the project.

Origin

Mike: I understand the eBPF technology is mind-blowing – Cilium is quite a project as I said. I mean, you’re not one of the co-founders, but do you know anything about how did it become actually a business?

Liz: I think pretty early on, as Cilium, the project, was getting established, and this sort of understanding that eBPF was going to be a really great foundation for efficient networking. That idea of building a company around this technology was probably in Thomas’s mind right from the get-go – I don’t know that for sure, but I imagine it was. And he and Dan Wendlandt, who I mentioned earlier – this is Thomas Graf and Dan Wendlandt – Dan had the background in software-defined networking, he’d worked at Nicira.

And I think they really saw the future of container networking being built on eBPF, so it was kind of natural to build a company. But, for the first few years, really the focus was on building the Cilium open-source projects, getting that really well-established and really well-known in the Kubernetes community.

It’s now been adopted by the CNCF, so we’ve actually contributed the project to CNCF, we’ve recently applied for graduation status there. It’s probably the most widely adopted in production networking plugin for Kubernetes now.

That kind of path from open-source projects, we really need to see this widely adopted, and then, a business that can provide, not just support, but also some Enterprise features that really large adopter is going to need. And just makes a lot of sense.

What does a Chief Open Source Officer do?

Mike: Your title is Chief Open Source Officer, and that’s a title I’ve never actually heard before. How is that role defined at Isovalent and why were you so excited to take on this mission?

Liz: It’s a particularly interesting title in a company where the vast majority of the engineering is open-source engineering, but I don’t run the engineering teams. My role is much more about how do we continue adoption of the open-source project, and how do we interface with the foundations, the community – I do a lot of work with the CNCF as well. How do we both act as good citizens towards that community and do the right thing in the open-source world. But also make sure that we’re taking advantage of everything we can.

You know, foundations like this offer us a lot of roots to speak to people who might become users and how we can do that in a way that is beneficial for people who want to learn about Cilium, or who want to learn about eBPF. So, that kind of educational role also falls within my team.

Open source v. Enterprise

Mike: This may sound like a silly question because Cilium was so powerful, but from a business perspective, what would you say are the main value propositions of the software?

Liz: So, from the open-source perspective, it’s a highly performant networking solution with built-in observability and security features. And we could dive into more details on what those are. From our perspective, it’s fantastic. If people are satisfied using the open-source version of the code – that’s great – we never want to make it such that — we don’t want to curtail the functionality, so that it always wants to be useful to open-source users.

That said, there are some features that particularly larger Enterprises are particularly interested in that you won’t need if you’re not a big Enterprise. So, for example, integrating with Legacy workloads. Some high availability features that you don’t really need unless you’re at a certain scale – those are the kind of features that we provide in the Enterprise distribution at Cilium.

Isovalent v. Sysdig?

Mike: Do you see yourselves competing with a company like Sysdig?

Liz: On the security front – yes. There is an element of competition there. I think we’re sort of speaking with slightly different customers there. Because, to my understanding, Sysdig is very much a security focused solution, whereas Cilium really applies more to a platform team who’s establishing, I would say Networking first, with this incredible set of security capabilities that you can then show to the security team, these amazing capabilities that they’ll get all that they already have by using Cilium.

I think we’re probably talking to different people within our respective customer organizations, but there is a certain amount of overlap around particularly the kind of runtime security, which we have a sub-project of Cilium called Cilium Tetragon. And there’s the ability to create profiles for the kind of things like accessing sensitive files or running certain executables, privilege escalation, suspicious network activity – these are the kind of things that we can detect at runtime using eBPF.

Why contribute project to the CNCF?

Mike: You mentioned that Cilium was contributed to the CNCF. What was the reason you brought the project to the CNCF? Also, what does that mean for the governance of the project?

Liz: It’s a big step to contribute a project. Because we hand over the intellectual property to the CNCF. That is something that Isovalent used to own and no longer owns. And the governance of the project really needs to be in the hands of the community. So, Isovalent remains the most prolific contributor, but – and this is again part of my role – encouraging more people and more organizations to get involved in not just code contributions and not just documentation contributions, but also the kind of broader evangelism of what Cilium is and the advantages of Cilium.

So, yeah, we’ve really embraced that community. And I think the phrase that we’ve used internally is “paved the world with Cilium”.

And the best way to pave the world with Cilium is to give it to as many people as possible, and the CNCF gives us a really great route to reaching all those people who are using Kubernetes. It gives those people confidence that it doesn’t matter what happens to Isovalent, the Cilium project is in the hands of a much, much bigger organization at this point.

And then, you know, that subset of people who are using Cilium, but then, find themselves needing Enterprise features. We won’t necessarily be the only Enterprise distribution, but there’s no doubt in my mind that we have the greatest expertise. So, hopefully, we will be the obvious choice for someone looking for Enterprise features or Enterprise support agreements around Cilium.

Trademark

Mike: This actually leads into my next question, which is that CNCF actually owns the trademark for Cilium, but your product, the Isovalent product is called Cilium Enterprise. And so, hypothetically, another company could make a product called Cilium Pro. I mean, I looked at the contributors and I went down eight contributors, they all work for Isovalent, I didn’t have time to go any further, but, obviously, your company has a lot of expertise, but still, the prospect that company spent a lot of money defending their trademarks, I almost never heard of anything like that – is it sort of terrifying, though?

Liz: I mean, at one level, yes, it is kind of terrifying. And Cilium is a brand name that is better recognized today than Isovalent is. And that’s a challenge that we have to embrace. And there are rules around what you can and can’t use – I think that there are probably still a few instances of documentation and use of the word Cilium, which we’re not really allowed to do any more, that we haven’t managed to tidy up everything.

There’s limitations on what you can and can’t use around a name based on what is now a Linux Foundation trademark. But everybody understands there’s a transition between us having a trademark and then giving it to the foundation. It obviously takes a little while to tidy up all that options around that, yeah. So, Isovalent Cilium Enterprise is the Isovalent distribution of what is a CNCF-owned community project.

Outside Contributors

Mike: I mentioned that there’s a lot of Isovalent engineers who are contributing code, but are there other engineers who are also contributing?

Liz: Absolutely! Google is quite a prolific contributor, Cilium is actually used in Google’s Dataplane V2, we have maintainers from Datadog, again a huge adopter who has been using it. Enormous scale – there’s some really good talks from Datadog talking about the scale of which they’ve deployed Cilium, we have contributors from Palantir.
Yeah, there’s several what we call committees, so maintainers of the project, who come from lots of different organizations. And then we have – I think it’s around 700 contributors in total. Isovalent today is just over a hundred people. The contributor base is much, much wider than just Isovalent. That said, we probably have the largest group of people working full-time at Cilium.

Market Segmentation?

Mike: On the commercial side, for infrastructure, the marketing is very horizontal, but have some natural segments worked out in terms of the customers who convert from open source to a commercial relationship with Isovalent? And are you figuring out that there’s any ways to segment the market here or the messaging?

Liz: I think that’s something we’re learning – I have just mentioned that we’re about a hundred people now, so we’re growing in our capabilities for how we target different customers and different verticals. We’ve had a lot of success in financial verticals media, quite a few transport, strangely enough. Yeah, so there’s a pretty wide breadth of Enterprises who have adopted this. I guess, the prerequisite for nearly all cases is that there are Cloud Native Kubernetes users, or that we do have some users who are using Cilium in a standalone load balancer scenario.

Have we figured out how to market to all of these different types of businesses? We’re absolutely still evolving and learning. But I think the fact that we’ve for many years had this very community-based focus, a very community-based approach, means that we can establish relationships and have trusted sharing expertise on a technical level that then encourages those engineering teams to recommend us internally.

And when it comes to making a choice about an Enterprise product or whether they need commercial support, those engineering teams already know who the experts are, and have potentially already had help from our team through the open-source community.

Team Location

Mike: Is there an Isovalent headquarters office where engineers go in, or is everyone like spread around the world?

Riz: We are fully distributed. We do have offices in Zurich, where Thomas is based, and in the Bay Area, where Dan is based. And I think that the timing, you know, really around the pandemic, just at the point as Isovalent was growing was sort of around the same time as the pandemic hit. So, inevitable that we were going to be remote based.

And as people have joined, they joined from countries all around the world. We have people from as far as long as Japan, or Alaska, Australia, throughout Europe and across the U.S. So, our team is really now fully distributed, and the culture has to embrace that. So, we’re very much focused on being remote first.

We do get the team together, and we try to get the whole company together, at least once a year. And we have a lot of encouragement around getting teams together in what we call hive time. Because we’re all about kind of bee-related metaphors.

Monetization: What features are enterprise?

Mike: I’m curious about monetization. It sounds like it’s open core, and what are the extra bits that you’re offering, I guess, in the Enterprise? And how do you decide what to make open source and what to add as an extra feature in the Enterprise distribution?

Riz: I see that the term open-core can sometimes come with a bit of a negative connotation. Sometimes people think of it as an open-source software that’s got some kind of, you know, been cut off at the knees, and that’s absolutely not what we believe in.

We absolutely believe in the open-source product being genuinely usable, and there are some pretty large organizations who continue to use just the open-source version. The kind of things that people will come to us for will be — there are some high availability features, there are things like BGP support for connecting into your legacy data center workloads, some Telco specific protocols that we’ve worked on – we very much don’t want people to feel that there’s something that’s core to their basic use case that they can’t do with Cilium.

Unless they are big enough that they’re the kind of organization that wants to pay anyway. You get to a certain size of organization, where you really don’t want to be just relying on open source with no sense of who’s going to support it when anything goes wrong. And they may come to us for features, they may come to us because they just want to know that somebody will be there to help them, you know, with a contract in place, should anything be needed.

Features for Growth

Mike: We mentioned that Cilium is a really broad product. Is there one particular product feature that you see driving the most growth, going forward in the next couple of years?

Liz: That’s a really great question, because we do have you know really, really powerful features in a number of different axes. So, for example, we just did a partnership with Griffon, where we’re building some really great dashboards, again a big part of this is available, completely open source.

There are also going to be some additional Enterprise features here. Perhaps the thing that strikes people is that they get this amazing visibility. And you know, that could be the moment when they realize, “Huh, look at the power of Cilium!” And the fact that we can see all these latency metrics or security information being shown in a visual way. So, that could be one thing that really drives growth.

It could be Service Mesh. We have a very efficient approach to doing sidecars Service Mesh in Kubernetes. Service mesh is one of those features that when it first started being talked about in probably 2018 – huge hype, huge excitement – the reality of people adopting Service Mesh, they found that it’s actually quite resource-heavy, there are issues, instrumenting all your workloads with these Service Mesh sidecars.

I think some of the realities of deploying Service Mesh had not quite lived up to the initial expectations. And then, last year, we announced the sidecarless approach that Cilium can bring. And mostly through the power of eBPF, it’s incredibly efficient. We can shortcut a lot of the path that a network packet has to take through the Service Mesh.

So, I think that’s another area that can be a real driver for growth, as people realize they can get all the benefits of Service Mesh, but without the overhead that they’ve come to associate with it.

And then, finally – security. I think I mentioned earlier the runtime security tooling that we’re able to provide through eBPF and through the Tetragon project, combining in a really performant, efficient security tooling. At the moment, everybody’s focus in security seems to be on supply chain, but they also still have firewalls. I’m quite a big believer that we have runtime security, everybody has runtime security in the form of firewalls.

We just were on the cusp of people understanding how powerful this new generation of runtime security tools can be to essentially firewall, not just Network packets, but things like bad executables or unexpected privilege escalations, that kind of thing.

Mike: Does the breadth of the product ever feel like a curse? Wouldn’t it be so much easier if there was just one application, and we can focus the marketing message and the sales, and all is just this one thing?

Liz: I’m sure the marketing team tasked with coming up with a tagline would find it a curse, yes.

Lessons for Open Source Startups?

Mike: So you’ve been in the techs business for a long time, taking off your Isovalent hat for a second and just as an observer of the startup scene, and other than the open-source scene in, do you have any advice for particularly entrepreneurs? Because this podcast is really designed first for founders, any advice for founders?

Liz: Yeah. This is actually something I’m getting increasingly interested in and I’m working with the CNCF on how we can encourage businesses on how to operate and be successful with open-source based businesses. There’s two sets of vendors who I would say have quite a lot to learn, particularly if they come into like a Cloud Native community audience.

There’s one class of vendor who is open-source based, they have an open-source project that they’re building their business around. The second class is people who are not open-source, but they have a product that they want to sell into the primarily open-source based Cloud Native community.

I think for both those sets of people, really understanding how powerful community is, Cloud Native community is kind of where I’ve lived for the last, I don’t know, half a dozen years. And it’s incredibly powerful, the relationships that you can build up – not just between individuals, between organizations, can be a really solid foundation for the business relationships that you then build on top of that.

And I think the real lesson for a lot of vendors is: don’t just expect to turn up at an event, pay for a booth or a table, and expect people to come and buy your software. Invest in time as well, invest in contributing, get involved in our project, get involved in the cigs and tags.

Don’t just expect people to immediately think that your open-source project is the one true amazing solution. Take the time to learn what other people are doing around that, and then, have those conversations about why your solution is great and what its strengths and potentially weaknesses might be. Learning to get involved in a community is really, really important.

Closing Notes

Mike: Well, I think that brings us to a close. Liz, thank you so much for sharing and best of luck with Isovalent and Cilium.

Liz: Thank you so much.

Mike: Again, special thank you to Amanda Brock and the whole open UK team for launching the State of Open Conference, where we recorded this episode. Cool graphics from Kamal Bhattacharjee, music from Broke For Free, Chris Zabriskie and Lee Rosevere.

Remember how Liz said that eBPF and Cilium are really good for Service Mesh? Well, remember that, because next week’s guest is Idit Levine the founder of Solo.io.

Until next time, this is Mike Schwartz, and thanks for listening to Open Source Underdogs.

The post Episode 63: EBPF Networking Isovalent with Liz Rice – Chief Open Source Officer first appeared on Open Source Underdogs.

Mike: Hello, and welcome to Open Source Underdogs! I’m your host Mike Schwartz, and this is episode 62 with Amandine Le Pape, Co-Founder and COO of Element, the software startup behind Matrix, an open standard for secure, decentralized real-time communication, which you can learn more about at Matrix.org.

This episode was recorded in early February at the inaugural State of Open Conference or SoCon, which was held in London at the QEII Center in Parliament Square.

SoCon was made possible by the inexorable tenacity of Amanda Brock, who leads an organization called OpenUK and is the editor of the 2022 Oxford University press book, Open Source, Law, Policy and Practice, (2^nd edition).

If you’re an open-source founder and you haven’t read this book, go to Amazon right now and order it. If you can travel to London next year, I hope to see you at SoCon 2024. If it’s half as fabulous as this year’s event, you definitely should not miss it. I guess that’s enough gushing about SoCon, let’s get on with the interview with Amandine.

Origin of Idea

Michael: Amandine, thank you so much for joining us.

Amandine: Thank you for having me.

Michael: As one of the founders, I have to ask what’s the origin story of Element? And at what point did you think about starting Matrix, the open-source repository and Matrix of protocol?

Amandine: So, it goes back to almost 9 years now, in 2014, where we were a team selling commercial messaging apps to Telco’s, incubated in a big corporation called Amdocs. After a while, we were really annoyed by the fact the whatever we did with our apps, WhatsApp would always win. WhatsApp would always be on the front page of the Telco’s website, next to the app we were building for them.

And this fragmentation even from a user perspective is really bad. For email, I can talk to anyone with my phone, and can send SMS and call people whatever phone they use, whatever network they are on, while on chat I have to actually install a new app every time someone wants to use a new one. So, we came to Amdocs and proposed them to actually try to fix this by creating an open standard for communication.

Having built on top of all the other existing standards before, we had learned a lot and thought that with the professional team, we would be able to truly bring something to the world, which was able to answer the needs that we had of interoperability for chat and messaging voice over IP.

Origin of Company / Project

Michael: That sort of answers my question, but you’re working at Amdocs and you’re thinking, “Well, wouldn’t it be great if we could federate these chat servers,”, but how does that lead to actually starting an open-source project and the founding of the company?

Amandine: So, what we do actually is create the open standard and open protocol – we set it up as an open-source project. So, within Amdocs, we set up completely something independent with a new brand, completely open-source. And we started working on it for three years, actually building the reference implementations, defining the spec, etc.

After three years, there were other companies building on top of Matrix and monetizing it, like Erickson for example, selling communication systems for banks in Sweden. Whilst the core team, we were still building the project and not funding it.

So, based on that, we thought that it would be better to actually set up an independent company and try to monetize Matrix on the side. So, that’s when we actually spent out of Amdocs, set up Element as the commercial company, which builds the flagship app itself – called Element – and selling services and proprietary product on top of Matrix. And we also set up the Matrix Foundation as an independent nonprofit, which is the custodian of the standard itself.

Project Contributions

Michael: The Matrix Foundation governs the protocol, but it also has some software in there. There’s a reference implementation, I think, in Python. Who contributes the code to that software project? Is it mostly Element or, are there community contributions?

Amandine:  Basically, Element contributes a lot of code towards reference implementations of servers and SDKs and some of the application services. And it’s literally donating the IP to the foundation, so that it’s completely independent from the commercial entity. But beyond that, Element contributes the reference implementation server Synapse, we also have another server called Dendrite – all the various SDKs for iOS, Android, etc.

But then, the community, on the other side, is actually building their own projects and building their own reference implementation servers, their own SDKs, Bridges, etc.

So, whilst Element contributes a lot to some of these projects, which are the ones which are often used in production by governments or enterprises. The community is very vibrant, and I think we’re close to 5,000 contributors across the entire Matrix project and the different repos.

Value Prop

Michael: So, there are a number of communications platforms out there, we’ve actually had Ian Ten from Mattermost and Gabriel Engel from Rocket. And there’s Slack, of course, is out there. What makes the Element commercial offering different, and why do we need another communication platform?

Amandine: So, if you’re just trying to have your own communication system that you can run yourself, then yes, you may want to just go to Mattermost or Rocket.chat. The difference with Element is the fact it’s built on the open standard – it means that once you run your Element and Matrix deployment, you can communicate to any other deployments out there. The same way that when you deploy your mail server, it federates with all the other email servers out there.

And actually, Rocket.chat built a bridge to Matrix, so now, Rocket.chat can communicate with Element without a problem. And the interesting thing is that was under the impression of the Swedish government, which brought all its vendors into one room and said, “Guys, we cannot use SaaS solutions for communications – we don’t want to designate one vendor for all the government, ministries should be able to choose the app they want to use. So, you have to federate, you have to interoperate – figure it out, find something.”

By the way, there is this standard called Matrix that should do the job, but that means that today, if you use Rocket.chat, you are able to participate in the Matrix network. So, the interesting thing is also that when you use Matrix for your communication, as for a government for example, it really solves the political problem.

Because different ministries will own their own communication, they will deploy their own servers, they run it wherever they want, under the security they want, but yet, they are able to participate in the wider network and the ownership of the discussion is shared between the two. So, you completely skip over the “Shall we use your system or my system” to come to work together on this project.

Building Matrix v. Element Brand?

Michael: So, here at the conference, I noticed that there’s a Matrix booth, but there’s no Element booth. Why did you feel that it was the right thing to do to promote Matrix and not the commercial company here?

Amandine: It felt more aligned with the idea of OpenUK in terms of building open source in the community side of things. Basically, the same way, this weekend we had the Matrix. It’s Matrix which is being most represented – we don’t even have an Element sticker or an Element banner out there. Even if Element is open source too, but really trying to grow the ecosystem in the community for Matrix.

Technical inspiration

Michael: This is a little bit of ancient history – but do you remember a platform called Diaspora? Were you thinking about Diaspora at all when you started Matrix?

Amandine: So, the thing is that we’re addressing very much the social network side of things whilst we wanted to go for the full communication, real-time communication system. In terms of whether we thought about them when we chose the decentralized structure, actually it’s more inspired from Git, and basically the idea of replicating the content of the conversation and the history of the conversation on every server.

Community Contributions

Michael: Let’s talk a little more about the community. What areas do you think the community makes the most contributions? Is it in Bridges, Bots or Widgets, which is, like how you extend the functionality? Or is it in the core server? Where do you see the most activity from the community?

Amandine: So, the way we built Matrix is to make sure that the development of clients was super easy. Because what we saw in the past is every time people wanting to add chat in their communication systems, everyone thinks it’s easy – it’s just sending a message. And then, if you want the actual features of history, etc., it’s tough. So, we wanted to provide an easy way for any web developer to add chat to their system.

So, all the complicated stuff is in the server with a very simple client-server API, just HTTP/API that anyone can use. It means that we have a lot of contribution for clients, a ton of clients out there – all sorts of clients, from common line to mobile, etc. We even have clients running on Nintendo DS for example. And a lot of Bridges as well because people want to connect to existing networks out there, so they tend to build their own Bridges. There is also contribution to the core, to Synapse itself, and we actually have the rest SDK as a new core project, which is led a lot by the community. I think it’s a quarter or a third of the developers actually are not employed by Element. And it’s like the core contributors on this project, and it doesn’t even have an internal room -everything is really in the open for the rest SDK.

Monetization

Michael: So, Element is very transparent about the monetization strategy. It’s fairly simple, it’s based on monthly active users, and it looks like it’s the same price whether you host it yourself or whether it’s SaaS – can you talk a little bit about the logic behind the pricing model? How did you get here and were there other pricing models? And did you get it right the first time?

Amandine: All those are complicated. So, when we started, we thought that the easiest way to get going would be to provide it as a SaaS platform, because it’s end-to-end encrypted and based on an open standard. So, even if we run it for people, it means we don’t see what’s inside, what’s happening on the platform due to their encryption, and people can take the data and move it to their own server later on if they want.
The fact is, our customers actually want to self-host – be it on-premise or in a cloud – so, we had to basically make sure that the on-premise hosting was actually served very well. That’s why we ended up, this is — I don’t know which alteration of pricing model it is, but it’s definitely not the first one. And yet, the idea was like, okay, let’s try to simplify one single price in the cloud or on-premise, it should be the same, because in the end it’s pretty much the same service.
I think we are about to release unless we released a couple of weeks ago – I can’t remember – a new pricing model, which is a bit like a more integrated basically. Here, we had, I think it was a three- or four-dollar user a month. And then, you can add add-ons on top of it. But we’re trying to build packages where basically the add-ons are included, but the total price may be higher, so have more of a split like this.

Sales Motion

Michael: So, what does the sales motion look like? Do people download one of the open-source and find you? Is it more an inbound motion or, are you out there, trying to find like who wants a service – like what is the sales, how have you built the sales team?

Amandine: We hired our first salesperson three years after starting the company because everything was coming inbound. Basically, it’s very much the community being here and enthusiastic, and then, you have people who tried on personally or investigated, and then bring it in-house and suggest it to their governments or their enterprise as something that would be useful.

The community has very much been our main source of leads, and so many times you have a first customer called, and then you see one guy sitting at the back of the room with the Matrix hoodie, and it’s the one who doesn’t say anything. But you know it’s the guy that people actually listen to and trust because, from technical perspective, they are the expert. So, we now have a sales team, and we’ve focused a lot on making sure we have content and marketing, etc. do a bit of outbound, but yes, the fact that our tech is good and take his, “No, it is good.”, is our best-selling point and our visibility as Matrix as well.

Market Segmentation

Michael: Have you found that there’s some natural segmentation in the market, either vertical or by application, like how does it breakdown? It seems like it can be used by so many organizations, so does that drive your marketing department crazy?

Amandine: Yeah, it’s tough to focus when you can be used by anyone, basically you can solve pretty anyone’s problem. When we started, before setting up Element, we looked at the different business model to figure out how are we going to monetize it to actually fund the development. We ended up with 72 business models. We went for one which we thought would be pretty easy, which is enterprise collaboration and starting on SaaS, etc.

We looked at one of them was public sector communications, and we were like, “Huh, that’s a good match!” But oh, my God, no way we’re getting into this, it’s going to be endless sales cycle tenders – no way! Guess who knocked at the door? It was the French government! Because in the end, it’s such a good product market fit in terms of no vendor lock-in because it’s open-source and open standard, ability to run yourself, end-to-end encrypted, decentralized, so it matches the organization, and each ministry can have their own deployment.

So, we have really seen a good product market fit there as either generic collaboration tool, like French government for example uses very much as with team’s replacement, or also, for specific use-cases like defense. Because you can take Matrix into extreme environments, you can use it peer-to-peer, in a mesh network, you can use it low-bandwidth on ships. So, the US Navy is trialing it on ships. Their ship has their own server, and if your submarine is actually going down, loses contact with the network, they still can talk locally. And when they come up, then it merges the history, and they can get back in contact and see what has been happening with the rest of the fleet.

So, all sorts of very specific use-cases, which I’ve been working on. But overall, it’s very merged, we need sovereign communication, end-to-end encrypted, we need to replace WhatsApp because it’s not compliant and it’s centralized, and we need to replace teams because it’s not even encrypted and centralized.

Partnerships

Michael: You’re still a pretty young company. When was the company actually founded?

Amandine: Element was founded in 2017.

Michael: Okay. So, have you built out the partner network at all? And are partners helping you deliver or have partners become a distribution channel for you at all yet?

Amandine: We’re just starting. Literally, we’re still building up offers, contracts, etc., because we’re seeing a lot of companies who are actually helping institutions deploy their own NextCloud or LibreOffice and this sort of things. And now, they’re coming to this guy saying, “Can I have my Element deployment as well please?” So, there’s this sort of partnerships that we’re looking at, but it’s very, very much the beginning.

Trust Management

Michael: Maybe I can degress back into the tech, or maybe this is a tech / business question, but it seems to me like one of the challenges around a federated system would be trust. “Yes, I could connect to anybody, but if I’m a submarine, how do I know I’m not connecting to an enemy’s ship? Yes, I can connect to anyone, but how do you know who you can trust?”

Amandine: You can set up securable gateways, for example, which are going to give you an opportunity to apply business logic to it. Like, for example in the French deployment, you don’t necessarily want anyone to be able to message the top layers of the government. You want to put like civil servants in the government, can invite external people civilians into a discussion, but the other way around is not true. So, you have tools like this which says, “Oh, your server can connect to anyone, or, your server can only connect to this subset of domains,” and this sort of thing. So, we rely on additional tools around it to do that.

Ecosystem

Michael: What are your plans to foster growth in the ecosystem? So, not just the open-source contributors, but also sort of other companies who maybe have a commercial interest in working with either the Matrix protocol or the core Matrix open-source project?

Amandine: The idea from the start was to create Matrix as big as the biggest ecosystem as possible. And Element being the leader of it, but maybe like ten percent market share, the same way as Google is probably the leader of the web market, but it’s like tiny market share in corporate reason – it’s just a very big market. We are trying to encourage companies to build on top of it and support them.

Within the foundation, we want to set up at some point the ability to provide grants. We’re setting up a membership model within the foundation and then the ability to actually be able to fund all this money to other people contributing to the ecosystem. So, that’s the kind of things were trying to do. But we are very, very conscious about making sure that others have the space to grow within the Matrix ecosystem, so that it’s basically rising up the sea for everyone.

Commoditization

Michael: One of the key differentiators for Element is this aspect of decentralization and federation between servers, but that’s not proprietary. Are you ever concerned that maybe your key differentiator is also open and maybe, overtime, not unique?

Amandine: So, the beauty of an open ecosystem is that people will complete a value, so it’s up to everyone to find where the best value lies and bring their own expertise. So far, we have been relying a lot on the fact that we’ve been the expert in Matrix, having created it. So, we are the best to run servers at scale and this sort of thing. So, people come to us. We are at the point where other companies are now competing with us at that level, providing hosting.

So, we need to bring our expertise into more specific use-cases, and maybe it’s this specific property product for use-cases like around security, and that sort of things that we can build proprietary, and we can license, because we know best how the protocol works and we can go around these things. So, yeah, it’s up to us to be creative.

Another thing is that the vision is that everyone would be communicating via Matrix in a few years from now. And some of them will be using Element, some of them would be using all their applications out there. But we do provide today as an Element’s kind of app store, where you can install an integration to GitHub or Bridge to Slack, etc. One idea is that this App Store would be available to any other applications out there and can become one of the main points of monetization potentially for Element in the long term.

Product Roadmap

Michael: On the product side, which product are you the most excited about do you think has the most growth potential? And were you’re investing – perhaps more in R&D?

Amandine: Right now, we are rewriting the Element application, especially on mobile, based on the rest SDKs. So far, we had an IOS and Android SDKs. We are rewriting it from scratch using a Swift and Kotlin for Android. Basically, trying to get to a point where Element is as performant and fast as Telegram, with a user interface which is super simple. Because that’s been our biggest problem so far. Element has been very slow and bloated, and that’s really hindered the growth of Matrix as a whole.

This is the thing where we are investing a lot, and it should be out in the public test flight for iOS next week or in the couple next few weeks. And it’s really exciting because it’s like you started with some of the biggest accounts, and it’s like 100 milliseconds start – it is really nice.

Europe tech startup challenges?

Michael:  We’re here in Europe, and the founders are European – do you think that there are any challenges about being in Europe versus Silicon Valley, and what’s it been your experience of tech startup in Europe?

Amandine: Our market is very much around privacy data sovereignty and this sort of things – which is huge in Europe – so, somehow, it’s probably easier for us to be based in Europe because we have Germany, we have France, and they’re all so advanced on this angle of data sovereignty and privacy. I think that was really good for us. And it’s now a real challenge to cross the Atlantic and see on the other side if we can address this market as well. Because in the US, as far as I see it, the clouds seem to be pretty much the default and it’s less questioned than here.

Advice for entrepreneurs?

Michael: So, every startup is kind of a marathon and an emotional roller-coaster – do you have any advice for entrepreneurs, especially entrepreneurs who are looking to use open source as part of their business model?

Amandine: We just had an interesting panel around the community side of things, so one of my advices would be if you are actually wanting to do it, think about why. If you want to do it right, really take care of your community. Because the open-source company without a community, it’s missing the point of doing the open source. So, make sure you manage to grow a nice community because this will help you so much. It really makes the experience something different, and you know, otherwise, it’s just usual tech entrepreneur, in terms of make sure you stay alive because if you don’t, then you cannot take care of the rest of them.

Advice for women founders?

Michael: I have a related question for you: we need more women founder role models for the next generation of open-source founders. Do you have any advice for women founders?

Amandine: It’s always hard for me to talk about this, because I’ve never felt that I’ve been hindered as a woman. I have the feeling that the problem is more that, early on, it’s like the work needs to be done at school level. It feels like it’s education, from young kids to understand that no, tech is not just for boys, and yes, everyone can be involved. And as a woman founder, I think we always tend to – it’s the things we hear quite a lot – but tend to not push and not take the seat at the table. I think we need to be careful about that as women. We tend to just like intervene when we think it’s necessary, but we need to be a bit more outspoken and push it a bit more. Because, otherwise, people around us who are just more pushy will just walk over basically, even if they’re less competent.

Credits

Michael:  Amandine, thank you so much for joining me today. I know you have a busy schedule, probably flights to catch, so thank you so much for sharing your experiences on the podcast.

Amandine: Thank you for having me.

Michael: Special thanks to Amanda Brock and the whole OpenUK team for working so hard to launch the State of Open Conference. It was really amazing – thank you. Cool graphics from Kemal Bhattacharjee, music from Broke For Free, Chris Zabriskie and Lee Rosovere.

Next week, as I promised, Liz Rice from Isovalent, who’s going to tell us about the Cilium project and all the cool things they’re doing.

Until next time, this is Mike Schwartz, and thanks for listening to Open Source Underdogs.

The post Episode 62: Amandine Le Pape, Element CO-Founder / COO, Messaging and Collaboration first appeared on Open Source Underdogs.

Mike Schwartz: Hello and welcome to Open Source Underdogs! I’m your host Mike Schwartz, and this is episode 61, with guest Nauren Batjargal, Co-Founder and COO of Erxes, a firm based in Mongolia that produces an open-source CRM and Customer Experience Platform. It is the first crowdfunded startup I’ve interviewed in the series. So, without further ado, let’s cut to the interview.

Mike: Nauren, thank you so much for joining us today.

Nauren Batjargal: Thank you for having me today.

Mongolia

Mike: You are the first open-source founder I’ve spoken with from Mongolia – is there something special about Mongolia that led to the development of this open-source platform?

Nauren: It’s minus 40 degrees right now, Celsius degrees, in Mongolia right now. It’s actually some of the coldest places in the world right now, so…yeah, here we are. Just doing the things that we do every day. Except the cold.

Mike: Where is the team located? Is there a critical mass there in Mongolia, or you are globally spread out.

Nauren: Yeah, we’re globally spread out, but the majority of the team and the development team is based in Mongolia.

Why position directly against Hubspot?

Mike: So, I liked the description of Erxes on GitHub. It says, “The open-source HubSpot alternative enables SaaS providers and digital marketing agencies/ developers to create unique experiences for their entire business.” I’m curious, why did you choose to position yourselves there versus HubSpot?

Nauren: We started the whole business, I mean, substituting the HubSpot, because, basically, we started the Erxes when we were the marketing agency. Then, like, while we’ve been marketing agency, and that we had to obviously generate some leads. And then, at the same time, looking after some of the existing clients as well as nurturing and implementing the project, at the same time with the limited human resources we had. And we’ve been using Intercom and HubSpot, Pipedrive, I think. You could name most of the marketing tech tools we’ve been using.

Partially because the single tool can only fill the part of the business life cycle. There was a lot of manual work behind using those several tools, as a small company. Most of the time, only four or five people are using four or five different tools, but then, there’s so manual work at the back. But then, on the other hand, it was too expensive for us.

So, that’s how we started. The main plug-ins, what we call it now, the main features that we have is what really HubSpot does. And also, explaining this kind of tool is really difficult. I use HubSpot to give an idea for everyone, like it’s an easiest and quickest way. So, that’s how the name came up.

Value Prop

Mike: What are the most important value propositions for your customer?

Nauren: There’s so many tools out there, and an average company uses at least 5 to 10, some like more than 10 tools they use in their everyday operation. Just using those so many different tools can lead so many ineffective and manual work. And also, eventually, it makes each team start talking in different languages – purely because the database they’re using is not the same. And those tools don’t often talk to each other, which directly affects the costs as well as the growth of the company.

The biggest value proposition that Erxes offers is, make the entire company talk in the same language. Because, the open-source, you can customize it entirely to fit to your business. And it has more than 48 plug-ins that can fit into every single of your different field, or different teams that you have. And even if Erxes doesn’t have any of the tools that you require, maybe you can develop one, or maybe you can integrate it because it’s open-source. You can actually do that. Plus, it’s open-source, and compared to some of the closed tools, it offers fairly sustainable price-friendly options.  As long as you could manage maintaining, and configure, and all those technical work that you can manage doing it, yeah, you can have better pricing options that can have you grow better.

Technical Skill Required

Mike: There’s a funny saying that I always think about, which is that open source is only free if you don’t value your time. Because there is a care and feeding aspect to operations.

Nauren: We have a service that we provide to save our customers’ time, to help to set up all those technical work. I know when you start a new tool, it’s a lot of work – especially with the tools like Erxes or HubSpot. It’s a lot of time, but once you get to know this value proposition and once you decide to move forward to this, there is a lot that you can benefit from.

Monetization

Mike: Which actually brings us to a good question about monetization. How do you monetize a SaaS license, plug-ins, APIs, and which monetization strategies are actually the most important to the company in terms of both current revenue and growth?

Nauren: Because we started and we had to bootstrap, we’ve had a number of enterprises which have like a large number of customers. Most of them operate in highly regulated industries. We offered them a tailored solution and like a dedicated support. What we aim in the future is to support partner companies as well as developers, independent developers, who can benefit from us, so then, we can earn from our support, as well as from the percentage from their revenue.

That’s one way of revenue-generating. And also, some of the plug-ins that we have are paid plugins – that’s the other revenue-generating plan that we have.

Moving from Enterprise to SMB?

Mike: So, you are really looking to figure out how can you really grow into the SMB space, which maybe would have better growth for you.

Nauren: That’s right, that’s right. That’s the biggest challenge that we have. Last year, we prepared our technology to be ready for this growth and resistant. But then, this year, we go into purely focusing on building the community and supporting those developers within our community, and make sure our tool is now developer first, shifting from an enterprise first to a developer first, I would say.

Product Focus

Mike: You mentioned that, perhaps, you’re going to introduce commercial plug-ins – which area do you see contributing to the most growth in the future?

Nauren: Yes, we already have a number of commercial plug-ins. This year and the next couple of years, we really purely focus on developers building the great developer roadmap and supporting them. And whichever way this will lead us, we will follow it. Because we started listening to the developers, and yeah, making the whole road to be smooth and easiest as possible.

Segmentation?

Mike: So, with regard to your business plan going forward, marketing technology – it’s a very horizontal market, which makes it very challenging, as you know as a marketing expert. What is your plan to segment the market? Is developers your segment? Or is there any other way that you’re looking to segment the market going forward?

Nauren: You are right. We’ve been doing marketing ourselves for the last 10 years. One thing that we know is, depending on who they are, and even though the companies operating in the same place and doing exactly the same thing, in the same industry, when it comes to marketing, they all require completely different thing from one another. Building a tool for them – it just doesn’t work if it’s just one SaaS tool. And that’s why we started this open source.

And the biggest advantage Erxes has is, whoever doing marketing is using Erxes can make the tool fits completely entirely for themselves, just like Lego. So, you could just make little changes within the plugin, and also you can add additional little bits and pieces to make it fit entirely, especially all those additional tools that communicate within the organization as well – you can sync it all together, sync the data all together, and eventually work as one.

So, in that way, anyone who uses marketing, whether it’s different or the same, you could have your own tool. Because we made a mistake over the years.

Like in the past, we were trying to segment the market, and then, we build something and then the next thing we jump in, and it turns out to be completely different. And then, we create another plug-in, and we create another plug-in. That’s how we already have 48 – like, so many plug-ins we already created. Even in the same industry, they require completely different tools. I mean, being open-source, it just helps make this tool to be suitable for everyone really.

Product Best Positioned for Growth

Mike: And in your marketing strategy, do you see your cloud-hosted offering as being a bigger driver for growth or the plug-in license revenue?

Nauren:
We always believe in open source. And we believe that the open-source plug-in is the biggest growth potential that we have.

Origin

Mike: When was Erxes actually started exactly – what year?

Nauren: The idea was initiated in 2016, but officially started in 2018. So, it’s six years.

Challenges of Mongolia

Mike: Just getting back to Mongolia for a second, because it is a very remote place. Have there any challenges from being in Mongolia?

Nauren: In terms of being an entrepreneur, being a developer, it’s the same – we are just using the computer and talking to you at the midnight in Mongolia. It’s normal, just like any other entrepreneur on a daily basis – it is the same. Except the weather and the atmosphere. Mongolia is based in Central Asia, and the Covid and all these political and economic challenges that we’re facing – it affects some of the members of our team. Otherwise, it’s just pretty much the same, you know.

Mike: Interesting. Yeah, thank you for sharing. Any advice for entrepreneurs who are launching a business around an open-source product?

Nauren: I mean, it’s the same. Whether it’s open-source or SaaS, you got to be really tough, stick to your decision and to make sure you love it. And then, to be persistent in challenges that you would face along the roads. Starting the business is not easy. Whether it’s related to technology or any other industry, it is the same. It’s challenging. So, you just make sure you be prepared.

Mike: Nauren, thank you so much for joining us today, and best of luck with the Erxes.

Nauren: Oh, thank you very much.

Mike: And thanks to the Erxes team for reaching out. Cool graphics from Kemal Bhattacharjee. Music from Broke For Free and Chris Zabriskie and Lee Rosevere.

Sorry for the long delays in releasing episodes. Being CEO of Gluu has been keeping me busy. But I’ll have two more episodes in the next few weeks: Liz Rice from Isovalent and Amandine Le Pape from Element. So, until next time, this is Mike Schwartz and thanks for listening to Open Source Underdogs.

The post Episode 61: Interview with Nauren Batjargal, Co-Founder & COO of Erxes, a Leading Open -Source Customer Experience Platform first appeared on Open Source Underdogs.

Intro

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.

Origin

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.

Monetization

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.

Cloud?

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.

Community

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.

Translation

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.

Team

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.

Close

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.

Credits

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 7^th, 2023. I’ll be there, and I’m even recording a podcast live at the event.

So, until next, time thanks for listening!

The post Episode 59 – Igor Farinic, Evolveum: Open -Source Software Vendor in the Identity Management and Governance Space first appeared on Open Source Underdogs.

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

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

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

Antti: Thank you, Mike.

Origin

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

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

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

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

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

Product

Michael:  What are the products that RoboCorp sells?

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

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

Low Code Strategy

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

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

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

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

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

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

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

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

Community

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

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

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

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

How Low-Code Impacts Onboarding

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

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

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

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

Cloud Native Impact

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

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

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

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

Customers

Michael:  Who are the customers of RoboCorp today?

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

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

Segmentation

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

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

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

Partners

Michael: Are these partners globally distributed?

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

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

Team

Pricing

Michael: Is the RoboCorp team similarly globally distributed?

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

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

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

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

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

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

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

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

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

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

Value Prop Evolution

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

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

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

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

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

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

Advice For Open-Source Entrepreneurs

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

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

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

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

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

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

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

Closing

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

Antti: Thank you. It was great being here.

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

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

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

The post Episode 60 – Robotic Process Automation with Antti Karjalainen, Founder / CEO of RoboCorp first appeared on Open Source Underdogs.

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

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

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

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

Common Theme Of Products

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

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

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

What Is Commercial?

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

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

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

License Enforcement

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

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

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

Tension Between Free and Commercial?

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

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

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

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

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

Accounting For Support V. License

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

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

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

Market Segmentation

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

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

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

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

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

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

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

Vertical Segmentation

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

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

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

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

Distribution Channels

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

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

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

Monetization Strategy

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

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

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

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

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

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

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

Pricing Strategy

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

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

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

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

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

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

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

MPL License

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

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

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

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

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

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

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

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

New Products Are Open Source Too?

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

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

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

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

When Does Open Source Make Sense?

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

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

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

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

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

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

Governance?

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

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

Tao Of HashiCorp

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

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

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

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

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

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

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

Ecosystem

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

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

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

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

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

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

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

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

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

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

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

Challenges For Open-Source Companies

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

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

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

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

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

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

Advice For Entrepreneurs

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

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

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

Closing

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

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

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

The post Episode 58: Cloud Infrastructure Automation Platform with Armon Dadgar, Co-Founder & CTO of HashiCorp first appeared on Open Source Underdogs.

Intro

Mike Schwartz: Federico, welcome to the podcast!

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

Background

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.

Seasons

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.

Credits

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.

The post Episode 56 – Connecting Web3 Blockchains, Federico Kunze Küllmer, Co-Founder of EVMOS first appeared on Open Source Underdogs.

Max’s blog post on our announcement day is a great summary of our mission, he touches on how difficult it was making homebrew without compensation and how we’re setting out to fix “the Nebraska Problem”: Something new is brewing

This link has a good summary of our white paper, and a link to the paper itself: Tea Releases Whitepaper Outlining Decentralized Protocol for Rewarding Open-Source Developers

Here is my favorite interview Max has done (so far!), a “Dev & Tell” with the Developer DAO community.

Michael Schwartz: Hello, and welcome to Open Source Underdogs! I’m your host, Mike Schwartz and this is episode 57, an interview with Max Howell of Tea.xyz. Max is the third Web3 guest – see episode 37 and 56 for the other two.

He has some notoriety as the founder of the Brew repository. That’s relevant here because Tea is a next generation Web3 package repository toolkit that developers can use to build properly incentivized open-source ecosystems. It’s a wildly disruptive vision of how we can make open-source software more equitable, more secure, and more innovative.

Tea’s published a white paper about how they intend to build a new layer one blockchain, but Tea’s also a well-funded startup that’s making a two-year roadmap to make all this Web3 tokenized repository ecosystem stuff a reality. If you’re like me, some of this blockchain jargon may go over your head. For example, what’s the difference between Proof of Work and Proof of Stake? What’s a DAO? What are Cosmos and Polkadot? My advice is, just go along with the jargon, hit pause, and do some Googling in the background.

Web 3

With that said, without further ado, let’s cut over to the interview with Max. Big welcome to Max Howell, CEO of Tea Inc. and renowned founder of Homebrew, the ubiquitous package manager for macOS. Max, welcome to the podcast.

Max Howell: Thanks for having me here.

Michael Schwartz: You mentioned in a previous podcast that you were into computer science major as an undergraduate, maybe before we dive into Web 3, and all the business model stuff, you could tell us a little bit about how you ended up in the tech business and open source.

Max Howell: Sure thing. So, I have a chemistry degree. It’s a British masters, which means it’s four years and not as prestigious as the US masters. That came from thinking I wanted to do science. I think I was undue influenced by all the ‘80s movies, where scientists were changing the world and saving the world and being cool in general.

And I did a year in chemistry in the lab. And it was like, three months, and I was like, “I can’t do this.” It was boring. I stuck it out for another nine months. And then I quit. I was like, “I got to figure out something else to do myself.” And programming had always been a hobby, but dad had introduced it to me when I was six. And I’d done a bunch of programming here and there as a hobby yeast, and never considered it for a career.

Partly because when I went to the career fair, as a 17-year-old, and I met some programmers there, they were just like the geekiest people I’d ever met. And I was like, “Oh my God, I don’t want to be like that!”

But I fell back into it, after quitting the job and moving back in with my parents and not really knowing what to do. Obviously, I was like in this depressed funk. And then I found open source, I installed Linux. And I found the communities that are out there for open source, and this was back in like 2003/2004, and fell in love with it basically. I started making apps, go involved with a bunch of apps on desktop Linux, worked for KDE, contributed bunch to KDE.

And then, that got me a career in the industry. I found this job in London, they contacted me because of the work I’ve been doing on this music player called Amarok. And that got me into it.

What is Web3?

Michael Schwartz: So, one more warm-up question. What’s your definition of Web3? For example, like, what features distinguish a Web2 piece of software from a Web3 piece of software?

Max Howell: Web3 is just the natural evolution of how the Internet has gone. And I think Web2 especially – we lost the web, right? If we go back to where the web came from, where the Internet came from, and what it was about, it’s all open source at the beginning. Everything about how it was developed, was decentralized, and not monetized, and for the benefit of everybody by putting information out there and making open API’s and programmable interfaces and small tools that could interact with each other and create a network for humanity.

And Web3 really, for me, is just an acknowledgement that we lost our way with Web2. And then we centralized everything. And we gave too many big companies too much power and control over how it’s built. Even open source, and like maybe even especially open source.

So, I don’t like the way open source is now mostly developed by companies. All the big projects, they purchase, well, they hire – we don’t want to say purchase – they hire the developers who work on these important projects. And then, that company then like controls it essentially.

I believe that they don’t intend to do malicious things with these projects. But like, at the end of the day, I don’t trust Microsoft, Google, Facebook, etc. It’s who build this essential infrastructure that makes the Internet work.

So, I love the fact that Web3 is also returning to some sort of roots movement with open source, where people are building themselves, and like, tokenization is part of the reason that that’s possible. You don’t need a company to support you.

What Makes a Web3 App?

Mike Schwartz: You know, Tim Berners-Lee recently said something like, “My decentralized web doesn’t need blockchain. And because the Internet was already pretty decentralized, and maybe even still is with, like, a billion domains and millions of autonomous web servers.

I get the ethos and the aspiration of Web3 that you’re expressing. But is there a technology underpinnings or infrastructure that’s available in Web3 that wasn’t in Web 2? What makes Web3 app?

Max Howell: We’re developers and engineers, and we love to, like, define things precisely. But, you know, I don’t think these things can be defined that precisely. Tim Berners – Lee, probably his internet still is as decentralized as it was initially, because he’s probably still using all these Web1 tools, and hasn’t really migrated. I doubt he has a Facebook account or anything like that. But for the vast majority of us, we’re using these highly centralized chunks of the Internet that have massive sandboxes around them. And that’s what we need to be working on to get rid of.

You know, blockchain is a part of Web3, because that was the ingenious invention that allowed us to understand that we can make databases that are decentralized, where we were struggling to do that. And a lot of people still don’t think it’s that important. But, you know, the recent crypto crash, it was pretty impressive how DeFi stood up while all these centralized systems collapsed.

So, for me, that means that you don’t even need to prove that Web3 is the way forwards, it’s just going to prove itself, as Web2 continues to have issues with centralization.

What is the Monetizing Strategy?

Michael Schwartz: Before we go down the blockchain rabbit hall at a high level, Tea Inc. is a for-profit company. What is the basic plan for Tea to monetize? Is it going to be a strategy similar to other Web3 startups?

Max Howell: Yeah, so, we’re a well-funded startup. And we’re currently raising a little more. Like, our intention is to give ourselves like two, three years of runway, so that we can build a kick-ass suite of products, which also allow for the open-source ecosystem to be remunerated.

But after that, essentially, we see the package manager component of what we’re offering as a form of an app store. And we see ways that we can, like monetize — it sounds terrible to say we’re monetizing open source, and that isn’t what we’re doing.

Like, we’re not changing the nature of open source at Tea. It’s important that we emphasize that fact. You can’t change something that’s so established 25, 30 years, even more, that it’s existed like 100% free, and everything about what we’re doing is still free. And our remuneration system, which we’ll talk about later, with no doubt, understands that. And that’s a key part of it.

So, any monetization we apply on top of that will be an opt-in kind of way of doing things, where we allow like teams and enterprises and businesses that are using the Tea product suite to gain extra value out of the fact that they’re a business, and that they need systems that help the dev employees to work more effectively. So, we have a number of ideas there, but they’re under wraps currently still.

Why Tea Blockchain v. DAO?

Michael Schwartz: Why a Tea Blockchain and not a Tea DAO? Or, is there also a DAO?

Max Howell: Yeah, there will also be a DAO, we need some kind of blockchain to record the data. Essentially, we’re putting out the package registry. And I say the because, currently, there’s 400 different package managers out there. The vast majority of them are duplicating the same data time and again.

The history of the Internet, and open-source and software technologies, it is full of examples, where like people cobbled together systems, because it is just about works for now. And then eventually, someone figures out how to make it more cohesive, bring it all together, and then, like provided that solution is correct, it gets adopted. So, we’re trying to do that.

We’re making a decentralized blockchain based package registry. Everyone who maintains open source will be able to publish their releases into it, their own private keys, as a result deduplicate all of that, but also allow for the Tea remuneration system.

Can other projects use Tea as a template?

Michael Schwartz: The Tea protocol algorithmically defines the governance and payments in this package ecosystem. And it seems like that’s very scalable, and it’s sort of free of subjectivity. Do you think that other open-source projects, I guess, besides package managers, might define protocols that model value in their ecosystems, by using metrics different than what you used?

Max Howell: I expect so. For me, this is a great use of the technology. We’re going to start seeing more and more people and projects doing things like this. So, there was one — what’s it called – someone was trying to replace Steam, essentially, with a similar kind of model blockchain based licenses that you put in the chain for releases of your games, essentially.

And then, it’s just understanding that you put an NFT out there, and you direct token towards that NFT, based on who owns it, like people will shy away from making new layer ones. But I think that doesn’t really make sense. So, we have like great tools nowadays for building new layer ones. And essentially, just each one has its own like specific database.

I remember, when I worked in my last firm, this music startup in London, and we replaced the entire database with a completely custom model. Because it was impossible at the time with, like, the way computers were – at least then – since before, cloud infrastructure was awfully common, to get enough performance out of the type of data that was used there.

Having your own blockchain for your specific use case, you have to bridge the tokens in order for it to be generally useful to a lot of people. But we’re going to see more and more of that. And Tea, I think is a good example. And I’m hoping that it’s going to cause people who are skeptical about Web3 technologies, and blockchain especially, to reconsider that skepticism, when they see what we’re doing and how we have good intention.

You asked who our customers were. And for me, the people who are not paying us – the open-source ecosystem package maintainers, and package consumers who are not going to directly be paying us in any manner. Or even indirectly, in fact, based on how our model is going to work.

We believe in creating solutions that are going to improve the open-source ecosystem, because we’re all super passionate at Tea about open source. And ensuring that it thrives, thrives in a way that currently it’s remarkable to me that open source exists, and that it works.

Why use an NFT for package maintainers?

Michael Schwartz: In the Tea ecosystem, you mentioned that we have package maintainers, and we have package developers, we have end users, people installing packages, and we also have package testers. Those are sort of the roles or the actors within the ecosystem that I’ve sort of figured out. And based on your role, your GitHub usage may differ. You know, in this ecosystem, where you’ve defined these actors, how do you figure out how value is distributed between them?

Max Howell: Well, we’re still fleshing out the specifics, we’re doing a yellow paper right now on how, specifically, the value will be, what percentages of things. But as package maintainer, you release packages, like initially, you have a creator NFT that you put into our blockchain that indicates that there’s a new open-source package, and then each release has its own NFT.

And so, you put those out there, and you have to stake a little bit of value to say that you are supporting this package, and that you are guaranteeing the security of the package, and that you’re guaranteeing that the semantic versions of the package are correct. A lot of the things we’re going to try and do with this technology is not just remunerate open source, we also increase the robustness of the ecosystem.

Open source is messy right now, and things break all the time. And that’s partly because there’s no incentive really beyond what is best for the rest of the open-source ecosystem, and a moral imperative to do a good job. So, the maintainers are going to release those NFTs.

And we understand that a lot of projects involve more than one person. And we expect to either build ourselves a bunch of DAO tooling, so that each project can have its own DAO, which runs on top of the Tea token. Or for the open-source ecosystem to step up and do that, like everything we’re doing, we’re coming at it with the attitude that we have to build things that are flexible, and composable, so that the open-source ecosystem can build on top of what we’re building, so the maintainers do that.

And then, there’s Tea tasters. Tasters are going to be people who are — they’re staking against packages in the graph. For a start, we’re calling this steeping, where people are staking value against a package, several other packages, etc. And then, as a result, they’re also staking value against all of the dependencies of those packages.

So, if you stake against Log4j, for example, a good example that we use regularly, then all Log4j’s dependencies will be staked against effectively.

The key part of our system is that stake rewards that are done per epoch, probably 24 hours, are distributed to the packages that are staked, as well as the people staking. So, there’s an incentive for the stakers, like in a normal proof of stake type system.

DAO Voting?

Michael Schwartz: So, democratically, I think everyone appreciates that the package maintainers get a vote, but if an organization wants to financially contribute, is there a way for you to contribute to the governance?

Max Howell: So, we’re going to have a DAO which will have governance based on ownership of the token, or at least have some of these votes be strictly for patch maintainers rather than like other people with vested interests outside of that.

The DAO will be deciding on slashing events that we are intending to have to increase the security of the open-source ecosystem overall. So, if your package has a security exploit, then you can expect to be slashed.

If you violate semantic versioning, which can break the internet, then you can expect to get slashed. And the DAO is responsible for receiving the votes from those who are participating and creating a larger vote with the rest of the token holders.

Will OS vendors adopt Tea?

Michael Schwartz: Do you see operating system vendors adopting Tea?

Max Howell: I can see them suddenly transitioning to using our package graph instead of their own. That’s one of the things that I want the packaging ecosystem to do. This is duplicated data. Sometimes, it’s duplicated for good reason. But we can be like the original resource they use to figure out what versions of Tool-X and what dependencies Tool-X has, etc.

Now, the way I’m building Tea is very feasible for it to be the only package manager Linux distribution users. So, we’re packaging everything all the way down, not including Libc, everything up above that, but design this thing to be more of a developer tool than system operations tool or DevOps tool.

Now, it’s an exciting tool in that one of the things I’m doing with it is, much like Git was released as essentially a set of primitives that it made it possible to build a version control system. But especially when it was initially released, it was not a very good version control system. A part of the reason, it took a while to catch on because the user experience was bad, and certainly gotten better in the last five, six years, I’d say – we’re releasing a tool that’s essentially a set of primitives for packaging.

So, I’m hoping that just like with Homebrew, I built it to inspire people to get involved and to contribute and to be a part of it, I’m building Tea in exactly the same way. And I’m hoping that the open-source community is going to be super excited to use Tea’s primitives to build essentially entirely different tools on top of that.

So, one thing I’d like to see is for these Linux distributions is they still maintain their own package manager, because many times, it is like the package manager is what defines what is different about different varieties of Linux. So, I expect them to build essentially their own. But like Tea should be like the bottom 70% of, in much the way that open source has evolved over the last 30,40 years. So, people release these fundamental libraries and tools that change what is possible after that.

Then, they become like bricks in a tower essentially, where after that, everything is easier and simpler and faster to build. That’s what we all love about open source, I think, and why it must be free, and must be freely available, and must consist of an awful lot of tools, and make it as easy as possible to consume.

Metrics for Value

Michael Schwartz: In your package ecosystem, I didn’t see anything about documentation as an actor. How do you plan on handling that? Because I think that’s another one of areas in open source that needs attention.

Max Howell:  Most of what we have out there right now is just a few blog posts, tweets and a white paper. And the white paper really only discusses the protocol, the blockchain components. We deliberately haven’t gone into a lot of detail about the other parts. But what we’re building at Tea is a suite of products, which have a blockchain underpinning as the decentralized database for the package registry. And I’m a huge believer in documentation myself. This is limited what we can do for the open-source ecosystem. But we are going to have a way for projects to publish their documentation into the Tea platform in a much licensed form.

How to incent all project contributors?

Michael Schwartz: I’m wondering about these other contributors to building quality world-class software, is there any way for them to participate in the Tea ecosystem?

Max Howell: In the white paper, we define package maintainers as being known where the token is directed, or when the stake rewards come in. That is a vague term, probably not, at least initially, anyway, going to define it beyond that. So, it goes to one wallet. But we are going to encourage and expect projects to form a DAO and distribute that token with tooling that either we will write or the community will write.

That points it up to the project to decide how people are doing documentation, or outreach, or translations. Like, these are extremely important roles, worked on the number of large and small projects. And a lot of the time, the people who are just out there, fielding support, are the most important, and they deserve to get some of the rewards for sure. So, we’re encouraging, but we probably won’t initially, at least for version one, build out other tooling.

We shouldn’t be doing everything. It’s not the best way for things to go, there needs to be some competition in the space where people come along and say, “Okay, here’s some DAO tooling that is suitable for Tea.” And someone else will come along with something else. And then, we’ll see which ones gain popularity and which ones work.

How Tea will incentive other types of contributors, like technical writers?

Michael Schwartz: One of the interesting aspects of your design is that you are sort of gamifying reputation, where based upon your reputation, it almost impacts your level, which could impact how much you’re paid as for your contribution.

Can you give us some thoughts about what were some of the pros and cons of setting up that system? For example, I think you’re using GitHub stats as the basis for reputation, but can you just talk a little bit about how you came up with that idea? And what are your thoughts on the first iteration that you’re announcing?

Max Howell: The stake rewards will be given to projects based on who is steeping those projects. So, we’re outsourcing that kind of decision making to the community. There will be a curve to prevent projects getting too much, because there’s some that are more popular. We’ll be incentivizing people to steep projects that are less popular. And to avoid gamifying that, there’s slashing which can be submitted to the DAO for review, if people are publishing patches that are just fake.

And then, dependencies will get — they have this sort of in-built reputation for dependencies, because if you’re a dependency for other projects, then that’s proof in itself, that you have a successful project that deserves to get those steeping rewards. There is a reputation system for reports, for like security issues or other slashing events. And we’re still working out the details of that.

GitHub stats – that’s solely for an initial token trove, essentially. We want to make sure that the open-source community, those who actually are contributing to the open source that powers the internet, start off with a reasonable amount of tokens, so that they can be part of the Tea ecosystem, the amount will be in proportion, I should think – details not exactly worked out yet. But you have to have open source. And that’s what we’re doing with the GitHub OAuth.

Why use an NFT for package maintainers?

Michael Schwartz: I noticed that you’re using an NFT. An NFT is issued to a package maintainer I guess for a certain version – why did you use an NFT there?

Max Howell: Well, I think it’s a really good use of NFTs for a change. NFT’s got a bad rap – everything’s got a little bit of a bad rap in the sector, probably because there was a lot of…naughtiness, shall we say, going on with JPEG based on NFTs. And JPEG isn’t even part of the NFTs – it’s just a hash inside of it. NFT is just an immutable data point, and that’s what an open-source release needs to be – an immutable data point.

Once you’ve released a package, if you change it, you could be breaking like portions of the internet, or portions of people’s products, or like introducing security issues into portions of what is Web to Internet currently. It’s a logical use of the technology of what an NFT is.

Is the Protocol a Formalized Set of Smart Contracts?

Michael Schwartz: This might be displaying more of my ignorance about the blockchain level one stuff, but at the risk of that, would you say that the protocols provide a template for the smart contracts that you’re going to have in your ecosystem?

Max Howell: Well, I have a bunch of smart contracts that control staking and steep rewards, but either blockchain will be EVM compatible, or at least generally programmable in some manner. And we expect people to build on top of it to make open source into a viable career path for people.

Now, Emery talked about it, but I hope that once Tea is up and running, some of these extremely well-paid engineers at Facebook and Google net will quit to work on things that have actual benefit to humanity. Because they have ideas, they know about open source they could be building that actually benefits the world.

Blockchain Tooling?

Michael Schwartz: Okay, one more geeky question for you. You mentioned that it’s getting easier to build a level one blockchain. Can you talk about maybe some of the technology stack that you’re looking at to do that? Like, what are some of the tools that you’re considering?

Max Howell: We’re still figuring it out. But, like, all choices are becoming more and more clear, I think. So, like Cosmos is great. Everyone says great things about it. And you know, they provide the great tooling, so that you can build out what you need. Polkadot’s also great. And so, that’s an option for us. And we’re quite interested in Neo4j. So, they are the three main ones. I just like the way that they’ve understood that we are using same kind of bricks, when you’re building out these tools.

It is just easier to iterate when like 90% of the difficult bits are done. Like all of us who are engineers, who have tried to build something that is a library from scratch, just for fun, and you realized that there’s a lot of work that goes into that. That’s why open source is so valuable.

Like years of bug fixing, maturity, understanding like the nuances of things, that doesn’t matter how many meetings you have with a team, you don’t figure out until you actually build it. Blockchain has reached that level now, where you can’t just whip one up.

A lot of the people we’ve been talking to and a lot of our investors were like, “Don’t make your own layer one, it’s a nightmare, you’ll hate yourself!” It’s less and less the case. It’s still complicated. Launching a blockchain is a lot more complicated than a lot of things you can do in the cloud. Takes a lot more planning and resilience. And I’m glad that we have experienced people on staff who were going to help us with that.

Could Tea have used a DAO?

Michael Schwartz: And you don’t think that you could have done everything you need to do by just using a DAO that ran on top of an existing layer one?

Max Howell: Yeah, probably. We haven’t finally finished out what we’re going to do, we haven’t made any final decisions yet. So, it’s still possible that we’ll pick one of the existing layer ones. And, you know, we’re going to have a DAO whatever, you got to have your own DAO, you can’t just like take someone else’s. And that’s just a bunch of smart contracts anyway.

The truth is like, there’s a few pieces to what we’re doing that if we use our own system, it makes it possible for us to get the performance characteristics more correct. The dependency graph of all open source is to tend to 20,000 different projects with depending on what kind of layer out – like, if you’re in an NPM package, you can have like 5,000 – 6000 dependencies. Figuring out the reward distribution for that, performance implications are quite interesting.

And so, we want to have control over that. But, yeah, we can use this ZK roll-up and all that. And maybe we still will – maybe. There’s considerations we have that just make sense for us to consider our own.

I was saying it earlier, it’s like rolling your own database. Sometimes you have to do that. It’s more like just having your own instance of Postgres running. Like, if you take blockchain tech and just tweak it slightly, it’s only slight tweaks here. I think it makes sense for the technology.

Non-Profit?

Michael Schwartz: Do you think that there’s any advantage to have a non-profit entity, like a government or a charitable organization might say, “We really want to help pay open-source developers, we’re going to give this much money to it.” Do you think there’ll be any advantage to having maybe a non-profit entity that’s sort of attached to this?

Max Howell: Our DAO will be a non-profit entity. That’s why DAO’s are interesting. I wonder how they’re going to change over the next 10 years. Certainly it’s all so very nascent, but like the way you were describing it is like sponsorship bounties. Like Gitcoin, for example. And, you know, fundamentally, we don’t feel that sponsorship or bounties are functional for funding open source.

Open source is a bunch of people who have passion and need a steady income. They don’t want to have to wait for people to post bounties and then accept them, getting unsteady income in that respect, and sponsorship’s the same. And also, like sponsorship bounties really reward the top of the stack, projects that people really know about – Log4j was a great example of a project that nobody knew about, which everybody was using.

And Tea is by design, trying to fix the lower rungs, the Nebraska projects, like the XKCD comic that features the maintainer from Nebraska, who nobody knows is keeping the internet running.

Tidelift vs. TEA?

Michael Schwartz: You mentioned also that you are part of the Tidelift ecosystem, you’re a Tidelift developer, do you think in Tea.xyz, would that be better for you? Or would it be about the same?

Max Howell: Well, yeah, that’s the point. The project I get sponsored by Tidelift for is PromiseKit, which is this framework for iPhone that I developed about 2015, a few years after Homebrew. It was used by 100,000 apps. I’m not sure if that’s still the case, because Apple have released some fundamental technologies that make it, so you don’t need the Promise’s abstraction as much. But I haven’t checked in a while.

So, 100,000 apps, part of the motivation behind Tea was, for years, I’ve been saying, if every one of those apps pay me just $1 a year, then, that’s a good enough salary for me to not have to chase contracts, or join other companies and startups.

It’s not a great salary, but it’s a starting salary, where they can like make some other open source and maybe has 100,000 users, etc.

So, yeah, Tidelift gives me 400 bucks a month, which is very generous. And I maintain PromiseKit as a result to a certain extent. But I haven’t done a lot to it a long time. There’s a lot of things I could have done to it if it was more of a moneymaker.

This is part of the reason that we’re doing Tea, we’re building Tea is that when you think about all the people like myself, who’ve put tens of 1000s of hours into open source, a Homebrew loan was tens of 1000s of hours, the whole time I was having to either take contracts and then work two jobs, or save up some money and quit, so that I could work on open source full time.

Because I like open source, I want to work on open sources. It’s where I feel they’ve actually made a difference in this world, while building crappy apps for companies that are hoping to sell them for millions of dollars is really not as much of an impact on humanity at all. I need a reasonable salary for that.

And Tea’s goal is to make it, so that people like myself, who do make the open source that powers the internet can just make open-source full time. I can imagine how much further along we’d be, if everybody who’s contributed the open source could have been doing that full time, for the last 20 years. That’s how it should be.

First Startup?

Michael Schwartz: Is this the first company that you founded?

Max Howell: I’ve tried to found a few others years ago, 2012, trying to found a music startup with a friend. My co-founder, me and Timothy have tried to found a few here and there, made progress on some of them. And it’s difficult. Getting funding is difficult. Like I say, if Tea existed, I would be using Tea to build Tea in order to fund it. And you know, Web3 does change it. It makes it so you can tokenize, and then, basically, you’ve received investment in that respect.

So, the future is rosier for this kind of thing. I would hope that it enables more and more people to build technology that the world needs, without having to chase VC money.

Advice for Entrepreneurs?

Michael Schwartz: Do you have any advice for entrepreneurs who want to start a business around a piece of open-source software?

Max Howell: The truth of it is, you have to market what you’re doing heavily, find people on Twitter or Discord, and push what you’re working on, heavily. Probably nowadays, also means, making videos and being involved in more than just Twitter and GitHub. Because that’s how I made all my open source big. Monetizing it, that was always the trickier part. And let’s face it, a lot of open sources monetized nowadays is SaaS -Software as a Service. And that works well.

And before I figured out Tea, which was about eight, nine months ago now, it sort of came to me in a moment of inspiration, I was trying to build SaaS, which was going to be an open source one. That’s how I’d do it right now, if you’re going to go with the Web2 texts, but we’re hoping that Tea will enable entirely new ways of doing business with open source. We don’t want to change the nature of open source, but hopefully, it will enable people to seriously consider it as career open-source communities, essentially.

Michael Schwartz: Well, Max, thank you for your patient answers. I think that I understand Web3 a little bit better right now. And best of luck with Tea. And where should we go to find out more?

Max Howell: Tea.xyz is our URL. And from there, you can find our entry link which has some references to some of the material we’ve published elsewhere and find our white paper and our Discord. Discord has a dev channel, it’s probably the best place if you’re a dev.

We are also hiring. So, if you’re interested in changing how the Internet is built, then we have a number of positions available, from working on the package manager through to. Interestingly, I’m after a bunch of TypeScript Reactives.

Michael Schwartz: Awesome. Thank you so much, Max, for being on the show.

Max Howell: Thank you so much, Michael.

Michael Schwartz: If you want to hear more, on the episode 57 website, I will post additional interviews with Max and some Tea links. Thanks to the crew team for helping me pull this episode together. Once again, cool graphics from Kemal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.

Next month, I’ll talk to Avi Press, the CEO of Scarf. He has a lot of interesting thoughts around open-source data and how companies can use that data to better support their communities. If you liked this episode, don’t forget to share it on your favorite Web2 or Web3 social media channel. Until next time, thanks for listening.

The post Episode 57 – Tokenizing the FOSS Package Ecosystem, with Max Howell, Founder of Tea.xyz first appeared on Open Source Underdogs.

Mike Schwartz: Hello and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is Episode 55, with Miguel Valdés Faura, CEO and Co-Founder of Bonitasoft.

Not every tech company follows the same trajectory to success. Hypergrowth is great if your market supports it, but the world of infrastructure software is diverse, and hypergrowth can subject your business to unreasonable risk.

To me, Bonitasoft was a reminder that a CEO’s responsibility can transcend shareholder value. While the primacy of shareholder value seems axiomatic in Silicon Valley, it’s worthwhile for entrepreneurs to weigh that risk. Miguel and his team did just that, and their success validates the idea that business models are not a one-size-fits-all proposition.

As a side note, as I was doing my research, I noticed that Miguel has interviews in Spanish, English and French. American CEOs are lucky to speak two languages, but three is pretty exceptional. Anyway, I hope you enjoy the interview. This was the last of 2020. So, without further ado, here we go.

Miguel, thank you so much for joining the podcast today.

BPM Market Overview

Miguel Valdés Faura: Thank you, Mike, for having me.

Mike Schwartz: So, although this is a business podcast, you’re a technical founder, and sometimes, it helps to have a high level of understanding of the market. Business Process Management, or BPM, it’s still an important way to think about how to apply technology, but the technology landscape has changed so much since 2001, I guess when you started the project, and even since 2011, when you started Bonitasoft. Why is BPM still a good way for companies to think about how to build applications?

Miguel Valdés Faura: Good question. So, it’s because companies – I like to say that it is all about processes, a ton of processes that are required to run a company, some that are more critical than others, but BPM technology has been here for a while to help companies, to rethink, re-invent and automate their processes, whatever, they are critical or not. Also, I think it is something that is here for a wider dimension, and of course, the market is evolving because also the needs of those processes are changing in organizations.

Project History

Mike Schwartz: So, the Bonita project itself started at the French National Institute for Research in Computer Science. The project was transferred to the Bull Group, and then, in 2009, you started BonitaSoft with Charles Souillard and Rodrigue Le Gall?

Miguel Valdés-Faura: Exactly.

Mike Schwartz: And also, over the years, how is the community grown? Is the Bull Group still involved, and are there other important contributors in the ecosystem?

Miguel Valdés Faura: BullGroup, which is now part of Atos, at the origin, is involved, but as a partner. It is one of those hundred employees, partners that we have – I’m talking about Consulting and System Integrators Partners that helps customers worldwide with the Bonita implementation, but nothing more, meaning that over the years, Bonita self has grown into an international community that goes beyond specific companies, but, also, having individuals working sometimes as freelance models, as part of the bigger companies.

And I think that’s one of the main achievements now. We have now a community of around 150,000 individuals working with Bonita, not all of them of course are contributing, it is only a small portion of this contributing code, but there is people participating in answering questions in the forum, or translating the products – there is a lot of activity in the Bonita community that is not relied only on one company.

Why No-Code Is No-Go?

Mike Schwartz: In an interview a few years back, you said that the no-code approach does not open the possibility for developers to write code that meets business needs. Can you expand on that? Don’t business people love drag-and-drop GUIs, to build BPM workflows?

Miguel Valdés-Faura: Yeah, a good one. So, probably, it was referring that with this new trend of local done, this new kind of developers, the thing some analysts were calling business developers, at some point, we were facing with people that are not skilled in development to build some complex applications, and at some point, they’re going to face some limitations. Of course, a lot of people like to build on applications, using drag-and-drop, as I mentioned, or visual tools, but when the application gets more complex, or when you need to customize a little bit more the application, at some point, developers need to be part of the game as well.

So, I’m not saying that it’s not useful to have business people participating in the development projects. I’m not saying that the local movement is not something that is real, I’m just saying that we need to find a balance between things that can be done graphically, and first that require code, and it’s about how those two different skill sets can collaborate, how business people or people without development skills, can also work on the same project with developers.

Probably, those two personas are not going to use the same thing.

Customer Profile

Mike Schwartz: Thousands of organizations use Bonitasoft, but switching to the business side a little bit, from a revenue perspective do you see the 80/20 rule, where 20% of your customers make up 80% of your revenues? And if so, what does that 20% segment look like, with regard to use cases or industry verticals?

Miguel Valdés-Faura: In terms of the verticals, of course, I think it’s not only something  -particularly Bonitasoft, all BPM vendors, you know, have a lot of traction in market that are highly competitive. So, for example, insurance, banking, telecommunications, because there is a lot of pressure to do better than the competition, because there is a lot of processes that are related about how you provide better services to your customers, and how are you going to retain those customers by providing good services.

So, those will be probably the main four sectors in which Bonitasoft is evolving and getting customers, and also, potentially the ones, in which other vendors are also evolving. In terms of the split or the size of the customers that we have, we have this idea from the very beginning to focus on medium and large organizations.

So, there are some BPM vendors that are focusing on smaller implementations, we are really focusing on complex implementations and meet large organizations. So, the majority of our customers, like 75% of our customers, will match that criteria. And the majority of the project implementation inside those projects are either core or critical to their business. We usually don’t start working with a customer in less critical business process, but this is part of our strategy. And, of course, our product is better suited for those complex implementation.

Value Proposition

Mike Schwartz: Kind of a basic question, but what would you say are the most important value propositions for your customers?

Miguel Valdés-Faura: First of all, we are selling a platform, not a product, so, what we want is like to bring together those two personas that I was referring in a previous question, so business people or less skilled people, in terms of technical skills, and how developers can work together. So, we have a platform, in which you have clearly separated the visual programming capabilities versus the coding capabilities. So, in a sense, we are taking the benefits of the majority of things that we see in an open-source project. So, extensibility, open architecture, which APIs, compatibility with other open-source technologies that are things that appeal to developers. And at the same time, we have an integrated platform, a unified platform, that is also providing visual capabilities to less technical people. And, also, this clear separation in which, depending on the skills that you have, you can use some of the capabilities of the platform, and depending of your skills, you can use some others – these are the things that make us different, and that people like about our solution.

Monetization

Mike Schwartz: Bonita project is open source, and Bonitasoft has a platform built around that – how exactly do you monetize?

Miguel Valdés Faura: So, we sell subscriptions – package additional capabilities to the open-source version, and also, some professional services. And those subscriptions, minimum is an annual subscription, are sold either for people that are deploying the Bonita platform on premise, or people that are using our cloud offering now. But, in two situations, we are basically adding capabilities on top of the open-source solution, like for example, monitoring capabilities and scalability. And we package that together with a professional support, SLAs, contractor warranties, as part of this subscription. Also, it’s a 100% of our probably related revenue is a recurring revenue.

Cloud Strategy

Mike Schwartz: Cloud hosting is really a great business model, and I heard you mention that you have a hosted offering. How has the hosted offering evolved over the years, and do you see that becoming sort of the most important way that you deliver the software? Would you say self-hosted is still going to be more important from a revenue standpoint?

Miguel Valdés Faura: Yeah, a good question. I think in our space, the BPM space, and particularly because of the nature of the projects that we target in our customers, as I was referring as core or critical, we still have a lot of people using the on-premise version, especially in banking insurance that are sectors that are still using a lot of on premise, or they are starting their cloud movement, using public clouds, but not really externalizing everything to SaaS solutions. So, on-premise is still really a big majority, but we have released our cloud service 18 months ago, and we already see a traction. So, there is more and more customers also embracing that new offering – I will say today is more like 80/20. We expect that this is going to change.

It took us a while to offer a Bonita Cloud version because we didn’t show a lot of demand previously. We, as I mentioned, we started seeing some companies that are more and more interested. We really believe that it’s going to be maximizing in the next years, but again, the on-premise is still the number one option today for our customers.

Prioritization Of R&D

Mike Schwartz: So, how do you prioritize your R&D effort, because you’re still contributing to the open-source project, but you are also building your commercial like extra features. And how do you prioritize R&D?

Miguel Valdés Faura: That’s a tricky one for every open-source company. Because you need to make also clear rules about what are the developments that are going to go open source versus the ones that are going to go commercial, and the same applies to the teams – do you have the same organization working on the two kind of features, do decide to have different organizations?

So, we have evolved over the years, but one thing hasn’t changed is that we have defined from the very beginning clear rules about what is open source and what is not. For example, we didn’t want our open-source version to be something that cannot be put into production, because that was not the essence for us, the essence for us as open source.

So, the open-source solution at Bonitasoft you can develop, and you can put it into production, however, for example, as soon as you’re talking about scaling – if you need to CCP, if you want to do clustering, those are the kind of things that, from the very beginning, have only been available in the commercial version.

Also, first of all, is about defining the rules, so, your development team knows what goes into one edition versus the other. Not only your development team, but also of course the community, the community using the open-source version and also your customers – it needs to be really clear. Secondly, over the years, we have evolved, also, in terms of how the development team is a structure, to be more focused on one product, one edition, meaning, one set of people for developers working, one part of the product that is either open source, or is commercial, which, of course, is a way simpler to manage from a management point of view.

Cloud Native Opportunity

Mike Schwartz: In the Cloud Native world, scaling is sort of table stakes, like Kubernetes out of the box is clustered, and my company Gluu, we’ve decided that we’re going to make scaling sort of part of the open-source, just because it seemed like it’s hard to get adoption in the Cloud Native world unless you support Kubernetes, and Kubernetes has clustering.

Do you see a similar trend in the BPM market? And are any challenges or opportunities around Kubernetes and the move to Cloud Native?

Miguel Valdés Faura: Even before Kubernetes, the move that we saw was the adoption of Docker. So, four years ago, we started to demand Docker super, as a way to use and deploy Bonita. So, that’s one of the first that we did. So, to certify a Docker image for people wanted to start their projects, it took us depending of the geography some time, we got that traction from the US, a little bit less in Europe in terms of adoption of the Docker image. Now, it’s a reality – there are more and more people using that. And, of course, those people are also asking now, “Okay, let’s combine that with Kubernetes.”

We have decided that Bonitasoft, that this is part of the kind of the capabilities that we can provide as part of our Cloud Edition. So, the elasticity capabilities that are offered to our Cloud customers is based on Kubernetes. And I think that the value to the customer is that we are able to manage that automatically for them.

This is something that we are at Bonitasoft proposing in our Cloud offering. But if someone wants to do it on premise, and they want integrate, the current Bonita on-premise version without the Kubernetes and manage Elasticity, they can do it.

But at Bonitasoft, we have a package to make it really simple for people who want to use the Cloud service.

Growth While Pivoting

Mike Schwartz: As you know, investors are super-focused on top-line growth. They want growth, growth, growth, but when there are major technology shifts, like from 2011 to today, seems like a different world. It’s hard enough to survive, let alone to grow a 100% per year. Can you talk about some of the challenges of achieving this high level of growth, especially if you have to pivot at the same time, like you probably did over the last couple of years?

Miguel Valdés Faura: A really good question. I mean, you know, it looks like hopefully things are changing, but when we started Bonitasoft off in 2009, and especially in the years that follows, looks like everyone needs to become a hyper-growth company. And of course, I really was trying to raise a lot of money, and we did it as well as Bonitasoft. And, of course, raising a lot of money means also at some point delivering really high growth. But things are changing, and I think that that’s okay, and that’s possible in some situations, it’s something you need to also be willing to do.

We wanted, at some point, growing the company that way at Bonitasoft, especially at the beginning, we decided to change. We decide to change because we wanted to build a more sustainable business, and of course, the level of research you take, if you are always following the hype- growth is a big risk. Because, of course, you are depending a lot of on money from investors, usually high-growth means high losses. So, you need to raise money. Of course, missing some of your targets can put the company at risk.

So, we decided five years ago to change, and embrace what we call a sustainable growth business model, in which profitability scheme for us, in which we try to grow as much as we can, if the company is profitable, and learn in environment in which people are enjoying their day-to-day work.

Now, we have to switch from one to the other, and I think that the pandemic that we are living these days is also reminding us that potentially that’s also a model that some other companies should consider..

Transition From Growth To Profitability

Mike Schwartz: That’s very interesting that you’re saying, “switch to high-growth as long as its profitable”, but how did you manage a relationship with your investors? Were they on board with that, or was there some friction around, saying, “We don’t want to accept this high level of risk?”


Miguel Valdés Faura: You mean, at the beginning, or when we decided to change to a more sustainable growth model?

Mike Schwartz: When you decided to change.

Miguel Valdés Faura: I think they were happy to see that after seven years of existence, we wanted to start looking to profitability. I think at some point that’s important for a company. And so, they were okay with that. And, then, of course we think that we have another kind of discussion with them because we are not asking any more money, the company is profitable for the last four years. So, then, do we need to deal with all the things like, okay, are we looking for an exit, are we looking to grow and do some acquisitions that we want to continue to grow the business organically – but, in any case, you are not forced to raise money which I think is good for us, and in some situations also good for investors.

Building The Sales Team

Mike Schwartz: So, it’s the technical founder one who’s been on the business side for a long time. Building a sales organization is really challenging – is there anything you’ve learned about building the sales team that you’d like to share with startup founders?

Miguel Valdés-Faura: Yes. It’s maybe because I’m also an engineer by training, but, of course, we did a lot of adjustments in the sales organizations over the years, and we’ve made a lot of mistakes and we’ve learned a couple of things. We made some great success, but you know, for the last four years, we are operating with sales methodology that probably you know this, it’s called Customer Centric Selling methodology, which is really focus on the value that you can bring to the customer, that is more focused on quality versus quantity, in which you do, not a lot of prospection, but you are really trying from a marketing perspective to have people really interested in having a discussion with you, and spending a little bit more time and trying to provide a solution that is, as I mentioned, to the problem.

So, then, you can surely acquire a new customer, but also make sure you can renew over the years. And this is one of the big things that we did. And we did it by having a mix in the sales team, people that are coming from different backgrounds, including engineering.

And I think that’s one of my first learning is that you can’t have people that have an engineering background that are doing exceptionally with that, and I think we’re seeing that with more and more companies.

Second, you need a methodology that is really focusing on providing value and delivering value to the customers. And this methodology needs to also be shared with marketing, and needs to be shared with the rest of the organization, including product teams know. And that has been a big change for us. Of course, we didn’t need that from one day to the other, but that move to this new methodology, having the right mix of people and focusing more on content and maturity of our leads than on quantity and prospection, has made a big difference for us.

Partner Strategy

Mike Schwartz: You mentioned that Atos was still a partner, and perhaps, there are other partners who are either bringing you business or you see as critical. But can you talk about like the role of like how the partner strategy has evolved over the years?

Miguel Valdés Faura: Today, we have three different kind of partners – we were talking about Atos, we have a category that we call Consultants and Systems Integrators Partners. As I mentioned, we have something like a hundred and plus of those partners, so, including CGI, including Atos, including Sopra, and then, other things that you in the U.S., you call it more boutique-like partners, or people that are more specialized in one particular sector. So, implementing projects in insurance or in banking. For example, in the U.S. people like Evoke, in Latin America people like Indra – this is one category. Those kind of partners are helping us either to identify new opportunities and also to do the implementation.

By the way, 62% of our new business is influenced by those consulting partners. Second category will be the technology partners. So, there’s no surprise here, this is about integration of our product with other products in a similar market. So, for example, we have those kind of partnerships with the UAiPath in the RPA space. We have this kind of partnership with a DocuSign. So, basically that means bi-directional integration between the two products. And I joined go-to-market, in which we think that the two products combined can bring more value to the customer.

And the third type of partners that we have are OEM Partners. So, it’s people or companies that are embedding our technology and reselling as part of their product. So, to name one that is more representative. Talend is doing that, Talend is that integration leader that is embedding Bonita as one of their offerings. So, those are the three kind of partners. And of course, this thing has been evolved, and has been over the years. So, we started with putting a lot of effort on Consulting and System Integrators Partners, and then we started to focus, in a second step, on more of the technology side of the story.

OEM Patnerships?

Mike Schwartz: You mentioned OEM partnership, which is interesting for open source, because I think that companies who want OEM can use the open source and become part of the ecosystem. What is the driver for a company to OEM in open-source product?

Miguel Valdés Faura: A good question. I think is that the nature of the technology that you are embedding, if you are embedding just Log4j for logging – that was, at least, used 15 years ago, – or Hibernate for persistence. Potentially, it’s the same done embedding, BPM engine or Workflow engine.

So, if you are embedding a solution, that is more like a project or a platform, that is in some way critical to the other solution that is embedding, potentially you’re going to look for, not only can I do it from a license perspective, but also, potentially, you are going to contact the other company to do a partnership. So, that’s what’s happening a lot in our ecosystem – embedding a VPN engine or embedding the whole platform, embedding a workflow solution is something that’s potentially going to be used for mission-critical things.

So, if that is the case, even if the license allows you to do it, potentially, you are going to also look for some help from the company that is building that. And of course, then, it could be also an issue with the license. You know, some of the licenses, for example, the GPL license are not allowed to embed directly without having an OEM equipment in place or changing the license. So, it could be either a license issue, or it could be that you need some helping if something goes wrong.

Licensing

Mike Schwartz: I normally don’t ask about license because I’ve actually been thinking about doing a whole another podcast, or maybe in a season or something, just on licensing, because it’s a complex topic.

Miguel Valdés Faura: Yeah.

Mike Schwartz: And, of course, Bonitasoft’s project’s been around for a long time, but is it GPL license – can you just talk for a second about the open-source license that you’re using, and maybe why?

Miguel Valdés Faura: The open-source project is really under the GPL license, and it’s more historical reasons, this is how we started the project. You know, at that time, it was the time when MySQL was – those kind of projects were appearing, it was the time of Enterprise middleware – so, we kept that license because that was also all discussions around open-core business model. And we didn’t change the scene that, for example, we are now also launching new ones, new products in which, we are also moving to some other license like Apache or MIT. But we kept, for the Bonita project, the GPL license because this is the one that get everything started.

Mike Schwartz: It sounds like the less permissive license actually has benefited you. But I think there’s sort of a knee-jerk reaction or policy among entrepreneurs these days to use permissive license, like MIT or patchy, but it sounds like GPL actually helped you in this case.

Miguel Valdés-Faura: Yeah, it kind of helped, for example, we’re talking about the OEM, it can help the OEM space, some of the people are going to see that there are some restrictions, and then, of course, there is this debate about, okay, but if I’m burying a GPL library, it’s going to be contaminating my project, but usually when you have that issue is because the project that you are building is usually something that you want to follow the open source, you want to commercialize something, just by liberating all those people work in open source, so, yeah, as you mentioned it, it’s always a complex discussion.

But, yeah, I think there are some benefits of using GPL, there are potentially some drawbacks depending of what do you want to build with that license – I think it depends. So, it is not magical rollover for what is the best license to use in your next project.

Keys To Growth In 2021

Mike Schwartz: So, there’s a lot going on today. We have the pandemic, moved to Cloud Native, changes in paradigms, like continuous delivery. What do you think are the keys to growth in the next few years?

Miguel Valdés Faura: I think nobody knows. I think we need to be humble, especially with everything and all those things that are going on, that are going on these days. But you know what, I will be back to my – what I was talking about the sustainable growth. I think that more than ever, being in a business, running a business in which you know that you are profitable, that you are of course trying to maximize, and you are ambitious to maximize the growth, if you are still profitable, having a strong customer base that this renewing year after year is what makes a big difference, especially when there are some situations that they want to do, are facing now.

Because, of course, if you don’t have that, and for some reason, you just stop signing new customers, or signing the new customer database that you were signing before. If you have a strong customer base, you’re going to suffer more than others. So, I will be back to that concept of sustainable growth because I think it’s what makes the company less risky, more sustainable in the long run.

Advice For Entrepreneurs

Mike Schwartz: You know, startups are roller-coasters. I personally don’t recommend starting a company, especially a tech company, to anyone who’d asked me, but for those people crazy enough to dive into entrepreneurship – do you have any advice for new entrepreneurs who are launching a business around open-source product?

Miguel Valdés Faura: I will have one. It’s obvious that I think it is good that we remember that from time to time, which is, there are no two companies that are alike, so, the same applies to founders. Don’t pretend to be somebody else. Of course, listen and learn from others in your ecosystem, but be yourself. And if you create a company, as you mentioned, if you are crazy enough to create the company, try to be surrounded by people that share the culture that you have in mind, the strategy that you have in mind. Don’t pretend to be a CEO that you are not. And that’s – I go back to – not all the companies need to be the same, not all the companies need to be unicorn, not all the companies need to follow the same business model, but you need to be really comfortable about the choices that you make, otherwise, it is going to be even harder than you know it simple journey.

Closing

Mike Schwartz: It’s 55 podcast. I always ask that question at the end – no one’s actually given that answer yet, but I have to say I agree with that a100%. So, thank you for being the 55th guest, and best of luck this year. And thank you so much for being on the podcast, Miguel.

Miguel Valdés Faura: Thank you very much, Mike, for inviting me. It was a real pleasure.

Mike Schwartz: Special thanks to the Bonitsoft team for helping us to schedule the interview. Editing by Ines Cetenji. Transcription by Marina Andjelkovic. Cool graphics from Kemal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.

This is the last episode of 2020. Next year, I’ll keep going, although probably at a somewhat slower rate. If you have any ideas for the direction the podcast should go in 2021, I’d love to hear your feedback. You can contact me on the website opensourceunderdogs.com. Happy holidays, founders! Hang in there, and keep an eye out for new Season 4 episodes after the New Year.

The post Episode 55 – Miguel Valdés Faura, CEO and Co-Founder of Bonitasoft first appeared on Open Source Underdogs.

Mike: Hello, and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is the episode 54, with Justin Borgman, Chairman, CEO, and Co-Founder of Starburst, the company behind the Presto Data Access Project.

Before we get started, I have a quick request – we all want to help open-source founders and startups. I make the podcast, but I need your help to get the word out, so tell your friends, post on LinkedIn, tweet out a link, post on Hacker News, or follow me and share one of my posts on LinkedIn, whatever you think makes sense, go for it.

One of the themes of Machiavelli’s the Prince is Virtu e Fortuna—virtu meaning excellence in your domain, and fortuna meaning luck, whether good or bad. I really like how the story of Starburst exemplifies this 500-year-old insight.