Good (& Bad) Markets for Open Source Based Businesses
What next.js, Spark, and dbt teach us about picking great markets for open source based businesses and when open source is a bad choice.
There are certain markets and problem domains that work well for open source and others that do not. This post will explore some patterns I see from markets and founders for good open source businesses.
If you like this content, please share it with a friend!
Side note: In a previous post, I talked about picking markets for open source, this post will elaborate a bit by discussing good ones and bad ones.
What markets make for good open source businesses?
Open source has historically worked well in a couple of domains:
Developer Tooling - Examples: Terraform & HashiCorp, MongoDB
Developer Infrastructure - Examples: Redis, Kafka & Confluent
Data, Analytics, & Scientific Computing - Examples: Spark & Databricks, Clickhouse
Application Code (with boiler plate) - Examples: Next.js & Vercel, dbt & dbt
While these are just a small sample, venture firms characterize it in the same way. Here is Bessemer Venture Partner’s perspective on Open Source Company categories.
Reasons and examples of good open source based businesses
So what are the reasons these spaces work well for open source businesses? Here are three key principles as to why the above categories make sense:
(1) Technical founders can “build for themselves”, solving their own problems.
CockroachDB makes for a great example. The founders worked at Google on Spanner and sought to rebuild some of the infrastructure for work at Square. They had a problem to solve.
They built the CockroachDB infrastructure as an open source project rather than just starting a business right away. This allowed them to validate the market first, as mentioned in a 2014 wired article.
Kimball says that eventually, if the database is going to catch-on beyond a handful of large companies with the internal resources to manage it, some sort of commercial company will need to provide support for the software.
Takeaway: If you can, get an education (about the market or the problem) on someone else’s dime. It’s not the only way but it can avoid some pain. Validate your problems with the broader market before taking the leap yourself.
(2) Data processing and infrastructure is critical for businesses but complicated and specialized.
Extracting value out of mass amounts of data is the core of many businesses - building a distributed data processing framework to do so is not.
Spark and Databricks are a perfect example of massive business trends (e.g., data science & analytics) requiring massive infrastructure to be successful. The challenge is often that that infrastructure is difficult to build and maintain and not the core of most businesses. The job to be done for businesses is not to build data infrastructure but to extract value from data.
Spark and Databricks provided that solution (in addition to riding those massive business trends) and did so in a way that less sophisticated users could succeed.
Takeaway: Founders should look for rapidly growing markets along large business shifts and figure out how to democratize special skillsets or infrastructure.
(3) Productivity is low on work that has to be repeated often but is complicated and error prone (e.g., boilerplate).
Next.js was created to solve many “boilerplate code” issues with building JavaScript applications. In 2016, shortly after the 1.0 release, next.js laid out the principles for the project. The creators described a different way of JavaScript development - putting the developer first and solving for things that come up in every single project.
Side node: The post is a great example of a manifesto as I wrote about in Picking Markets and Creating Movements. Give it a read!
Next.js is based on six basic principles: zero setup and using the file system as an API; only using JavaScript, with everything acting as a function; automatic server-rendering and code-splitting; data-fetching is up to the developer; anticipation is the key to performance; and simple deployment.
“Next.js provides an abstraction layer to aid in common tasks” (source) and is a recommended toolchain when creating a new react app. By automating common tasks, next.js makes developers more productive and in turn, a potentially scalable business.
Takeaway: Focusing on tedious, error prone, and boilerplate code is a great way to solve real problems for people. It can be a bit more difficult to build a business around but Vercel seems to have done a great job.
Combining Problems: low productivity, boilerplate code, data processing and developer infrastructure.
dbt is an example of several problems coming to a confluence:
SQL is powerful, but it’s easy to write error prone code. This leads to low productivity for users.
SQL can have a lot of boilerplate code making it difficult to maintain as the business evolves.
SQL involves doing data processing, something data practitioners need to do for the business, but is slowed by the above problems.
When you have something that combines these different issues, you’ve probably got a great project (and potential business).
Takeaway: dbt provides an example of a company that (a) was built originally for the founders themselves, (b) operates in a space that is critical for business and needs democratization and (c) solves for boilerplate code challenges. dbt adoption has skyrocketed because of this and has potential to become an iconic company.
When is Open Source the wrong choice for a business?
Open source software is constantly evolving and it is difficult to predict where it will and won’t work going forward. The following points are a snapshot in time. I’m not going to provide examples here as I don’t want to bad-mouth any specific projects because building open source companies is hard and I admire people’s desire to take on the challenge.
There are some warning signs that founders or project creators will want to look out for when building a project or business:
Lack of market need or small market (that isn’t growing): This should be obvious but that doesn’t it make it less important. Make sure there is a market need. Open source can be a good way of testing the market. It may be that there is a latent need in a marketplace - providing you as a founder with a great opportunity.
Little developer interface or interaction: As a rule of thumb, if you aren’t saving developer time then you might not be on the right track for an open source software business (Aside from CrossFit of course). Take this with a grain of salt, we may see “open source” manifest itself in different ways.
No repeatability: If the work you are trying to facilitate or do with your open source project isn’t done often (or isn’t expected to be done often), it probably won’t solve that much pain. Ideally, you have something that people are going to do or repeat every day.
No platform future: Not approaching things from a platform perspective is going to be challenging. You must have the ability to expand over time and facilitate more developer (or end user) usage.
A level of indirection: One thing to keep in mind, is that open source can cause a LOT of complications to building a business. You’re making your problem of building a business into a 2 step process - get people excited about open source then monetize it. This is under appreciated and something that I see from founders quite often. You may think you “get a community for free”, but it’s just not the reality. Building off open source is a risky trade-off, not a solution.
These are guidelines but good rules of thumb to think about before starting off on your open source project (and business).
Market: ✅ Problem Statement: ✅ - what’s next?
So you’ve chosen a market and done some research and specified your problem statement. You’re prepared to tell the story, to paint a vision, and to inspire others to follow.
The next step is actually building your solution and sharing it with the world. In a later post, we will dive deeply into community building and iterating on your solution in the open source domain.