I talked with Anais Concepcion about a program she’s been testing at Grist to give free activation codes for the enterprise version of Grist to individuals and small businesses that have a revenue under $1 million. The program has been in place for 5 months, and Anais came on the show to talk about both the strategy behind the program as well as some preliminary results. 

The strategy comes down to shifting the perception of Grist Open Source and Grist Enterprise. The goal, Anais says, is to make the ecosystem consider Grist Enterprise the ‘default’ version of Grist, rather than the other way around. In fact, she’s considering renaming Grist Enterprise to just “Grist” to reinforce the idea that it is not the ‘special’ version of Grist, but the default version. 

There were other strategic goals, too. One is to get more feedback on the ‘enterprise’ features, another is to avoid nickel-and-diming individual users while making sure that big companies are paying. 

The results so far have been interesting. The biggest concrete result has been in partnership relationships; it’s easier for small consulting / development shops to get access to the full Grist and to then resell it to their clients. There haven’t been been any signed deals yet as a result of this dynamic, but there are companies in discussions with the Grist sales team that probably wouldn’t have happened without the program… it will be interesting to see what happens as the program matures. 

After we turned off the recording, we had an interesting discussion about pricing as well; at Open Source Founders Summit Anais is going to do a workshop on pricing strategy. Not how much to charge, but what to charge for (consumption, seats, etc), how to set pricing anchors, and more. Join us in May if that’s interesting to you! 

So why does it matter? 

• Developers prefer open source, and they’ll always choose the open source option if there is one. On the other hand, developers don’t often have buying power (and don’t even know how to buy software even if they did). But developers can influence buying decisions, and that can be important. 
• We also talked about how there are different constraints that the open source project and the cloud version operate under. For example, ease of deployment doesn’t matter in the cloud version, because it doesn’t impact user experience at all. But the opposite is the case for the open source project, and that leads to different technical decisions. 
• We talked about the problem getting information about people who use the open source project, because it is hard to get developers to talk. This is a puzzle that Tom says he still hasn’t cracked. 
• Being an open source / open core company is a distraction, and it can be hard to manage externally and internally. 
• We talked a lot about trust — how open source helps you earn trust, but you still need to earn and keep the trust. 

Want to talk more about the ins and outs of running open source businesses, and how open source companies win? Come to Open Source Founders Summit next May in Paris. And if you’re struggling to figure out how to monetize your open source company, you might want to work with me. 

We talked about the need to find product-market fit, particularly in the AI era — Quentin says that AI companies need to find product-market fit constantly, because the ecosystem is changing so quickly. 

Quentin mentioned hearing from an advisor earlier in his career that you can’t focus on both usage and revenue — but that in some ways you are forced to focus on both, especially now. When I asked how you decide which of the two goals you should throw more resources behind, he couldn’t say… it’s such a case-by-case decision that there isn’t an easy formula for deciding. 

Lastly, I had a burning question: What actually does go-to-market mean? And what does it mean to be a “Head of Go To Market?” Quentin says that to a large extent it’s a euphemism for sales, but there’s a little more to it than just that. In his mind, Go-To-Market is a much less siloed function than sales. It’s about getting the entire company aligned, in the expectation that ultimately that will lead to sales. But it’s not just about forcing prospects down the funnel or cold calling, either. 

Want to talk more about the specifics of go-to-market for open source companies, with people who have been there? You should join Open Source Founders Summit, an in-person conference for leadership in open source companies. The next edition will be May 18th and 19th, 2026 in Paris. 

And curious about my consulting options? Check out how I help open source companies here. 

One thing to note is that none of Permit’s open source projects are branded as “Permit.” They are all separate from the permit.io brand. On the other hand, Or talked about the essential balancing act for open source companies… figuring out the balance between what goes in the open source project and what goes in the commercial offering. “Companies that get it wrong die, and companies that get it right end up flourishing,” he said. 

Or Weiss has a theory about open source businesses that he calls ‘open foundations.’ He thinks that this model is better than open core — to be honest I think open foundations is a type of open core, but I think that Or’s argument about how to do open core are fundamentally correct. 

Permit’s primary open source project is OPAL, and the way that Or puts it is that Permit uses OPAL, but it is not OPAL. The two pieces of software are different and have different value propositions. He also talked about how important it is for everyone to understand what features belong in the project and what belongs in the product… by ‘everyone’ he means product managers in your team but also members of the open source community. 

We also talked about how you have to have a moat for your product, and especially with AI coding tools a lot of models do not have a moat anymore. Which is why he doesn’t think that just SSO and a fancy UI are enough of a difference between project and product anymore. 

If you are interested in having more conversations about building open source businesses, join us next May in Paris at Open Source Founders Summit! 

Some of the things we talked about include: 

• The state of open source in the semiconductor space, and why that matters. A large part of it is the high cost of proprietary software for chip design, and the fact that there are a lot of barriers to entry, both for the design software and to chip creation. 
• Rob also talked about how an open source approach is the only way to bridge between research institutions and universities and the commercial world — too often, researchers would do brilliant work during a Ph.D. program and then it would be completely lost when they entered the commercial world. 
• On the other hand, open source is little-known and mistrusted in the semiconductor space. Rob described it as a marketing liability, which is why it’s downplayed on the company webpage. —> I come across this more often than is often recognized inside the open source bubble. 

