Thoughtful Friday #17: Open Source Business Strategies & Types of Open Source

I’m Sven, and this is Thoughtful Friday. The email that helps you understand and shape the one thing that will power the future: data. I’m also writing a book about the data mesh part of that.

Let’s dive in! It’s a long read, but it’s worth it. And it has a huge graphic!

Time to Read: 8 minutes

• There are 13 good business goals to open source something

• I like to think of 5 categories of open source

• You have to get the match between the open source category and goal right to achieve it!

🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮🔮

“While open source work may have benevolent results, it is not an act of charity. Releasing work as open source and the corresponding contribution process eventually result in a higher return on the initial investment made versus the alternative closed source process. ” (Google)

Over the last 10 years, very different types of open source have developed, powered by a plethora of licenses. 

On the business side, I identified 13 business goals companies pursue by open-sourcing parts of their software. On the open source side, I like to work with five different kinds of open source.

The dilemma starts, when we bring these two things together because only some forms of open-source are great for achieving certain business goals, some are not great at it, and some make it almost impossible.

Types of Open Source

The categories of open source I like to think of are:

• Closed - Code not available, resulting product is not usable for free.

• Source available - resulting product is not usable for free (e.g. because it needs a paid license).

• Source available - commercial use is prohibited. I like to call this Non-commercial OS

• (Full) Open Source - source available, resulting product usable without restrictions.

• Open Source Clones, source is not available, but the resulting product is still usable for free. (I’m including this because it’s a powerful strategic tool)  

Of course, there are a lot of edge cases like MongoDB which can be used commercially only if the resulting product is also open-sourced. 

Business Goals for Open Sourcing

Open Sourcing parts of your software isn’t a strategy restricted to start-ups trying to get “free marketing” (hint: it isn’t free, it likely is more expensive than the alternative). Open Sourcing can be a powerful competitive play in competitive markets.

Example: Databricks open-sourced the table format “Delta Lake” at the moment of emergence of a market of table formats - with Hudi & Iceberg. I have no insights into databricks strategic reasoning, but the market of table formats is a serious threat to databricks business model because they will enable completely open and modular “databricks clones”. Open Sourcing Delta Lake thus might be a competitive play to win or at least slow down the table format markets’ convergence onto one format. 

Let’s look at my 13 reasons for open sourcing parts of your software:

0. Doing the right thing. Since I truly believe in doing the right thing, this reason has to be on the list.

1. Growing a category. By open sourcing a part of the software, a company stops others from reinventing the wheel. That means, that the whole category can progress at a much higher pace, literally giving it a speed boost of years.

2. Marketing and sales, it’s not free, far from it, but OS is a very different marketing & sales mechanism, one which operates primarily through developers, or broader awareness. Example: @hashicorp and the amount of awareness they get from @terraform.

3. Disintermediation, companies might want to decouple previously coupled parts of the standard tech stack. Kubernetes basically decouples container mgmt, deployment & operations. The results for @Google: People are quite happy to find Kubernetes natively supported on the Google Cloud.

4. Innovation, I don’t think Google could foresee the things that people used & contributed to TensorFlow, and yet again, @tensorflow seems to drive significant business for Google (just think about the hrs of computation now running on TPUs)

5. Talent acquisition - especially true for all-remote companies, but still valuable for collocated ones. Showing off great software development work, exciting projects, and the will to “do the right thing”. 

6. Testing Markets, for an incumbent company, putting out OS might be an excellent way of testing markets in multiple directions, before launching a heavily paid offering (and possibly killing the OS project).

7. Providing Extensibility to Customers, whether it’s an SDK, a slight wrapper around your APIs, or a more extensive plugin system, companies provide open-source as ways of letting customers extend parts of their (possibly non-free) software. 

8. Derisking customers, by creating a community around an #openSource component, a company can basically help customers hedge against future events. The OS community will likely be there, even if the company goes bankrupt. It might provide extensions the company doesn’t and the customer can always grab the code and do changes himself.

9. Creating a protocol, Think about https://github.com/protocolbuffers/protobuf essentially creating a possible protocol in an already existing market (that of serialization tech). That was only possible through #OpenSource as integrations in all kinds of programming languages had to be created.

10. Creating a lingua franca, before @mongodb/@couchbase and the rest, there were no “NoSQL” databases. Today, they basically created the language of “NoSQL” - a paradigm shift that was made far easier by providing things for free & open-source.

11. Building up a reputation for expertise. I would always consider @dbtlabs as the primary source for anything “analytics engineering” related, period. And that’s for the sole reason of their open-source project @dbt. They did so by creating a huge community around their #openSource project which now grows on its own.

12. Building up a platform, most software products have an easy time building a solid product satisfying 50-80% of a target market, but an extremely hard time getting the rest. By building up extensibility mechanisms through #openSource, products like @gitlab enable others to extend the product to cover 100% of the market.

13. Building up an ecosystem, if extensibility is done really well as @wordpress does, it turns into a whole ecosystem of consultants and companies creating forks, plugins, and themes around the product itself multiplying its target market far beyond the initial scope, through #openSource.

Note: Yes, I think you should only pick one primary business goal for each component you open-source, as they are conflicting and need very different strategies.

Bringing it together

Now not all types of open sources are equally well adapted for enabling these business goals. 

Take a look at this graphic while you read the explanation below.

Full Open Source is able to power all 13 goals, from growing categories to building out ecosystems. Great examples here are WordPress (powered by Automattic) and terraform (powered by HashiCorp), both growing huge categories and building out ecosystems at the same time.

But once we start to limit the commercial viability of an open-source project, we’re not going to be able to build out an ecosystem anymore. We will still be able to build out a platform, we will still be able to get lots of consultants, theme developers, plugins supporters, etc. But a true ecosystem lives from the commercial reusability of the project and without this multiplier, we won’t be able to create one. 

We also will have a hard time establishing a protocol, as protocols live from being integrated into commercial products. 

We going to make it a bit harder, but still doable, to grow a category, disintermediate some chain or build a platform.

And we’re going to be just fine with all other goals like marketing or testing out markets, or any of the others.

If we move to open source that makes the source available but not usable, we’re very limited in our goals. We’re still going to be able to test out markets, see how many people are interested in a certain product, or enable paying customers to add features only they need to the product. We also might get some innovation out of it, although not as much as with the other open source options.

Of course, being closed won’t enable us to achieve anything. However, there is one interesting alternative, which for instance the company RudderLabs uses. They make their “Control Plane Lite” available for free without the source code to restrict the feature scope of their open-source offering. Offering something for free but without a source is a great way of testing out markets & generating marketing & sales leads and complementing your open source strategy.

Choosing

The fundamental strategy is very simple, and yet by no way easy. A company can open up, to achieve any of the above-mentioned goals, and needs to close down, to capture value.

The right mix is up to the company to figure out. 

But, choose wisely, because on open-source, things tend to accumulate or die, so early actions do have a serious impact on later outcomes. 

What did you think of this edition?

-🐰🐰🐰🐰🐰 I love it, will forward!

-🐰🐰🐰  Average newsletter... 

-🐰 It is terrible  ( = I just made it to this link b.c. I was looking for the unsubscribe button)

Want to recommend this or have this post public?

This newsletter isn’t a secret society, it’s just in private mode… You may still recommend & forward it to others. Just send me their e-mail, ping me on Twitter/LinkedIn and I’ll add them to the list.

If you really want to share one post in the open, again, just poke me and I’ll likely publish it on medium as well so you can share it with the world.