The Business of Open Source

This week on The Business of Open Source I talked about Open Source Manifestos with Vincent Untz, CTO of Centreon. The entire conversation focused on this idea of open source manifestos, which Vincent is going to talk about at Open Source Founders Summit — and I had never heard of before. The idea to create an open source manifesto came about because internally there was a lot of frustration around Centreon's relationship with open source. A lot of people, especially those who didn't come from an engineering background, would routinely ask why the company invested so much in open source. At the same time, there was a feeling among the engineering team that the company's commitment to open source — and the concrete development time spent on open source — was slipping. After creating the manifesto, the doubts about why open source mattered went away immediately — there hasn't been a single conversation calling into question why open source matters since the manifesto was finished. Now conversations about open source are different. Externally, there's been a huge change in conversations around open source. People say things like “Centreon is back in the game.” It's hard to point to concrete financial results as a result of the manifesto, but there have been differences in relationships with partners for sure, and it has helped get more companies to contribute to the project. Want to see what the Centreon Open Source Manifesto looks like? Check it out here. 

This week on The Business of Open Source, I spoke with Lukas Gentele, the CEO and co-founder of LoftLabs. Here's some of the things we covered: There are many open source projects at LoftLabs. We talked about what the team did differently the second time round, when they'd had the experience of creating the first project under their belt, and why they continued creating additional projects after that. How they make roadmap decisions to decide what goes in the OSS versus what goes in the enterprise editionHow they thought about the benefits to the business from open sourcing vCluster, the second project they released, and whether or not the theory about how it would benefit the business ended up being correct. Whether or not open code is necessary for community building, and why. In particular, we talked about the difference in how people feel ‘ownership' of open source projects when they contribute to them. The pros and cons of building different brands around your project, your product and your company; and of having different brands around your different projects. We talked about this a lot; LoftLabs has a different company brand from any of the products or projects, but they discovered that if the project and product do not have the same brand, people get so confused that they ultimately do not buy. If you need to figure out how to brand your project and product, you might want to work with me. If you want an opportunity to talk with other founders about branding, community building, and more, you should join us at Open Source Founders Summit May 19th and 20th in Paris. 

This week on the Business of Open Source I spoke with Daniel Jarjoura, an investor at Avolta who specializes in developer-facing companies, and who writes a newsletter on developer-facing startups and also collects data on investments in open source companies. We spoke about the overall state of investment for open source companies and specifically the state of investment in open source companies in Europe. Here's what we talked about: Differences between venture funding for OSS companies in Europe and in NAHow open source companies were relatively stable in terms of getting venture funding, even as the entire venture funding ecosystem was in free-fall.How it might be true that European investors don't understand open source companies, but on the other hand plenty of North American investors invest in European companies. Do developers trust open core companies? We had a discussion about whether or not open source companies have a trust problem…How important communication is for open source companies, something that I think is very true — a lot of the problems that open source companies run into when they either adopt an open core model or even when they do a license change. How founders can do a better job communicating with their VCs, including how to do a better job targeting appropriate investors. What do optimizing for in the VC relationship … and spoiler alert, that is for money. You might want a perfect VC who can make introductions, give you advice, give you money, be nice, etc. But the most important thing is the cash; focus on that. The second most important is the introductions. But advice isn't something you should count on from VCs, and that really isn't a VCs job, anyway. We finished the conversation with a discussion about M&A for open source companies. If you want good advice about your open source company, you might want to work with me. If you want an opportunity to talk with other founders about things like M&A for open source companies, communicating with VCs, and other topics specific to open source companies, you should join us at Open Source Founders Summit May 19th and 20th in Paris. 

This week on The Business of Open Source I spoke with Andrew Martin, CEO and founder of Control Plane. Control Plane is ultimately a consulting company, as Andrew introduced it. But the company also created and maintains KubeSec, and also has an enterprise version of Flux CD that it licenses. That gives this conversation a slightly different flavor from the usual. Here's some of the things we talked about: The business ROI that Andrew expected to get from releasing KubeSec, and whether or not he as actually seen those expected results play outThe difference between bootstrapping a company by offering services and by offering consulting — specifically what the difference between services and consulting is. The problem with “drive-by” feature development in open source projects — when people contribute features but don't commit to the ongoing maintenance of the projectWhy Control Plane decided to release an enterprise version of FluxCD, and how the enterprise version of Flux is differentiated from the pure open source project. Why underinvesting in marketing, especially in marketing for the open source projects, was a mistakeJoin us at Open Source Founders Summit if you want more conversations about how companies are built around open source projects, from consultancies to large corporations. 

This week on The Business of Open Source, I spoke with Misha Bragin, co-founder and CEO of NetBird. This was also the first episode I recorded in 2025, which gives you an idea of how far in advance I'm recording episodes. NetBird has an interesting origin story — it came out of an original idea to make a hardware product, but as Misha and his co-founder were starting to work out the realities of manufacturing, they realized that they would be better off building a software company. Here were some of the take aways from the conversation: Sometimes your users want to pay you! Misha explained that before there was a commercial offering, some open source users proactively reached out asking for one — because they understood that in order for the company to be viable, it needed to have revenue. Just because you get crickets at first doesn't mean your project sucks. When NetBird's open source project was first released, it made zero splash.The reality of working in a proprietary piece of software, you can do things quick and dirty. *Obviously you shouldn't, but let's face it a lot of people do. But when your code is open, it is also a part of your communication strategy! If you push out code that's not tested or that's not well done, you risk reputation damage even if the software works exactly as it should. Misha talked about how choosing Auth0 as an authentication service was a mistake — not because it is a bad service, but because it was not appropriate for their target audience, who are self-hosting. This is a very good reminder of how sometimes choosing the best technology for the job can backfire; you also have to take into account who the target user is and if they are going to be repelled by the choice you're making. Struggling to figure out how to balance your project development with your product development? Need to supercharge your funnel? You might want to work with me. Want to share your knowledge and learn from your peers who are open source entrepreneurs? You should join us at Open Source Founders Summit May 19th and 20th in Paris. 

This week on The Business of Open Source, I spoke with Ty Dunn, founder of Continue.dev, which is an open source AI code assistant. We had a fabulous conversation that touched on both the AI hype wave and why open source. The first thing I'd like to touch on is why Continue.dev is open source, in other words, what business rationale Ty has for taking that route. Because he makes some great points about building an ecosystem. If building an ecosystem, and encouraging people in your community to build on top of your software, is something that is important to your for either strategic or philosophical reasons, the absolute best way to accomplish this goal is with an open source project. In the case of Continue, being open source, and allowing companies to retain control over their data, is also a differentiation in the market. There was also a phrase in the conversation that I wanted to pull out — Ty talked about monetizing “next to” the open source project. This is precisely how many of the most successful open source companies work. They have a successful open source project but monetize it in a way that is adjacent, rather than directly competing with the project. Check out the full episode for a discussion about the AI hype wave and how it intersects with open source business models. If you want more discussions about open source companies, you shouldn't miss Open Source Founders Summit this May 19th and 20th — it's the only event specifically designed for leadership in open source companies. And if you're struggling with your open source strategy, you should consider working with me. 

This week on The Business of Open Source I had a slightly different conversation: I spoke with the CFOs of two open source companies, Sysdig and Percona, to better understand what is different (and what is not) about financial management in open source companies. Karen Walker is the CFO at Sysdig, and Eileen Doody is the CFO at Percona. They both joined me to talk about the CFO role in general and the CFO role in particular at an open source company. Why did I do this episode? Many founders I've spoken with are a bit unclear on the role of a CFO — whereas I've never spoken with a founder who had trouble understanding what their CTO does. Here's some takeaways from our conversation: Part of the CFO's role is about thinking about open source strategically, in terms of how the open source project is going to fit into the company's overall strategy.Because open source is so ingrained in the company, it doesn't fit into a single budget line item; it's impossible to break out and say ‘we spend $X on open source' because it's so integrated into everything the company doesHow do you measure your ROI on investment in open source? At Sysdig, two out of three prospects come to the company because of Falco, their open source project. We also talked about the ecosystem effects of having a huge footprint with your open source project; it's hard to measure the positive influence of having massive brand awareness, but both CFOs are convinced that it is very important to the company. Eileen says that many CIOs now have mandates to look for open source solutions when possible, which was not the case a decade ago. That's changed the dynamic for a company like Percona that's based around open source. Another reason I did this episode is because while I usually have founders on the podcast, there are some really important perspectives from other leadership team members. Part of the the role of a CEO is to understand all the other C-level leadership position's roles and responsibilities, and in my experience the CFO is one of the less well understood roles. In fact, we wrapped up the conversation by talking about how a CFO can be a real strategic partner that's forward-thinking rather than just the bean-counter that some people expect a CFO to be. A couple things to mention. First of all, if you want to learn more about my consulting work with open source companies, you can do so here. Second, if you want to chance to connect with other founders of open source companies, consider joining Open Source Founders Summit this May 19th and 20th in Paris. 