It’s one thing to build an open source company in the software infrastructure space, where open source has a positive reputation and is often seen as simply table stakes; it’s quite another to build an open source company in a conservative industry where open source doesn’t have a positive image. Perhaps the most interesting thing is that this means you have to have a reason other than marketing to build and maintain the open source project. 

Want to join others to talk about the challenges and opportunities in building open source companies? Join us at Open Source Founders Summit next spring in Paris. 

Taco is the co-founder and CEO of Open Social. 

A couple interesting takeaways from our conversation: 

• When you’re transitioning from a services company to a product company, it’s much easier if the product you work on is connected to the services your clients are already paying for. 
• Landing a huge customer, particularly if it’s your first customer, can be a double-edged sword. On the one hand you have a lot of revenue, but you also risk becoming your customer’s servant and losing control of your product’s roadmap. 
• You can’t do everything; and particularly you can’t build a product that meets the needs of small, medium and large organizations. 
• Sometimes you need to re-launch / reposition. Open Social recently completely changed their positioning earlier this year in response to changes in the marketplace and how their customers were use the product. 
• Customers might not care about open source, but they care very much about lock-in, exit costs, and data sovereignty. This is all a part of risk management that CIOs are thinking about a lot. 
• Some organizations use both the self-hosted and the SaaS product. 
• One of the biggest / most instructive mistakes they made was maintaining completely separate codebases. When they invested in merging the codebases, it dramatically improved the customer experience in relation to updates, bug fixes and simplicity of the engineering effort. 

 We talked about Open Source Founders Summit at the end — and which is where I first met Taco. If you’re interested in joining us in 2026, sign up for the newsletter! Tickets will be on sale soon. 

Perhaps the most interesting part of the conversation is the discussion of the business model. It’s almost like open core in reverse. Penpot open source is fully featured and very flexible; but there’s a separate product available for business stakeholders to control how Penpot is used in their organizations. So when you need gouvernance and control, you should pay for the additional product to control Penpot usage in your organization. But if you don’t need to limit how Penpot is used at all, you (and everyone else in your organization) can use the open source version without the additional controls. 

We also talked about dual audiences. Penpot has to appeal to designers and developers, and building something (and ultimately marketing/selling it) that has to appeal to two very different stakeholders. We talked about how the company manages that balance, and why they want to have more developers using Penpot than designers. 

We talked a bit about Open Source Founders Summit as well. If you’re interested in learning from other founders and leaders in open source companies, join us at Open Source Founders Summit in Paris! 

At Zulip, they think about the contribution process as a product. They think about the contributor experience and making it as easy as possible for new contributors to get started. They even did user experience testing on the developer experience for contributors — and made changes as a result. 

And why does this even matter? Because when it’s done right, community contributors can end up increasing your development velocity. Especially on things like integrations, the community contributors can really push things forward. 

There’s much more to this episode, so check it out! And if you’d like more content about open source companies, or if you’re the leader of an open source company, join the mailing list for Open Source Founders Summit. 

The dual flywheel strategy 

This strategy is based on the idea that as an open source company you want to simultaneously push growth in your open source user base and your customer base, and that the two should reinforce each other.  

The co-create strategy

The co-create strategy involves encouraging paying customers to contribute to the open source project. In other words, customers who are already paying are encouraged to also invest engineering resources to improve the product. Nick said that this has obvious benefits for GitLab, but it also has benefits for the customers. They end up with a much better understanding of the product, and end up getting more out of the product then they would otherwise. 

If you want to learn more, I highly recommend having a look at the GitLab Handbook, particularly the section on strategy. 

And if you want more information about working with me, check out the options here. 

Before David founded Expanso (which is behind the project Bacalhau), he was the first non-founding PM on the Kubernetes project, and we kicked off by talking a bit about what made Kubernetes so successful… and you probably can guess that it didn’t have to do with having the most awesome technology. A big part of it was that it was the right time and a number of factors in the larger ecosystem were aligned in favor of making Kubernetes a success. 

It comes down to luck and building to where the puck is going… so how do you know where the puck is going to be a year from now? David talks about selling into basic truths. If you’re pegged to a specific technology, you’re putting yourself at huge risk. But if you are solving a problem that has always been a problem and is likely to continue to be a problem, you are more likely to be successful. 

We also talked about Adam Jacob’s talk on building a business around open source that he gave at KubeCon Salt Lake City, which you should definitely listen to. Adam Jacob also came on this podcast a year ago, and you should also listen to the episode he did. 

Lastly, we talked about how hard GTM is, and how David would invest way more into GTM, starting much earlier, if he could start over again. 

David was at Open Source Founders Summit this year, and you should come next year too! 

• Spinning out from an agency —> in my experience, one of the most common ways for open source companies to be bootstrapped, or even to be go on to raise venture capital, is to start out as a web development agency that uses a lot of open source tools.
• They are working on moving away from services and getting more revenue from the product; and Thomas talked about the advantages that they get from providing both services and developing a product-based business strategy.
• The CMS market is crowded! And everyone is open source, so being an open source company doesn’t differentiate the product at all. So how does Sulu differentiate itself in the market? Thomas talked about it. 
• I loved that Thomas talked about how important opinions and technology choices are in differentiating themselves on the market. 
• I also loved that Thomas talked about keeping some things out of the product as a way to differentiate themselves from others. Sometimes more features can deliver less value to users. 
• How being small can allow you to move quicker, and that gives Sulu and advantage over the huge players in the CMS market.
• Why differentiation and knowing your niche is so important when you’re a small company competing again large players. 

