Hello everyone. Welcome to another Hacking Open Source Business Podcast. I'm one of the co hosts, Matt Yankovic, joined again by Avi Press from Scarf. And today we have a special guest, Chad Whitaker from Sentry, the head of open source at Sentry. Hi Chad, how are you doing? 

Good. Thanks for having me. 

Um, so Chad, where are you located?

Just out of 

curiosity? I am located outside of Pittsburgh, Pennsylvania. Okay. USA Earth. 

All right. Fair. Well, there, there we go. That's great. That's wonderful. That's specific enough. Yes. Specific enough. . Good. So, um, you know, you, you, you're the head of open source at at Century. What does the head of open source mean at Sentry?

Just give us maybe a little background about your role because Mm-Hmm. , that title is used in a lot of different places for a lot of 

different things. Yeah, no, that's fair. Um, sure. So head of open source at Sentry, so I run our open source program office or OSPO. Um. Which I think by now is fairly common.

A lot of the larger companies have, have OSPOs. Um, and at Sentry, you know, we're, uh, we're about 350 people, so a little on the small side for companies that do have OSPOs. But the thing about Sentry is that open source is core to our company culture. Um, you know, we can get into some of the history, but, uh, you know, Sentry started life as an open source.

Uh, kind of side project, um, and open source is really important to us. So, yeah, so my role as head of open source, um, I run the OSPO. OSPO is a, you know, a tiny team of, uh, two engineers that work with me in our OSPO. Uh, but we work with every other part of the company. So, again, open source is core to Sentry's company culture.

Um, and so, yes, we've got kind of, uh, dotted lines to every other department in the company, basically. Yeah, 

and Century itself, um, does monitoring and maybe give us the overview of Century. 

Sure. Yeah. So Century is an application monitoring company. Um, you know, started out with error tracking, uh, and, uh, put out a performance product a few years ago.

Um, you know, and we do crons and replays and things like this. So, yeah, it's an application monitoring company really focused on developers. Our target audience is developers. We're developers, we built for developers, you know, queue up Steve Ballmer, developers, developers, developers. That's, that's us. Yeah.

So application monitoring, uh, for developers. 

Okay. Go ahead, Avi. Oh, 

okay. Um, you know, and so talk. Yeah, yeah, yeah. Um, so I think, you know, one of the main reasons that I was, we're so excited to, to talk to you today, um, is because recently Sentry made a lot of news in the open source world, generally, um, with the introduction of a brand new license.

I think that's kind of, you know, the, the meat and potatoes that we wanted to get into today. And so maybe we can just kick it off with, if you want to just start by, you know, just. Really quick summary for those that don't know about what the FSL is. And then we can, you know, dive into more discussion for those that are more familiar.

So I'll go ahead and bring up on our screen share. If we want to bring it in at some point, uh, this is the homepage for the FSL. So FSL. software, um, is where you can learn more about this. The FSL stands for functional source license. And it's a mostly permissive non compete license that converts to Apache or MIT after two years.

So the goal with this license is really to balance user freedom and developer sustainability. With open source and kind of pure open source licenses. The chief value is freedom, software freedom, user freedom for software. And what we've learned over the years is that that value can sometimes be in tension with developer sustainability.

So our goal with the FSL is to put out a license that says, Hey, we love open source. We use open source. We breathe open source. You know, again, we can get into some of the history, but Century started life as an open source side project and lived that way for years before we started building a company around it.

Um, yeah, so the FSL is kind of our attempt to, um, start to, uh, there's been a lot of attempts at this to kind of balance user freedom and developer sustainability. Um, you know, this is, this is kind of our, what, our offer or our attempt at this. Um, yeah, maybe, I don't know, the immediate predecessor to this is the business source license.

Um, I don't know if that's where you want to go next, but in terms of the FSL, uh, yeah, the functional source license. Uh, and it, uh, it's designed to balance user freedom and developer sustainability. Yeah, let's 

go back because you mentioned this and I want to kind of walk through the timeline. So, you know, um, Century started off as a BSD project.

Well, if you want the timeline, we actually, cause I did this history. I'm going to, uh, you can decide if you want this on the screen share or not, but I got to dig back in and find the details because it's great. Open source values. Here's his blog post about open source values. And here it is. David Kramer first published Century in 2008 as a non commercial public licenseless side project.

So when he first published it, there was no license on it, you know, it was sort of this era of like freewheeling. Here's like the first era of kind of open source pioneers, um, has, is, is sort of like, um, you know, further along in their career, there's like the second generation is coming along that doesn't maybe have.

Um, all of the, uh, immediate knowledge of kind of the licensing battles that we went through with Microsoft in the late, very late 90s and things like this. And, you know, it's the era of GitHub just getting started. 2008 is very early GitHub. And, uh, you know, there's this concept of like, uh, what is it called?

I'm going to click through on this. To remind myself. Oh, yeah. Post open source software, F the license and governance, just commit to GitHub. This kind of like freewheeling, you know, just put the code out there. We're, you know, we're, like, I don't have time to think about licensing. I'm hacking too much, you know, just like putting code out there.

So that's really where Sentry started. It was just, you know, of course I'm going to post the code up there, because that's what we do. It wasn't until a year later that, you know, projects started to get some traction. That's when David put BSD license on it, yes. Um, so it's BSD, BSD for years, um, and then, uh, you know, again, as a side project, then the timeline is 2012, started to commercialize, so 2008, 70 line Django plugin, you know, license list, 2009 BSD, 2012, uh, Heroku plugin.

Okay, remember Heroku? Uh, Yehuda Katz is bringing Heroku back, I just learned, which I'm excited about. Um, but, uh, yeah, so Heroku plugin, 2012. Um, first, kind of, uh, testing the waters of commercialization. 2015, so another three years before, uh, David and Chris, our two co founders, uh, raised some, uh, some seed money and some venture capital and, and started hiring folks.

Um, so that was 2015. Yeah, and so it's been. Uh, kind of a, you know, the, uh, more traditional kind of startup, uh, story since that. Okay. 