This week on The Business of Open Source, I spoke with Ivan Burazin, the CEO and co-founder of Daytona. First of all, Daytona was one of the sponsors of the first edition of Open Source Founders Summit, and I had a chance to meet Ivan in person at the event. So a big thank you to him for taking a risk on the first year of the event! But let's get down to business. We talked about: Why Daytona took an open source approach, even though they originally started out with a pure commercial licensed software. The thought that went into choosing the license — this was a great discussion, because it is a question a lot of people have. Ivan walked through his thought process in choosing a license and how he thinks about difference licenses. The theory about how open source will help Daytona build their business, and the dynamics of how open source adoption leads to commercial success. The importance of technical decisions in an open source project's growth strategy.The different stakeholders in the community, as well as in the customer community. I really liked the piece when Ivan talked about the individual motivations that people might have for getting involved in a community — instead of thinking about how you get something from the community, think about how others can get something out of the community. For example, you can have someone who wants to get into technical writing who gets that experience by writing documentation for your project. Making it easier for that to happen is in everyone's best interest. Like this episode? Struggling with your messaging or with your conversions from open source project to commercial customers? You might want to work with me. And if you want to join us at Open Source Founders Summit, apply to join us here. 

This week on The Business of Open Source, I talked with Ludovic Dubost, founder and CEO of XWiki about the long history of XWiki, which he started in 2003. This was a wide-ranging conversation… here's some of the things we covered: Why XWiki is an open source company. Ludovic started out with the explicit goal of creating a company, so why start it as an open source company? The reality that starting a software company in Europe means putting yourself at a disadvantage — which doesn't mean that you shouldn't do it, but rather that you need to be aware of that fact, and that open source is one tool that European companies can use to  succeed even when they are at a disadvantage. How Ludovic bootstrapped the company, including moving from support contracts to recurring revenue from the SaaS and how the transition has happened over the yearsThe difficulties that come from being small and bootstrappedManaging the balance between distribution and monetizationWhy a community version / enterprise version model did not work for XWikiWhy it's so important to pay attention to your competitive landscape, because the only way to get customers is by offering something that is better in some way than your competitors — it's your comparative strengths that matter. Did you enjoy this conversation? Find Ludovic and XWiki at Fosdem on Saturday! And/or join us at Open Source Founders Summit. Are you also interested in the challenges around product management for open source companies? You might want to work with me. 

This week on The Business of Open Source, I spoke with John O'Nolan, the co-founder of ghost.org. Before further ado, John is going to be one of speakers at Open Source Founders Summit 2025, so if you'd like a chance to dive deeper into any of the subjects we talked about on the podcast with him, in person, you should join us in May. There's a lot of interesting tidbits to pull out from this conversation. First of all, I think it's interesting that Ghost came about because Wordpress was moving away from its roots as a pure publishing tool and becoming a website builder. John, who was very involved in the Wordpress community at the time, wondered what it would look like if Wordpress went back to its roots and focused on publishing and only publishing. It's a lesson for founders that sometimes focusing on the small niches left behind as incumbents expand can be huge opportunity. —> It's worth noting that we recorded this podcast last fall when the drama between Wordpress and WPEngine was exceptionally hot. Ghost is organized as a non-profit, and John also talked about why he made that decision from the beginning. It came down to wanting to make a good salary at a company he had started, but without the goal of becoming fabulously wealthy as a result. We also talked about whether or not a venture-backed company can be ‘responsible' with respect to their community; and what types of companies tend to be able to manage the tensions between the community needs and the fiduciary duty that you have if you take outside funding. We also talked about the difference in the market between the product and the project, how Ghost manages to expand in spite of not having a dedicated marketing team. We also talked about the difference between building a sustainable business and building a business that gets hockey stick very quickly as well as some of the tension between technology decisions and business decisions. If you want to talk more about these issues — and want to talk directly with John — you should come to Open Source Founders Summit May 19th and 20th, 2025. Get your tickets here. 

In the last episode of The Business of Open Source recorded at KubeCon Salt Lake City, I spoke with Omri Gazitt, co-founder and CEO of Aserto. Aserto has two open source project that it maintains, one of which it donated to the CNCF. In this episode, we talked about the decision to donate a project to the CNCF — both what the process entailed and what is in for Aserto in having a project at the CNCF. But of course Aserto also has another project, Topaz, which it has not donated to the CNCF. We also talked about why Topaz wasn't donated to the CNCF. A couple things to pull out of this conversation: The complicated calculus of deciding whether to donate a project to a foundation, and how the dynamics of the market change over the years and you have to think very critically about the specifics of your situation before making the decision to donate to a foundationHow every company has slightly different market pressures — sometimes the market pushed you to donate to a foundation, sometimes the market doesn't care. The importance of thinking not just about market share when you're open source, but also how you are going to monetize! It's possible to have vastly smaller market share but make vastly more money. Why being an open source company does not have to mean that your paid solution has to be cheaper than your competitors. Why you don't have to start selling into startups — sometimes your best customers will always be either mid-market or enterprise from the very beginning. We talked about the panel I moderated at CloudNative StartupFest at KubeCon. If you missed it, here's the link to see the replay. We also talked about Adam Jacob's talk at the same event, which you can see here. If you're building a company around an open source project and aren't sure how to manage the relationship between the project and product, you might want to work with me or come to Open Source Founders Summit this May. 

This special episode recorded live at KubeCon Salt Lake City last November is with Martin Mao, CEO and co-founder at Chronosphere.We talked about how M3 was foundational to the early history of Chronosphere, and how the ability to leverage M3, which Martin and his co-founder had written while they were still working at Uber. One of the most important aspects of this story is that since M3 is the foundation Chronosphere is built on, the fact that it was developed over four years at Uber while they were still on Uber's payroll meant that when they decided to build a company it allowed them to get to market dramatically faster than would have been possible otherwise. Chronosphere's core platform is a proprietary SaaS product, but still has a significant relationship with two other projects: Perses, which was developed at Chronosphere and donated to the CNCF in 2024; and FluentBit, a CNCF graduated project that was originally developed by Calyptia and became part of Chronosphere when it acquired Calyptia. We talked about: The pros and cons of donating projects to the CNCF, from both the perspectives of the company creating the project and the interests of the community and project itselfWhy Chronosphere's core platform isn't open source itselfHow a company can end up getting financial advantages from being the stewards of large open source community, even if the connection doesn't always seem obviousHow product roadmaps are managed for the two projects versus how it's managed for Chronosphere's proprietary products. If you're building a company around an open source project and aren't sure how to manage the relationship between the project and product, you might want to work with me or come to Open Source Founders Summit this May. 

Happy new year everyone! There was a short break for Christmas + New Years the past two weeks, but this week I'm back with a fabulous episode with Wei Lien Dang, General Partner at Unusual Ventures and formerly co-founder of StackRox. I recorded this episode on-site at KubeCon Salt Lake City back in November 2024. This episode is particularly fabulous because Wei was willing to give some founder real talk. This is easier once you've sold your company, and especially easier when the ‘outcome' of your company's trajectory looks like an unmitigated success. And that is precisely why you hear so few founders willing and able to be honest about what the company's trajectory really looked like — and all the times when things did not look like a chart going up and to the right. Wei has also written an open source field guide, which is absolutely worth reading and is available here. We talked a lot about product-market fit, how hard it is to find and how important it is. From the risks from just going to your network for feedback to the difference between general, high-level feedback and a very specific idea of how and why your product is used, Wei talked about both recognizing that you have a product-market fit problem and how to fix it. We also talked about empathy as a founder, recovering from building the wrong product, and managing the hearts and minds of your team. Are you struggling with product-market fit, or feel like you have project-market fit but can't translate it into commercial success? You might want to work with me, and / or come to Open Source Founders Summit to chat with other open source founders. 

