In this last special episode of The Business of Open Source recorded at All Things Open, I spoke with Elias Voelker, VP North America for CheckMK. We talked a lot about product strategy; when CheckMK decided that they needed a clear strategy for deciding which feature goes in the open source project and which goes in the commercial version. Elias finished up the conversation by circling back on this issue: As an open source company, if you don't have a big enough difference between the value customers get from project and what they get from the commercial relationship... you won't survive. 

Since Elias works in sales, we also talked about sales for open source companies. He said one of the most important questions in the context of open source is “why now?” Since many customers have been using the open source project successfully for years, this question is really important for uncovering what’s changed and why they are ready to buy at the moment. 

We also talked about some cultural differences between selling in North America and selling in Germany, since while Elias is German (as is CheckMK), he leads sales in North America and therefore has some advice for European companies moving into the North American market. 

###

If you’re struggling to figure out your product strategy as an open source company, you might want to consider working with me. I help open source companies figure out how to differentiated themselves in the market, how to differentiate the product from the project and how to take advantage of the opportunities specific to being to a open source company. 

This week on The Business of Open Source, I have the first episode I recorded on-site at KubeCon Salt Lake City (and the only full-length episode), with Solomon Hykes, CEO and co-founder of Dagger, and co-founder of Docker.

One thing Solomon mentions briefly but that is very important is that there are limits to what can be learned from Docker’s story, simply because the situation was so unique. Docker experienced explosive growth, at least some of which was due to having the right technology at the right time. This kind of explosive growth is very rare, though, and it brought it’s own set of challenges. The point being that while most companies will struggle to get enough adoption, Docker struggled to monetize effectively but got so many chances to try again just because it had a massive community. 

• The hypothesis — or actually, lack thereof — behind creating the original Docker open source project. 
• How having a massive community does help — but also doesn’t guarantee you’ll be able to build a financially sustainable 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! 

In this special episode of The Business of Open Source, I spoke with Nithya Ruff, director of Amazon’s Open Source Program Office (often referred to as an OSPO). We started out talking a little about what exactly an OSPO is and what they do in companies — something I’m guess not everyone understands. 

It boils down to managing the company’s open source strategy — something that is relevant to pretty much any company that writes software of any kind. There are a lot of components to an open source strategy, and there are different ‘models’ for an open source strategy, depending not just on the company’s size, but also whether or not open source is core to what the company sells. Nithya previously led the OSPO at Comcast, and talked a bit about the difference between running an OSPO for the a company like Comcast and a place like AWS, because their products are different. 

And why do open source strategies matter for startups? Even if you’re not an open source company, if you can’t prove you’re in compliance with open source licenses for projects you depend on, or if there are security concerns related to your open source use, it can sabotage acquisitions. 

By the way, helping startups figure out their open source strategy is what I do as a consultant. If you’re figuring out how to balance your open source project and your product strategy, and how to manage the risks and opportunities associated with open source projects, you might want to work with me.  

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

The biggest 🤯 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. 

This week’s full-length episode is with Bhaskar, founder of YottaDB. This episode was recorded on-site at All Things Open last week, and we covered a wide range of topics. Including:

• How the open source ecosystem, and the open source business ecosystem, has changed over the past 30+ years.
• Who can responsibly self-support an open source database, and who really needs to have someone to call if things go wrong. 
• The spectrum of professionalism among open source developers 
• How YottaDB started out as a project developed inside a larger company that was in financial services; and Bhaskar decided to spin it out as it’s own company.
• The challenge articulating the value of support contracts, especially for software that is reliable. Bhaskar says he is selling peace of mind more than anything else; and he works with customers to avoid incidents — because ultimately avoiding an incident is a better outcome for everyone than a quick recovery from an incident. 
• How to convince people that they are actually not as good at managing open source databases as they think they are. 
• We also talked about conference strategies: according to Bhaskar, the way he’s decided which conferences to exhibit at is a series of trial and error — and by the way, this is something I’ve heard from many people. Yes, you have to think about where your customers are, not where your friends are, but sometimes you don’t know ahead of time which conferences are going to have the best ROI. 

I’m working with YottaDB right now on how to differentiate themselves in the crowded database market — and we talk about that process a bit right now. If you’re having trouble standing out in a crowded market, you might want to work with me. 