And it was 2019 that, um, the company shifted to the BSL. Yes, correct. And so what was kind of the motivation for that? Like at the time. Um, BSL, uh, had just started to kind of like, you know, come out.

MariaDB really is, was the driver around BSL. Um, you know, we saw other folks kind of like follow suit. Mongo did their SSPL shortly thereafter. I mean, there was a lot of movement around the different licenses, but from a sentry perspective, what kind of drove you all? To go from that, uh, BSD kind of license to BSL, 

you know, so I should, um, caveat here.

I've been at century for a little over 3 years. So I was not around, uh, specifically for this. Um, but yeah, I can definitely speak to it. So, yeah, so 2019 then, right? We relicensed from BSD to BSL. Maybe, you know, if viewers, listeners are maybe a little bit on kinda the details of the BSL might be helpful.

It's, um, it's what we call an eventual open source license. So the, the core idea of the BSL is, Hey, I put this code out here and in four years this code is going to be, um, Apache two, or MIT or some OSD approved license. Until then, you can do everything you want with it, except compete with me. Okay, because I'm the producer of the software, my company is the producer of the software, uh, our company.

We want to, uh, you know. Protect our, you know, viability, our ability to continue growing as a company and continue producing the software. So for four years, we get exclusive rights to commercialize the software. Uh, and then after four years, it, um, you know, one of the terms was a springing license. So it's, it's, it's not just a promise that you can renege on, but it's kind of baked in that.

Uh, you know, this is we're granting you a license that four years from now you can use this under Apache. So that's the fundamental shape of the BSL. Um, and the reason that, you know, it was compelling to Sentry is that we were starting to get big enough as a company that we were seeing other actors, other companies, uh, kind of IS up, I up, um, our product.

Uh, the Sentry product and there was nothing, you know, in the licensing preventing other companies from offering hosting for Sentry, which is how we make our money. We make our money as a, as a SAS company, uh, you know, with a BST license on Sentry's core product. You know, imagine your nearest cloud provider could offer Century as one of a number of, you know, products that exist, um, in their, in their catalog and undercut our undercut us on price because they don't have to pay for it.

They don't have to pay for the development of it. They don't have to bear, you know, it's well. Okay. Um, yes. Sorry to wrap this up. Am I answering your question, Matt? So it was really that, uh, that, that can that, that. Okay. Really existential risk to the business. You know that, like any one of these much larger players could totally eat our lunch.

Um, that that was the risk that we were looking to mitigate with BSL. 

So that was a risk the whole time, right? So I, I'm curious, um, you know, we're, we're, what was in particular going on that, like, why then? Why at that point in time versus sometime earlier? Were there very specific things that were going on that was, uh, that was causing this?

Um, or. Was this just a general conversation that was ongoing and then kind of kind of do a header, what was 

that 

like? So again, I wasn't actually, I know you weren't there at the time, but what I can share here, uh, is this link, um, to our old forum, this forms kind of read only now, but this is our discourse forum thread about the relicensing in 2019.

Um, yeah, let me bring this up. Move. And what I want to point out is, you know, a lot here on YBSL. This is what's fun. Okay, Ken C. Johnston. Hi, Sentry team. Exciting news. I'm the Director of Product Management at GitLab. Okay, and I cover our Ops section. Are we considered an APM provider for the purposes of your license?

Is our integration considered use? And then here's David, the founder of Sentry, replying, Unfortunately, that is the kind of thing we're trying to prevent. If GitLab's bundling Sentry for its customers. Who are we going, how are we going to fund, uh, who's going to fund the development of Sentry? So, I guess I'm answering your question with a specific example that's, uh, public here as a, you know, one example of a use that we were trying to prevent.

Um, I don't know. I thought that was interesting when I found this. It's like, okay, here it is, you know, here's GitLab saying, hey, we were bumbling sentry and David's saying, yeah, that's, uh, that's, that's what we're looking to have. Yeah, 

what was it? Was it that type of relationship? And then you were running into this probably more than this.

This is a good example of that, but where you've got maybe and I'll just use some numbers, you know, like, you might have 1000 customers that are paying you, but then. You know, another company like GitLab has 50, 000 that all of a sudden use Sentry and then you see nothing 

from it. Yeah, exactly. GitLab, AWS, Google, you know, like the clouds, um, cloud providers.

Yeah, that's the sort of, um, company that was, um, kind of threatening us. Now, what 

I find funny about this is, you know, like, I do hear from companies who do like, you know, hey, we've embedded, but we give back to the community and maybe they'll throw some patches out there or I've even seen some of some of them.

Like, you know, look, we donated like 10, 000 dollars. You know, like, or something to, to, to the project, you know, and it's, it's, it ends up being kind of like a very small component. That's it. Right. The overall thing. And, and it's, it's interesting to see how that's positioned. 

Yeah. So it is interesting because there's definitely cases, you know, the, the big one, the past six months was HashiCorp, right?

I mean, HashiCorp relicensed to BSL and blew up, it blew up because they had built this really vibrant community. Of, you know, value added resellers and other companies that were depending on HashiCorp products, uh, you know, so there was a sense of betrayal, right? There's a sense of a rug pull, like, hey, you built, you built this, like, bonafide open source community, you know, or this open source community, like, uh, you know, trusted you, right?

These folks trusted you and now you've changed. Now you've switched. Um, so there's a sense of betrayal and. Yeah. Yeah, I guess one message I want to get out there. It's like, it's not one size fits all. So Sentry is not HashiCorp. And I actually, uh, I do want to bring this up. It was really interesting when I went and I looked at the numbers.

Um, so this on the screen share now is, um, maybe not the best chart, but it, bear with me. Um, this is some analysis I did. I went back to our main repo. It's a Django app, this monolith, Django monolith, Sentry. git sentry sentry on github, um, and did some analysis of the commit history, you know, and I took the email addresses that you get in the commit log and I mapped them to, uh, founders.