This week on The Business of Open Source, I have a special episode recorded on-site at KubeCon NA this fall, with Ramiro Berrelleza, the CEO of Okteto. We kicked off the conversation with a discussion about branding. Okteto is the name of the company, the name of the project and the name of the product. We started this conversation because it had been a big part of conversations I had with other founders at KubeCon. Most interesting to me was that while Ramiro explained how that decision was made, he said he was 50% happy with it, 50% not. Which is about the same as what I hear from founders who have made the opposite decision — so maybe there is just no ideal way to approach branding. Some other things we discussed: What's the different from fully embracing open source versus just having an OSI-approved licenseNot donating the project to the CNCF specifically because he wanted to maintain control over the brand; a decision he thinks was a correct one. The specifics of developer marketing, and especially how sometimes developer marketing can be a mix of B2B marketing and B2C. The tensions between the needs and desires of individual users and the needs and desires of their employers. Ramiro and I are on the same wavelength about a couple of things; I particularly appreciated his distinction between users and customers. We ended the conversation with a discussion of the benefits of open source companies — the opportunities that come from being open source that you can't get any other way. Having trouble taking full advantage of your open source project? You might want to work with me, and / or come to Open Source Founders Summit to chat with other open source founders. 

This week on the Business of Open Source, I have an episode recorded on-site at KubeCon SLC last month with Cole Kennedy, co-founder of TestifySec. We kicked off the conversation with a discussion about software development practices in the US Department of Defense and the US government at large — and the challenges involved with deploying quickly and frequently when you have to keep things both compliant and security. Here are some of the take aways from the conversation: Why TestifySec decided to donate Archivista and Witness, their two open source projects, to the CNCF — in particular, because they don't see their business model as directly monetizing either. How they monetize with a SaaS platform instead“Founder-market fit” — Cole used to work as a developer for the Department of Defense, and that gives him a unique perspective on the needs and pain points specific to defense organizations. Changing culture with software. During our conversation, it really struck me that a lot of the problems around compliance are organizational culture problems, not just software problems. How do you use software to change culture? The main advantage of open source, Cole says, is the feedback loop you get with your users, including people using the software in ways you never thought possible. Advertisement time! Are you struggling to figure out how your investment in open source translates to revenue? Do you want to figure how to increase the percentage of users who even know the commercial product exists? You might want to work with me. And if you are a founder of an open source company, consider coming to Open Source Founders Summit, the only conference dedicated to building financially successful and sustainable open source companies. Attendance is restricted to founders and leadership in open source companies. Check it out here. 

Who pays for the future of infrastructure? In this special episode, I spoke to Bobby DeSimone, founder and CEO of Pomerium, about how he feels like infrastructure and security both have to be open source — but then, what does that mean about the future of the financial support for infrastructure and security? We talked about: The importance for customers, especially early customers, of being able to do code audits early in the buying cycle — and Bobby thought that just a BSL license would not have been enough.We talked tension between project and product

This week on The Business of Open Source, I spoke with Mark Fussell, CEO and co-founder of Diagrid and co-creator of Dapr, in a special episode recorded on-site at KubeCon NA in Salt Lake City. We kicked off with a discussion of what's different about running an open source company versus a proprietary software company, and Mark said that a big part of it is that you have to nurture the community. But what does that actually mean? I pushed back, and happily Mark was able to go into more specifics about what he means. We also talked about: Why, and how, to build a contributor ladder. —> worth noting here that not all companies even want to encourage outside contributions, so it was interesting to hear Mark go into this dynamic. Dapr is now a graduated project at the CNCF, and Mark talked about what changed for Dapr as a result of getting that seal of approval… as well as what changed for Diagrid. And since Diagrid is the primary maintainer of the project, this probably means Diagrid will end up spending more engineering resources on the project. The constraints that come from having your open source project hosted by the CNCF — or any other open source foundation, for that matter. The delicate balance between the engineering resources you need to put into your open source project and the engineering resources you put into your commercial product. Even though Dapr has many (around 4,000) outside contributors, it takes a huge amount of effort (and effort = money) to manage that community, and Mark talked frankly about the investment it requires to make that happen. What percentage of the open source users even know that Diagrid exists?

In this last special episode of The Business of Open Source recorded at All Things Open, I spoke with Elias Voelker, VP North America for CheckMK. We talked a lot about product strategy; when CheckMK decided that they needed a clear strategy for deciding which feature goes in the open source project and which goes in the commercial version. Elias finished up the conversation by circling back on this issue: As an open source company, if you don't have a big enough difference between the value customers get from project and what they get from the commercial relationship... you won't survive. Since Elias works in sales, we also talked about sales for open source companies. He said one of the most important questions in the context of open source is “why now?” Since many customers have been using the open source project successfully for years, this question is really important for uncovering what's changed and why they are ready to buy at the moment. We also talked about some cultural differences between selling in North America and selling in Germany, since while Elias is German (as is CheckMK), he leads sales in North America and therefore has some advice for European companies moving into the North American market. ###If you're struggling to figure out your product strategy as an open source company, you might want to consider working with me. I help open source companies figure out how to differentiated themselves in the market, how to differentiate the product from the project and how to take advantage of the opportunities specific to being to a open source company. 

This week on The Business of Open Source, I have the first episode I recorded on-site at KubeCon Salt Lake City (and the only full-length episode), with Solomon Hykes, CEO and co-founder of Dagger, and co-founder of Docker.One thing Solomon mentions briefly but that is very important is that there are limits to what can be learned from Docker's story, simply because the situation was so unique. Docker experienced explosive growth, at least some of which was due to having the right technology at the right time. This kind of explosive growth is very rare, though, and it brought it's own set of challenges. The point being that while most companies will struggle to get enough adoption, Docker struggled to monetize effectively but got so many chances to try again just because it had a massive community. The hypothesis — or actually, lack thereof — behind creating the original Docker open source project. How having a massive community does help — but also doesn't guarantee you'll be able to build a financially sustainable companyWhen you build a massively successful technology or standard, you'll attract competition — and in the case of Docker, the competitors were savvy companies who'd won the previous cloud wars and ultimately were quicker to figure out how to monetize Docker containers than Docker itselfWhat Solomon is doing differently at Dagger compared to Docker, one of which is thinking about monetization much soonerThe open source movement was founded on such explicitly anti-commercial principles that companies building in the space would often not be intellectually honest about the fact that they were building both a software to give away for free as well as a business that needed revenue. Docker tried too hard to please everyone, including those who felt that open source should be pure and non-commercial — at Dagger, they're much more transparent and upfront about the fact that it's a company with commercial ambitions. Solomon also talked about the difference between components and product, and how designing products requires control, including the ability to just say no without explaining yourself. ###It was fascinating to hear Solomon talk about the lack of intellectual honesty around who pays for the development and maintenance of a lot of open source projects, because that precise topic was the focus of two panels I moderated at KubeCon, one during the main conference and one during CloudNative StartupFest. If you're struggling to articulate how your product and project are different from each other (and others in the ecosystem) and why someone should pay you, you might want to work with me. Reach out! 

In this special episode of The Business of Open Source, I spoke with Nithya Ruff, director of Amazon's Open Source Program Office (often referred to as an OSPO). We started out talking a little about what exactly an OSPO is and what they do in companies — something I'm guess not everyone understands. It boils down to managing the company's open source strategy — something that is relevant to pretty much any company that writes software of any kind. There are a lot of components to an open source strategy, and there are different ‘models' for an open source strategy, depending not just on the company's size, but also whether or not open source is core to what the company sells. Nithya previously led the OSPO at Comcast, and talked a bit about the difference between running an OSPO for the a company like Comcast and a place like AWS, because their products are different. And why do open source strategies matter for startups? Even if you're not an open source company, if you can't prove you're in compliance with open source licenses for projects you depend on, or if there are security concerns related to your open source use, it can sabotage acquisitions. By the way, helping startups figure out their open source strategy is what I do as a consultant. If you're figuring out how to balance your open source project and your product strategy, and how to manage the risks and opportunities associated with open source projects, you might want to work with me.  