Do you need to differentiate yourself in a crowded market? You might want to work with me. 

So who is part of the community open source projects that are so connected to hardware? Here’s what we talked about. 

• There aren’t many hobbyists in the community — but there are a lot of people who have professional interests in the electric vehicle industry. EVerest doesn’t focus on what Marco considers “personal” or “hobbiest” features. This was a great discussion about how understanding the target market, including for the project, leads to different feature decisions. 
• How does Pionix money? It doesn’t yet :), but we talked about various plans the company has for monetization in the future. 
• How being involved with the LF Energy has helped build trust, which is very important for a company that is only going to be selling to large companies and governments. 
• Why Marco thinks that the huge vision he has for creating firmware for EV charging stations is only possible with open source, and how he makes sure that he’s able to fund the large mission without hurting the community. 
• The balancing act with getting investors who specialize in the energy market but who don’t have experience with open source

Struggling with positioning your project or figuring out how to best monetize? You might want to work with me. 

Several things that we talked about: 

• AI and open source code. This is a topic that’s slightly tangential to business, but very interesting to me. If you’re using an AI code generator, you are almost certainly putting verbatim copies of open source code into your codebase, but without realizing you’re doing so and without any understanding of the license requirements. This is a huge compliance risk. 
• 2% of code generated by AI is a verbatim copy of open source code. 
• How the biggest challenges isn’t necessarily monetizing, but getting visibility into the sales funnel. It can feel random and sudden; a company appears out of nowhere ready to sign a contract because they’ve been using the open source project for months. 

This is the last week to get tickets for Open Source Founders Summit, so if you want to join other leaders of open source companies May 19th and 20th in Paris, get your tickets now! 

We talked about: 

• Trademarks. This is a very important part of what you donate when you donate a project to the CNCF (or other foundations). We talked about what you can and can not do with the name and logo of “your” project when it becomes part of the CNCF, and what that means for the competitive landscape you’re a part of. 
• How to best take advantage of the marketing benefits that being part of the CNCF brings. 
• How to create a link between the CNCF project and the company that donated it. 
• The role that Cilium and eBPF played in Isovalent’s acquisition by Cisco. 
• Why Isovalent’s relationship with open source is valuable to Cisco in and of itself. 
• How open source companies can increase the likelihood that they’ll be able to continue investing in open source post-acquisition. 
• Why it’s so important to find opportunities for collaboration. 

Want help making the link between your CNCF project and your commercial product? You might want to work with me. 

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. 

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 edition
• How 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. 

Here’s what we talked about: 

• Differences between venture funding for OSS companies in Europe and in NA
• How 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. 

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 out
• The 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 project
• Why 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 mistake

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

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. 

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. 

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 does
• How 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. 

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 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 years
• The difficulties that come from being small and bootstrapped
• Managing the balance between distribution and monetization
• Why a community version / enterprise version model did not work for XWiki
• Why 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. 

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. 

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 foundation
• How 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. 

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 itself
• Why Chronosphere’s core platform isn’t open source itself
• How 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 obvious
• How 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. 

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. 

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 license
• Not 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. 

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. 

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 😳 my favorite topic. If you’re curious, I did a talk at All Things Open on the subject, one that was sadly not recorded :( but you can reach out if you want the slides. 
• How Pomerium manages that tension, both internally and externally. There are open source purists as well as cutthroat capitalists. Bobby describes it as making a bet on the middle. 

If managing product-project tension is something you’re struggling with, reach out, you might want to work with me. 

And if you want more conversations about the unique aspects of open source businesses, you should come to Open Source Founders Summit this May. Join the mailing list to find out as soon as tickets are available. 

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? 😳 Mark guesses that it’s 5%, and he talks about what he’s tried doing at Diagrid to make that percentage go up. Is 5% good or bad? We talked about how it’s hard to know, actually, how Dapr/Diagrid compares on that. 

###

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. 

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. 

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 company
• When 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 itself
• What Solomon is doing differently at Dagger compared to Docker, one of which is thinking about monetization much sooner
• The 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! 

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.  

The biggest 🤯 in this episode was about enforcing what it means to be open source; in particular, FerretDB positions itself as a truly open source alternative to MongoDB, and has received threatening letters from MongoDB as a result. How do you enforce it when a company claims to be open source but does not use an OSI-approved license? How well do the average users actually understand the license implications, and if a big company says they have an open source license even though it’s source-available, not open source, how much will people understand the difference? 

If you want another perspective on the enforcement of advertising around open source licenses, listen to the episode I recorded with Stefano Maffulli, also at All Things Open. 

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

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. 

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. 

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 address
• User personas versus buyer personas
• The situations in which Grist is the best option — which incidentally I could not understand from the website or the project documentation
• The 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 velocity
• Giving up ‘darlings’ or features that they really want to develop but that they don’t think would drive revenue
• The 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. 

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. 

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 for
• How open source companies, and open source projects in general, can be viewed as risky if they are only backed by one company
• Who 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 directly
• Why 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. 

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 project
• On 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 customers
• The 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. 

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 product
• Why they originally had two products, and then decided to merge them into one single product
• How 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. 

So many things to unpack with this episode, but a couple I want to call attention to in particular. 

1. 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. 
2. 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. 
3. 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 source
4. How Altinity’s customers tend to value the four freedoms of open source

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

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

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 strategy
• Why people often do want to avoid self-managing critical infrastructure
• The difference in ideal user profile and ideal customer profiles
• How 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 company
• Why open source companies need to consider the open source users and communities as one of their stakeholders that needs to be represented in strategic discussions

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

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 overnight
• How 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. 

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 Eventbrite
• I 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 building
• It took five years for Pretix to hire one person, about 10 years after starting Pretix there’s about 20 people on the team
• About 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. 

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-prem
• We talked about product led growth and how there is an obvious starting point for promoting an open source project
• Why lead qualification is so important

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

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 source
• You might have to try a lot of different ways to monetize. Per said he felt like Umbraco tested 17 different income streams
• There 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. 

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 doing
• Why 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 it
• How 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 success
• Choosing 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. 

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! 

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! 

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!

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!! 

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

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! 

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. 

• 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 project
• The 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 Bagisto
• How 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. 

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! 

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 world
• Medplum 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. 

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 do
• Getting disrupted four times, and trying out many different business models along the way
• We 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 :). 