So David and Chris. Uh, second bucket there is employees or future employees, and then the third bucket is others, you know, community members trying to get a sense of because there's always anecdotally. And again, I've only been here for 3 years. So I've been, uh, you know, a customer century for much longer.

Um, there's always sort of anecdotal that. You know, Century, we've always built it ourselves, right? Um, so I went and I did the homework and it turns out that that's true. So what this is showing is it breaking down three eras. So again, as I mentioned, 2008, we started. 2015 is when we incorporated and so we could take venture capital.

Um, and then 2019 is when we relicensed, as you mentioned, to BSL. And what I wanted to see was what was the impact of those two events on our contributor community? Okay, and what this is showing then in this column others, it's showing that before we incorporated 6 percent of sentry commits came from outside of the founders or first employees.

Okay. In other words, even before we incorporated, 90 plus percent of Sentry was built by David Kramer, to be honest, David and Chris. Chris is our design founder. Okay. Then what's interesting is, okay, so two interesting things, right? So when we go from incorporation, you know, side project to business, that has a significant impact on the contributor community.

You can see that it goes from 6 percent to 3. 5%. In other words, you know, when you raise money and you have money and you can start paying people to work on the product, those people work on the product more than volunteers. And, you know, people on the Internet. Right? Um, so that's presumably you hired some of them.

I would imagine. Right? Exactly. That's my point. And that would still cut those away. Yeah, no, no, no. Actually. No, because employees here, you can see this 2. 7 percent before incorporation. So those core contributors, they were core members of the project. Right. Uh before we incorporated and they became employees so they're counted here as employees even though we're not incorporated yet Does that make sense?

Yeah. Yeah, so So it doesn't take away from that six percent. So that six percent was folks. Um, you know that didn't end up getting hired in and let's see, but then the other interesting thing is that the bsl had Pretty much no impact on, uh, outside contributions. You can see we went from 3. 5 percent of contributors between Incorporation 2015 and BSL in 2019.

So that's when we were a BSD licensed product with, you know, with a, a growing, uh, venture backed startup behind it. 3. 5 percent of our contributions came from, you know, outside the company. And since we, you know, since 2019, we were licensed. It's 3. 4 percent, right? The point is, like, that hasn't changed.

That's been consistent. Uh, so, it, first 

of all, And these are, these are the number of commits, not the number of committers. 

This, let me see, so this is commits. Commits to the Sentry monolith by relation by era. Yes, so, yes, this is the number of commits. There's 59, 60, 000 commits to Sentry of all time. Yeah, now, also, Sentry's not, like, we have our Django monolith.

We've got thousand plus repos. You know, our SDKs are a different story. That's true for a lot of companies. Um, you know, SDKs tend to be a place where you see a lot more community engagement. Um, you know, so we definitely have like, contractors and volunteers and, and community, long time community members participating there in SDKs.

And those are licensed MIT. Uh, you know, so those are, are, are, are true open source license. But what I want to, what I want to show here is that this narrative about Uh, you know, the betrayal, the rug pull, you had this community and then, you know, you're greedy venture capitalists, you like closed, you know, like you, you, you closed it off.

That's not really accurate for Sentry's case. It really is the case of like, we were always the ones that were building the software and look, if you're motivated to hack on Sentry, we want to hire you, you know, like, uh, there's, I don't know. I feel like that's, that's where this conversation gets interesting is like, how do we provision software again, going back to this idea of balancing developer, well, start with user freedom, balancing user freedom with developer sustainability.

How has this impacted the adoption? 

Like people using Sentry? Yeah, yeah, yeah. Yeah, uh, specifically the license change in 2019? Or 

even the license, the recent, I mean maybe it's too, it's too new for the recent, but yeah. Yeah, the 

recent one. Well, and I guess to, um, to connect the dots, so the FSL is really an evolution of the BSL.

The challenge with the BSL is that it has these fill in the blanks. It's parameterized. So there's this, you know, it's like, okay, you pick what you want your change date to be. Is it four years? That's the default centuries been using three years. Other companies, you know, are using longer. So that can change the license.

It converts to can change, but most importantly, what's called the acceptable use grant can change. And so every BSL is essentially. Uh, unique license because of that, because every person that adopts BSL has to write their own acceptable use grant and those vary wildly. So centuries is 

just to clarify acceptable use grants are things like anybody, but Avi press can use my software.

Correct? So, Matt, obviously, that's what you're going to put in your acceptable. I 

have it in every license 

license software. Yes. Yeah. Yes. Yes. Uh, yes. Uh, right. So point is what we were trying to do with the FSL was take the BSL. And just fix some of its worst problems. By essentially closing those holes, uh, filling in the blanks and, uh, you know, what is it?

Uh, convention or configuration or whatever, remember that old Ruby on Rails? Yeah. What, aphorism? Yeah, so VSL, right, has these variabilities. FSL is only two years. So we cut it from four to two years because we thought, you know, four years is a long time. Two years is long enough. Four years is a long time in software.

If you have four year old software, it's It's more than twice as old as two year old software, if you will. So we cut it from four to two years, but it's only two years. Then there's only two changed license options, Apache or MIT and there's no acceptable use grant. So, yeah. So FSL is an evolution of BSL.

And was this really a motivated by the purchase of, uh, code Cove, um, code Cov 

community there? Yes. Okay. So the story there then, um, right, we bought Code Cove probably about a year ago now. I think, you know, code Cove is this, uh, code coverage, uh, you know, pre-pro testing focused, uh, company. And, you know, closed source when we bought it.

Essentially, we think of ourselves as an open source company, so of course we're going to open source the thing, you know, the closed source thing we, that we bought. Um, you know, part of our company culture. And then, when we, you know, so we did a lot of work to get it ready to publish that code. When we did, we put the BSL on it.

And we put out a blog post that said, CodeCov is now open source. And we got some feedback from the community that, uh, They disagreed with us. The CodeCup, they thought, was not open source because it was under the BSL and not an OSI approved license. Okay, so we heard that feedback the next day, you know, David put up a post, uh, you know, apologizing and, uh, you know, saying we Yes, apologizing, backpedaling on that, and then that kind of, so that was late July, early August, I think August 2, August 2nd was the post, um, the CodeCub is now open source post.

