How To Become The Next GitLab

31 “Simple” Steps to Build A COSS Company

“Software might be eating up the world, but open source is eating up software faster!”

GitLab is now a commercial open source software (COSS) giant. The DevOps tooling company has a market cap of roughly 7 billion USD and 400 million in revenue. And still, finding the business model GitLab runs today started off with ice cream.

“”Dmitriy used to talk about ice cream money, which were donations,” Sid recalls. “They were seven bucks a month, so he and his wife could buy ice cream once a month from the donations. We tried that […] wasn’t sustainable to run a company with multiple employees.”” (GitLab on Monetising and being Open Source)

It’s not 2015 anymore. Today, we have a plethora of profitable COSS companies that can show us how its done. I dug through 100+ case studies in the last couple of years. No matter how long these companies searched for a business model, in the end most seemed to land on a very similar path.

There is a standard model for going from 0 to your first $$$$ with a COSS company. It is a very simple idea: Use the open source project as a marketing and sales engine to sell a service that falls into four different categories on top of it.

There are many other good business models, but this article isn’t about them. It’s about this one model. I distilled the lessons from the COSS companies like databricks, Red Hat, hashicorp, confluent, GitLab and many more into this blueprint. Here it is.

Part 0: Commercial Open Source Software Essentials

• Your business is COSS if you have open source projects at your heart
• Open Source is open, free and dominated by network effects
• Now is a good time to consider open source
• Open Source will continue to grow
• A new mindset
• Test, grow, turn into marketing & sales engine

Part 1: Test the markets

• Prepare to build for growth

Part 2: Make your (free!) open source project really successful

• You do NOT need contributors
• You do need innovation & users
• Preparing for paid services

Part 3: Choose a business model, and don’t kill the OS

• Choose any license for your COSS
• Evaluate the “support” COSS model
• Evaluate the “hosting” COSS model
• Evaluate the “open core” COSS model
• Evaluate the “marketplace” COSS model
• Evaluate the “platform” COSS model
• Don’t fall of the edge

Part 0: Commercial Open Source Software Essentials

Before you’re going off to start your COSS company, I want you to be aware of three things:

1. If you’re committed to doing it, now is a great time to get started with open source.
2. But you should have a clear understanding of why COSS is so powerful.
3. You might need to switch your COSS mindset.

Even though I’m a huge fan of openness in general, there is a literal graveyard of COSS companies in front of you. So if you do decide to go down this route, I applaud you, and need to tell you: it’s going to be really hard, much harder than founding a non-COSS company.

But, that’s what this is about. So get your essentials right, starting with why open source is in theory a great idea.

Your business is COSS if you have open source projects at your heart

There are a bunch of definitions of “COSS”, but I like this one:

“Your business is a COSS business, if you publish & maintain open source, and you derive the majority of your profits directly or indirectly from them.”

That makes databricks a COSS company. The founders of databricks created the open-source framework Sparks, and databricks is still churning out open-source projects like Delta lake. Their profit is in direct relation to Sparks and Delta lake. You might view databricks as a huge enhanced and wrapped version of Sparks + Delta lake.

Red Hat is a COSS company, even though the founding team didn’t write Linux. Still most of Red Hats profit have a direct relation to Linux.

Open Source is open, free and dominated by network effects

The three key characteristics dominating everything inside the open-source space is that any piece of open-source software is:

1. Open — allowing people to look and contribute to the interiors
2. Free — offering some form of free usage
3. Network effect dominated — the biggest open source project will attract the most contributors, attracting the most users, making it the “only one”

It’s crucial to understand that these are three separate properties. It means you can learn a lot from freemium business models when it comes to the “free” side of things. It means you can learn a lot from open business models, models that invite contributions without being open-source.

It means GitHub is an excellent case study for COSS. GitHub has a freemium business model, invites a ton of contribution and operates in a true network effect dominated market. You have a GitHub repository because that’s where all the others are, that’s networking at its core.

Now is a good time to consider open source

Hashicorp, Confluent, Red Hat and Databricks lead the wave of successful COSS companies. As Joseph Jacks points out,

“Open source & COSS companies are eating up the world faster than software.”

It’s not 2015 anymore, while it still is hard to build up a COSS company, we have a ton of experience and successful case studies by now.

Now is a great time to get started. The commercial open-source markets are exploding and expanding into every area of tech.

Open Source will continue to grow

This explosion of open source is not temporary, it will keep on growing exponentially. As Peter Levin from a16z points out, a flywheel was set off.

“Open” is the best way to drive innovation in a fast-moving world, and infusing open source with business is the best way to fund these innovations; In turn, speeding up openness and innovation.

A new mindset

However a lot of people still hold the mindset of

“I have to sacrifice parts of my open source projects to make money.”.

