Whenever we talk about Sentry’s open source values we immediately have a bunch of nay-sayers jump on us. It’s almost exclusively negative, either they’re FOSS hard-liners who believe GPL is the cure for cancer, or they simply refuse to learn at all about what Sentry contributes, how we contribute, and in general our (fairly well informed) opinions and values. Today I’m going to talk a little about that, with a focus on Sentry’s journey to the Business Source License. I doubt we’ll convince the nay-sayers, but maybe it’ll help you understand our choices a little better.

Note: As of writing this we have migrated off of the BUSL, and onto our own iteration of it called the Functional Source License (FSL). This post is not about that.

When I started the Sentry project I was new to open source. I didn’t really understand many of the complexities of copyleft vs copyright, or the myriad of choices in-between. All I knew is I wanted to collaborate on software with other people, and this open source thing seemed like a great way to do that. I never intentionally chose to build open source software, it just seemed like the obvious way the world should work.

Now, when I say open source, I don’t mean all open source software. Specifically I don’t subscribe to the copyleft and the Free Software Movement, but that’s a story for another day. Just operate with the perspective that the focus was always on permissive open source. This environment is what led me to license Sentry under the BSD 3-clause, and what drives us to continue to license the majority of Sentry’s source code, as well as much of the other software we release under similar licenses.

So why then, is Sentry’s core service using a non-compete license? Well, ideologically it may look complicated, but in practical matters it’s pretty simple.

I remember a conversation I had with an investor - who eventually ghosted us (sigh) - about AWS. This was pre-Series A, and when Sentry was still fully Open Source. Their question: why wouldn’t AWS just host and sell Sentry? You see, this was the era when Elastic and Mongo had grown to be pretty significant in size, and were (rightly so) worried about AWS cannibalizing their businesses. A fair question to ask, but one that lacks nuance.

Sentry isn’t anything like Elastic or Mongo, and we never feared that AWS would sell it. Our entire monetization strategy was based on two fundamental beliefs:

1. No one really wants to self-host software.
2. We built the software with very little outside contribution, thus all of the expertise lived in-house.

One of those would have been enough to drive my conviction, but the latter is what cemented it. We were the experts of the software, so any rational company would avoid the extreme risk of trying to distribute (and thus, support it). I still believe in that today, but then that goes back to the question of why we changed our license?

Well not all companies are rational, and there’s a lot more that goes into decisions than simple algebra. At this stage of Sentry’s life were still a young company, one trying to do things a little different than the rest of the industry. A lot of our model relied on us giving away the most we could of our software to generate goodwill with customers. We figured if they knew we built a good product, charged a fair shake, they’d come to us when they wanted to move to a cloud offering. That works most days, but as you start moving up market, or into more traditional businesses, it becomes less and less common. More so, not everyone shares our moral code of “just pay the people who build the software”. Businesses are going to go with whatever is often easiest, especially if the financial tradeoff is minimal.

We had a dilemma in front of us: we started seeing signs of companies legally (and illegally) taking Sentry’s open source software and trying to commercialize it. When it was illegal - when someone licensed things incorrectly - we simply enforced our license. That might seem ok, but it was still demoralizing. Legally however was another concern. You see, one of the complexities of Sentry is the sheer volume of components we build: the Sentry service itself (e.g. the dashboard), the SDKs to collect telemetry, and a lot of things in between to transform the data or otherwise help us ship software. We knew that people might leverage our SDKs, and almost certainly would use some of our middleware (Symbolicator is a great example), but what we didn’t believe was people would try to leverage the core Sentry service itself.

The first person to do that was a fairly high profile company in developer tools, one who shared very different values with us and primarily focused on selling open core software behind the firewall. They’re an interesting case study because they primarily operate in the open (that is, their issue tracker is public), so imagine our surprise when someone sent us a public discussion thread about them distributing and monetizing Sentry to their enterprise customers. Imagine our frustration and anger when we knew they had not contributed anything of substance to the open source software or our community.

That is what began the conversation about how we could protect ourselves.