We talked about:

• How the relationship started long before anyone was thinking about an acquisition
• What the 1 + 1 = 3 equation looked like in this particular case
• How it makes sense for an infrastructure company to acquire a complementary software company 
• What it means to hire a pre-revenue open source company
• It’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 general

Come join me at Open Source Founders Summit if you want more conversations about building open source companies! 

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 deals
• In 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 is
• Pivoting 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 used
• What Sonatype gets out of it’s relationship with Apache Maven and open source Nexus
• How 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. 

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 well
• An 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 now
• If you love (insert your favorite open source project here), it has to have a sustainable economic model
• It’s really critical to have a rationale behind what functionality goes in your product and what goes into your open source project

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

• Is BoxyHQ a security company? Does it matter either way? 
• Starting the open source project at the same time as the company, and why they did it that way
• The relationship between the user community and the customer community
• BoxyHQ as the anti-platform — instead of trying to build a platform, which is the default goal for a lot of companies I speak with — they are explicitly trying to build a more a la carte experience for users
• The challenges of community building around a project that isn’t sexy and how to build community that isn’t project-focused, but rather that’s focused around a problem space
• Making the mistake of assuming your startup is completely unique and unlike any others! 

We talked about much more as well, and it’s definitely an episode you should check out. 

Here’s what we talked about:

• The first step of figuring out your pricing is not the number, but rather what you’re charging for. Is it API calls, or amount of data you’re processing, or monthly active users, or monthly active principles… that last one is what Cerbos is charging for
• Why it’s important to have a pricing system that allows potential users to be able to roughly estimate for themselves how much using your software is going to cost them
• You also want to avoid pricing models that encourage people to look for ways to hack around to find ways to lower their monthly costs
• Why your pricing model should be about the value you’re providing, not about how much it costs you to run your system
• Discovering what your price anchors are / what your customers are comparing you to

Check out the full episode for more details! 

And join us at Open Source Founders Summit for more discussions about the specifics of pricing for open source companies. 

I went with Patrick Backman, general partner at OpenOcean and co-founder of MariaDB, because it’s a little more in my lane. (The conversation with Brian Fox will have to wait for next week!). 

One of the main things we discussed was the relationship between the MariaDB foundation and the MariaDB company. Including: 

• Why they decided to put MariaDB open source in a foundation, and why they created a separate foundation instead of putting it in an existing foundation 
• The relationship between MariaDB foundation and company today, including the financial relationship

MariaDB was founded by the founders (and some key employees) at MySQL; we also discussed the lessons learned at MySQL that the team then applied at MariaDB. And we talked about customer acquisition, one of the things that Patrick thinks the team had learned at MySQL and therefore had pretty well figured it out at MariaDB. 

Patrick’s co-founder Monty Widenius is one of the speakers at Open Source Founders Summit — if you want to go into more details on with the lessons from MySQL and MariaDB, as well as lessons from being an investor at OpenOcean, join us in Paris May 27th and 28th at Open source Founders Summit. 

• Being an open source mercenary, but also being dedicated to making Linkerd a ‘proper’ open source project
• Feeling like open source was table stakes for a company in the space Buoyant plays in. This is an under-appreciated reason for being an open source company — you feel like it’s just expected in the market you play in, so you do. 
• Waiting too long (or is it too long?) to commercialize
• Starting out by selling support, but the problem with that because Linkerd worked well and people kept saying that they didn’t need support because they never had problems
• Competing against Istio, which was backed by the Google engine and how that made Linkerd / Buoyant an underdog (or cockroach). 
• For those of you who haven’t been following Linkerd / Buoyant… Buoyant recently announced that they would be doing edge releases for Linkerd, but not stable releases. We talked about why they made this change and how the ecosystem responded. 

Check out the full episode! 

Here’s what we covered:

• Why you should think of your project and product as two different products so you avoid thinking of your open source project as a loss leader and get your incentives right
• The differences between supplementary and complementary products, and how the relationship between project and product is often complementary, even in situations where that relationship is non-obvious
• We disagreed about pricing — should COSS businesses have cheaper products than closed-source companies? 
• Why cares about your being open source? 
• Are open source companies more capital efficient? Heather says so, but I’m not convinced. 
• Heather also talked about how they select companies to invest in
• Do open source companies by definition do a better job at paying attention to user / customer demand? 

Check out the episode, and check out more about Heather Meeker here: 

Personal website

OSS Capital

LinkedIn

We also covered: 

• How SigNoz is differentiated in the crowded observability market
• Why Pranay thinks being open source makes it much easier for developers to play around with the project and get to know it; so for them it made intuitive sense that the company that they’d build an open source company 
• Why Pranay also thinks open source enables much deeper integrations, which is critically important for an observability company like SigNoz
• How one of their first lessons / mistakes was releasing an open source project that didn’t work well on an individual developer’s laptop, because it used too much resources
• The GTM market, and the challenge delivering value within 30 minutes of trying out the project/product for an observability tool that provides maximum value during an incident — but no one is going to be trying out a new tool during an incident situation 
• Why their first commercial product was a cloud offering

And much more! 

And if you’re interested in more discussions of open source businesses, make sure to join us at Open Source Founders Summit this May. 

If you are the founder of an open source company and you have the idea of being acquired even in the back of your mind, this is a must-listen episode. Whether or not you plan to join us May 27th and 28th in Paris, though of course we hope you do join us. 

By the way, at OSFS Thomas is going to lead a workshop on the topic of being an acquisition target for open source companies. It will be interactive, which means you can ASK QUESTIONS. 

In this podcast episode, he talked about: 

• Exits 101. You probably know that strategic buyers usually pay more for companies than other types of acquirers, but we talked about different exit strategies and what they entail
• Why strategic buyers acquire businesses (in general) but also why you, as the business seller, need to understand every specific potential acquirer’s story and goals so you can see how your company fits into their strategic plan
• Strategic acquisitions are about 1+1=3… so you have to know what your buyer’s “3” is
• Why it’s important to be self-aware and know your own goals before you sign any acquisition paperwork

And tons more… 

If you want the chance to ask Thomas about strategic acquisitions for OSS companies — as well as to talk about sales strategies, lead generation and more — join us at OSFS 24 in Paris this May 27th and 28th. —> Get your invite here. 

PS the audio was a little quiet, but so if you’re having trouble hearing turn up the volume, it’s worth it. 

The first thing I wanted to call your attention to is that Zach talked about how he’s building an open core business because building an open source business is what he wants to do. When his previous company turned away from open source, Zach left to do consulting around OSquery and Fleet (the project). I always like to talk about how companies / founders need a solid reason for building an open source company… and “this is the kind of company I want to build” is a very good reason. (“Everyone else is doing it” on the other hand, is not a good reason). Everyone puts constraints around the type of company the want to build, and as long as you are intentionally about the decisions, there is nothing wrong about this, business-wise.

Second, we talked about the tension that exists between making a great project and still leaving room for a commercial product that people will pay for, and Zach talked through how Fleet uses a buyer-based open core strategy to decide which functionality to put in the enterprise version or in the open core. 

We also talked about:

• Leaving his first company, Kolide, when the founders had divergent visions about where the company should go
• How his investor arranged a ‘co-founder marriage’ for Zach and his co-founder Mike McNeil
• How the transparency aspect of open source can be extremely important, especially for anything in the security space

Lastly, Fleet happens to be a former client of mine. You can check out what Mike, Zach’s co-founder, said about working with me here. 

And if you’re interested in more conversations like this… but in person!!! you should come to Open Source Founders Summit May 27th and 28th in Paris. 

We talked about:

— How there was a dynamic around Cassandra where many of the many of the contributors ended up being sucked into the DataStax orbit, simply because it allowed those contributors to work on on Cassandra full-time

— How there can be tensions between different stakeholders simply because everyone involved ultimately has their own interests at heart, and those interests are not always aligned. 

— How it is actually hard to really have open discussions about new features, and how often there can be a new feature dropped in a project that clearly had been developed behind closed doors for some time, and sometimes that created tension in the community

— Some open source projects are just too complex to be hobby projects — Cassandra is so complex that you won’t become a code contributor unless you’re working full-time on Cassandra, because that’s the level of skill you need to keep up. 

— How the relationship between a company and a project often changes as the technology matures. 

— The importance of addressing tensions between company and community head-on, as adults, when they occur — as well as why you need to remember to treat people as humans and remember that they have good days, bad days, goals and interests. 

Patrick on LinkedIn

Mick on LinkedIn

A couple other things to pull out as takeaways. 

First of all, Frank talks about how he originally planned to target big companies who wanted to keep their data private — but as it turned out, most big companies don’t really care deeply about keeping their data private. On the other hand, the public sector and universities really do care, and those have ended up being a huge part of Nextcloud’s customers. 

Frank also talked about the rather obvious differences in needs between home users and big organizations. Nextcloud has some customers with millions of users — their needs are different from a home user. And as far as home users go, Frank says these users are obviously never going to pay Nextcloud anything. On the other hand, they have built mechanisms into the software to nudge open source instances with over 1,000 users to get in touch to talk about a commercial relationship. 