In this special episode recorded at All Things Open, I talk with Peter Farkas, CEO and co-founder of FerretDB. We talked about about MongoDB and the license change fiasco and why Peter wanted to build an open source company and never considered building a non-open source company. The biggest

This week's full-length episode is with Bhaskar, founder of YottaDB. This episode was recorded on-site at All Things Open last week, and we covered a wide range of topics. Including:How the open source ecosystem, and the open source business ecosystem, has changed over the past 30+ years.Who can responsibly self-support an open source database, and who really needs to have someone to call if things go wrong. The spectrum of professionalism among open source developers How YottaDB started out as a project developed inside a larger company that was in financial services; and Bhaskar decided to spin it out as it's own company.The challenge articulating the value of support contracts, especially for software that is reliable. Bhaskar says he is selling peace of mind more than anything else; and he works with customers to avoid incidents — because ultimately avoiding an incident is a better outcome for everyone than a quick recovery from an incident. How to convince people that they are actually not as good at managing open source databases as they think they are. We also talked about conference strategies: according to Bhaskar, the way he's decided which conferences to exhibit at is a series of trial and error — and by the way, this is something I've heard from many people. Yes, you have to think about where your customers are, not where your friends are, but sometimes you don't know ahead of time which conferences are going to have the best ROI. I'm working with YottaDB right now on how to differentiate themselves in the crowded database market — and we talk about that process a bit right now. If you're having trouble standing out in a crowded market, you might want to work with me. 

This special episode of The Business of Open Source with Tatiana Krupenya, CEO of DBeaver, was recorded on site at All Things Open 2024. It's a short conversation, so we addressed one main question: What is the difference between running an open source company versus as proprietary software company? Tatiana says the difference is big — and it's complicated. The bottom line: Your OSS can be your main competitor, and your customers have to really see the value in your commercial offering if you want to make sales. ## If you aren't sure how to talk to your potential customers are about why they should use your commercial offering, you might want to work with me. 

This week on The Business of Open Source, I spoke with Stefano Maffulli, Executive Director of the Open Source Initiative, about the definition of open source and… the definition of open source AI. We recorded this episode on-site at All Things Open, so there's a little bit of background noise. We talked about why OSI felt like it needed to develop a definition of open source AI, how “open source” is enforced, and the thought process behind the definition that the OSI ultimately published. We talked about open data quite a bit — different kinds of data, what kind of information and data is important to researchers and professionals in the AI space, and if there's a way to include AI models that are trained on proprietary data in the definition of open source AI. If you are interested in open source AI, definitely check out this behind-the-scenes discussion of how, and why, this definition was published — and what the future likely holds for defining open source AI. 

This week on The Business of Open Source, I spoke with Anais Concepcion and Paul Fitzpatrick , the co-CEO of Grist Labs and CTO of Grist Labs. We talked about managing growth of users versus growth of revenue, moving to an open source approach for technical, not technical, reasons, and open-source related product management questions for open source companies. Some really interesting themes we talked about:Moving from a SaaS first approach to also focusing on enterprise sales. Why they did that, what other sales channels that opened and what questions it also forced the company to addressUser personas versus buyer personasThe situations in which Grist is the best option — which incidentally I could not understand from the website or the project documentationThe relationship between the open source project and both enterprise sales and SaaS sign-ups. How open source has been critical for a strategic relationship Grist has with the French government, which has been important for increasing product development velocityGiving up ‘darlings' or features that they really want to develop but that they don't think would drive revenueThe difference Anais sees between running Grist and running non-open-source companies — one of the most interesting differences is that users often have a sense of ownership over the project that you just wouldn't see in a fully proprietary How open source true believers often work in large companies and control budgets, and should not be underestimated. Why trying to sell based on features — including telling yourself that if you just had one more feature, you'd unlock all the sales — was a big mistake. Are you struggling with price anchors fixed around zero dollars, or can't figure out how to manage the push and pull of developing open source and building a business? You might want to work with me. 

This week on The Business of Open Source, I spoke with Eric Holscher, co-founder of Read the Docs. We had a really far-ranging conversation that included talking about why documentation is often so bad, why documentation should be a priority, but also Eric's experience building Read the Docs and Write the Docs. This episode was interesting because it's both about building an open source company and also about the importance documentation for software projects in general and open source projects. Some things we covered included: What is documentation? Is it a marketing effort, is it a part of the project itself? Eric talks about how good documentation for an open source project is a clear signal of a level of seriousness for the project. How Read the Docs was really started to support open source projects, and that is part of why there's no enterprise installs — either you use the open source code on your own, or you use the hosted product.How Eric sees building in the open as a way to help other people become better software engineers, but that ‘helping companies use Read the Docs for free' is not the reason he wanted to build an open source company, and he's still not sure how to feel about the fact that this happens. You don't get bonus points for being open source or bonus points for being bootstrapped — it won't prevent a potential customer from using a competitive product because it has a feature that Read the Docs doesn't have. How open source in general — and even documentation in general — can help build brand value, but it is super hard to quantify and put in a slide in a board meeting to justify an investment in open source. The decision to build Read the Docs as a business stemmed from the pressure that Eric got from having a successful open source project. How they tried very hard to avoid accepting advertisements, but they should have started doing so much sooner because it turned out advertisements is well-aligned with the things they want to be working on. The difference in risk between being open source for a database company versus an app-level open source project like Read the Docs; for Read the Docs one of the risks is the brand damage associated with people running the OSS on-prem and doing a bad job. Are you the founder of an open source company and struggling with figuring out how to manage the relationship between the project and product? You might want to work with me. Enjoy the show? Help it reach more people by leaving a review and sharing with your friends. 

Today on The Business of Open Source, I spoke with Chris Holmes, co-founder and CEO of Greymatter. Greymatter is deeply involved in the open source ecosystem and maintains the Go Envoy Control Plane, but Chris is adamant that it is not an open source company. We had a great discussion about why that is, what it means for the company and the conversations he ends up having around open source with his customers and partner companies. Some particularly interesting points that came up:Customers worry that buying Greymatter could force them to buy enterprise versions of open source software — and Chris thinks that this could be a symptom of the fact that many users expect that they'll end up being forced to pay for something they don't want to pay forHow open source companies, and open source projects in general, can be viewed as risky if they are only backed by one companyWho is gonna pay for open source? How if you are going to get away from open source projects being aggressively monetized, big companies have to put their money where their mouth is and pay for open source development directlyWhy and how to get started selling to governments. Yes, the sales cycles are longer but the deals tend to be very sticky once you get in — and why Chris actually finds it easier to sell to the military than to large enterprises. What benefits Greymatter gets from being a maintainer of the Go Envoy Control Plane. Struggling with how to get your product strategy right, and find the right balance between your open source project and your commercial offering? Not sure how your user audience and customer market relate to each other? You might want to work with me. 

This week on the Business of Open Source, I spoke with David Höck, co-founder of Vendure. We talked about switching licenses from MIT to GPL, the ways that Vendure is different from it's competitors and how architectural decisions can be a powerful differentiator for an open source company. Favorite quote: “You need to build your product together with your clients.” Some specifics we talked about that you should pay attention to: Why they switched to GPL in order to encourage more people to reach out to them and get more visibility into who was using their open source projectOn the other hand, they wanted to make sure that big companies building commercial platforms on top of Vendure's platform are forced to pay for a commercial license. They also wanted to choose a less-permissive license, but something that was still well-known and wouldn't cause a lot of confusion among users or potential customersThe difference between being happy with people using your software for free, and being happy with competitors using your software to build a competitive product, without offering any support to the underlying software. Do your customers care about whether you are VC-backed or bootstrapped? We had an interesting conversation about this, because Vendure is bootstrapped. I think we settled on a real important nugget — if your technology is really critical to the company, they will care about your long-term sustainability. Being bootstrapped can help convince potential customers that you are independent and will be sustainable for the long term. The top advantage of open source, David says, is the ability to get fast product feedback from a community. —> I just was talking with someone yesterday about this advantage of an open source strategy, I think it is under-discussed but extremely important. If you're the founder of an open source company struggling with your product strategy — uncertain how to differentiate between project or product or how to differentiate the entire company in the ecosystem; don't know what your project is supposed to do for your business; aren't clear on the target market for your project or product — you might want to work with me. Find out more here. 