It was never triggered by our board members, by hypothetical risk from cloud vendors, but by another company simply doing what they’re supposed to do (in abstract, at least): maximizing profit. We didn’t think that was right - we still don’t - and that has driven a set of decisions we’ve made over the years to try and better the industry for people like ourselves. It started with our license conversion, and continues with our efforts to push the conversation about sustainability. This isn’t about that broader initiative though, so let’s go back to the Business Source License.

When we initially switched licenses there weren’t many role models. We knew a lot of folks relied on an open core approach which we are adamantly against, and even if we approved of copyleft licenses, they wouldn’t have protected us in this scenario. What struck us as interesting was an article that had surfaced at the time talking about a company who had just switched to this fairly unknown non-compete license, that company was CockroachDB. Their scenario wasn’t entirely the same as ours, but we quickly realized the BUSL was more of a framework than a license - allowing you to define several variables. Additionally we were big fans of the time-delay component - Eventual Open Source - as we began to think of it. We still wanted to min/max our contributions to the wider open source community, so the protections given by the BUSL and the fact that we could easily re-license code seemed like a no brainer.

So we made the switch, and (mostly) nothing changed.

We still had plenty of folks self-hosting Sentry with new folks doing it every day. Our business continued to grow just as it did before. Financially, both from revenue and adoption numbers, it’s never had a negative impact on our business. Two interesting things did happen though.

First, the company which pushed us over the line, the ones trying to ship Sentry themselves, asked for an exemption to the license. I will never forget the awkwardness of this conversation, as it roughly consisted of “can you give us a license to distribute Sentry”, us responding with “are you going to contribute back meaningfully or financially?”, them saying “no”, and us saying “absolutely no fucking exceptions”. That was many years ago, and I’m sure the company is still trying to find some route to commercialize our success, but we no longer are distracted by them.

Second, not overly surprising, someone immediately forked Sentry. Similar to the other company trying to commercialize our work they also had never contributed to the project. I’m not even confident they knew what it was before it showed up on Hacker News that day. As far as I can tell they very quickly learned what we had thought to be true: it’s complicated to take someone else’s software, commercialize it, and then have to maintain and support it. They’ve since given up on that idea and now just attempt to leverage our SDKs and other components.

So what I mean to say is: the Business Source License worked well for us. It allowed us to protect ourselves from these demoralizing distractions, and most importantly ensured we were able to continue to fund Sentry’s development, and to grow the business arm that did so. It has allowed us to continue to ship both time-delayed open source as well as traditional open source, in addition to pushing other efforts around funding and sustainability across the industry.

If you’re considering a non-complete license, there’s a few reasons I think the BUSL and now more importantly the FSL were right for us:

1. We are single-source. That is, we are the authors and maintainers of the software, and we do not expect the community to provide us with contributions. We still allow it, and are thankful, but we consider it our duty to develop our software.

2. We commercialize via cloud services. Many projects cannot or do not do this, so its unclear if this kind of non-compete license can have the same kind of success for them. I’m personally skeptical, which is why the FSL only targets the cloud services use-case.

3. We want to allow people to self-host our software and we do not intend to ever commercialize that aspect. The non-compete clause only protects against commercialization of other cloud services, and enables developers in every part of the world, in any kind of company, to benefit and trust our technology.

4. Most importantly, we want to give as much back to Open Source as we can, with a level of risk tolerance that makes sense for us to protect our investments and our employees. The time-delayed license conversion clause helps us put our mind at ease that our work can be used in the future for many other purposes if they so present themselves.

It’s important to note that Sentry has a set of Open Source values and it’s worth thinking about yours. We don’t simply rely on a single non-compete license, and only a few of our core server components utilize this. The rest of our public software is permissive Open Source. Its also important to recognize if a non-compete license is even the right tool for you. Either way, source available is always going to be better than closed source.

If you liked this article, I’d appreciate a share. Feel free to also reach out on X, I’m @zeeg. I’d especially be interested if there’s something you found helpful, or something you’d like to hear more about.