Understanding Business Models & Defensibility in Open Source

First-Principles Business Models Matter for Open Source

A key concern for open-source startup founders is defensibility–how to maintain a competitive advantage even though your source code is publicly available. So why is Heavybit running this extensive interview on why open-source software (OSS) founders need to focus on their business model from first principles?

Because defensibility comes from setting up your business on a solid foundation–which can evolve, but requires you to place some kind of bet. Chef and System Initiative co-founder Adam Jacob suggests founders will build more-defensible startups, and make more than enough revenue, after they get realistic about how they run their business.

This in-depth interview covers:

• How to Think About Founding an Open-Source Startup from First Principles
• How to OSS Expands Your SAM and Delays Competition
• Understanding Other Parties Will Exploit Your Tech for Profit
• Getting Realistic About Business Models
• How to Avoid “Competing Against Yourself”
• How to Think About TAM and Market Efficiencies
• Defensibility From First Principles
• How to Manage Bull Markets and Plan for Down Markets
• Worry About Business Model First, Then Defensibility
• Success Comes From Community That You Don’t Own or Control

How to Think About Founding an OSS Startup

Jacob advises new founders to think about open source from first principles–including the impact it has on technology and people’s lives, and how they feel about the Four Freedoms. He concedes there’s an idealistic “hippie” aspect to building software that’s free to use, but cautions founders to consider how to structure their business and go-to-market.

The founder recommends starting from the concept of total addressable market (TAM)–the hypothetical maximum of the number of customers who might ever buy your product multiplied by the average price each would pay. Scaling down, you’d then look at your serviceable available market (SAM)–the market reachable by your startup, then to the more-realistic serviceable obtainable market (SOM) across your proposed timeframe.

While it’s important to think about product vision and whether your scope is large enough to appeal to a TAM that can support a VC-backed business, your biggest concern should be your ability to generate revenue. “How much people will pay is an integral part of the conversation. The ‘naive version’ of this starts with you open-sourcing your software and charging nothing for it. This drops your TAM to zero, which is bad business.”

More Foundational Intel for Open Source:

• Article: The Power User’s Guide to Open-Source Licenses
• Article: How to Successfully Fork an Open-Source Project
• Article: What Success Looks Like for Modern Open-Source Software Startups
• Article: Understanding Legal Issues for Open Source Software Start-ups
• Video Archive: DevGuild Open Source Covers GTM, Security, Licensing, and More

How to OSS Expands Your SAM and Delays Competition

Jacob offers his own startup as an example. “For System Initiative, we're building this foundational primitive that we think overtakes infrastructure as code. We think this is how huge enterprise customers will operate over time. That is a huge TAM. But it’ll be difficult to capture all the possible revenue in this space.”

“If I’m successful, I’ll breed competitors who will carve the market up. But deciding to open source lets me also make a bet: If the technology is open and I let people benefit from its existence, maybe I can delay the appearance of stronger competitors and grab more market share. It's a strategic choice about how I expand my SAM and how I react to competitors over time.”

The founder suggests that when entering a crowded market against bigger players with better, but not fundamentally transformative tech, an alternative license like fair source might make sense. “You might try to disrupt the leader by having a better enterprise version. Maybe it deploys faster, or it's easier to manage. Look at the Kafka ecosystem–where there are proprietary or fair-source players who sell faster versions of Kafka.”

Adam Jacob discusses OSS licensing with fair source at Kubecon 2024. Image courtesy Wilson Craig

Understanding Other Parties Will Exploit Your Tech for Profit

Jacob warns that “free” isn’t free. “If you’re thinking about open source for your startup, you can’t say: ‘I want to be open source, and everyone in the world should be good actors to me.’ When you decide to open source the software, you're allowing others to benefit, including people you may not like, or people you wish wouldn't benefit.”

“Is having other parties benefit from your technology a problem, or is it an advantage? Think of it this way: If another party slurps up your code, it’s understandable to react with anger–‘I can’t believe they did this to me!’ But another way to react is to see it as an incredible validation that shows how much of a market leader you are, right?”

“Yes, you can get mad at those other parties, but they need to collaborate with you to move this foundational technology forward. So you could say, ‘We can’t wait to collaborate with these other people in the upstream!’ I’m not saying freeriders are good actors. But this is the game. This is one of the reasons you make this choice as an open-source founder. And if you make this choice, you have to double-down on that.”

