5 Ways to resist the threat of service-wrapping with buyer-based open core

GitLab makes money as a commercial open source software (COSS) business. As you might imagine, open source is at risk of becoming commoditized, just by its inherent characteristic of being completely … open. In today’s age of hyperclouds, open source businesses are under threat of service-wrapping via cloud providers like Amazon, Microsoft, and Google.

To avoid commoditization, GitLab has tried a number of business models, from donations to consultancy to single-tenant service, but none of them worked. Finally, we settled on open core. At this year’s Open Source Leadership Summit, our CEO Sid Sijbrandij talked about where GitLab has hedged its bet to avoid becoming obsolete. As Sid describes in the presentation below, there are five key methods for resisting commoditization with buyer-based open core.

Watch the presentation

Key takeaways

What is buyer-based open core?

Buyer-based means that GitLab offers four different tiers of the software, which offer different functionality based on what each buyer persona needs.

How do you generate revenue with buyer-based open core?

Each tier focuses on what the buyer wants – and nothing more. It is also priced accordingly. Those at a higher level in the organization often have more budget authority – so they can spend budget on what provides value for them.

How can COSSes avoid commoditization?

1. Insert proprietary functionality in a majority of your use cases.
2. Offer many proprietary features.
3. Offer interaction through a user interface, rather than through APIs.
4. Cater to price-insensitive buyers.
5. Attract users that rarely contribute to open source.

Learn more about these best practices and how GitLab has implemented them by watching Sid’s presentation, or viewing his slides below:

Cover image by Nastuh Abootalebi on Unsplash