That’s not true anymore. If that’s you, you need to update your mindset to

“Openness and profitability aren’t a opposites, in fact, I can create a flywheel turning openness into profitability using COSS. Turning open source projects into businesses might be the best way to advance a specific open source initiative.”

Test, grow, turn into marketing & sales engine

The COSS blueprint has three steps:

1. Test the markets (fast changes, easy to do with opensource, developer-focused)
2. Growth (based on users & contributions)
3. OS project turns into a marketing & sales driver for the business

Sounds like your typical product? It does. But in fact, Open source projects are very unique. Due to their open code nature, they offer a very different set of prototyping options allowing you to move much faster.

Their growth phase is happening before product-market-fit, and is heavily reliant on devs and contributions (not contributors!).

And finally, you will need to strike a delicate balance between free and paid services once you enter step 3.

Let’s get into them!

Part 1: Test the markets

Vlad Ilyushchenko is the creator of QuestDB. His open source time-series database has over 10,000 GitHub stars. It’s been quite the success, but Vlad approached “testing the markets” with a developer mindset, not a product mindset.

“With some money aside, I left my job and started to work on QuestDB solo. I used Java and a small C layer to interact directly with the OS API without passing through a selector API.”

“A year in, I realised that my initial design was actually flawed and that it had to be thrown away.” (My journey making QuestDB)

Well, turns out, others do this within hours or days. The most effective way of making sure you’re on the side of hours and days to find test markets is to ensure you have a good set of prototypes ready, before you even create your project.

But even if you already have a project ready, you still need to test its economic feasibility and thus should use prototypes. Here are my favourite five, specifically for open source projects:

1. Use forums, twitter, reddit, social channels to validate your idea even before having anything out there.
2. If you have to, build a functional prototype displaying nothing but the 1–2 key features.
3. Write blog posts, just a README or do a video about your project idea/mock up.
4. Do a talk about it.
5. Write a deeper white paper explaining more complex topics you’re going to tackle.

All of these will get you good feedback within hours or days. Use it.

Prepare to build for growth

Once you start building you bare bones open source project, make sure to build it to grow.

To grow fast you’ll need to nail the basics before even starting to code. Start with the README first.

Keep in mind, that your project will be shared within a dev community first, so design it for easy sharing.

Add pictures, a great description, add animated GIFs of your software (even if it is a mock up at first). Make your contribution guidelines clear, set yourself up to be recommended throughout GitHub, Reddit and other sources.

Have a link to an online demo ready (register the domain, take a look at other projects and how they do their demo).

Once you got a great draft ready, you can start the actual building.

Part 2: Make your (free!) opensource project really successful

The idea of the blueprint is very simple. You’re not going to do anything else than working on free stuff, until you hit your growth goals.

The growth goals will depend on your project, but once you hit them, you will pivot at least 50% of your efforts towards paid efforts. So don’t pivot to early to the next step.

If you pivot too early, your OS project will die. First slowly, then quickly. Your main marketing & sales channel will be gone.

Let’s talk about what you really need, and what you do not need.

You do NOT need contributors

A common mistake people make, is to think they do open source to attract contributors.

But that’s not true. The main characteristic of “openness” doesn’t aim at bringing in lots of contributors, lots of people with ideas. It just aims at bringing in ideas.

None of the big successful open-source projects thrive on a large number of contributors, quite the contrary. But what the openness does it to quickly let you test & dive into additional user segments.

You do need innovation & users

Having contributions is about having more ideas, about quickly going from your market tests to actual product-market-fit.

The blueprint COSS company does this by making contributions super easy.

That doesn’t just mean providing a “contributions guideline”. It means you have:

1. Great documentation around contributions
2. Possibly even tutorials for contributions
3. Don’t just let people modify your core, but have an actual mechanism for extensions (think plugins, themes,…).
4. You have great dev setup, think devcontainers, make files,…
5. You respond within hours to any PR, issue,…

Contributions in breadth will enable you to quickly find product-market-fit.

Then start selling your open source project heavily to the user base.

Yes, you will need to “sell” something free. After all, setting things up, reading things does cost time — the most precious resource on earth. So go sell your open source project to users.

Preparing for paid services

So when is a good point to pivot to paid?

First of all, keep in mind, once you work on paid you will truly pivot. You might trick yourself into saying “If I do X, it will go into the open core and then it will benefit the users as well, so I’m really working on free 50% of the time”.

But that’s just foolish. Whatever you do for your paid service will be almost always not important at all to the free side of things.

Unless you have a dedicated PM for your open source project that does just that, open & free stuff, you’re not dedicating any resources to open anymore.

You pivot if:

1. You feel confident your OS project will continue to grow organically (more than linearly!) without you doing anything for the next year(!)
2. Your project has linear (or better) growth in contributions (not contributors!) and users.
3. You have product market fit. (that means also, a big free user base!)