That is what began, uh, kind of the, yeah, the process in earnest of, um, because FSL is really, you know, it's, it's an implementation detail. The bigger picture is. How do we balance user freedom with developer sustainability? You know, this is, we're not the first ones to have this problem. We're not going to be the last ones.

This is, and this isn't the only way that this problem manifests. Open source, by definition, is susceptible to the free rider problem. Open source says anybody can do whatever they want with this. It creates this commons. It's a, it's a, it's a public good. And

the mechanisms to fund the production of public goods primarily taxes, to be honest. Like that's the way that we fund things that are in the same bucket as open source. The second way that you fund things like that is through, uh, I mean, it's really quasi governmental where it's like you get a bunch of people together and they sort of.

Um, come up with their own, uh, agreements and social norms around funding and provisioning these things. And look, this is like well established, well outside of software. You know, there's a whole body of research on this, how to fund the commons. Governing the commons is a major bulk in this. Um, gosh, how'd I get off on that?

You were asking about FSL. We're talking about BSL. FSL. 

Talking about adoption for a while. Yeah. 

Adoption. Yeah, yeah, yeah, yeah. So we, I mean, so no, we have not, uh, certainly it's too early to, uh, to tell with FSL on adoption, um, but no, BSL is not slow to adoption for us. And actually I'll say this, um, the way that we wrote the BSL and now the FSL, we wrote our, our version of BSL and FSL, we are focused on SaaS commercialization.

So we explicitly allow for self hosted usage of Sentry. So that means all those folks that were self hosting Sentry for years before BSL continue to be able to self host Sentry. The restriction that we put on it is you can't, you know, you can't do like GitLab wanted to do or like AWS might want to do or somebody else which is offer a hosted version of Sentry, uh, you know, for a fee.

Uh, that's what we limit. So, yeah, so that, that might have been the place where adoption would have suffered. Uh, but we specifically allow for self hosting. So maybe that's a more direct answer to your question, Matt, instead of going off. Yeah, and I 

do, I think, you know, when I, when I see this, um, you know, this breakdown of how, you know, the, how much outside contribution is coming into Sentry over, over these events, I think that one thing I'd really want to know with this is, you know, what, well, A, there's a couple of things here.

So one is that, um, As the central user base grows, um, you know, how that's actually impacting. Cause you know, just because if there's a lot more users and the contribution percentage is staying flat, that actually did harm contributions kind of materially, like depending on like, you know, absolute, uh, as a portion of the code base versus how many, um, The percentage of your user base that is contributing as well, I think, is kind of another variable here.

And the other one that's the other thing that I'll say here, too, is that, um, percentage of commits also is totally up to you. Right? Like, you can accept or reject any given submission. Sure. That's fair. Um, and so it could be the case, right? That, like, maybe century had less ability to ingest a You know, prs because they're busy with other things or whatever that might look like.

And so there's so many variables here. I feel like I, I, I, I'm immediately wanting to, to ask six different follow up questions about this. 

Um, well, so to take those two, you know, this, I guess the second, first. Um, we, we certainly do not optimize for outside contributions to the Sentry Monolith. Um, again, for the SDKs, it's a different story.

And we do have some, um, yeah, some other, like, kind of, uh, generic, I'll say, projects, you know, that, that are more traditional open source projects. But, uh, for the Sentry Monolith itself, we don't optimize, certainly, for outside contributors. So like, it's a lot of work to set up a development environment for Sentry.

You know what I mean? And we do occasionally get folks that go to the trouble and give us contributions. And, uh, you know, I, we accept them, you know, as much as we can. It's generally celebrated in the company, you know, when somebody gives us an outset contribution. So, I mean, I'll let you do your own research and decide how conspiratorial we want to be about us, uh, you know, doing that to gain these numbers.

Um, but oh, sorry not 

not to imply you're gaining the numbers. I just mean that like I like I I'd be interested It's a very interesting question how it's a design 

choice, right? It's like how do you want to run your project? How do you want to run your company like? So, you know, do you want to do like HashiCorp and build this big vibrant community, you know, or do you want to like Century was very explicit from the beginning.

Like I said, David built most of Century himself for many years. And that was always kind of a design choice for the project and for the company that no, we're not really like, because here's, here's one thing I want to say, and I do want to get to your, your first point to, uh, come back to that, but, um, there's different kinds of software, a library, a left pad, or a colored JS whatever, or a log for J, right, or a larger framework, even like there's different kinds of software, lower level operating systems.

Yeah. You know, frameworks, libraries, CLI tools. Those are different than end user applications, kind of full product experiences, and what we're building with Sentry is a product it's. Uh, it's something that requires kind of a, a different level of, um, uh, what do I want to say, like attention to detail, focus on, uh, on user experience, um, you know, kind of the things that we, that we sort of like naturally accept, you know, like Gmail has a billion users, you know, Facebook has a billion users, you know what I mean?

More right? Like YouTube and the product experiences we've come to. Expect as normal from that level of software, like world class software, like, you know, we, we don't see, okay. That's what Sentry is aiming for. Like, that's, that's, that's what we're benchmarking ourselves against in terms of product development, product direction.

We're trying to build a world class software product. Okay, we're developers, so we want to do it openly, um, you know, but in terms of, uh, accepting contributions from the outside, the challenge there is like, we have a very opinionated Product direction. So even for our customers, you know, we've got what, like 80, 90, 000 plus customers, like we're building for tens of thousands of customers, like big customer comes to us and says, Hey, I need this feature to get this done.

We're like, great, get in line. You know, we're building for thousands of customers at a time, right? And so that mindset is, uh, is, is very different than again, it's design. It's like, what are you trying to do in the world? Are you trying to build a really amazing world class software product? Yeah. You know, with the business to match it, or are you trying to build a really vibrant, uh, volunteer community that, you know, maybe doesn't, like, doesn't have that economic layer in it?

Uh, there's, there's trade offs, um, 