He also talked specifically about the importance of really talking with your customers and your users — and incorporating their feedback into your product roadmap. For open source companies, you have so much more information and feedback than proprietary companies, and you should take advantage of that to inform your go to market strategy. 

We also talked about how the millions of home users who will never pay Nextcloud are still extremely valuable to the company — and why Frank think it’s really wrong to think of pure open source users as just leads to be converted. 

And much, much more. 

If you’re the founder or leader at an open source company, and you want to be a part of more discussions like this, join us at Open Source Founders Summit May 27th and 28th in Paris! 

There’s a ton of great info in this episode, too. First of all, Ann talked about being a ‘suit’ in a geek’s world and her career trajectory that led her to lead Percona. She also set the stage around the constraints that Percona has chosen for itself: To be completely open source and only sell services, and to be completely bootstrapped. And what the ramifications of those decisions are for the business. 

Here’s some concrete takeaways:

• The key to thinking about managing the tension between creating a project that’s high quality and still being able to sell services on top of that is to ensure that the services really create value
• There’s a difference in profile between happy anonymous users and happy customers — often customers are operating at scale or are working in companies that simply always have to have support for critical software. But just as importantly, customers are often not database experts —they just need a database that works, and can turn to Percona to be their database experts. 
• Founders are often more emotionally attached to aspects of the company that a non-founder CEOs like Ann can sometimes be more analytical about what’s working and what isn’t
• Collaboration isn’t automatic, and how to make it actually happen
• How Ann decides what problems to collaborate with others on, what they don’t collaborate on and when in the project / feature lifecycle they look for collaboration

We also had a bit of a random conversation about controlling status in relationships — the book we talked is Impro: Improvisation and the Theatre. And talked about how founders who are ready to step down as CEO can find a replacement and manage the transition. 

Ann’s links:

LinkedIn

Percona 

• “Beware an entrepreneur’s second company.” — Mike says his second company was a disaster because he tried to apply the lessons from the first company in the second, and often those lessons aren’t right for the new business
• Going all in on being a product company — the toughest year in Gluu’s history was when they decided to stop consulting and make it or break it as a product company
• Why it’s a good idea to look at the market analytically and start a company in a market you’ll be able to compete in without a huge number of features
• Why Gluu actually has more features in the open source version than the enterprise edition — because the open source distribution gets features that are in beta whereas the enterprise customers need a product that is 100% fully baked. 
• Why Mike doesn’t believe in making the enterprise product more ‘scaleable’ — the open source project should be just as scaleable as the enterprise product

This episode was recorded on site at State of Open Con 24, outside in a media van! 

Also, this episode was recorded on site at OpenUK’s State of Open Con! 

Here’s the concrete takeaways from this episode: 

• Even before starting the company, Peter had built up a personal brand as a MySql expert — this is what made it possible for him to get consulting gigs pretty much immediately
• Peter’s personal brand wasn’t just around MySql in general, but was very specifically focused on MySql performance optimization
• How a growing team meant that the sales process had to get much more disciplined — and deal sizes had to get bigger so that it’s worth the sales team’s time 
• How to align sales incentives with your business goals — how it’s important to adjust sales quotas and incentives so that sales people don’t oversell, which can hurt your reputation long-term, and don’t sell long-term agreements at too much of a discount. 
• Why it’s important to separate out your revenue that comes from new customers and your revenue that comes from customer renewals, and how to do so in the organization

If you want more opportunities to go in-depth on sales for open source companies — and to discuss sales and other aspects of business development with other founders, join us May 27th and 28th in Paris at Open Source Founders Summit. 

In this episode, Garima explains how her experience in finance and belief in the power of open source helped MinIO to break into the data storage market. She also reviews the challenges she faced as a first-time founder and what others can learn from her mistakes and take away from some of their own. Since Garima started her journey with MinIO as CFO, she outlines that role for me and explains how she thinks a CFO should operate in an open source company. In reviewing mistakes she’s seen from other founders, Garima states some principles that create the “foundation for any open source business.”  - “You should always be very honest to your community. You should always be very transparent to the community”

Highlights:

• Garima introduces herself and explains why she and her co-founders started MinIO (1:31)
• Garima describes how the MinIO founders honed in on a problem they wanted to solve (3:55)
• How the MinIO founders used open source crack the market (6:37)
• What triggers a user to purchase a commercial license for the product (10:33)
• Garima explains why she and her cofounders were set on their open source strategy from day one (11:35)
• Garima explores the differences between being an investor and advisor for other companies and starting her own. (13:25)
• Garima shares go-to-market advice for other founders (15:21)
• Garima outlines her strategy for building on small successes (18:38)
• Garima explains why she started as CFO for MinIO and breaks down the role a CFO can play in a new company (21:46)
• Why Garima thinks a CFO’s role remains the same in an open source company as compared to a proprietary company (27:17)
• How to avoid competing with your open source product when you also have a commercial offering (34:06)

Links:

Garima

• LinkedIn: https://www.linkedin.com/in/garimakap/
• Twitter: https://twitter.com/garimakap
• Company: min.io

Highlights:

• Intro (00:00)
• I introduce Federico, who is a Partner at SquareOne (00:59)
• Federico describes his role at SquareOne and the areas of investment they focus on (01:28)
• What Federico typically sees when companies move from closed source to open source (04:42)
• How important conversations come up about business strategy and open source versus closed source (07:40)
• Why many companies end up not pursuing an open-source strategy (11:17)
• Federico tells the story of a company he worked with that made the leap from closed source to open source (15:03)
• The most critical things businesses have to do in order to utilize an open-source strategy (16:23)
• What decisions led to success in the company Federico helped shift from closed source to open source (18:09)
• The psychological challenges leaders face when considering making a pivot to open source (23:54)
• Federico shares the advice he would give to a founder who’s considering an open-source strategy (26:40)
• How you can connect with Federico (31:40)

Links:

Federico

• LinkedIn: https://www.linkedin.com/in/federicowengi/
• Twitter: https://twitter.com/federicowengi
• Company: https://squareone.vc/

In this episode, I talked with Remy about Open Source Founders Summit, a summit they're organizing on May 27th and 28th, 2024 in Paris, France — we each shared our motivations for organizing the event, and talked about why we think it's important for people to come together in person.

You should listen to the episode, but if you don't want to, the bottom line is that we think there needs to be a space for all open source founders (not just the DevTools, not just the VC-backed) can come together to share business ideas — a place where business, not tech, is the focus. 

Listen to the episode, and join us in May! 

Highlights:

• Intro (00:00)
• I introduce Ben Haynes, who is the CEO and Founder of Directus (00:59)
• How the Directus platform has evolved over time (02:33)
• Ben tells the story of what happened after the initial release of the Directus project in 2004 (06:06)
• The strategy Directus has used to land enterprise customers as a small company (10:20)
• Ben and I discuss the importance of early-stage open-source companies optimizing to work with government agencies (13:59)
• Ben describes the SaaS business model that he chose for Directus (16:38)
• Why Ben feels that open-source is the best strategy for starting a company (25:19)
• How Ben landed on a product-led growth strategy for Directus (27:39)
• What Ben learned about mistakes he made in timing his product and company (31:23)
• The advice Ben would give to another open-source founder (33:52)
• How listeners can learn more about Directus and connect with Ben (39:32)

Links:

Ben

• LinkedIn: https://www.linkedin.com/in/contactbenhaynes/
• Twitter: https://twitter.com/benhaynes
• Company: https://directus.io/

Highlights:

• Intro (00:00) 
• I introduce Peer Richelsen, the Co-founder of Cal.com, and he discusses the company and its calendar scheduling tool (00:59)
• Does Peer think about Cal.com as a dev tool (2:09)
• What is Cal.com’s business model (03:57)
• The lack of customizability in the scheduling tool marketplace (06:15)
• Switching from accepting donations to selling a profitable product (09:48)
• Launching without a free version (12:50)
• The human cost of freemium usage (16:20)
• The decision to raise VC funds (17:41)
• What business value being open source brings to the company (20:48)
• How Cal.com positions itself in the market (24:13)
• Interesting mistakes Peer has made as an entrepreneur (28:22)
• How “free” is the software (30:57)
• Peer’s parting words (32:27)
• Where listeners can connect with Peer and learn more about Cal.com (33:04)

Links:

Peer

• LinkedIn: https://www.linkedin.com/in/peer-richelsen-221233138/
• Twitter: @peer_rich
• Company: https://cal.com/

Highlights:

• Intro (00:00)
• I introduce Birthe Lindenthal, the Co-founder and CMO of OpenProject, and she gives us her background along with the company’s history (00:59)
• How OpenProject used custom developments to fund the business (02:42)
• The pros and cons of not taking VC funding (04:15)
• Ways in which being open source benefit the business and the customers (06:09)
• How OpenProject was able to monetize the user base (08:34)
• The division of revenue and users between on-prem and cloud versions of the software (10:24)
• Who are OpenProject’s customers and users (13:57)
• The most interesting mistakes Birthe made along the way (16:44)
• Merging branding between the free and paid versions (18:52)
• Why Birthe got involved with open source (22:38)
• Marketing challenges and strategies specific to an open-source product (24:47)
• The surprising difficulty of creating a glossary of company terminology (29:11)
• Birthe’s advice for founders of open-source companies (31:02)
• Where listeners can connect with Birthe and learn more about OpenProject (32:05)

Links:

Birthe

• LinkedIn: https://www.linkedin.com/in/birthe-lindenthal/
• Company: https://www.openproject.org/

Didier and I chat about his background, what led him to start OpenBB in his spare time, and his vision for the company's future. He shares the story of teaming up with his co-founder, why he loves working in the open source ecosystem, and how his team continues contributing to OpenBB's success. 

Highlights:

• Didier introduces himself and recounts his background and what led him to start OpenBB (1:20)
• Why Didier didn't know OpenBB would become a business when he started the project (6:47)
• Didier affirms my thought that part of what makes OpneBB's origin interesting is that the idea was unrelated to his day job. (10:13)
• Didier tells the story of how his co-founder, James, came on board once the project went viral (16:36)
• How OpenBB has changed since the project began (19:16)
• How open source has shaped the development of OpenBB (21:35)
• Didier outlines the current monetization plans for OpenBB (24:44)
• Didier's vision for the future of OpenBB and the democratization of investment research (26:30)
• What Didier learned from his most interesting mistake - believing users know what they want. (29:45)
• Didier emphasizes the importance of building a cohesive team with shared values (32:58)