This week on The Business of Open Source, I talked with Allard Buijze, the CTO and founder at AxonIQ. We talked a lot about the importance of open source for getting feedback on your product and validating your idea — or not. One of the things we talked about was how the beginning of AxonIQ was tied to the same consultancy that developed Spring Source; Rod Johnson, the founder and CEO of Spring Source was on the podcast a couple months ago and you can listen to that episode here. We talked about: Spinning the company out of the an established company, and in particular how Allard ended up becoming co-founders with his former boss, and got buy-in from their previous employer to found the company after the open source project took open. How they underestimated some elements of human psychology around sunk costs and how it would impact people's willingness to move from the open source project to the paid productWhy they originally had two products, and then decided to merge them into one single productHow the key turning point for the company was when a new salesperson joined the company and convinced them to quadruple the prices; the result was both an increase in revenue per customer but also an increase in the number of customers. How they evaluated the success of the decision to consolidate the two products into one. How product market fit is a journey, not a destination. How each individual hire can impact the way your product and project is perceived in the world; and it's important to get alignment on what people are saying. The importance the avoiding confusion among potential customers***Are you leading an open source company and struggling with product strategy? I will help you improve the quality of your conversations, so people understand your product sooner, remain more engaged in the conversation and understand the relationship between your product and project. Learn more here. 

This week on The Business of Open Source, I spoke with Robert Hodges, CEO of Altinity. This is a great example of an open source company that is built on top of an open source project, ClickHouse, that they did not create and still do not have direct control over. Altinity has created and maintains other open source projects in the ClickHouse ecosystem as well, but So many things to unpack with this episode, but a couple I want to call attention to in particular. The origin story of how Altinity's founder discovered Clickhouse (he did not create it!). I love how Robert specifies that Alexander Zaitsev, one of the Altinity co-founders, discovered ClickHouse because he wasn't happy with how the database he was using scaled — and by the way, it had nothing to do with how much the database cost. Great example of an open source project winning because it provided superior value, not because it was/is free. Making product strategy decisions based on who the ideal user and the ideal customer is. Robert talked about how Altinity didn't contribute a particular high-security feature back to open source ClickHouse because while it's something that very security-conscious organizations would want, for an open source users who doesn't have major security and compliance requirements it would be confusing and create a worse user experience. Working in friendly competition with the 10 or so other companies that are building around ClickHouse, and how this is one of the unique things about working around open sourceHow Altinity's customers tend to value the four freedoms of open sourceAre you a leader of an open source company and you're struggling to prioritize your product roadmap in a way that reinforces your differentiated value… reach out. I help companies figure out the differentiated value of their product and product, where to put the line between the two, and how to use that information to prioritize your roadmap, build a sales narrative and communicate with your market. 

This week on The Business of Open Source, I spoke with Jesse Williams and Brad Micklea, co-founders of Jozu and each with a long history of experience in various open source companies behind them. Even though Jozu is young, there was a lot to learn from these two and their experience in both open source and non-open source businesses. We talked about open source and not open source from CodeEnvy, Red Hat, AWS and Docker. “It's very hard to get a sustainable open source project if you don't have a company behind it paying those developers to work on it.” Some things we talked about: Why it's important to focus on ‘what people get” instead of ‘what you give people.' This is a fundamental component of effective product strategy and understanding your value prop: You can't just talk about about the features you're delivering; you have to connect that and focus on the value that people get from using the product. Jesse talked about the wizard behind the curtain that makes open source projects drive commercial adoption and revenue. You must be able to communicate the additional value of the commercial product; otherwise you will run the company into the group.Many open source companies get taken hostage by the open source community and end up having trouble monetizing because they make give away value in a way that is not sustainable.Users — and especially customers — are often unwilling to commit to a project if they are not convinced that the business behind it is healthy and has a sustainable business model. Open source, open standards and open governance — the relationship between the three and why we should all talk more about open standards and open governance in the open source ecosystem. The importance of really thinking through why you are open sourcing something, something that many companies don't think through. We wrapped up the conversation talking about how difficult it is to figure out which features to prioritize — and that this is a really hard decision for any startup. This is a big part of my shift to focusing on product strategy in my consulting. If you're an open source startup struggling with product prioritization and strategy, check out my product strategy offering. 

This week on The Business of Open Source, I spoke with Jimmy Zelinskie, co-founder and CPO of Authzed, which is behind SpiceDB. We kicked off the discussion with a really interesting discussion about whether or not SpiceDB is a database and whether or not Authzed is a database company. At first they didn't see it that way, but as soon as they started leaning in on describing the product as a database, the more successful they were at getting people in their community to quickly understand what they did and how to use it. But it wasn't just important for adoption: Once the team realized they were a database company, the business model they should follow seemed obvious, and they could make product decisions without stepping on anyone's toes. Some topics we covered: How positioning SpiceDB as a database, and Authzed as a database company, helped everything else fall into place, from growth to product strategyWhy people often do want to avoid self-managing critical infrastructureThe difference in ideal user profile and ideal customer profilesHow transparency is the biggest benefit that Authzed gets from having an open source project. How the decision to release an open source project was a direct consequence of positioning the technology as a database.Why it is extremely important to have a decision-making framework for deciding what features will go into the open source or the proprietary features, that is communicated throughout the companyWhy open source companies need to consider the open source users and communities as one of their stakeholders that needs to be represented in strategic discussionsIf you're the founder of an open source company — or you know anyone who is — and you don't have a good framework for making product decisions or struggle to communicate internally and externally what the difference between project and product is, I can help you figure that out. Here's more information. 

This week on the Business of Open Source I had Galeal Zino, CEO and founder of NetFoundry, which creates OpenZiti. One of the most interesting things about the this conversation was the conversation about how to balance whether you're promoting the product or the project. I talk to a lot of founders who assume that because you have both, you have to promote both. The same goes for SaaS and onprem options — some people think that just because you offer both, you have to build a go to market function for both. This topic came up in the conversation with Joe Duffy as well — in their case, it was the opposite, though. Pulumi started with both open source and commercial product, but put all the emphasis on the open source project for the first two years. Some of the interesting takeaways from this episode: Even though there was no “GTM” focus on the open source project at the beginning, it still had business benefits to NetFoundry, because it made prospects more comfortable that they wouldn't disappear overnightHow building an open source company is more difficult, because you end up supporting multiple products. But it also can build a flywheel of innovation that you just can't get any other way. Do you have to get product market fit twice? We had a long conversation about whether or not you have to get product market fit twice in open source companies. We also talked about testing ideas and business models in the actual market, and how lessons learned in other businesses can influence how you approach you take even with open source companies. Thank you for listening! PS: I'm changing my consulting offerings slightly, to focus on product strategy instead of positioning. And I'm looking for beta clients while I figure out exactly what the offering looks like. So if you're an open source company and you're looking for a clear product vision, a better understanding of how your product + project are differentiated and how to build that into your roadmap, reach out. 

Pretix founder and CEO Raphael Michel has a completely different philosophy about what he is building compared to the big players in the event / ticketing platform space. We had a great conversation this week about Pretix, how Pretix is positioned compared to big players, and who care about the fact that Pretix is an open source company. Some takeaways: Pretix is a small company, but Raphael feels like it is able to have a much broader feature set than the big players like EventbriteI think of Pretix and Eventbrite as competitors, but Raphael was able to very easily tell me the difference between Pretix and Eventbrite, how that stems from a different philosophical stance about what they are buildingIt took five years for Pretix to hire one person, about 10 years after starting Pretix there's about 20 people on the teamAbout 20% of people care about the fact that Pretix is open source, and 80% don't care. But those who do care, care a lot. Figuring out who cares about open source and who doesn't depends on the target market and can be trickier than you would expect. Even though SaaS is the main business model for Pretix, they have an on-prem offer — and they have on-prem customer.How growth is a huge challenge, both for the company growing and for the customers and partners, because it becomes more challenging to get support.Notice how clear Raphael was about Pretix's positioning, and how it was different from the big players in the event space. Are you that clear on how your software is different from competitors? Do you have a clear point of view, like Raphael, that sets you apart from the rest of the eocsystem? If not, you might want to work with me. 