yeah, to, to, to follow up, just to clarify, you know, and correct me if I'm wrong. What I'm hearing you say is really, you know, as, as the century was founded, Um, it was done in the open source space to get feedback, to provide people confidence in it. It really wasn't there to garner large scale contributions and collaborate.

It was more for, you know, hey, we're going to start off, this is this cool thing, and oh, let's make a business of it, and we'll do it in the open source 

space. I mean, Kramer's a hacker, man. He's like out there, you know, and again, it's like in the air. You just share your code, right? Yeah, 

and so, you know, and we've seen this with other folks, right?

So Mongo, you know, they've come out and said, we never open sourced for. The, you know, the community, we didn't want contributions, right? We did it because it was a marketing strategy. We did it because we wanted to have a, um, you know, developer adoption, right? So there were reasons for it that open source was just a means to an end, if you will.

So I'm going to go back to this open source values post that, um, I put out. This was, I started writing this the day, you know, the day of the. CodeCov kerfuffle as I've come to call it and publish it a month later. So this went through a number of drafts. So this represents kind of our settled thinking on, because one of the pieces of feedback we got from the CodeCov kerfuffle, Adam Jacob was like, Hey, why don't you guys tell us what your values are?

Because open source values are user freedom. Okay. The four freedoms, right? Like that's, that's clear and settled. Like that's the philosophy behind open source, even though it's really rooted in free software. Um, you know, why don't you are try articulating what your values actually are and then conversate conversation can proceed from there.

So that's what this post does. So this is a month after cook of, um, kind of again, long, uh, back story on the history and values. But that's where we get to balancing. User freedom and developer sustainability. So, you know, are there marketing benefits from being open source? Yes, of course. It's like the most powerful brand in the software world, right?

Uh, are there, uh, you know, adoption benefits, uh, because developers, uh, you know, can see and, and, and trust the code more? Yes, of course. You know, and what we talked about in here is there's a focus on, let me find it. Yeah, here you go. We think of freedom primarily in terms of access to technology and knowledge to improve efficiency for developers.

So, you know, this, this is where we get to like a little more altruistic, you know, like, you know, the motivations are mixed or whatever. We're a company, you know, but a company of people, um, you know, we can assume good intentions here, right? Like we're, we're developers. We want to, we want to share our code with other people and we want to see other people's code.

You know, we don't want to, you know, waste time having to reinvent wheels if we can go learn from something else without stealing a whole hog or whatever, you know what I mean? So like There is a, uh, you know, yes, you can take the cynical view that it's just marketing or something. Um, you know, but I, I would try to balance that with like, we are developers that love geeking out with other developers on stuff.

Right. 

Yeah. And I think that, you know, that, you know, I, I don't have a problem with your, you licensing or any company licensing on something that is, you know, towards their values. I think where the open source community tends to get more. Um, uh, not necessarily even upset or more passionate is one of the tenants has always been around open source, um, non discrimination that's like one of the core tenants and we've had many guests on here.

Yeah, yeah, yeah, we've had many guests on the podcast where that comes up because we've talked about the BSL before we've talked about the SSPL probably like, geez, a dozen times, at least right now, half of the episodes, half the episodes, probably, you know, I'll have talked about this. And when we talk with the folks who, you know, are from either the OSI or from that community.

It's really about that one that they're like, Hey, we don't care if, if you're SSPL or BSL, we just care that you call that open source because it violates that. And, you know, it's a good point because. Um, we've had some discussions with folks who have been part of early discussions before some of these licenses were launched.

And, um, we've had people who have developed the original licenses and were part of OSI who have come out and said, you know, like, you know, yeah, you know, this is a great license, whatever, but just don't call it open. And I think where this really started to get a hot button was with Elastic, right? Yeah. So when Elastic made the change.

Their, their whole thing was maybe a little similar to maybe the, the faux pas with, you know, calling it open source, um, when, when, you know, code cov, but Alaska came out and said, we're doubling down on open. Yeah. Yeah. And so everyone just went, what the heck is that? Right. You know, like, you know, and I think that that was probably the lightning rod for a lot of that controversy.

Yeah. Um, and, and I think that that's just something that. You know, a lot of passionate developers who have invested a lot of time, money and resources into open source and who, who bleed open source through and through. They look at this and they're like, you know, yeah, um, that, that, that, that is what I believe in.

Yeah, the, I think the frame of reference with some of the stuff is also really important too, where, you know, if you say we're gonna, you know, um, we're really committed to this very particular thing and we're going to take one step to the right of it, um, you know, saying that we're doubling down on that thing, open source versus we were having to make a decision between moving to a fully closed source proprietary thing.

And this was the best set of compromises that we came up with. Um. The exact same action, very different framing. Um, and I think, you know, would probably be received very different. And I think the way that, yeah, the, the, the marketing and the, the messaging around these kinds of changes are just so crucially, crucially important.

Um, I'm curious. So, you know, with, with this initiative to roll out this new license, is it your goal to have other companies in the space adopt this license as well? 

Are you? Yeah, a hundred percent. We, um, so we have one other product already answer overflow, shout out, answer, overflow, adopted the FSL, you know, in the first week or whatever, after we announced it, I think it's been, it was December 21st.

They were recording this call. FSL was announced November 17th. If I remember right, it's been about a month. Um, you know, we get into the holidays and slow down here, but yeah, that's definitely, uh, something that we'll be working, that I'll be working on next year is, um, yeah, spreading the word and, and talking to folks for whom it's a good fit.

It's not the right fit for everybody. Um, it's really designed for SaaS companies that have an open source affinity or whatever we want to say, you know, that want to like, cause you're absolutely right about the framing of it. It's like, you know. Again, Gmail is not open source. YouTube's not open source.

Facebook is not open source. They're not even source available, right? And like, we're not talking about that. You know, nobody's like, hey, why isn't, you know, hey Google, why isn't Google search, you know, open source? It's like, what, it, it, I think that's, you're right about the framing, but like, why are companies like Century and Elastic In a sense, getting punished for trying to do something that's, uh, I think better than what we see, you know, from, uh, you know, from, from companies that are, or maybe not.

