The Business of Open Source

It comes up over and over again... when is the right time to start a company and commercial offering based on an open source project? 1️⃣ After the project has gotten tons of traction 2️⃣ At the same time as your project 3️⃣ Commercial product first, then release open source project I find entrepreneurs are often really opinionated about this, though I like the answer Vinoth Chandar, CEO and founder of Onehouse gave in the most recent episode of The Business of Open Source: You start the company when you can, and sometimes there are external reasons for waiting (like immigration status). I also liked that he entertained the possibility that he was too late in starting Onehouse, but also that maybe Onehouse also came too early. Regardless, if the company had started earlier or later, the platform Vinoth and his team ended up building probably would have looked completely different. Also, my take aligns with Vinoth's: There's no right answer to the question of 'when should you start the company / when should you start the commercial product.' There are pros and cons either way. Check out the full episode here: https://lnkd.in/dS7A9vRA

If you've been watching open source companies switching to BSL licenses and wonder about the backstory, you should check out my most recent episode of The Business of Open Source with Tyler Jewell, the CEO of Lightbend, Inc.. Tyler talked about some real problems that open source companies can face: a delta in value between commercial product and OSS that isn't big enough, and that's falling; a project that's mature and just works, so there's not much more people want; an engaged community that creates the features in the commercial product themselves. He talked about a company with $13million in ARR and $20+million in annual costs. And a project that was extraordinarily respected and relied on. As we talk about in the podcast, I also feel disappointed when an open source company changes their license to BSL or something else. For me, it's disappointment that they couldn't make it work, because I see the point of my own work as helping open source founders figure out a way to both keep their OSI-approved license and build a profitable business. But I don't think for even a second that there's a betrayal. If we expect all founders who build companies around an open source project to know ahead of time for sure that they have a winning business strategy that will allow them to be profitable and keep their OSI-proved license, no one would start OSS companies. There are no certainties in building a business, and anyone who claims to know at the beginning of the journey exactly how it's going to play out a decade later is full of 💩. Isn't it better to try and fail than to not try at all? That's what we tell ourselves as entrepreneurs, and it should go for OSS entrepreneurs as well -- better to try and fail with an open source project than to not try at all. Check out the podcast here: https://lnkd.in/emxRw7wn

In what situations is having an open source component of your business simply table stakes? And if being an open source company is essentially a constraint given your industry, how do you nonetheless both mitigate the risks that come with that and actually use the open source project to drive business results? This week on The Business of Open Source I spoke with André Eriksson about how Encore manages the risks and benefits of building an open source company, especially in a situation where a robust open source project doesn't feel optional. We talked about: -- Making sure the open source project is valuable and not crippleware while still making sure there's enough of a difference in value between project and product that people are willing to pay for -- Understanding what risks the open source project creates, and the difference between objective risks and perceived risks -- The challenge getting code contributions to the project, and why that's not a surprise Check out the full episode here: https://lnkd.in/eGfGSmTr

Thanks for having me on The Business of Open Source Emily! Healthcare needs systems that are composable and extensible - and that's why open source will have high impact in this domain.

This week on The Business of Open Source I spoke with Saurav Pathak, CPO at Bagisto , about building an open source company as an internal startup inside a larger parent company. This is definitely not the traditional open source company, which is part of what made the conversation so interesting! But there were plenty of things that Saurav talked about that are relevant for any open source business: -- Balancing the end-user audience (merchants) and the developer audience. This is a super interesting issue for any open source company with an end user audience that isn't just developers — people use the software to solve a business problem, but developers interact with it and often extend it. -- The importance of building community and using community as a growth driver -- Avoiding feature bloat in an open source project, even when that means rejecting community PRs -- How the tech stack can be an important differentiator for open source projects — unlike a black-box software, people care what language the software is in because they want to extend and adapt it. Check out the full episode here: https://lnkd.in/eeRvRr-m

Do you know what the difference is between software and a product? This week on The Business of Open Source, I talked with Adam Jacob, co-founder of System Initiative as well as Progress Chef. We talked about the difference between your code and your product — and why that difference is especially critical for open source companies. Check out the full episode here: https://lnkd.in/eehui7e3 We also covered: -- Why the TAM for an open source software is $0, and understanding that is important as you think about building a business around open source -- Why open source companies should embrace companies that repackage and sell the code they produce — and can do so profitably if they understand and communicate effectively the value customers get from buying directly from the code authors -- How looking back some things that you think are going to be massively important decisions end up being not very important.