This special episode of The Business of Open Source with Tatiana Krupenya, CEO of DBeaver, was recorded on site at All Things Open 2024. 

It’s a short conversation, so we addressed one main question: What is the difference between running an open source company versus as proprietary software company? Tatiana says the difference is big — and it’s complicated. 

The bottom line: Your OSS can be your main competitor, and your customers have to really see the value in your commercial offering if you want to make sales.

##

If you aren't sure how to talk to your potential customers are about why they should use your commercial offering, you might want to work with me. 

This week on The Business of Open Source, I spoke with Stefano Maffulli, Executive Director of the Open Source Initiative, about the definition of open source and… the definition of open source AI. We recorded this episode on-site at All Things Open, so there’s a little bit of background noise. 

We talked about why OSI felt like it needed to develop a definition of open source AI, how “open source” is enforced, and the thought process behind the definition that the OSI ultimately published. 

We talked about open data quite a bit — different kinds of data, what kind of information and data is important to researchers and professionals in the AI space, and if there’s a way to include AI models that are trained on proprietary data in the definition of open source AI. 

If you are interested in open source AI, definitely check out this behind-the-scenes discussion of how, and why, this definition was published — and what the future likely holds for defining open source AI. 

This week on The Business of Open Source, I spoke with Anais Concepcion and Paul Fitzpatrick , the co-CEO of Grist Labs and CTO of Grist Labs. We talked about managing growth of users versus growth of revenue, moving to an open source approach for technical, not technical, reasons, and open-source related product management questions for open source companies. 

Some really interesting themes we talked about:

• Moving from a SaaS first approach to also focusing on enterprise sales. Why they did that, what other sales channels that opened and what questions it also forced the company to 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. 

This week on The Business of Open Source, I spoke with Eric Holscher, co-founder of Read the Docs. We had a really far-ranging conversation that included talking about why documentation is often so bad, why documentation should be a priority, but also Eric’s experience building Read the Docs and Write the Docs. This episode was interesting because it’s both about building an open source company and also about the importance documentation for software projects in general and open source projects. 

Some things we covered included: 

• What is documentation? Is it a marketing effort, is it a part of the project itself? Eric talks about how good documentation for an open source project is a clear signal of a level of seriousness for the project. 
• How Read the Docs was really started to support open source projects, and that is part of why there’s no enterprise installs — either you use the open source code on your own, or you use the hosted product.
• How Eric sees building in the open as a way to help other people become better software engineers, but that ‘helping companies use Read the Docs for free’ is not the reason he wanted to build an open source company, and he’s still not sure how to feel about the fact that this happens. 
• You don’t get bonus points for being open source or bonus points for being bootstrapped — it won’t prevent a potential customer from using a competitive product because it has a feature that Read the Docs doesn’t have. 
• How open source in general — and even documentation in general — can help build brand value, but it is super hard to quantify and put in a slide in a board meeting to justify an investment in open source. 
• The decision to build Read the Docs as a business stemmed from the pressure that Eric got from having a successful open source project. 
• How they tried very hard to avoid accepting advertisements, but they should have started doing so much sooner because it turned out advertisements is well-aligned with the things they want to be working on. 
• The difference in risk between being open source for a database company versus an app-level open source project like Read the Docs; for Read the Docs one of the risks is the brand damage associated with people running the OSS on-prem and doing a bad job. 

Are you the founder of an open source company and struggling with figuring out how to manage the relationship between the project and product? You might want to work with me. 

Enjoy the show? Help it reach more people by leaving a review and sharing with your friends. 

Today on The Business of Open Source, I spoke with Chris Holmes, co-founder and CEO of Greymatter. Greymatter is deeply involved in the open source ecosystem and maintains the Go Envoy Control Plane, but Chris is adamant that it is not an open source company. We had a great discussion about why that is, what it means for the company and the conversations he ends up having around open source with his customers and partner companies. 

Some particularly interesting points that came up:

• Customers worry that buying Greymatter could force them to buy enterprise versions of open source software — and Chris thinks that this could be a symptom of the fact that many users expect that they’ll end up being forced to pay for something they don’t want to pay 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.