So you’re starting a company and you want an Open Source business model, eh? Let’s talk about what that means, and how that statement is both totally valid, and makes no sense at the same time.

I was inspired to write this as we recently launched Fair Source - our approach of creating more access to software while also ensuring protections for maintainers. Due to the nature of the goals, a lot of arguments came up from Team Free Software and Team Open Source. That’s totally expected and fine, but my biggest gripe about all of it is the number of assumptions people make about how businesses choose licenses. They will tell you that its some trick to get community contributions, or to garner good will. I’m not saying no ones ever done that, but I will tell you I’ve not met a single founder who wants to open-source their product for those reasons.

They are interested in an Open Source model primarily for two key reasons:

1. To increase the market potential of what they’re building - to gain more potential customers.

2. To reduce the adoption risk of their customers - to remove their objections.

What this boils down to is they’re trying to grow their business, to solve a problem in their business, and they’re looking at “Open Source” - often naively - as a solution to that. What is missed is the simple fact that Open Source is not a business model. Rather, the license you choose is just a component your product’s packaging, whether its Open Source or not. The choice of a license, or even Open Source in general, cannot be made independently.

If you keep that framing in mind, it will help you understand why some licenses are crafted the way they are. More importantly if you’re a fan of Open Source software, it will help you understand the importance of encoding mutually agreed upon values into licenses.

A Distribution Model

The first part of this story is understanding how licenses affect your packaging - your distribution model. At Sentry we’ve made a set of choices that are tightly coupled with our choice of licenses:

1. We have decided to focus on wide-market adoption vs say just selling to the Global 2k.
2. We commercialize via a hosted cloud service - we run the infrastructure - at a low enough price point that its affordable to most.
3. We don’t want to sell support and services for self-hosting, and we don’t mind if others do.

Our choice of license pairs well with those decisions and importantly allows us to grow our overall TAM by creating more access to our software, more awareness of our software. Not all of those customers will ever pay us, but many of them will generate revenue through their peers paying us, or future employers. Additionally the fact that you can self-host Sentry with - for most - no strings attached, that creates defensibility from upstarts competing with us.

The fact is FSL (and previously, BUSL) works for us because those are the attributes of our business, of packaging our product. It doesn’t mean our license couldn’t work for others, but it also means its not the right choice for all. This is the most important point people miss when talking about “Open Source” when it comes to businesses. Packaging is the name of the game, sometimes more important than the product itself, and your license is part of your packaging.

If you’re not familiar with FSL, it primarily does two things. It has a non-compete clause, but one that only prevents you from monetizing the software as a service. That means you can still provide services like charging customers to integrate it, or providing support, but you cant sell the hosting of the service. That’s a beautiful mutually beneficial relationship for both parties, and at the end of the day users win. They gain more access to great software and the maintainers of the software are able to sustain their livelihoods off of it. The second component is DOSP - the source code becomes permissive after two years.

A Safe Investment

The second part of this story comes down to why customers might choose Open Source software in the first place. Many of them are looking to invest into modern, less mature technologies. At the same time they want to be confident that choices they make won’t create undue liability for them in the future. They need to make sure that if they invest into your technology that it will still be there, or at the very least it wont disappear, and still can be maintained.

With Open Source that freedom is guaranteed. You have rights over the source, you can maintain it if the company disappears, pay someone else to maintain it, or even fork and commercialize it yourself if you have to. With Closed Source software, and even many approaches to Open Core, that risk is ever present. Sometimes its an acceptable risk as the product you’re using isn’t tightly coupled to your own business, think something like Notion vs MySQL, but its often not. Its why almost all infrastructure technology is based on some variant of Open Source. Businesses do not want unnecessary risks.

As another perspective, look at how that differs from traditional Open Core models and Closed Source software. In those models you’re limited to completely rebuilding the components you require, the ones locked behind the paid license scheme. You’re also at risk of litigation as we’ve seen with some of these recent rug pulls. Who’s going to prove that the code you write that mirrors the proprietary version of the product wasn’t just the company’s IP passed through ChatGPT? Thats why its so important that we recognize the needs of all parties here, and make sure we’ve got a mutually agreed upon set of terms for software that really delivers what we all want.

