Open Source Underdogs

Episode 70: Early-Stage Venture Capital, OpenOcean, with Patrik Backman

Intro 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 1st. 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 – 29th, 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.

Episode 69: Kevin Mueller, Co-Founder / CEO Passbolt

Intro 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.

Episode 68: Solomon Hykes, Co-Founder / CEO Dagger

Intro 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.

Episode 67: Document Database FerretDB with Peter Farkas, Co-Founder/CEO

Intro 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.

Episode 66: Open Source Founders Summit 05f524, with Emily Omier, Founder

OSFS Website: https://05f5.com/ 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 27th and 28th. 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 28th. 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 15th. 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 28th, 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.