This week on the The Business of Open Source, I spoke with Ashraf Samhouri, the CEO and co-founder of Activepieces. Activepieces didn't start as an open source company — and we started out the conversation by talking about why it was important to take an open source route because Activepieces is building an ecosystem. Some other highlights from the episode: Making software that is both for technical users (engineers love Activepieces!) and non-technical users (who also love Activepieces, because the UI is good)Understanding the different user types, and marketing to them separately and specifically. I challenged Ashraf to tell my why Activepieces is better than Zapier even without the open source piece — it was a challenge, but he made a good argument about having a simpler interface as well as that Activepieces allows you to run on-premWe talked about product led growth and how there is an obvious starting point for promoting an open source projectWhy lead qualification is so importantIf you're the founder of an open source company and you're struggling with your open source strategy, with your positioning of your product or project in the ecosystem or with communicating that value of your product and project, reach out — that's what I help companies with. 

This week on The Business of Open Source, I spoke with Per Ploug Krogslund, who is currently  senior director of developer programs at Docker, and who previously had a number of experiences at the intersection of open source and business. He founded and ran an open source company, Umbraco, for many years, and also led the Open Source Program Office at Spotify. We had a wide-ranging conversation about open source businesses. Some of the topics we covered:What is the right size for an open source business? How do we make space in the conversation about open source businesses for the companies that will never become billion dollar unicorns? The tension, both internal and external, around building open source software and building a company. We talked about this in the context of Umbraco and in the context of Docker — most fascinating to me was that Per felt like as soon as Umbraco had figured this out, it wasn't as interesting for him to keep working on the company. Why hasn't there been an “enterprise Backstage” company to spin out of Spotify? We also revisited the question of Microsoft and open source, because Umbraco is an open source company built on a Microsoft stack at a time when Microsoft was publicly hostile to open source. What should you take away from this conversation? There are plenty of opportunities to build small-to-medium size companies around open sourceYou might have to try a lot of different ways to monetize. Per said he felt like Umbraco tested 17 different income streamsThere will be a tension, both internally and externally, about how much to open source. This is part of the game; you have to figure out how to manage this tension but might never feel like you get it perfect. If you're listening and want help on your open source strategy, finding the right balance between open source and income streams and figuring out what those income streams should be, reach out to see if it might be a good fit for us to work together. 

This week on The Business of Open Source, I talked with Tom Wilkie, CTO at Grafana Labs. We talked about how he had a 10-month run building a startup before ultimately joining Grafana in an acquisition — why he thought that was the right move at the time and how it's developed since then. But Tom has also had a long career in open source businesses, and we had plenty to talk about. My favorite quote: “I've always seen open source as a privilege of successful businesses, so I want to be a successful business.” At Kausal, Tom's first startup, the focus was on financial sustainability from the beginning, and they had $100k in revenue in 10 months before the acquisition by Grafana. At Grafana Labs, everything is done with an eye on revenue — yes, there are tons of open source projects and tons of investment in those projects, but it has to be tied to revenue. Some other things we talked about: Starting an open source company with the explicit goal of being a successful business, which is not what Tom sees all open source companies doingWhy you should probably start with open source code at the beginning if you intend to open source at all, because otherwise your code will get messy and you'll be too embarrassed to open itHow integrations are the secret sauce that Grafana Labs monetizes — why that it, and how it allows so much code to stay open source without threatening Grafana's financial successChoosing a SaaS strategy versus choosing an enterprise on-prem strategy — and how you need to be aware of what your competitors are doing when choosing which is right for you. Thanks for listening! I'm Emily Omier, a consultant who works with company on open source strategy related to positioning and product management. If you're struggling with your strategy around open source — whether you're unsure how to differentiate in the ecosystem or not sure what to open source — I can help. Learn more here. 

This week on The Business of Open Source I spoke with Mike Milinkovich, executive director at the Eclipse Foundation. We had a wide-ranging conversation about the role of open source foundations in the open source ecosystem, especially as related to open source businesses. The existence of open source foundations, and how companies decide to engage (or not) with them, is one of the aspects of open source businesses that is truly unique. Perhaps one of the key things to keep in mind from this conversation is that a foundation's priority is project sustainability — and that is not always aligned with the goal of increasing profits for a company. On the other hand, there are a lot of advantages to contributing a project to a foundation. But founders should be aware of both the advantages and the constraints that working with a foundation entails. Here are some of the things that stood out from our conversation: Investors want a successful business more than they want a successful project; foundations' priorities are opposite. You have to take into account commercial/financial interests if you're thinking about sustainability of a project, because you have to put food on the table; projects take time to maintain.The only community you get around an open source project is the one you build — contributing a project to a foundation is not a magic community pill, and building a community takes work. Running a foundation is not free, so if you're going to contribute a project to a foundation seriously consider supporting that foundation financially.Your customers should also become sponsors or members of the foundation(s) that your project(s) are hosted under, and you should actively encourage them to do so. Listen to the entire episode for even more insights! 

This week on The Business of Open Source, I spoke with Vinoth Chandar, the founder and CEO of Onehouse and the creator of Apache Hudi. We took a pretty deep dive into the relationship between Onehouse and Hudi, a topic that for me is at the heart of building a company on top of an open source project. In fact, whether or not Onehouse is an ‘open source company' could be debatable; Hudi is an Apache project — it's not owned by Onehouse in anyway — and Onehouse is not a ‘managed Hudi' or ‘enterprise Hudi.' Onehouse solves a problem that is fundamentally not the same problem that Hudi solves. Here's some other take aways from my conversation with Vinoth: There were both technical and business reasons for the relationship between Onehouse and Hudi; Hudi is a library, and you can't offer a library as a service. Also, Onehouse does way, way more than Hudi.Out of Hudi's 16 project management committee members, 5 are from Onehouse. Which means both that Onehouse has a significant presence, but also that it can't completely control the project. The disadvantage of being in a ‘hot' market, which means there are lots of big players trying to define the narrative around data lakehouses.Starting Onehouse two and a half too late… or was it actually too early? We had a discussion about timing of starting the company, and Vinoth had arguments for why they started the company too late, but also why it might have been too early. Are you giving away too much? The Onehouse board sometimes thinks so; but what Vinoth thinks was a mistake was not spending enough time educating both Hudi users and the larger community about just how much Hudi can do, instead of letting external players define the narrative about what Hudi does. Check out the full episode for more wisdom from Vinoth! 

This week on The Business of Open Source, I spoke with Joe Duffy, co-founder and CEO of Pulumi.We kicked off the conversation by talking about why Pulumi is open source in the first place — a mix of Joe's long-standing interest in open source and a feeling like a developer tool like Pulumi just has to be open source in order to be taken seriously. But there was another reason, too: Pulumi's founders weren't just in it to build a company, they wanted to transform their industry and build a lasting community, and felt like open source was the best way to do that. Lots of good take aways in this episode, like: Learning from open source legends... uh, actually, learning from Microsoft. Microsoft is an open source giant, right? It's interesting to hear Joe talk about learning about open source business strategy from Microsoft, precisely because Microsoft does not make money directly from VSCode, and also does not invest millions of dollars into R&D just to be nice. “If you're going to try to build a business with open source, you need to be very thoughtful and very strategic about it.” The founding team at Pulumi sort of iterated on figuring out the business model, but to a large extent they just thought about it until they had an Aha! moment. On the other hand, they didn't go public until they thought they had a winning strategy for building an open source business. In the case of Pulumi, there's a client side and a server side, so it made sense to build in a natural division between the two. This also made it so users were less likely to feel like Pulumi was holding back essential features in order to drive sales. “The way I always view it is the thing you're selling has to stand on its own” Pulumi started a company, an open source project and a commercial product at the same time. Joe's not sure he would recommend that approach, but it worked for them. “Figuring out the relationship was importnat, but actually the most important thing was to have a successful open source technology.” One thing I wanted to pull out: Even though Pulumi launched the open source project and commercial product at the same time, they focused all their efforts in the first two to three years on getting the open source project off the ground. Many founders I talk to think that once the commercial product is out there, you are forced to build a GTM team… but you don't have to. In fact, I think the strategy of having the possibility to buy the commercial product while focusing the company's energy on the open source software in the beginning is brilliant. Result: “We were able to create this immense funnel of inbound commercial interest, even when that wasn't really the top level focus.” Even if you're primarily a SaaS company, you can still offer an enterprise on-prem version for customers with hard requirements to host themselves, like air-gapped environments. Just because that option exists doesn't mean you must build GTM motion for it, though. The business value Pulumi gets from the open source project is: generating leads, building the company's brand, and also recruiting top-level talent. The fact that developers building the tool are so close to developers in the community is also a huge advantage. Listen to the full episode, it has a huge amount of great insights!