In my experiences talking with founders, removing this liability is often one of the primary drivers for why they’re considering opening up their product. The problem they come to, very quickly, is which license, and that comes back to the entirety of packaging and is where one of the biggest burdens exists today. If they choose AGPL they’ll deter all but the most determined competitors, but given its a GPL-based license, it might also scare off certain customers. If they choose MIT they might as well rely on thoughts and prayers, as nothing protects them from predatory companies. So what do they do? Well, most of them choose Closed Source.

When they do that two things usually happen

1. They build some really interesting technology.
2. No one ever truly gets to use it.

While I’d say thats the worst outcome, another you’re all familiar with burns at the community. They choose the wrong license, one that doesn’t align w/ their business or packaging, and a few years later we see the rug pull. Closed Source isn’t the answer for most technology, which is why this license choice is so critical. You need to choose a license that fits your commercial model. One that allows you to safely invest into your technology. Sometimes that will invite competition - and thats ok! - and in other situations that might be too much of a liability. That’s what makes this decision so hard.

A Set of Values

The core of the misalignment I see seems to be an over rotation on the personal freedoms afforded by variations of Open Source. People assume the choice of a license is simply about someone’s values. I care a lot about the freedoms of Open Source, but I will also tell you that those freedoms may have risks I cannot afford. This is why I’ve been so bullish on considering new ways to do non-commercial licensing. Licenses, after all, are the way you lock your personal belief system into your distribution model.

Your personal belief system is what we need to focus on here. Values that you personally believe in, and if you’re lucky, what your customers believe in. I said businesses don’t care about the freedoms, or the other values that many people in the community do. That is true, but people still care about them, and in particular, some of these freedoms - like the safety of your software living on - are valued by your customers. Those values need encoded into the license, and always contain a set of tradeoffs.

This in particular is where Open Source gets tricky. When you look at things like GPL, they are extremely focused on user freedoms in the absolute sense of the word. What values does GPL actually provide a business? I’d argue - none that a permissive license doesn’t grant them. They instead provide some deterrents that might implicitly aid the maintainer to a various degree, but ultimately they bias around the maintainer’s belief system. The FSL on the other hand is pretty much entirely the opposite - we focus on protecting the maintainer, while trying to minimize the risks and restrictions to the customer. What I like about Sentry’s approach with the FSL is the set of values we’ve written into the license.

We’ve said we believe in Open Source, we believe in access to software, and we’ve made both of those things absolutes in our license. We’ve taken our personal values and put them into formalized terms and conditions that are well packaged with our business. They’ve set us up for success on all angles to where the business incentives are completely matched to license’s terms. This is the area people need to focus on when they think about their business model and how it relates to Open Source. You have to package it with your product, and align it with your businesses incentives and risks.

This compromise, these values and protections, can be attractive to both the users of the software as well as the business and its maintainers, which is exactly what Fair Source is all about. Its maximizing the benefits to users while removing enough risk from the business.

Not All Software

I would love to see the community stop misunderstanding each other. People build software, but businesses fund it. It’s a circle of life that we all live in, and we all want to use technology to improve our lives. Most importantly, remember that the license you choose for your business cannot be based exclusively on your belief system. This is why its important to have a variety of choices, ranging from truly open to truly closed, because packaging of a product has so many of connected decisions that there will never be a one-size-fits-all.

If you’ve made it this far, I want you to remember that this is entirely focused on the commercialization of Open Source. Much of software should be absolutely open, and in my opinion, permissive in the fullest. If it can’t be, and you’re trying to build something new, we’re hoping you’ll consider something more than Closed Source. Loosen the restrictions a bit and open up your software. If you can’t tolerate the risk of permissive Open Source, choose Fair Source.