How to save your company with a license change with Tyler Jewell

07/03/24 • 52 min

This week on The Business of Open Source, I spoke with Tyler Jewell — for the second time, now. Last time I spoke with Tyler, he was an investor at Dell Technologies Capital, he’s since taken over as CEO of Lightbend.

We talked about a lot, but there was a definite theme to our conversation: License changes. Lightbend had been running an open core model, with the open core using a permissive Apache license. The company’s open source project, Akka, is massively popular. Lightben had about $13 million in ARR. But it was spending over $20 million per year, mostly of on R&D and then GTM. And they had a churn problem; and the churn problem was that customers would stop buying Lightbend’s product, but they would stay with Akka, because it was good enough.

Why did this happen? The added proprietary features weren’t valuable enough for companies to pay for, especially in the face of budget cuts. And because the community was quite mature, it often started to duplicate these capabilities. And then the company faced a near-death experience in 2021. At the same time, usage of Akka was only growing, while the company was facing potential bankruptcy. Investors saw the potential and didn’t want to give up on the company, but it was clear to the board of directors that something needed to change — and that the thing that wasn’t working was the business model.

So they changed it.

There’s a couple things I hope people can take away from this.

If the difference in value between your commercial product and your open source project isn’t big enough, you’ll have a rough time building a profitable company.
Sometimes the alternative to changing a license is bankruptcy; bankruptcy ultimately is not in anyone’s best interest, not the company, not the community’s, not the customer’s.
Offering a cloud option can work, but it’s an entirely different business, and trying to build it up while the company is in a crisis and expecting it to save the company is only realistic if there’s a good overlap between the market for the cloud offering and the open source project; in this case, there wasn’t good overlap.
The license options open to you depend on what the actual software does. And if you’re going to enforce the license at all, you need to have some visibility into where it’s installed, which, again, can be challenging depending on what kind of software you’re dealing with.
Changing an open source project’s license is not a trivial undertaking. You have to hold copyright to the code, and you better hope that you’re structured your contributor license agreements correctly. You also have to do the change on a new release — and it’s more likely to work if the new version is different enough from the previous one that people really want to update.
If you’re going to make a license change, you might get backlash, but if being transparent and honest can go a long way towards minimizing the PR disaster.
So what happened? Churn went down, revenue is nearly doubled and Tyler projects that this year will be cashflow positive.

This summary doesn’t do it full justice, though, so check out the full episode!!

So they changed it.

There’s a couple things I hope people can take away from this.

If the difference in value between your commercial product and your open source project isn’t big enough, you’ll have a rough time building a profitable company.
Sometimes the alternative to changing a license is bankruptcy; bankruptcy ultimately is not in anyone’s best interest, not the company, not the community’s, not the customer’s.
Offering a cloud option can work, but it’s an entirely different business, and trying to build it up while the company is in a crisis and expecting it to save the company is only realistic if there’s a good overlap between the market for the cloud offering and the open source project; in this case, there wasn’t good overlap.
The license options open to you depend on what the actual software does. And if you’re going to enforce the license at all, you need to have some visibility into where it’s installed, which, again, can be challenging depending on what kind of software you’re dealing with.
Changing an open source project’s license is not a trivial undertaking. You have to hold copyright to the code, and you better hope that you’re structured your contributor license agreements correctly. You also have to do the change on a new release — and it’s more likely to work if the new version is different enough from the previous one that people really want to update.
If you’re going to make a license change, you might get backlash, but if being transparent and honest can go a long way towards minimizing the PR disaster.
So what happened? Churn went down, revenue is nearly doubled and Tyler projects that this year will be cashflow positive.

This summary doesn’t do it full justice, though, so check out the full episode!!

Previous Episode

Complementary Projects and Products with Justin Cormack

This week on The Business of Open Source I have an episode I recorded on site at AI-Dev in Paris with Justin Cormack, CTO of Docker. We finally get around to talking about AI at the very end of the episode, but otherwise we talked business and open source and how Docker manages both. Here’s some of the take aways from the episode:

There are upsides and downsides to being an open source company, and you should absolutely make sure you are leveraging the upsides. Because they don’t necessarily translate into business value automatically, you have to be intentional to make that happen.
It’s often a good idea for open source businesses to create a commercial product that is complementary to their project, so that if usage of one goes up usage / adoption of the other goes up, too. This is in contrast to an open core model, where the open source project can easily end up being crippled so that people are incentivized to buy the closed source license.
If you want to get to $100million ARR, you can either sell $10 subscriptions to 10 million people or you can sell $100,000 subscriptions to 1,000 people. Both get you to the same revenue number, but the business model is very different.

We also talked AI and open source, given the event we were at.

Next Episode

Thoughtful open source strategies and nailing the OSS/product relationship with Joe Duffy

This week on The Business of Open Source, I spoke with Joe Duffy, co-founder and CEO of Pulumi.

We kicked off the conversation by talking about why Pulumi is open source in the first place — a mix of Joe’s long-standing interest in open source and a feeling like a developer tool like Pulumi just has to be open source in order to be taken seriously. But there was another reason, too: Pulumi’s founders weren’t just in it to build a company, they wanted to transform their industry and build a lasting community, and felt like open source was the best way to do that.

Lots of good take aways in this episode, like:

Learning from open source legends... uh, actually, learning from Microsoft. Microsoft is an open source giant, right? It’s interesting to hear Joe talk about learning about open source business strategy from Microsoft, precisely because Microsoft does not make money directly from VSCode, and also does not invest millions of dollars into R&D just to be nice. “If you’re going to try to build a business with open source, you need to be very thoughtful and very strategic about it.”
The founding team at Pulumi sort of iterated on figuring out the business model, but to a large extent they just thought about it until they had an Aha! moment. On the other hand, they didn’t go public until they thought they had a winning strategy for building an open source business.
In the case of Pulumi, there’s a client side and a server side, so it made sense to build in a natural division between the two. This also made it so users were less likely to feel like Pulumi was holding back essential features in order to drive sales.
“The way I always view it is the thing you’re selling has to stand on its own”
Pulumi started a company, an open source project and a commercial product at the same time. Joe’s not sure he would recommend that approach, but it worked for them. “Figuring out the relationship was importnat, but actually the most important thing was to have a successful open source technology.”
One thing I wanted to pull out: Even though Pulumi launched the open source project and commercial product at the same time, they focused all their efforts in the first two to three years on getting the open source project off the ground. Many founders I talk to think that once the commercial product is out there, you are forced to build a GTM team... but you don’t have to. In fact, I think the strategy of having the possibility to buy the commercial product while focusing the company’s energy on the open source software in the beginning is brilliant. Result: “We were able to create this immense funnel of inbound commercial interest, even when that wasn’t really the top level focus.”
Even if you’re primarily a SaaS company, you can still offer an enterprise on-prem version for customers with hard requirements to host themselves, like air-gapped environments. Just because that option exists doesn’t mean you must build GTM motion for it, though.
The business value Pulumi gets from the open source project is: generating leads, building the company’s brand, and also recruiting top-level talent.
The fact that developers building the tool are so close to developers in the community is also a huge advantage.

Listen to the full episode, it has a huge amount of great insights!