This week on The Business of Open Source, I spoke with Tyler Jewell — for the second time, now. Last time I spoke with Tyler, he was an investor at Dell Technologies Capital, he's since taken over as CEO of Lightbend. We talked about a lot, but there was a definite theme to our conversation: License changes. Lightbend had been running an open core model, with the open core using a permissive Apache license. The company's open source project, Akka, is massively popular. Lightben had about $13 million in ARR. But it was spending over $20 million per year, mostly of on R&D and then GTM. And they had a churn problem; and the churn problem was that customers would stop buying Lightbend's product, but they would stay with Akka, because it was good enough. Why did this happen? The added proprietary features weren't valuable enough for companies to pay for, especially in the face of budget cuts. And because the community was quite mature, it often started to duplicate these capabilities. And then the company faced a near-death experience in 2021. At the same time, usage of Akka was only growing, while the company was facing potential bankruptcy. Investors saw the potential and didn't want to give up on the company, but it was clear to the board of directors that something needed to change — and that the thing that wasn't working was the business model. So they changed it. There's a couple things I hope people can take away from this. If the difference in value between your commercial product and your open source project isn't big enough, you'll have a rough time building a profitable company. Sometimes the alternative to changing a license is bankruptcy; bankruptcy ultimately is not in anyone's best interest, not the company, not the community's, not the customer's. Offering a cloud option can work, but it's an entirely different business, and trying to build it up while the company is in a crisis and expecting it to save the company is only realistic if there's a good overlap between the market for the cloud offering and the open source project; in this case, there wasn't good overlap. The license options open to you depend on what the actual software does. And if you're going to enforce the license at all, you need to have some visibility into where it's installed, which, again, can be challenging depending on what kind of software you're dealing with. Changing an open source project's license is not a trivial undertaking. You have to hold copyright to the code, and you better hope that you're structured your contributor license agreements correctly. You also have to do the change on a new release — and it's more likely to work if the new version is different enough from the previous one that people really want to update. If you're going to make a license change, you might get backlash, but if being transparent and honest can go a long way towards minimizing the PR disaster. So what happened? Churn went down, revenue is nearly doubled and Tyler projects that this year will be cashflow positive. This summary doesn't do it full justice, though, so check out the full episode!! 

This week on The Business of Open Source I have an episode I recorded on site at AI-Dev in Paris with Justin Cormack, CTO of Docker. We finally get around to talking about AI at the very end of the episode, but otherwise we talked business and open source and how Docker manages both. Here's some of the take aways from the episode:There are upsides and downsides to being an open source company, and you should absolutely make sure you are leveraging the upsides. Because they don't necessarily translate into business value automatically, you have to be intentional to make that happen. It's often a good idea for open source businesses to create a commercial product that is complementary to their project, so that if usage of one goes up usage / adoption of the other goes up, too. This is in contrast to an open core model, where the open source project can easily end up being crippled so that people are incentivized to buy the closed source license. If you want to get to $100million ARR, you can either sell $10 subscriptions to 10 million people or you can sell $100,000 subscriptions to 1,000 people. Both get you to the same revenue number, but the business model is very different. We also talked AI and open source, given the event we were at. 

This week on The Business of Open Source, I spoke with Karthik Ranganathan, founder and co-CEO of Yugabyte. This is the second time Karthik has been on the podcast, but since three years had passed I thought it'd be a good idea to catch up and see what's changed at Yugabyte and how his perspective on the open source commercial ecosystem has changed. Some really cool topics came up in this conversation. For example: Why engineers don't choose databases based on features (and how this is related to why so many databases are open source This was super interesting, because I've seen a lot of conversations in the developer tools space about how developers choose their tools based on the features the tool has, and you should therefore market/sell based on features (unlike marketing/selling to any other market). I think this is bullshit and based on a misunderstanding about the difference between a feature and a benefit. Going back to the database market, we talked about how ultimately database users need to develop an intuition around when a particular database is the best choice, and that it takes time to do so. Choosing a database is about choosing what to prioritize for a particular application, and in a way Yugabyte presents its users/customers with a way to prioritize what's important, simplicity or flexibility. Companies that want more simplicity get something that's fully managed (and pay for it) companies that prioritize flexibility above all else are a better fit for the open source. The database is the same, regardless of whether someone is using the pure open source version or the fully managed service — and it's important to Yugabyte that everyone gets the same core functionality. How the role of open source and it's value for Yugabyte as a company has changed as the company has matured, and in particular how it's a way for people to try out Yugabyte first, and then reach out. Why Yugabyte has invested in making sure the open source user experience is excellent — because they want users to get value out of the project immediately; no one has time to spend four days figuring out how a new database works. This is part of why they think the open source project has become a lead engine. The importance of messaging in helping people understand quickly what to expect from the project and minimizing the amount of time it takes for them to get value out of it. Whether or not Yugabyte was a bit early to the cloud native party, and the pros and cons of being early. And much more! 

This week on The Business of Open Source, I spoke with André Eriksson, founder and CEO at Encore. We talked about how open source develops trust, something I also discussed in the episode I recorded with Reshma Khilnani. For Encore, it's subtly different, though. In the case of Medplum, open source is a differentiator in a market that's used to black boxes, for Encore, open source is tablestakes in a market that won't adopt a completely proprietary software. We talked about: Launching with a cloud platform from day one — not the open source project. On the other hand, open source is also important because often users and customers have to modify things to get it exactly right; the flexibility is a critical part of the platform's draw. The challenge getting contributions, which André doesn't find surprising, especially because it's a project/product that solves problems for companies, not hobby projects. Having one brand for the open source project and the product, which can make it hard to communicate the difference between them. Ensuring that the open source project and all of the features in it are useable without being dependent on the commercial product — which is not always easy. Finding the right balance between avoiding crippleware and still having enough of a difference in value between the open source and the commercial product to sell it is a core challenge. The biggest risks from open source, which André kicked off by talking about the difference between what you perceive as a big risk and what objectively is — this is a distinction that I think is super important to understand in life and business. Ultimately he settled on a big risk just being that you build something that isn't valuable or differentiated enough for people to pay for. Communicating the value proposition clearly is their top challenge at the moment. Check out the full episode for some serious insights into what's working and what's a struggle at Encore. 

This week on The Business of Open Source I spoke with Saurav Pathak, chief product officier at Bagisto, about a very different kind of business relationship with open source — and open source software incubated in a larger company. There were tons of interesting nuggets in this episode, but some things I wanted to call out are:For open source projects, the tech stack that the project is built with can in fact be a differentiating feature. This is unique to open source (and has come up before, both in my consulting work and in podcast interviews). Users might want to choose a project because it's written in the language they are familiar with, even if the functionality is exactly the same as a competing projectThe difference in needs between the merchants (who just want to get their ecommerce store up and running) and developers building ecommerce platforms, who was worried about being able to build extensions How an open source company like Bagisto fits into the larger commercial strategy for the parent company. Build a community of developers versus building a community of merchants, and why both are important for a project like BagistoHow Saurav manages the tension between adding features that people want and not building an overly bloated product, including how to manage this tension when someone wants to contribute a feature that the core team may or may not want. It's always interesting to me to see different models for open source companies, and Bagisto certainly is a different model. Especially after last week's episode with Tanmai Gopal, which had a much more classic story. 