Getting Realistic About Business Models

The founder recommends starting from a startup’s basic need to sell products for money. Consider an enterprise-style open core approach as an example–most users pay nothing and essentially get no value out of the software, though hopefully, there are a few big enterprise customers that will buy massively valuable contracts.

“In this case, why try to be ‘defensible’ around features you've already said have no value? You’ve already set the cost at zero. So why do you care that someone else is trying to exploit them? You've decided your business model is on the enterprise value through things you add on top. So, why not go compete there?”

Jacob recalls how he and Chef co-founder Jesse Robbins took a ‘speedrunning’ approach to running an open-source startup, finally arriving at a good fit on business models later on. “I was looking at Chef yesterday because I was thinking about using it–and it’s actually kind of hard for me to use Chef now because it sells to the enterprise. That’s a little sad, but I get why that is.”

Jacob advises that founders skip ‘hard mode’ and focus on becoming as strategic as possible as quickly as possible when thinking about their business, and to start making bets. “For the bets that turn out to be true, let's double down.” He notes that founders often go backwards–starting from building interesting tech, to open-sourcing it to drive adoption, then finally starting to think about a business model.

The founder notes that OSS startups that struggle with the dynamics of making revenue against the structure of their company often start reaching for licenses. “Alternative licenses are often a reaction to market saturation. The more competitive and saturated things get, the more attractive alternatives like fair source look.”

Jacob suggests that founders sometimes think of licenses as a hedge to keep their tech proprietary against an open-source incumbent, and might use fair source to handle objections about ‘not actually being open source.’ “These are all business model conversations, and that's where I would encourage people to start. Too often, we focus on technology or principles of open source. You have to start with the business model and the rest will follow.”

I’m not saying freeriders are good actors. But this is the game. This is one of the reasons you make this strategic choice as an open-source founder. And if you make this choice, you have to double-down on that.”

How to Avoid “Competing Against Yourself”

Jacob notes that startups often build meaningful technology, open source it to build a community, then try to monetize with open core. However, every non-paying user ultimately contributes zero to the TAM–not an attractive prospect for investors. “If your idea for a business model is: ‘Look at how big a market we can capture where no one pays us anything for what we build,’ that's a dumb business model.”

“If you don’t sell anything for money, why do you think people are going to pay you anything? It’s not a licensing problem. It's a business model problem. Your TAM is too small. You might say, ‘I’ll sell to the enterprise.’ OK, but what’s your annual contract value (ACV)? Since you’re giving away the core value of your product for nothing, your ACV is going to be low.”

“Enterprises know the core value of your project is something they could get for free. So suddenly, it gets really hard to push past those six-figure ACVs into seven-figure ACVs. Now, you need even more market saturation to hit the same revenue targets. And your TAM is even smaller, right?”

The founder warns that bad business models can squeeze you out of revenue and make your funnel much less efficient. “At this point, what’s the incremental value you offer to enterprises? Whatever it is, it’s too small. So now, competitive pressures increase on your business. You get saturated in the market–and your problem isn’t struggling to win deals.”

“You’re losing deals to yourself more than to competitors because your value prop is all wonky. In contrast, look at the business model of a company like Red Hat, which made a billion dollars in ARR ‘selling Kubernetes.’ They didn't even write Kubernetes!”

How to Think About TAM and Market Efficiencies

Jacob points out that too many open-source startup founders oversimplify the math when calculating their TAM–assuming that their project may eventually have a million users, only a few of which will pay hefty enterprise fees, while the rest pay nothing. “You can’t ‘average things out’ to zero and call that a ‘loss leader.’”

“I was just talking to someone the other day about SAM, but they were using the term ‘TAM.’ They’ll say, ‘I want to grow my TAM.’ Maybe if you launch another product. Otherwise, TAM for your core offering is what it is, and isn’t likely to change. People make bad decisions all the time because they aren’t precise about how their models work.”

“Here's another thing: Open source, when it works, is so powerful that it overcomes these inefficiencies. Realistically, there isn’t a startup on the planet that wouldn’t be thrilled to have the kind of problems we mentioned–having a well-developed open-source product, many enterprise customers, and a few big vendors slurping up their technology.”