I don't know. Maybe we don't care. But I think the point is like. We haven't seen, you know, to date, open source is Linux. It's Apache web server. You know, it's like, it's these lower level projects, like name, name, an end user product that anybody that's not in tech knows about and uses and has on their phone, that's truly open source.

I mean, it's 

a matter of framing or sorry, a matter of expectations, right? Like Google makes no, they don't, they don't talk about open source. So no one's up in arms. Then you have to get back into the, 

why do we care about open source in the first place? Right. Why do we care about open source? Like what are, and this was actually, um.

You know, part of this values post, it's like all of the philosophical background for open source comes from Richard Stallman from Free Software Foundation. You know, I did this whole analysis where I went and looked at the 200 plus articles under slash philosophy, under NewOrg slash philosophy. And, you know, and, and like read all those articles and analyze them.

There's nothing on open source org that's like, here's the why behind open source, you know? So. I think some of the, if I want to push back on this a little bit, it feels like, obviously, yes, there is a very passionate. Community of folks that, you know, see the definition of the open source definition that see the free, you know, the free software, uh, you know, for freedoms and if a license doesn't meet that, you know, push back on the use of that term.

Okay, you know, and now with CodeCov, like, again, we apologize the next day and we're, uh, trying to be good faith participants in this conversation. At the same time, like, why, why do we care so much about those definitions and what's the downside? And that's where we get into the developer sustainability thing, right?

Like, there's a sustainability crisis in open source, you know, this is log4j, this is Heartbleed, this is the, you know, xkcd, whatever the number is with the one guy in Nebraska, you know, like, this is Roads and Bridges report, uh, you know, there's There's different parts of the community. There's companies that commercialize open source.

There's non commercial open source projects that don't want money. I mean, this is like the DHH rails thing. He's like, I want to keep them separate. Like, don't bring money into open source. So there's that component, but then there's this significant component in the middle, which is, we need to come up with the right word for it, but like sponsorable.

You 

know what I mean? Yeah. And I, and I, and again, I'm, I'm, I'm not trying to pick on you, Chad. Please don't feel like we are here to pick on you. Chad, we are not 

corporate. Venture backed. Yeah. 

Yeah. No, no, no. Here's my, my philosophy is that, you know, open source has become. You know, kind of ubiquitous with a lot of software development, because there's a lot of great stuff about it, but it is not necessarily for every project and as you're saying with, with, you know, SAS projects, a lot of the open source stuff wasn't designed even with that as a, as in my business, it exists, didn't exist, you know?

And so as we start to look at, Hey, we want to take. These five things, and we want to invent something new. And that's why I do really appreciate you coming out and saying like, you know, Hey, we, we heard this comment from, uh, what was it? The founder of chef. Right. Um, you know, who was like, you know, yeah, call it yourself on your own values.

And I think that's beautiful. Right. Because what it does is it says like, yeah, we do value. This stuff, but we recognize that this 1 tenant is causing us, you know, it's, it's preventing us from, um, you know, creating a commercially viable product and building a sustainable 

ecosystem. Here's a ticket. Yeah.

Sorry. Yeah. 

Yeah. Um, and I think that that is, that is a, a fine way to do it. Right? Um, I do 

this ticket here that I've got up on the screen is in our repo for FSL software. Um, and this is before we launched Dan here. Dan Brown came in and asked explicitly this question. How will open source be used or framed relative to this license or plan?

So, you know, whereas with CodeCov, we got this feedback after the fact. One of the wonderful things about FSL is we had this conversation before we launched FSL. So we actually went back and forth in this thread, uh, you know, and Jordan Harbans in here, and like we went back and forth and we reached an agreeable conclusion so that the FSL website, you know, really only mentions open source very briefly, um, just to say, you know, kind of distinguish ourselves from it, right?

So. I think we're still, I see this as kind of the beginning of a conversation, the beginning of hopefully the convergence of a conversation. Cause I think one of the things we're seeing is like, like you said, Elastic, Maria, MongoDB, like we're not the first ones. And honestly, you can go way back. Do you remember the shared source initiative?

Yeah. Yeah. From Microsoft, right? Like two years after open source came out, Microsoft came out with the shared source initiative. Which, you know, this, I don't think they've updated the website since, uh, it's, it's very old, but it's still there, like, and this is, in some ways, wrestling with the same sort of things, like, how do you have companies that have a need to make money, which comes from scarcity, which comes from restriction, which comes from discriminating, to use that term, the technical term from, from the definition, you know, how do you balance that with user freedom?

So it's been an ongoing conversation, the whole life of open source, and I think, Our ideal at Sentry would be to see some convergence around some practical, uh, answers, like the license proliferation that we've seen, you know, certainly, you know, it kind of like parallels what we saw in free software and open source, like you had this.

Uh, you have this license proliferation, but then the community kind of settles on a handful of, you know, half dozen, uh, licenses that are kind of the main ones that we see in open source. Our expectation and kind of what we're sort of, uh, looking for is like, can we find that same, like, well, here's two or three, um, you know, and again, we need to find the name for it because source available is too broad, uh, but two or three kind of source available non compete licenses.

Um, that fit under this sustainable source brand or whatever going to come up, um, you know, that people can know what it means and know what it stands for and know what to expect. Um, and then, you know, I do want to slip in this plug because being a successful company that does value the wider open source community.

It's very important to us to fund that component in the middle of non commercial projects that want to be sponsored, okay? So you got the commercial projects like Sentry, you've got the, uh, you know, non commercial projects that don't want any money. But then there is a significant number of developers that are putting open source out there.

Their open source libraries and whatnot are getting picked up by companies that make a lot of money off of them. And yeah, at Sentry we firmly believe in Funding, giving money to the open source maintainers that want it. Uh, and we think that's an important kind of corollary. Like, it, it goes hand in hand like we think about it, uh, you know, think about it.

And you, and you've done a lot 

