Let's Talk About Open Source

Yesterday we announced that Codecov is now “Open Source”, and we messed up in two ways:

• We wrongly used the term Open Source; while unintentional, we should have known better
• We let our emotions get the best of trying to explain our position, rather than stepping back and addressing the problem

I want to talk about both of these, how we made the mistake, why it’s important to us, and what we plan to do about this to improve the conversation in the future.

First let me clarify why the first mistake is a problem, as you might not be familiar with the open source ecosystem. Open Source, while you and I may sometimes use it as a simple English phrase, has a lot of historical and emotional context attached to it. Most people, especially those who are deeply involved with maintaining the values of that ecosystem, will tell you that the license we use is not classifiable as Open Source (typically referenced per the OSI definition). They are right, as the Business Source License (BUSL) - which is the license we use for both Sentry and Codecov’s core services - clearly violates the restrictions on freedom.

We made this mistake because we believe the BUSL is close to many open source licenses, and for most people, it covers the desires they have when they consider open source software. If you’re unfamiliar, the BUSL can easily be summarized as an eventual open-source license. That is, it’s a restrictive license that after a period of time will convert to another license, in our case Apache-2.0. The restrictive nature of it is fairly lightweight within the context of Sentry and Codecov: you simply cannot commercialize it as a competing service. Unlike many Open Core models, which often offer a lightweight free version and a more costly enterprise version, BUSL allows us to distribute the same version of our software our paying customers get, but with the ability for you to self-host and modify it without paying us.

I want to touch on a bit of history on why this restriction matters, as there was a lot of conversation on why we don’t use a copyleft license (like GPL), or why we even care about making the source code available. If you’re not familiar with our history, Sentry was actually created under the BSD 3-clause license. Open Source was in my blood when I started the project, so it wasn’t a decision made, it was just a default choice, and for whatever reason that choice generally was BSD 3-clause at the time. BSD is an extremely permissive license that intentionally offers very few protections for the license holder. Many years later - several years even after we had started the SaaS business - we started seeing several for-profit venture-backed companies pop up actively using or showing intent to use our code. This was a concern for a number of reasons:

1. There was almost no way we could protect ourselves, protect our ability to fund the project. While we had registered trademarks, the license granted them enough rights over the software. We had no legal recourse unless they failed to comply with the license (which you might be surprised, it does happen). This felt like a non-starter, and legal recourse also wasn’t something we wanted to be known for unless it was a bad-faith actor.

2. At the time, we were fairly small in all regards - the business, the team size, and even the complexity of the project (which is a natural defense mechanism). That meant we also had no real ability to defend ourselves on our team’s capabilities. I’d argue a bigger company could take on this risk with more appetite.

3. Lastly, we were trying to build a product that was fair to our customers, and to the community, so seeing other companies try to commercialize our work was mentally draining and demoralizing. For me personally, this was one of the primary driving factors - building things is hard, building companies is hard, and doing it with this looming over your head I would find unbearable.

As an aside, you might immediately consider why some of these problems are such a big deal. The community was building Sentry, no? What right or claim did we have to justify such concerns? Open Source is a variety of models - just like businesses are - and in Sentry’s case, most of the development on the core service was done by myself and eventually people who worked at Sentry. That’s not to say we didn’t have some great contributions or a vast array of help on related projects (like our SDKs), but it was quite a bit different than some of the other projects you might be familiar with. We intentionally shunned the mantra of “Pull Requests Accepted”, as we had a vision for our product that we wanted to focus on, and we had the ability to pay people to help us achieve it. That’s why that last point was so impactful for us: these other companies had not contributed back in the slightest to Sentry but were attempting to commercialize it. It didn’t sit right with us.

We were fortunate that around that same time, CockroachDB had gone through a license change to the BUSL (for similar, but different reasons), which was how it first showed up on our radar. It also seemed like a fairly viable option that upheld the core parts of open source that we valued, with only a small downside. We decided to do it, and in 2019 we made the change. I can say that I personally slept a lot better after that, knowing we could focus on building something that helped people, rather than the constant anxiety of a big company ruining everything we had worked towards. After all, Sentry was already a decade of my life and close enough to it for many others by that point.

With that context, fast forward to Codecov - who joined Sentry at the end of 2022. Codecov was the second technology acquisition for Sentry, and we knew from the beginning, just as we had done with our prior investments, that we wanted to bring it into the core operating model of Sentry. When you tell a team it’s okay to take the risk and stop selling on-premise support services, combined with the ability to open up the software to people, it’s a pretty easy pitch. Most people genuinely want to build good software and want to get it into the hands of as many peers as possible. That same principle is why Sentry’s base price has not risen from $29. We fundamentally believe in giving access to technology to as many people as we can.

Full circle, we announced yesterday that Codecov had been released using the same licensing strategy we had applied to Sentry. That is, critical server components get licensed under the Business Source License, and adjacent elements, or things with justification that they exist for the greater good, must be licensed under a permissive license (Apache-2.0, MIT, or BSD, depending on the context). We messed up though, and instead of focusing on the values, and the intent, we focused on terminology.

It’s my belief that most of us are aligned on the challenges, and we believe our heart is in the right place. We wanted users to understand that many of the freedoms an Open Source license would grant them, they were now granted with Codecov’s software. We don’t yet have a great way to articulate that, one that users understand. It’s not closed source, as you can self-host, view and modify the source, and even redistribute to some extent. It’s not source-available to most of us, as that’s commonly referring to nearly closed source software (look but don’t touch!). It’s eventually Open Source, but it’s not Open Source yet, and that doesn’t convey the freedoms. What is it? That’s a question we have to answer going forward.

We are committed to improving the conversation around this topic, around ensuring open source can be both sustainable and protected. We aren’t the first team to make this mistake, in trying to draw analogies to other open source principles and creating division, and while we likely won’t be the last, we want to help improve the situation. Some efforts we’ve already been working on for the past few years have gone well (like our annual contributions to other projects), but the licensing conversation is still just as complex as it was many years ago. We hope to better define what sustainable open source models can look like, including semi-restrictive licenses like the BUSL. We don’t know what that means quite yet, but we’ll make sure that we share our ideas with the community in the future.

I just want to close this by saying we’re all here trying to work together to build a better open source ecosystem, to continue the growth we’ve seen in that sector, and to ensure people have access to software and knowledge. We hope you’ll forgive us for this one, along with various past transgressions, and I’m sure some future ones, but know that we’re committed to making things better for everyone to the best of our ability.

Note: We commonly referred to the Business Source License as the BSL in the past, and I can’t promise we won’t accidentally typo that in the future, but the BUSL is the preferred acronym and we are working to correct that. The BSL is historically associated w/ the Boost Software License.