Links:

Didier

• LinkedIn: https://www.linkedin.com/in/didier-lopes/
• Twitter: @didier_lopes
• Company: http://openbb.co
• Personal Site: https://didierlopes.com

Highlights:

• Intro (00:00)
• I introduce Loris Degioanni who is the CEO and Founder of Sysdig, and he provides a little bit of context about himself and his company (01:00)
• Loris gives an overview of his previous company, Wireshark (01:57)
• Ways in which Loris was able to commercialize Wireshark as a tool for open-source end-users (04:30)
• How Loris used open-source as a marketing tool to create a profitable business model (07:28)
• The difference between Sysdig and Wireshark in their relationship to open-source (08:57)
• The bet that Sysdig is making and how that positions the company to become a leader in cloud security (12:36)
• Loris and I discuss Wireshark’s continued longevity (15:14)
• Where the inspiration for Sysdig came from and its journey from open-source project to commercial product (19:41)
• How building something useful replaces the need for a sales and marketing team (24:22)
• Closing the gap between the Sysdig project and the Sysdig platform (27:52)
• The framework for deciding what is offered open-source and what needs to be paid for (30:21)
• Loris’s most interesting mistakes in entrepreneurship and building Sysdig (33:20)
• How listeners can connect with Loris and learn more about Falco and Sysdig (36:31)

Links:

Loris

• LinkedIn: https://www.linkedin.com/in/degio/
• Twitter: https://twitter.com/lorisdegio
• Company: https://sysdig.com/

Highlights:

• Intro (00:00)
• I introduce Bob van Luijt who is the CEO and Founder of Weaviate, and he provides a little bit of context about himself and his company (01:00)
• Bob gives us the run-down on Weaviate’s operations, including fundraising, staffing, and monetization data (02:04)
• How the Weaviate project became the company it is today (04:03)
• The value that open-source brings to Weaviate’s business model (11:21)
• Bob and I discuss the disadvantages to building a company around an open-source project (17:55)
• The complexities of having an open-source project that is used within other companies and products/projects (20:19)
• How Bob and Weaviate have approached monetization (22:18)
• The most interesting mistakes Bob feels he’s made along the way in his journey to build Weaviate (24:37)
• Bob tells us more about his decision to shift from professional services to a product-led approach (25:50)
• Bob and I discuss the complex catch-22 of focusing on either profitability or growth as an open-source founder (28:39)
• How Bob filtered through product feedback and feature requests when first shifting to a product-led approach (32:19)
• Bob’s advice to people who want to be a part of the open-source ecosystem (37:54)
• How listeners can connect with Bob and learn more about Weaviate (39:13)

Links:

Bob

• LinkedIn: https://www.linkedin.com/in/bobvanluijt/
• Twitter: https://twitter.com/bobvanluijt
• Company: https://weaviate.io/

Highlights:

• Intro (00:00)
• I introduce Ben Rometsch, who is the CEO of Flagsmith, a commercial open-source feature flagging and remote conflict platform (01:00)
• What made Ben want to build an open-source feature flagging project (01:29)
• How the open-source project Ben started led to building a company around Flagsmith (03:39)
• Why Ben feels licenses are so important and how he learned that through early licensing choices at Flagsmith (09:10)
• When Ben started to monetize Flagsmith (13:24)
• How Ben’s understanding of what features users wanted to pay for has evolved (15:36)
• Why caring about the developer experience has set Flagsmith apart for enterprise customers (20:51)
• When revenue started to take off and why it took external expertise (23:12)
• Why pricing can be such a frustrating challenge to get right (26:47)
• How Flagsmith is currently remotely structured (28:57)
• Ben shares his thoughts on how open source contributes to his business (33:04)
• How listeners can connect with Ben and learn more about Flagsmith (38:05)

Links:

Ben

• LinkedIn: https://www.linkedin.com/in/benrometsch/
• Twitter: https://twitter.com/ben_rometsch
• Company: https://www.flagsmith.com/

Highlights:

• Intro (00:00)
• I introduce Max, the CEO of tea.xyz, and he explains his career background and how he started Tea (01:00)
• Max and I discuss the shift that open source needs to make from relying on charity to speaking in business and value terms (09:39)
• Max describes how Tea is representing the existing value of open source and translating it into monetary form (12:32)
• The administrative challenges of paying for open-source tools that are business-critical and how Tea helps solve them (14:36)
• Tea’s business strategy for monetizing their own open-source project (18:05)
• How Max’s goal of being able to work on the open-source projects he loves full time has played out with Tea (24:06)
• Max describes how he successfully pitched Tea to investors (25:21)
• Tea’s relationship with the rest of the crypto industry (27:32)
• The biggest challenge Max and his team are working on at the moment (29:06)
• What Max wishes he would have done differently and what he’s learned from the mistakes he’s made (31:59)
• Where you can go to learn more about Tea and connect with Max (38:53)

Links:

Max

• LinkedIn: https://www.linkedin.com/in/mxcl/
• Twitter: https://twitter.com/mxcl
• Company: https://tea.xyz/