of funding in that space, right? Dude, 

let's do it. Yeah. So, um, lemme go here. Uh, we just, yeah. So that was last year. Um, yeah. So here's our blog post from a few months ago. This is like a month before. The FSL went out, so we gave a half million dollars last year to open source maintainers, which for a company Century size is significant.

This is 3, 700 per engineer at Century for the year. Um, you know, it's, that'll be a, a different episode. We can go down that rabbit hole, but I did want to kind of, um, yeah, for us, we think about, it's all under this heading of sustainability, right? The FSL license. is our tool that we use to maintain our sustainability ourselves.

And because we're a successful business, we're able to turn around and give money voluntarily to that portion of the open source community. And this is, this is where I push back on like, well just don't call it open source. It's like, we're part of the open source community. We're, it's one community. And so, like, why is, you know, one of the things we talk about internally and get frustrated at is, like, why is a company like GitLab or whatever OpenCore, like, why is OpenCore considered more legitimate than what we're doing, you know, like, you're, you're sharing less, but, you know, it, because it feels like it's this nitpicky technicality that it's like, well, but they didn't use the license and they didn't call it, but it's like, you're, There's a bigger picture here, which is that we're all humans trying to do stuff together and we should take care of each other.

And one of the ways that works is we charge you for our product and you give us money. Okay. And we give you a good product. But then that's, excuse me, I'm hitting my mic. Getting so excited. That enables a turnaround. 

Get out! Get out here. 

No, but like for us, like, Yeah, like we love all these open source developers that are building all this stuff, but we think it sucks that they're not funded, right?

Like, and, and it just, it doesn't feel right to us that, like, That that that it's like, well, don't call yourselves open source. It's like, well, actually, we want to be part of the open source community, like us giving money to open source, like, technically open source free software, you know, like, us giving money to that is part of our open source commitment.

I don't know. Let me yeah, 

so I want to address because, you know, you mentioned, you know, why I was open court different. Let me, let me, um, Give you my two cents on that because I think that that's, that's a good differentiator. Um, it's dual licensed. That's really where it boils down to is, you know, you want this set of features.

You want this piece of software that is open core. It is not open source, like, yes, that's 

less open source than. 

But there is, there is a pure open source version that you can go do those things with MySQL. I used to work at MySQL, just an FYI. So, so, you know, Hey, enterprise version, non enterprise version.

Guess what? Amazon uses the non enterprise version. You know, they, everybody uses MySQL non enterprise version, but there is an enterprise licensed version that has other stuff or, you know, things that you can't get in the open source space. Um, and I think that that is. You know, you could say, yeah, it's not different than what you're doing.

And I would agree with that because what you're saying is, you know, Hey, there's this restriction here, but that restriction is in that kind of like dual license side where it's like this subset of things. Is not licensed in the open this subset is and so this subset is free. 

And that's where 

so we're saying we're more open source than open core companies.

We're saying we're more open source than GPL software because GPL has its own. Like, you can argue GPL is putting its own restrictions on and I would, but the main point I want to make is like, open source is bigger than licensing. Open source is people and there's a huge. Chunk of people in the community is saying, Hey, I could really use a few bucks from you guys that are making billions of dollars off of the software that I wrote, and we think that matters.

And we think that's part of the open source conversation. And it's, it's, if we only focus on the technicalities of the licensing to the exclusion of that, then we're not talking about the full picture of open source. Okay. 

Yeah, no, I mean, I think I, I think that's a very great point. And one thing that I've, you know, I've said on this podcast before is that I feel like we need to have better ways of talking about kind of the nuanced differences between kind of the very strict criteria that.

We've, you know, set out with the OSD versus things that deviate from it in, you know, many different dimensions to many different degrees. And so, um, one thing to tie back to something earlier that you said with that is that it does feel sometimes that we. In the open source community do like penalize exploration within that, that, you know, like, um, I would much rather a company try to commit to pure, pure open source than find that doesn't work and try to find the right compromises versus just start out assuming that it's going to fail and you just go for something fully proprietary.

And so, um, I feel like I, yeah, I would want to say that I just, yeah, I very much commend that effort of trying to. You know, do that exploration, try things and see how people are going to react. And hopefully we will land at something that, you know, finds the right set of compromises here that people are happy with and, you know, finds the right, um, you know, path forward for all of these companies.

So, um, that's, that's where my two cents on this stuff comes in. Yeah. 

Thank you. I started doing open source in 2001. So, you know, a couple of years after the, the terms coined. You know, so I've certainly spent my career in open source thinking of myself as working in open source, putting out open source software.

Um, and it, it, it doesn't sit entirely right with me to go start a thing over here that's like, okay, so now I'm not open source anymore. Like I, I want, I want to, I want to, I want to hold off on that a little bit and be like, isn't there some way that we could have like. Open source blank, or some like, you know, open source, something, here's something we talk about the concept it's bandied about the concept of an open source company.

Okay, like, what if there was some definition that, you know, arose in the community that like worked its way through that was like, here are the criterion you need to meet to be an open source company. And like, what if, like, a handful of licenses like the FSL were part of that. And also some commitment, some like pledge to giving, uh, to sharing money back to, uh, you know, those non commercial projects and like that, like, is it like, does it need to be a hard fork here?

I guess that's what I'm saying. Like, is it a hard fork between the open source community and the, like, the sustainable source community or whatever? Like, what? I 

hope not the relationship. I hope not. Yeah. Yeah. But well, and so 

this is where I mean, like, quite honestly, I think we get so worked up. About the term, um, or the descriptor that we feel like it is incredibly important to have it.

No matter what we're doing, because it reflects on, like, what we're comfortable with as, you know, and I'm not just saying, you know, chat. I'm not picking on you. I'm saying as a community as a whole, there are projects and stuff where we, you know, we, we, we look at the term open source and there really isn't an.

Open source company. It's their companies that do open source, right? You know that and I can guarantee you chat, even if you use the FSL, you, you are as a company at century are doing open source. You contribute to other projects you. You know, work on, you know, things that are in the open source space. I'm guessing some of your SDKs probably aren't FSL.

