Does Open Source Work as a Long-Term Business Model?

The viability of open source continues to be a hotly debated topic as businesses experiment with business model changes to operate effectively in the era of cloud architectures. In this post, I explore the fundamental question of how viable open source is as a long term business model. This post was sparked by the recent announcement around licensing changes by Cockroach Labs, which effectively amounts to them abandoning open source completely.

Analyzing the License Change from Cockroach Labs

The crux of the license change from Cockroach Labs is that they have now eliminated their Core offering, and require all organizations using their software that have revenue over $10m to pay for the proprietary CockroachDB Enterprise license. Let’s look at some historical context.

In July 2019, Cockroach Labs changed the license for CockroachDB Core from Apache 2.0 to the more restrictive Business Source License. They also gated access to many crucial features, (for example, read committed transaction isolation, multi-region capabilities, and data encryption) behind a commercial Enterprise license. They were following the trend of restricting core database access and features adopted by a swathe of former open source projects from MongoDB, Confluent (the company behind Apache Kafka), Elastic, Redis Labs, and others.

Around the same time, we decided to go all-in on open source by switching the YugabyteDB license model from open core to Apache 2.0. This change opened up the enterprise features in the database to all users.

Cockroach Labs has now gone a step further, by completely eliminating the free Core offering. As a founder of a distributed SQL database company (and a competitor), I can guess (and empathize with) the revenue pressure that led Cockroach to abandon their open source offering. But, I believe this is an example of short term thinking that can stifle long term growth.

Killing the Long-Term Growth Engine – Oracle, MySQL, All Over

Cockroach Labs’ new licensing model demands companies to “pay if you are successful as a business and grow over $10M in revenues.” And the smaller businesses (those making less than $10M in revenue) need to send back telemetry data mandatorily, presumably to identify users and extract revenue (the infamous Oracle audit checks anyone?)

I wonder how many developers and organizations will be inclined to adopt CockroachDB as a starter database given that they now need to think about the implications (costs, licensing, etc) of their business hitting $10M in revenue.

When a new application is being developed, businesses typically focus on making that application successful, rather than spending time on which database to use – the rationale from engineering organizations being that once it succeeds, it is totally worth a move or a rewrite. Today, the database of choice is PostgreSQL, and organizations eventually sign up to make this data layer “cloud native” when the application takes off.

However, if there were a database which provided an equivalent frictionless entry point to PostgreSQL while providing cloud native capabilities on day 1, they would opt for it. But, forcing them to think about implications to the business well down the road versus the PostgreSQL option adds too much friction, killing the growth engine.

When Oracle effectively acquired MySQL, the market worried about the long term viability of MySQL as an open source offering. This hurt MySQL and led to a slowdown in adoption for newer applications. As a result, MySQL has seen a marked decline against alternatives like (open source) PostgreSQL over the last decade.  Check out the DB-Engines ranking charts below (remember the Y-axis is logarithmic scale).

Already lacking the almost universal level of adoption enjoyed by MySQL and PostgreSQL, killing the growth engine on top will impact CockroachDB sooner and more painfully.

“Exit to Postgres” Database Strategy for Risk Mitigation

Why is full PostgreSQL compatibility so important?

Because, organizations that migrate to a new database want the assurance that they can easily migrate (back) to PostgreSQL as a risk mitigation option. CockroachDB is not really PostgreSQL compatible, which makes it incredibly difficult to move out and back to PostgreSQL.

We know, because we’ve tried. A YugabyteDB community user asked how to migrate from CockroachDB on the YugabyteDB Community Slack. You’d think that “wire-compatibility” with PostgreSQL makes it easy. It doesn’t. There is no similarity between how you export data out of PostgreSQL and out of CockroachDB.

We managed to figure out a solution thanks to PostgreSQL’s incredible feature set, but CockroachDB’s non-standard API didn’t make it easy. You can read all the details on moving data from CockroachDB to PostgreSQL or YugabyteDB in this blog post by Franck Pachot. You can now also use our database migration tool, YugabyteDB Voyager for this – the tool is fully open source under Apache 2.0 license, reaffirming our open source stance.

YugabyteDB is fully compatible with PostgreSQL and can interoperate with PostgreSQL. This means we can guarantee that an app written to YugabyteDB can move to PostgreSQL with no changes. On the other hand, not being able to move from CockroachDB to PostgreSQL (due to a lack of compatibility) means that you risk long-term vendor lock-in.

The MongoDB Playbook Doesn’t Apply When Competing With PostgreSQL

If you are a developer starting to build a new application, would you pick the most popular, widely-supported open source database (PostgreSQL), or a proprietary “similar, but not quite Postgres” database?

The sensible choice is clearly PostgreSQL.

