Matt Asay
Contributor

What happens when you open source everything?

analysis
Dec 23, 20207 mins
Open Source

Many open source software companies embraced the open core model to increase revenues. Yugabyte found greater rewards leaving open core behind.

Neon Open sign
Credit: Thinkstock

Chef co-founder Adam Jacob argues you should follow his lead and go all in on open source. Not open source “Community” with paid-for “Enterprise” bits. Open. Source. It. All.

Sounds great. But what will it mean for your business? Sure, you want to be popular with the open sourcerors, but you’ve got employees to care for, VCs that need another Aston Martin, and a crippling lease on now-useless office space in Palo Alto. Is there any proof that a 100% open source approach actually works?

I’m glad you asked, because that’s the question I put to Yugabyte cofounder and CTO Karthik Ranganathan in an interview. The tl;dr? Open sourcing all of your code can be incredibly smart strategy.

Making software work

Over the past decade, many companies have started with open source but turned to proprietary software licensing as a way to generate revenue. Yugabyte, which provides an open source, distributed SQL database, did exactly the opposite. It started with a blended open source and proprietary model, and shifted to 100% open source in early 2019.

This wasn’t done to be cool.

There was a “well-thought out strategy” behind it, Ranganathan said, one that depended on a key insight into how customers valued software. “We felt enterprises care more about… getting the database operational and getting it to work in production and making sure it runs really well,” Ranganathan said, “rather than just paying to acquire the software.”

In other words, the software was important but not where the compelling value was. If a customer can’t use the software, it has no value. The value is in operationalizing that software so the customer can be productive with it.

For this premise, Yugabyte took inspiration from AWS and Aurora (operationalizing PostgreSQL or MySQL), as well as MongoDB and its Atlas database service. But it also had direct experience: Yugabyte Platform. The Yugabyte Platform enabled enterprises to run a self-managed Yugabyte database service wherever they wanted, including on premises.

“When we saw how our customers were adopting it, we felt the platform that would get these customers to reliably run the database in production was actually the more valuable thing,” Ranganathan explained.

The decision was made: Open source everything.

Open for business

If you start giving away the product for free, it’s natural to assume sales will slow. The opposite happened. (Because, as Ranganathan pointed out, the product wasn’t the software, but rather the operationalizing of the software.) “So on the commercial side, we didn’t lose anybody in our pipeline [and] it increased our adoption like crazy,” he said.

I asked Ranganathan to put some numbers on “crazy.” Well, the company tracks two things closely: creation of Yugabyte clusters (an indication of adoption) and activity on its community Slack channel (engagement being an indication of production usage). At the beginning of 2019, before the company opened up completely, Yugabyte had about 6,000 clusters (and no Slack channel). By the end of 2019, the company had roughly 64,000 clusters (a 10x boom), with 650 people in the Slack channel. The Yugabyte team was happy with the results.

The company had hoped to see a 4x improvement in cluster growth in 2020. As of mid-December, clusters have grown to nearly 600,000, and could well get Yugabyte to another 10x growth year before 2020 closes. As for Slack activity, they’re now at 2,200, with people asking about use cases, feature requests, and more.

To review: Yugabyte’s open sourcing all its code resulted in no loss of revenue and dramatically better adoption (leading to much more revenue). There’s a lot to like in that model, and it’s not simply about revenue.

Closing the door on Open Core

I mentioned the company had started with an Open Core model, blending proprietary and open source software. It turns out this approach is complicated to pull off from an engineering and legal perspective, according to Ranganathan:

We didn’t like it because it wasn’t clean. It wasn’t good. It’s a big mental barrier on the part of the user because they don’t know which [features are] where. No one has time to go through all of the files, and the legal side gets complicated.

For every feature you have to debate which side it goes [i.e., Enterprise or Community]. And the CI/CD for community patches actually gets into a more complicated scenario. Because we have this sophisticated CI/CD for one side, do we now repeat it on the other? Do we repeat it for a subset? Do you just take the whole thing and qualify it? Just too many impediments.

By contrast, Ranganathan continued, a 100% open source approach has been “amazing.” It means “it’s very simple for the team to put out a design document for what the database does, and it can be consumed by our users, and anybody who has questions about how the features work, they can go read it up, and they know that it’s there in the database.” This is optimal, he said, “because we don’t have to artificially stop developers from trying to solve problems…. They can run their proof of concept. They don’t even need to talk to us.”

Some customers will opt not to use Yugabyte’s services but Ranganathan noted that this usually has meant the workload isn’t critical to the customer or they’re so price conscious that wrangling over a service contract wouldn’t make sense for the customer or Yugabyte.

In other words, open source, coupled with cloud services, aligns Yugabyte’s interests with those of its customers, rather than setting up an adversarial environment where artificial licensing constraints are used to compel payment for things the customer may not actually value.

But if Yugabyte open sources everything, won’t the cloud vendors obliterate them?

Competing in the cloud

That was my last question, and I had to ask it. I mean, I’m biased, right? I work for AWS. So I asked Ranganathan directly. His answer: “This competition is precisely what makes open source work and attractive to enterprises. Otherwise, you can just keep locking people in.”

According to Ranganathan, the dissonance between open source and cloud vendors was a blip because “cloud was a super-fast, secular trend and [open source vendors] were slow to react to it, leading the big public clouds to capitalize on that gap.” He went on to suggest that the introduction of cloud database services from Yugabyte and others should blunt the need (and ability) for cloud vendors to create compelling alternatives.

The other key, one which MongoDB, DataStax, and others have implemented well, is multicloud. As Ranganathan thinks about it, Yugabyte can offer the database as a managed service… anywhere. “Whether they manage it or we do is just a detail.” Yugabyte started with its Platform product, but is soon rolling out Yugabyte Cloud, a fully managed service. This gives customers absolute flexibility on how and where they want to run the database.

All of which turns the cloud vendors into partners, and customers into allies, not adversaries. It’s a model that has worked wonders for Yugabyte. It just might do the same for you.

Read more about open source:

Matt Asay
Contributor

Matt Asay runs developer relations at MongoDB. Previously. Asay was a Principal at Amazon Web Services and Head of Developer Ecosystem for Adobe. Prior to Adobe, Asay held a range of roles at open source companies: VP of business development, marketing, and community at MongoDB; VP of business development at real-time analytics company Nodeable (acquired by Appcelerator); VP of business development and interim CEO at mobile HTML5 start-up Strobe (acquired by Facebook); COO at Canonical, the Ubuntu Linux company; and head of the Americas at Alfresco, a content management startup. Asay is an emeritus board member of the Open Source Initiative (OSI) and holds a J.D. from Stanford, where he focused on open source and other IP licensing issues.

More from this author