They're probably open. 

Yeah, the SDKs are all MIT. We've got Symbolicator. Right? So, 

so you are working on and developing open source, right? And it's the same thing when you talk about Mongo, when you talk about. You know, Maria, there are the, you know, it's not an open source company and because why 

not? Why not?

What is an open source company? What's the definition? Many. There are zero. Yes. Why side here? Why not? There are zero. 

Why you commercialize open source 

if you, you are commercial guys, companies who 

wanna do open source. Right? You know, you know, like, it's a, it's a term that we'd like to apply because it's buzzworthy.

Yeah. 

It has a very particular meaning here. Like if you commercialize open source, if you do a lot of open 

source. company that does open source. But it's 

much easier to say open source company. Yeah, 

you might be easier. You might want to, but I'm just saying, like, I think you're just saying what you're 

saying, what it's wrong.

It's wrong. We're not, there's a definition of open source company. We don't fit it. Words. Maybe you wanted to mean, you know, like we can, if we want, if we want there to be a thing 

called open 

source, we can have a business model. Okay. We'll show me 

some. Okay. Like, it's like, it's like me saying like, you know, like, okay, if I've got one product that's open source and everything else is proprietary.

I'm not an open source company, you know, I'm a company that does open source and that's cool. I mean, there's not a problem with that. Right. I mean, you know, you look at Google and we picked on Google earlier. Google is, is one of the bigger contributors to the open source space. They have more open source projects than most other companies.

Are they an open source company? Why not? 

I don't know. I'm not sure. They're not because they're, first of 

all, because they're They write more code than I've ever written and more code in the open source space than any other company I've been associated with. Because their 

core products are not under open source adjacent licenses and because their contribution their financial contribution to their dependencies doesn't meet a certain threshold.

That would be my answer to why not. I would 

imagine that they do. I would imagine that they contribute a lot. Microsoft as well. Like you could make that argument now. Look, 

um, with all due respect to my friends at Microsoft and Google, Google's number for last year, am I going to say this live? It's probably information.

If you want, we can cut it out. 5. 7 million. They gave 5. 7 million to open source projects last year. Okay. Divide that by the number of developers at Google. Right, which is like 25 to 50, 000. I don't know what they're at But it comes out to like, well, what's the math? It's like, it's, it's, uh, 

but go and Kubernetes and all these things like now that 

should be now that's separate, right?

That's them. And that needs to be accounted for. Absolutely. And same with Microsoft. It's like the projects that you're putting out there. But again, this is what. I think that we need here, I think that it's worth doing the hard work of getting into these details of what are the things that matter, the financial, the money that you donate, the, the time, the, the, the, the time, the FTEs, right?

Like the, the developer time that you put on projects. Um, et cetera, et cetera. Right. Like, and, and the licensing of your own, those are really be the three, right? Yeah. Time, money, and licensing of your core products. I think core products is crucial core products. If you're going to be an open source company, like your core product has to be under.

And this is where, and this is why we haven't had to worry about this because like Linux hasn't been anybody's core product. Okay, that's false. But it hasn't been like one company's core product in the sense that Sentry is Sentry's core product. There's, um, there was a GitHub blog, I forget the name of the person who wrote it.

That use the term single source, a single source product or a single source project that, you know, basically controlled by one company. So Sentry is an example of this, um, but yeah, okay. So I think it's worth getting into these details. I don't know how long you guys have today. We're 

well, I can, I can keep going a little bit longer, Matt, if you can, but 

wind this down and yeah, 

so we do have to go.

I mean, you know, so, so, you know, what we've decided is I'm right. Right. Um, so, uh, yeah, always. 

Yeah. I mean, it's in the acceptable use grant. Yes, it's exactly my license. We signed up. Yeah. 

It's in my license. Uh, no, no. And Chad, you know, like I've actually given a few talks on this because I understand the funding problem.

Um, and I, and I gave a talk just, um, at the, uh, uh, what is it community over code conference, which is the former badgee conference about, you know, sustainability and. Why asking for money shouldn't make open source people feel slimy. So if you go check out, I think it's on YouTube or archive. org or whatever.

Um, but, uh, you know, there are a lot of companies who, um, do struggle and a lot of projects that do struggle. Um, to make ends meet and, um, you know, there has to be ways that they can work. Um, you know, within the confines of, you know, the current ecosystem and I'm all for, you know, new licenses, new business models, new things that we explore.

I think that the SAS, you know, model has really revolutionized quite a bit. Um, and I think it's something that is going to continue to change how we think about software and you know, how software's consumed. So, I mean, there's going to be changes in the next few years and there has to be, because there's so many projects out there that do need funding to.

Survive and continue. 

All right. So my homework for next time is to watch that. Watch the talk. 

Yeah. Yeah, we'll have to I will definitely have to have you back on because I feel like there's a whole lot that we could get into that. We did. We could, you know, go for hours. I think but you know, I think one thing that.

That, you know, really sticks out to me with this conversation. Um, it is my hope in the open source community that when we, you know, when we're looking at trying to improve, you know, various things across the board, that we really start to highlight more where we agree than where we disagree. And I think that in these conversations with, with, you know, source, uh, open source adjacent licenses, we really focus on the differences quite a bit where I think.

We there's a lot more that we all agree on than what we disagree on. And so, yeah, that's my ask for the open source community when we start to talk about this particular topic. And, uh, I hope that, you know, all this, these efforts with the FSL continue to, um. I don't know, lead to more fruitful discussions and healthier companies and healthier projects.

Plus one. Thank you. 

Well, with that, let us wrap up. Chad, thank you for coming on. We hope that you don't feel too upset about getting beat up, um, you know, and having a browsing debate, which is what we love to do in 

the open source community. Yeah, no, that was great. Thanks so much. Glad we could do this way easier to do this here than, uh, Other other channels and social media and whatnot.

So good talking to you guys. All 

right. We appreciate you hanging out Don't forget everybody like subscribe follow us on all of the socials