You will recognise the point, it will feel/ look like the image below. Just replace the Y axis with users/ adoption:

Now let’s make some money!

Part 3: Choose a business model, and don’t kill the OS

Now it is time to choose a business model. Prepare to switch later again.

You’re selling either:

1. Value-adding services (Support)

2. Hosting

3. Added features (“Open Core”)

4. Connecting users & customisations (“Marketplace Model”)

5. Products built on top of a “platform”

And then keep on watching your back!

As Peter Levin describes, you want to watch out for three failure modes that look like this:

The easiest way of doing this is to include your OS offering as a “free tier”, maybe even have a hosted as well as self-hosted version. Then have customer profiles that might use these tiers and include them into your usual product workflow. Check out how GitLab does this masterfully.

So keep watching those, choose a license and go all in with your business model.

Choose any license for your COSS

Licenses are NOT business models, prioritise business model search over licenses. Licenses are supporting business, not define it. You can change them or have multiple ones. Don’t sweat on licenses.

Take a few hours to pick one, then move on. Be prepared to change it later on.

Evaluate the “support” COSS model

Choose this model if you want to sell value-added services like consulting & on-demand customizations. It’s the model Gruntwork (as they started out) and Red Hat pursue.

On the “support” COSS business model, watch out how you set your own incentives, for what you charge for. Don’t charge for something that will slow down the adoption of the open source project. Try to align your paid & open source work.

Gruntwork launched with support, priority on feat. reqs and code reviews for paying customers. They align by contributing the features to the OS.

But as pointed out above, that doesn’t mean they are working 50% on the open-source side of things, it means they are working mostly on the paid side.

Pros of the “support” COSS business model: You’re the knowledge expert, you will always be the one source of knowledge.

Cons: No one besides Red Hat has successfully pulled out this as a standalone, but many have started here like GitLab and gruntwork.

Evaluate the “hosting” COSS model

Choose this model if you want to sell hosting for an open-source project.

Fun fact: The open-source project doesn’t have to be yours! There are plenty out there that you might be able to host:

1. cheaply
2. as a special fork/copy with added benefits
3. in a combination with other tools to make a nice package

It’s the second default model, companies like airbyte, automattic, acryl data, and many others deploy this.

If you use the “hosting” COSS business model, don’t forget to make the setup for the self-hosted open source users easy as well. There’s nothing like the famous 5 minute installation of WordPress, back in the day.

Pros of the “hosting” COSS business model: Clear separation of open source and non open source.

Cons: Hosting alone will force you into commoditisation, making you a sitting duck for incumbents and competitors alike. You won’t get around paring with complemental business model.

This model comes with a bunch of possible variations that will help you deal with perverse incentives you set up for yourself.

Evaluate the “open core” COSS model

If you choose the “open core” COSS business model, you open source a large part of your main product you’re also looking to get paid for. You get paid by closing off additional features of particular value to your (paid) target market. Examples include GitLab or SugarCRM.

On the “open core” COSS business model you choose a variety of features to close off, including early access to features, whole components of your offering or anything buyers are willing to pay for.

The key is to nail good pricing. Because pricing also includes the decision what you include in the open core and what not.

The simplest strategy to do this is to use GitLabs approach called “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.

According to Sid Sijbrandij this is the tool you need to use to avoid “commoditization”.

Evaluate the “marketplace” COSS model

On the “marketplace” COSS model, you build software that allows people to customize something else, and charge for transactions between “customizers” and users. Examples are theme marketplaces, “partner marketplaces” or “plugin marketplaces”.

Pros of the “marketplace” COSS model: marketplace models offer an orthogonal business model.

Cons: marketplaces need size and growth to work, which is hard to come by. Therefore, this is should not be the default choice for your COSS.

Evaluate the “platform” COSS model

On the “platform” COSS model, you turn your open source into a framework, making it widely available and super-extensible. You then profit by having a standard you can build things on top of. Examples are hashicorp (partially built on top of terraform and many others), automattic (wordpress) or canonical (Ubuntu).

Pros of the “platform” COSS model: Having a standard will mean having a huge customer base.

Cons: Building a standard is super-hard. Therefore this shouldn’t be the default nor the second choice for your COSS: But you can still plan for it!

Don’t fall of the edge

Once your COSS turns the first $$$, keep a close eye on the growth charts of all your offerings, including free, and prepare to switch your business model as you evolve, to realign with your open source project and maximize your company growth.

Once you’re here, congratulations. It’s time to prepare for level 2.

See you there!

Interested in how to build great data companies, great data-heavy products, becoming a great data team, or how to build anything great with open source? Then consider joining my free newsletter “Three Data Point Thursday”. It’s become a trusted resource for data start-ups, VCs, and data leaders.