“But if your business is inefficient, you don’t make enough money from your customers. This kind of thing is built into the business model, into the design of how companies decide to market and sell their products. And it's not a surprise that, for a lot of folks late in the game, they have to change their minds when the topic of defensibility comes up.”

If your idea for a business model is: ‘Look at how big a market we can capture where no one pays us anything for what we build,’ that's a dumb business model.”

Defensibility From First Principles

The founder is direct: “Defensibility comes from your product, being a thing that can only come from you and the fact that the product has value. But the product is not only the technology. Usually when we talk to engineers, they think about the product as the technology, but it's more than that.”

“Your ‘product’ as an open-source startup is actually everything that goes into producing that thing, selling it to your customers, supporting it over time, maintaining it, keeping it secure. That whole thing is your product. And you should not do any of that for people who don't pay you money.”

Step 1: Copyrights

The founder begins with copyrights–protections for original works for which open-source licenses carry stipulations on copying, modifying, and distributing. “We’ve established that the software isn’t the product, but licenses tell you the terms of the software release. For example, Apache generally says you can do what you want with the software–whether I like it or not.”

Jacob notes that licenses do not impart usage of trademarks–so while others can take open-source software from an existing project to build something new, they can’t refer to their new project by the original project’s name, though licenses also carry an important nuance–the ability to decide how software gets distributed.

“For example, VSCode is Apache, but when you download VS code, you have to agree to Microsoft's commercial terms. Most people don't think about that–they see a button that says ‘download,’ they click it, and they don't have to pay any money. All good, right? But make no mistake, the distribution license is different.”

Step 2: Trademarks

“Then, there's trademarks. This lever is about your brand. You must have one that is unique and belongs to you. With trademarks, you can determine how other people get to use them, and under what circumstances. For example, the System Initiative software is open source, but no one is allowed to make a build of System Initiative except for me, because you can't distribute it if it has my trademarks.”

“So if you check out the source code, make some changes, then decide you want to run it on prem? You can't, because that software has my trademarks all over it. And in order to use those trademarks, you would have to agree to the terms, including my commercial terms, which then leads you to having to pay me for the software.”

“If somebody wants to fork my project, go ahead. But they’d need to replace my marks. They’d need to call it something else. And they’d have a new product that’s theirs, and they become responsible for the supply chain, for building it, distributing it, securing it. All that stuff is now on them, not on me. And we can collaborate on the software. But they can’t pretend we're the same, because we're not.”

Step 3: Patents

“The last lever you can pull here is patents, which are supposed to ‘protect innovation,’ but aren't particularly useful in open source. While it's good to have them, they usually don't see a lot of use. Also, a lot of open-source licenses include patent terms. There are some arguments about whether the patent terms are inferred or implied.”

“Those are the three sorts of levers you have for defensibility: copyrights, trademarks, patents–with that special subnote for licensing and distribution licensing potentially being separate. Ultimately, as a founder, you're trying to create the circumstances where that product you produce, that branded thing you do, is something your customers can only get from you. Or, if they want that thing, the only way to get it is from you, and from there, you can decide what commercial terms you want to give to customers.”

System Initiative’s extensive open source page describes what users can and cannot do in exhaustive detail. Image courtesy System Initative

How to Manage Bull Markets and Plan for Down Markets

As markets change, VC-backed startups may move from a bubbly zero-interest rate policy (ZIRP) environment that makes it easy to raise funding and hire armies of engineers...to a down market where layoffs are common and engineering teams shrink. But Jacob isn’t convinced that startups that hired huge dev teams during ZIRP contributed any more or less to open source.

“Were there more ‘free hands’ to contribute to open-source projects? They were never really ‘free.’ If you're trying to build a cohesive piece of software, you have to manage those contributions–just like you would manage other engineers. And not being employees, contributors are even harder to manage. They’re little chaos agents that work perfectly if you’re lucky–but most of the time, you’re not.”

“And you still have to figure out: How am I going to manage those people? How am I going to manage their contributions? How do I ensure that the product stays cohesive and meaningful? So I don't know that down markets mean there are fewer contributions, or that companies become less willing to contribute.”

“I do think that in tougher markets, people get more sensitive because their business model problems become more stark. When people talk about business inefficiency, they go back to that point about the ‘easy money.’ How far into their funding did startups get before they understood what they had to sell? I can think of a couple that raised more than $50 million without ever really knowing.”