Now, if you want to move your scaling application to a distributed database, why would you pick a proprietary database (CockroachDB is kind of, but not fully, compatible with PostgreSQL) that is not fully compatible with PostgreSQL (hence something developers aren’t quite familiar with), and one that will lock you in?

One could argue that this strategy follows MongoDB’s playbook, which was successful. But the “this is how Mongo did it” argument does not really hold water. MongoDB innovated by introducing a new data model (document) which they used to grow rapidly. They were also already established as the leaders in the document database space – developers looking for the ease of the document data model would end up picking MongoDB, there were no established alternatives. Hence, the “MongoDB growth playbook” doesn’t quite work here.

In this case, CockroachDB is a relational database which looks like PostgreSQL. This announcement from Cockroach Labs effectively sets CockroachDB up in competition with PostgreSQL rather than offering a complementary solution.

Evangelizing against PostgreSQL can only go so far – Postgres is fully open source with a far bigger (passionate) community of users and contributors.

Reaffirming YugabyteDB’s OSS Stance

Now is a good time for us to reaffirm our commitment to open source. Five years ago, we decided to make YugabyteDB 100% open source under the Apache 2.0 license, including previously closed-source enterprise features.

We chose to confirm our commitment to open source at a time when leading database and data infrastructure companies were abandoning open source licenses for some or all of their core projects

When we look at what’s happening in the industry today, the reasons we chose to go open source are still just as valid, and have in fact become stronger. Our adoption of open source is not purely an altruistic move to remain open “at all costs,” but is driven by good business reasons.

The availability of a free open source offering gives enterprise customers confidence to buy commercial software. Why? Because if the commercial relationship with the vendor sours for any reason, the customer has the open source offering to fall back on.

Having an open source option gives the customer strategic optionality. This risk mitigation is an important consideration when enterprises are considering databases from modern “emerging” database vendors like Yugabyte and Cockroach.

OSS Growth Engine – A User Community of 10K+ (And Millions of Deployments!)

The open source model is still one of the most successful approaches to developing and distributing business-critical infrastructure software.

Organizations can start for free with open source software without speaking to sales or hitting a demo request or contact us form. This makes exponential adoption growth a real possibility.

The proof is in the pudding. Over the past five years, we have built a user community of over 10,000 (the YugabyteDB Slack community alone is nearly 10K users), with millions of clusters deployed. This open source software complements our managed cloud database service, YugabyteDB Aeon, which lowers the barrier to entry for YugabyteDB adoption.

I understand that in the near term, open source usage may appear to cannibalize the commercial offerings of a vendor. But, it is necessary to give all users the opportunity to experience the power and effectiveness of YugabyteDB without restrictions. Ultimately, more usage fosters more commercial success, and vice versa.

One of the happy consequences of YugabyteDB’s open source adoption is that it enables the feedback loop necessary for high-velocity, collaborative, community-driven development.  YugabyteDB’s vibrant, fast-growing Slack community of 10,000 members are actively using the software, supporting each other, and providing feedback (and code!) As more developers and organizations use the software, security hardening, ecosystem integrations, extensibility frameworks, and other enterprise features naturally get stronger.

The Future is PostgreSQL

PostgreSQL is one of the most popular RDBMSs in the industry, providing a mature and extremely powerful data ecosystem. Postgres wins because it is 100% open source, mature, feature-rich, and has a massive ecosystem of users.

It’s no wonder that PostgreSQL is becoming the default API for cloud native transactional databases.

We recognized this shift early and announced PostgreSQL compatibility in 2017-2018. We also saw that wire compatibility with Postgres was not enough – customers wanted full compatibility, i.e. runtime compatibility which ensures retries, error codes, etc. are compatible. It is not feasible to achieve this by building the PostgreSQL API from scratch. YugabyteDB reuses the PostgreSQL query layer to achieve PostgreSQL runtime compatibility.

Being a PostgreSQL runtime-compatible database, YugabyteDB also inherits the vast ecosystem of PostgreSQL integrations without requiring any changes to the code.

Most drivers, libraries, frameworks, foreign data wrappers, and other integrations/extensions created for PostgreSQL work out of the box for YugabyteDB. PostgreSQL also offers a rich set of extensions that provide a way to extend the functionality of the database by packaging additions. Most of these PostgreSQL extensions also work with YugabyteDB.

Developers can start to build their applications on PostgreSQL (or a Postgres-as-a-service variant), and when they need built-in resilience, or the ability to scale their workloads without disruption, they can seamlessly migrate to YugabyteDB, which is also 100% open source.

Stay Tuned For Big News!

Our love story with PostgreSQL continues to grow! In the coming weeks, you’ll hear some exciting updates from us – keep an eye on the Yugabyte blog and social channels to be the first to know.