This week on The Business of Open Source I spoke with Tanmai Gopal, co-founder of Hasura. We talked about how Hasura grew out of Tanmai's previous company, which was a consulting company. I like to call out examples of really novel open source businesses, but in fact the thing that stuck with me from the conversation with Tanmai was that Hasura is going the ‘classic' route… and it's working. What does the ‘classic' route look like to me? It's an open source project that targets individual developers and a commercial product that targets teams and teams of teams. It's having additional network security features in the commercial options. It's using the open source project as a growth engine and getting leads from companies that depend on it. It's also using the open source project as a way to get feedback on the product roadmap. Here were some of the takeaways from our conversation: It's a lot easier to sell a product if your customers see it as mission-critical. One of Hasura's first inbound leads was from a Fortune 100 company who said they'd be unable to ship any software for two weeks if Hasura went down — and so they wanted to make sure the team behind Hasura was serious and also wanted to pay them to make sure they didn't go down. For Hasura, the first clear difference between open source project and commercial product was that the open source project is for individual developers but the commercial product is aimed at the team level.Even for the cloud hosted edition, the product with ‘developer-level' focus is free. In fact, if you go to the Hasura CE product page, the CTA asks you to use for free on the cloud. Tanmai said this is an intentional choice because they want to reduce friction for people to test it out, and the fastest way to get up and running will always be to use the cloud version, not the open source. We talked a lot about the control plane versus the data plane — all the editions have the same functionality at the data plane level. But the control plane, where people are collaborating — that is commercial only. The open source project can be a great way to stay close to your users / customers and use their feedback to constantly refine your product roadmap. In fact, this can be a main advantage of being open source, because it is the only way you stay close to your users and get their feedback — otherwise you would often only talk to the buyer, who is likely an exec with a big budget but not using the technology on a daily basis. This doesn't mean open source doesn't create liabilities for Hasura — it does, and those liabilities have to be managed. And Tanmai is frank about the fact that creating enough value on top of the open source project without crippling the growth engine is a tough balancing act. Pay attention to what your best customers are doing! That has informed some really important product decisions for Hasura — and it took them way to long to figure out the unique way their happiest customers were getting more value out of Hasura than other users. Definitely check out the full episode for more insights from Tanmai! 

This week on The Business of Open Source I spoke with Reshma Khilnani, CEO and founder of Medplum. Medplum is an open source electronic health record development platform, and one of the things I loved about this conversation is that Reshma is so focused on the healthcare industry — a level of focus that I find relatively rare in open source companies. And not only that, when I asked her if she thought the company's focus was too narrow, she responded that actually she often worries that it's too broad. Another thing I really liked about this episode is that open source, for Medplum, is about trust and transparency, not growth. Medplum's customers, Reshma said, just don't mess around with free software that doesn't come with compliance certificates and some kind of support guarantees. It's a great episode to come on the heels of the episode with Adam Jacob, who talked about the difference between code, software and a product — that is a distinction that Medplum has clearly nailed. Other takeaways if you're running an open source company: Reshma is clearly really passionate not just about developing software, but about building software for the healthcare industry. She can also clearly articulate why her customers are not well served by the standard, off the shelf development platforms that can be used by any industry. This industry-specific expertise is really powerful, and quite frankly something I don't encounter very often. Even though there are different legal regimes in different countries, the underlying needs are pretty similar, so even for something as specific as healthcare companies it's not particularly challenging to provide a solution that meets the needs of customers around the worldMedplum is Reshma's third company, but her first open source company. She talked about how one of the key differences between building an open source company and a her previous companies that that the company has to pay incredible attention to the implementation details that at any other company no one would care about. Yes, you're building a product company… but that doesn't mean you should never sell professional services. Reshma says that one mistake she made was being too rigid about not selling any professional services at all, and ultimately they ended up offering packages of services to help customers get their implementations running. One last bit of info: Reshma compared the conversation around open source startups now with “internet startups' in 2013. Will all startups be open source startups in 10 years? I guess we'll see. 

This week on The Business of Open Source, I spoke with Adam Jacob, founder and CEO of System Initiative and formerly the CTO and co-founder at Chef. We had a wide-ranging conversation that at times veered into the philosophical (what is the meaning for ‘strategy'?) but also has plenty of concrete, practical insights. We talked about:The difference between being the CTO and being the CEO of a startup, even if you're a founder in both cases (and why Adam wanted to try out the CEO role this time)How Chef started out open source primarily because Adam and his co-founder really believed in open source values How they figured out a business model for Chef, but that it really felt like they were just making it up was they went along — and how he suspects that's what most people doGetting disrupted four times, and trying out many different business models along the wayWe also talked a lot about total addressable markets, serviceable available market and serviceable obtainable market in the context of open source companies. Three key takeaways: The software is not the product. A product is the entire experience of using the software, including how it is installed, how the team is onboarded, what compliance certifications you have, what happens if you have a problem, etc. As a vendor of open source software, you need to focus on creating and selling a whole product and take the focus away from the code. You can have 100% open source code and still sell a product, because they want to have a complete experience with support and compliance paperwork etc — and because they value buying those things from the same people who are writing the code. The way to calculate TAM is to multiply the number of people who want to buy a product by the average selling price of the product. When you phrase it this way, it becomes obvious that the TAM for any open source software is zero, because the average selling price is zero. If you enjoy this podcast, please share with other founders and leadership in open source companies! And if you like the idea of open source lawyer trading cards, reach out to Adam and he'll start a physical product company next :). 

This week on The Business of Open Source, I had a very different sort of guest — Mark Boost, the CEO and founder of Civo. We talked not only about Mark's history as an entrepreneur, but also Civo's recent acquisition of KubeFirst. This topic caught my eye because it's not often I get an offer to talk with an acquirer of open source companies, and I wanted to take him up on it. (Though if you missed it, I also talked to Thomas di Giacomo about this topic, and it was fabulous). The that is different about this case is that Suse is fundamentally an open source company, but Civo is not, and this was the first time that Civo had acquired an open source company. We talked about:How the relationship started long before anyone was thinking about an acquisitionWhat the 1 + 1 = 3 equation looked like in this particular caseHow it makes sense for an infrastructure company to acquire a complementary software company What it means to hire a pre-revenue open source companyIt's a relatively new acquisition, so we did a pre-mortem on it together, and Mark talked about what could go wrong — a super interesting process. Lastly, we talked about Civo's open source projects and what business value the company gets out of it's relationship with open source in generalCome join me at Open Source Founders Summit if you want more conversations about building open source companies! 

This week on The Business of Open Source, I spoke with Brian Fox, co-founder and CTO of Sonatype. In addition to having a really interesting discussion about the usual topic of how to build a business around open source software, we also had a good conversation about security — it was hard to avoid, because we recorded this right after the xz backdoor discovery, and software supply chain security is kind of Brian's thing. Business-wise, though, we also covered some really cool topics. Including: The tension between an open source project that's “too good” and yet the need for the sales team to close dealsIn some ways, the fully commercial, closed-source products in Sonatype's product line are more straightforward… but there are challenges that go along with a pure closed-source approach, too, especially for a DevTool company. Choosing your relationship with open source depending on who your target user / target buyer isPivoting to a top-down sales motion because the bottoms-up motion just didn't work; and how that means the features that sell aren't always the features that get usedWhat Sonatype gets out of it's relationship with Apache Maven and open source NexusHow do we solve real problems, and how do we solve them for real? Keeping in mind that no one buys what they need; they only buy what they want. Check out the full episode, and come to Open Source Founders Summit if you want more opportunities to talk about about business and open source. 

This week on The Business of Open Source I had Rod Johnson, founder/CEO of Spring Source and creator of the Spring Framework (as well as board member of many other open source companies) on to talk about Spring, monetizing open source and what's changed in the open source ecosystem since 2008. Key takeaways:Consulting was burning the entire team out, and that threatened the health not just of the consulting business, but of the open source project as wellAn amazing salesperson can often sell anything, but that doesn't mean that you'll be able scale, because your entire sales team is not likely to be incredibly brilliant Spring Source ended up not monetizing Spring at all — but rather worked on monetizing with products that were complementary to Spring. “We monetized Spring by not monetizing Spring, by using it to open the door” The moment that the company really started to see success as a product company was when the team stopped thinking about what they wanted to build and instead focused on what customers where telling them that they wanted.The risk of having a bunch of very good engineers on your team is that they're excited about solving hard technical problems — but your customers might want something that is not very technically challenging or interesting. A major part of the job of a company leader is to talk to your team and get them on board with your plans The environment around monetizing open source projects has changed — there are things that worked in 2008 that wouldn't work today, and things that didn't work then that would be fine nowIf you love (insert your favorite open source project here), it has to have a sustainable economic modelIt's really critical to have a rationale behind what functionality goes in your product and what goes into your open source projectAt the end we talked briefly about Open Source Founders Summit, a conference for leaders in open source businesses happening this May 27th and 28th in Paris.