Commercial Open Source Business Models: GitLab’s Bet on Buyer-based Open Core - Brendan O'Leary

Presented by: Brendan O'Leary, GitLab
Presented at All Things Open 2020 - Case Study/Demo Track
Abstract: In the age of commoditization, hyper-cloud service wrapping, and increased competition in the open-source world, many Commerical Open Source (COSS) companies are struggling to find a sustainable business model. Balancing support of open-source with the need to maintain the business that provides that support can cause companies to make rash decisions about licensing and their business models.
In this talk, we'll take a look at the commercial open-source landscape. We will learn from those who have been successful in building sustainable open-source communities and businesses. We will explore the various business models available to open source-based companies and where there have been successes and failures. We will use the case study of GitLab, a complete DevOps platform that is open core and based on git. The company has grown 177% year over year, even with the growing uncertainty in the space.
GitLab has made a bet on what we call buyer-based open core, and so far, it's paid off. However, this wasn't luck or some special sauce. It took many iterations on the GitLab business model to end up where we are today. Since founding the business in 2014, GitLab has tried many monetization techniques, including donations, consultancy, and single-tenet service. Still, none of them worked to allow us to sustain and grow the business.
Finally, we landed on buyer-based open-core. This talk will help you understand how we've modeled our business, and why we think that buyer-based open-core could be a winning combination for Commerical Open Source Companies.

[@setusaurabh1723]

Thank you for the this interesting exploration of how Gitlab navigated the maze of COSS business models.

[@NicolasGryman]

Excellent presentation! It gives me a lot of insight for my next project.

[@StevenAkinyemi]

Amazing talk!

[@Dieterbe]

TLDR: be a lot more proprietary (every feature only partially open) and build a product that's not attractive to aws to run (GUI driven, not natively multi tenant, and requiring little cloud resources)