“Keep in mind, they didn’t have to answer tough questions at the time because the strength of their open source community–that motion of people adopting the software–was so strong that people figured: ‘Of course, let’s turn the money tap on! There’s a ton of money here!’ But it’s a lot harder to turn off the money tap later.”

“By thinking about that equation in the beginning, you can make better choices. For example, you can decide you’re OK with having fewer users if you’re monetizing more of them. It all comes back to the same question: ‘How am I structuring my business to thrive in whatever environment it's in?’”

“When we started Chef, it was a very different environment. At one point, the money ‘got cheap,’ and it was amazing for a time, but that kind of thing ebbs and flows. I think our jobs as CEOs, as founders, and as executives is to be the people who pay attention to those things and design resilient businesses in order to grow them into big ones that thrive.”

“This is why most startups don't succeed. It's not because the money got in the way, or they messed up the license, or couldn't find product-market fit. Considerations like ‘the right license’ are important, but ultimately, they have to be in service of the idea that you need to get good at building and running businesses–as quickly as you can.”

“And it just takes a long time to get good at it, and to even realize that's the game you're playing. And if you don’t have a strong business model, then in a down market, you’ll feel the pain even more sharply. Maybe you could have soaked up that inefficiency in a market where the money was cheap because people were willing to give it to you.”

“But in a down market, how eager are investors going to be if you don't have a good answer to the question: ‘How exactly do you make money from your community?’”

Worry About Business Model First, Then Defensibility

Jacob suggests that new founders should first concern themselves with a business model that actually makes money. “New founders should be so lucky as to get to a point where their biggest problem is a competitor slurping up the technology. But if your biggest concern instead is talking about whether you chose the right open-source license...well, that's insane.”

“This is why I took so long to write the open-source page for the System initiative. It wasn’t because of how much I love open source licenses. That was me thinking about my business model. Here’s my plan: I'm going to sell System Initiative, this transformative technology, for money.”

“And then I'm going to run the most fabulous open upstream I can, so that when people realize I've completely changed the game forever, instead of competing with me or trying to build this kind of technology themselves, enterprises are going to realize that the fastest way to get on this train is to join me.”

“It's fine because I want other companies to come join me. I want them to make money. Because it's going to make me a bunch of money, because that’s what my business model is. This is where we loop back around to the question of whether or not you’re a ‘hippie.’”

“If you don’t believe in fundamental open-source principles–if you don’t believe that, as Tim O’Reilly put it, creating more value than you capture is a net-positive for society, yourself, or your company, what happens? When somebody else makes money from ‘your product’ that you think of as ‘your thing,’ you're going to get mad. Why? Because you don't think of software as a fundamentally infinite resource.”

“If you don’t believe that software is fundamentally infinite in nature (and the idea that it can be contained at all is antithetical to its nature), then it's a lot harder to get to the part where you believe that you should open source your code to build a bigger business.”

In a down market, how eager are investors going to be if you don't have a good answer to the question: ‘How exactly do you make money from your community?’”

Success Comes From Community That You Don’t Own or Control

“As I’ve said previously about startup communities, if you really want to build a community-led movement, you need to let that movement be theirs...not yours. You need to let people take your project and make it part of their identity. And you should think about how you're going to engage in that process.”

“For example, System Initiative belongs to me. But if somebody comes along and they want to do something else with System Initiative, I’d want them to collaborate with me. And that makes us a community, right? This is not because System Initiative ‘belongs’ to them, but because whatever they want belongs to them.”

“And we decide together that we care about this infinite resource that is the software. And we're going to steward this thing into its future together. And as long as we can stay together, we get to be a community. If we don't learn how to stay together and work together, then we fracture and become something else. Warring camps, maybe.”

“That's where the ‘hippie’ piece comes back into the picture. It’s a good idea to ask yourself: ‘Do I actually have some fundamental beliefs about open source?’ For example, I've talked to folks at Sentry who I really like and respect. I'm pleased that they started the fair source thing. That’s important because it means that they're no longer calling something open source when it isn’t.”

“As another example, if you had asked me when GitHub was starting out whether that company was filled with open-source ‘true believers,’ I'd have bet you every dollar I had that the answer was ‘yes.’ But the answer was actually ‘no.’ Of course, they believed in the power of communities; they believed that there was power in building a tool for collaboration, and all that stuff. But they always knew where they wanted the benefits to flow.”