Transcript: Sentry - David Cramer

I'm Will Vincent, joined by Carlton Gibson.

Hi, Carlton.

Welcome, David.

It's a real honor.

We want to talk about Sentry, a lot of new products coming out.

Maybe for those, you know, given our the our listeners, we have a couple thousand, and some of those I think are well familiar with you, but for those who aren't, what's the quick story of how you got into programming and Django, and then we'll go from there?

So I've been around for a long time.

So I got my start with PHP like a lot of folks.

Uh and I don't know exactly what the trigger was, but at some point I was interested in doing other things, uh, like learning more things or learning, I guess, how to level up something along those lines.

And Rails was hot at the time and and Django seemed kind of interesting.

And and I had actually briefly looked at Python before that, and I'm just like, what do you do with this?

Uh without the web framework.

It did not seem overly useful back in the day.

Um, but it was easy to learn, which is one of the big things in my career.

Um yeah, so I got started in Django like 0.95-ish, somewhere around those time frames, and just kind of been growing with it ever since.

And do you remember?

You know these days I do a little bit of less, but uh I think honestly, I was just looking.

I'm like, oh, we should build, like we should use a new tech, like a better technology versus this random hodgepodge of PHP.

And I was exploring Rails, and I'm like, okay, what else?

And I I I have this vivid memory of just seeing like a video demo of you could put the comments template tag in there, uh, and it just like all of a sudden you had comments.

I'm like, oh, that's cool, you know.

Um and that was like that was like a revolutionary idea, I feel like at the time.

These days it's kind of silly, but you know, at the time that like just made the idea of many different things a lot easier.

And you know, then I compared Rails versus Django, and I'm like, well, I have no idea how this RubyTane works.

So yeah,

I mean um and then did you have a formal background in computer science, or how did you get into just programming in general?

Um, and so I'm self-taught.

Uh you know, I'm uh both a high school and a college dropout, which means I eventually fixed the high school thing, but then college was also uninteresting.

Um and I guess I got lucky along the way where you know my passion sort of aligned with something that pays fairly well these days.

Uh and I was uh a very much uh your like typical teenager who's into video games and whatnot.

And that kind of aligned well with World of Warcraft, which was coming out at the time, and I was just clever enough at reverse engineering uh the data structures in the games.

And so like with the early part of my career started with like reverse engineer video game, create like web database out of it, and then you know, one thing led to another that led to like you know one job and then another job, and then eventually made my way out to the Bay Area to work for uh what I would describe as more real companies.

Well, that makes three of us who are self-taught, so you're in good company.

Uh though Carlton went all the way to a PhD and I'm somewhere in between.

Like I mean, so I mean do you I mean uh do you I mean clearly you you don't need um that computer science pack.

I mean what's your sort of thought?

It uh you know, you people people get I mean I I still 20 years in get this sort of oh I didn't get CS sort of insecurity.

What you know Yeah.

Um I I I don't know, I felt a certain way a certain for a certain period of time in life where I'm like, yeah, it doesn't really matter at all.

And then I spent a couple years at Dropbox and they're all like 4-0 MIT grads.

It's like a lot of super smart people.

Doesn't nearly doesn't necessarily mean like everybody's more effective, but when there's actual like what you might call engineering work to be done, um, they've got a lot more knowledge to solve the problems.

And what I mean by that is I was trying to solve some like graph traversal problem, and I'm like, I have no idea how to do that.

And so I valued it in those things.

And I I don't think it matters all the time.

Like if you're just building like a login form, who cares?

But when it does matter, it helps a lot.

And I think you know, I I have a personal um take on this, but I I do think there's a gap in the industry now because there's been so much like everybody wants to get into tech, but then nobody can do like the actual engineering work, only like the simple web stuff, which you know, suffice to say, creates a lot of challenges when you know there's a lot of like infrastructure kinds of problems or systems or distributed systems, um, and just nobody has the experience or uh even academics like to kind of know what to do.

And so we'll see.

But I so I think it still has its place, but I also think if you're determined, it's not super relevant.

But it is helpful to go, oh actually, I remember seeing that there's a this this answer, and then you can go and look it up, which kind of I think that is

I'll just like I'll be able to come up with like a solution to a problem, but I there's like certainly like a formal name around it or something, and I would never know what it is.

Like it is actually like kind of embarrassingly, I spent less than six months in college, and in that time is when I actually finally learned what binary actually was and what hex actually was.

Before that, I just like I think I just guessed, or I don't even know what it was, but I couldn't quite grasp what was going on, and I'm like, oh, this was useful.

And I learned how like CPUs work, and I'm like, oh, that's kind of useful knowledge uh to understand because all of a sudden, okay, I I took that and now I understand what a pipeline is, like from a from a terminology point of view.

And so I I think it's just getting people with this like the same vocabulary actually massively helps, but you know, the I I don't think a lot of CS programs are that useful to compare.

The Indian mathematician who like did create everything on his own and kind of did a couple hundred years and then at some point got up to the 20th century.

Yeah.

That's how you should pitch it.

Anyways, yeah.

Well, I'm just thinking back to my startup experience when I was in San Francisco ten years ago and everyone was at MIT Stanford, and it was exactly that.

They may not know how to build a static site, but they all off-the-shelf algorithm stuff.

And um I certainly think there's nothing wrong with it.

Yeah, I think you also you get this sense of uh programming outside of a particular language when you're self-taught, a lot of times you go a couple years in one language and then it's harder to make that shift.

But most CS programs, you know, you're touching a bunch of languages, so you abstract away a little bit, which is frustrating if you want to actually do something, but from a pure learning standpoint, I do think it probably makes it easier to just pick up a language.

So I mean, like to your point of and video games, I mean, I have little kids and these days, you know, Minecraft and kids are like, I want to learn Java.

I'm like, Java, and it's like, oh, Minecraft.

And it's like, oh man, like I wish there was a Python Minecraft, you know, because kids are like, Why would I learn Python?

I want to build Minecraft.

Yeah.

Yeah, I I I think that's interesting.

Um, but with the technical approach, which I think is super interesting for the next generation, because otherwise, like you've got to learn this somewhere, right?

And yeah, you'll learn theory and stuff and in college programs, but like the practical application of things doesn't really exist.

And like we always bias around co-op universities like Waterloo and whatnot, just because those programs where it's like constant internships combined with sort of that CS theory, that's like the best of both worlds.

And I just think that like you need the practical application, like in middle school and high school kind of age range, um, grade six through 12.

And you get that, and then you combine it with some theory, you're you're great.

Like you can solve a lot of problems at that point.

Um, and to me, that's the gap.

You just need you need that diversity of skill versus, you know, there was like this trend of boot camps, and and it's like they don't actually teach you that much.

It's like cool, you can build an HTML form, but like that that doesn't get you actually that far into solving problems.

And so you can be determined and go from there, but I think the gap is you still have to be determined and have to like spend a lot of time like self-learning um to really kind of get over that barrier.

And I agree on like the multiple languages saying it's like one of my biggest struggles is like whenever I try to pick up something similar to Rust, where it's like here's all the academia thrown at you all at once, and I'm like, this is hell.

Just like bring back something simple, you know.

This is like your bedtime video.

Um but it yeah, I mean the thing with learning a new language is unless you're using it um on a particular project, it's kind of slow, it's like a a kind of back burner, you know.

Okay, a little bit here, a little bit there, a little bit there, and you know, I've been uh twinkering away at it for a year or so, and yeah, I'm about the point where I'm like, yeah, I'm comfortable here.

I can just but it's taken that long because I'm not thrown into the you've got to get this program working, and you know there's a sort of deadline there.

Yeah, I don't know.

Like I I don't want to have you repeat the same thing you probably have to repeat on most podcasts.

Sentry started as a uh as a Django set, I believe.

Is that correct?

Like, what's the what's the quick history rather than making the rest of the podcast about what uh Sentry is?

Because we want to talk about the cool details of it.

And that seemed super useful.

And so over time, through like sort of open source and community and all this, like I expanded that further to be sort of abstract of Django, like breaking it out and going from there.

And it was always just like, how do I make my job uh easier and more satisfying?

Like it's not fun when you're sitting here trying to like reproduce a bug and you've just got no details.

And so there's just lots of times in life where I just didn't have access to the right information, and and I would always build things to try to solve for those problems.

And um Sentry is one of those many things, and uh it's also probably the one that's been the most successful at this point, uh, clearly.

But uh, but yeah, and these days we do a lot more, but mostly focused on those developer kind of how do I debug production code problems.

Like is what's what sort of number do you reach for in terms of you know showing up into the right growth?

Because I just think of Century as everywhere.

Yeah but like how do you all internally think about the growth?

Um part of that's we just acquired Code Cubs, so there's a a kind of a spike in growth.

Um but uh yeah, I think when I thought about building Sentry, I mean I just like building software, so it's like cool, successful, that's awesome.

But like for me, it was like I just like doing this thing, so if I have to build a business around this thing, I'm gonna do it the way I want.

And so the the key thing out of that was I wanted all of my peers to use the thing I built because it makes it much more satisfying.

And you can get feedback and like like the hallway tracks at conferences are always fun to talk shop, you know, right?

I want to be able to talk shop all the time in life and not feel guilty.

That that's basically what I optimize for.

And so that's in our company values, we actually have this written in that it's like we are not an enterprise company, we're very market share focused, which means you treat a lot of things differently.

And so for us, I don't I don't know what the customer count these is today, or these days is rather, uh, but I do know we have somewhere around 50,000 uh people who pay for our SaaS service.

And and by people I mean organizations like companies, which to me is like awesome.

Uh, and and we achieve that by charging like a fair price and all these other decisions along the way, but it's awesome because like that is like bigger than most companies in the world that try to sell like enterprise software.

And I don't know.

So when I think about growth and I think about goals, it's just like there's still a lot more to do.

And that's why we do a lot more than Django these days.

It's like how do we like kind of service and help more developers and more like different kinds of software?

And so I think a lot of a lot of um things to solve within that, yeah.

But that that's the main way we focus on where we're going.

So it's not your typical like business, what are our goals or what's our growth, you know, kind of thing.

It's just like build it as it makes sense uh and optimize for uh becoming the most successful thing we can be, but from a mind share, not just a dollars and cents point of view.

Um I because the I've used Century for years and years and years, and I've always had this exact same thing.

It's that it's it's open source, right?

So I could download it, I could put it on my server, I could run it myself.

And I've never once done that because the the pricing is just so fair, and you know, it's it you don't a lot of things you feel gouged by.

I've never felt gouged by sentries.

I've always just been like, no, I'll just pay for it because and every client I've ever had, I'm like, just pay it, save that like the you know, you're gonna save that in the first week from the speed of speed of triage or speed of you know, you're just gonna get more information out of it, and it's not worth the effort to s to run it yourself.

So perhaps can you talk to that?

Because I I just think you've out of all the companies I can think of, you've pitched it just perfectly in in that balance of, yeah, you could run it yourself, but why on earth would you?

Yeah.

And I install Sentry right away because I feel like I'm handicapped without it now.

Like I actually like I just don't even pay attention to like QA.

I just assume that if something's broken that I've missed, it will like show up.

And so, and and the actual realization of that is like Sentry actually provides us immense value from like day one of going to production, where it actually over time it saves you a lot of money because you don't need to bring in like a bunch of expensive vendors.

You can actually get away without like logging for a long period of time, like a very, very long period of time.

And logging is very expensive, or like the traditional APM stuff, you would have to buy like a new relic or something, and they're also very, very expensive.

And you don't use 99% of whatever that product's trying to give you, even if if even if that 1% is actually useful to you, right?

And that to me was like the the the great realization over time, and so we've tried to keep that in kind of in check as we grow and try to expand, and especially as we expand the business side, is like remember like the goal is like that we will expand the market, that we will have many, many customers, and so it's okay to not try to over-rotate on the cost per customer.

And so when I remember I went through this exercise, um, and you know, this is not technical, so sorry, but uh with our VC early on, and it's like, how do you build a hundred million dollars in revenue?

And I'm like, I don't know, we get lots of customers, and then we just like did the math, and it's like, okay, we need every customer to pay us like $2,500 a year.

And if you know anything about a lot of these successful companies, they're that so you that's ACV.

Their ACV is $10,000 plus, it's not $2,500.

And so we're actually approaching the business from a very different model.

And it's like, how do we just continually drive more and more value?

Not how do we charge more and more money from the exact same thing over the years, like in like I don't know, enterprise or whatever.

Because you find a lot of companies, they just grow and all they do is like they they give up on what got them started.

Like they start uh stop offering a free planner, stop offering a cheap plan, and all of a sudden everything's super expensive.

And I I don't know, I just never wanted to be in that business.

It's not as satisfying.

I mean, this is one of the questions like Carlton and I are both in our 40s, like you know, at a certain point, it's like why how do you keep doing the same thing for a long time?

And it sounds like you know, you're leading with values, which makes sense, right?

Whereas it doesn't necessarily matter you hit a certain uh growth target, though.

I mean, for investors, it's like you're serving a mission, so that makes sense that that can be longevity.

So yeah, but that's exactly the sense I have is.

Yeah, publicly tell us how you feel.

Um, but I'm invested in the outcomes and like I'm still very passionate about it.

I think the hard thing for for folks to understand is uh this concept of control.

Like, you lose a lot of ability to get the way I describe this is like if you're a builder, like you just like building software, which is who I am, at some point, very quickly, the company gets to the point where all you can do is describe what you want your like sort of painting to look like.

You're like, I want a like a horse or something.

And maybe you try to give details, but you can't paint it.

Somebody else has to, and you have to tolerate that like the horse is gonna look wildly different than you want it to look.

And that's actually like a very challenging gap for me because I still want to be in the weeds and build things.

And these days I'm I'm just not hardly at all, but I still do drive a lot of technology and architecture and sort of product strategy, which I think is what keeps it interesting.

And I think the the challenges and the sort of continued momentum uh, you know, kind of keep me going to some degree.

Like as an analogy, like I very much want to see this through to a public company, which is kind of the trajectory we're on.

And I'm just like, thanks, world.

I don't know when this is gonna happen now because it's like

Yeah, I'm like, great.

Um, because for me, that's like the big milestone.

Yeah.

And I'm like, I don't know, maybe there's a milestone after that that keeps me going.

I'm not sure.

Uh and a lot of that's with like our open source thesis in mind and how we've approached customers and like the large market share and things like that.

So that that those are like the the exciting things for me, less so than the technology things these days.

Though I I think at least more recently we're starting to do more interesting tech uh investments, which is, I guess, one of the cool things you get out of becoming a larger organization as well.

Because I always find that's an interesting take.

Uh you know, we're very kind of narrow on this podcast.

And I worry because like at the end of the day, there is a shift towards sort of this service architecture, which is abstracting the front end away from sort of the API web side of things.

And Django certainly makes it easy to build like a small project, but I never use Django anymore.

I'm always like, okay, I want to build like a rich UI.

And building a rich UI in Django is actually like quite difficult because it doesn't have a way built in to make it easy to bundle, say, like a React application or something like that.

And I don't think anybody solved this for what it's worth yet.

But almost every time I build a new project, I'm reaching for a new JavaScript-based uh approach.

And my my dream would be cool, let me write the front end in JavaScript and the back end in like Python or something, but I don't want to have to run multiple services or set up like this complicated dev environment, right?

Because like my goal is like, how do I just build the thing and like not build the dev environment?

Like, I don't want to spend all my time just getting off the ground, which I do.

It'll take me like three days to bootstrap a new project, which I hate these days.

And I I could eliminate that by like using something like Django or a Rails or something that's like more traditional, but then you just lose all of this sort of innovation that's going on with the UI frameworks and those components.

So I think Django is still good, and I especially think the ORM is still one of the best solutions out there.

But I I do worry that there's not a clear um decision these days of what is the best and what is going to survive the next three years.

Because almost every project I start is like broken a year from now, or it's like really hard to rebuild, um, mostly because of dependencies and whatnot.

Like it's a sort of vicious circle, you know?

I will say the same thing happens in Python.

So we have this project that my co-founder and I worked on must be a decade ago.

And every year I'll be reminded of something and I'll try to boot it up again, and it doesn't work.

And so every year I'll spend like an hour trying to fix it or fix my requirements at text or or fix the fact that now it's on Python 2, and I'm even more screwed in this.

But um, and so it's a similar problem.

JavaScript's just more extreme to that problem.

And so, yeah, I I've not I mean I still know Django very, very well.

Um, and I still have strong opinions about what works and what doesn't work in it, but I've not actually written anything in Django in uh quite a while, actually, other than bolting on like some patches and stuff here and there.

Okay, no problem.

Century had a big presence.

There was like the fight club um like bath bombs and and all this stuff.

And in the hallways this year, there was a lot of talk around HTMX was probably the main takeaway.

As in to your point, you know, how do we still do Django but not get caught up in JavaScript things?

Do you have a hot take on HTMX?

Are you familiar with with that?

Yeah, I'm familiar

I'm familiar with the concept and the the implementations.

I think it's a good idea.

I think the challenge is like you need reactive interfaces, right?

Because we don't want to go back to jQuery land where we're doing all this awful like HTML manipulation.

And I think at the end of the day, like I don't want to write, well, uh to be honest, I've never been a fan of Django templates, but I definitely don't want to write Django templates.

I want to write just my actual reactive interface, and I want basically context to be stuffed into that somehow.

Um so I can't comment on the implementation, especially on the Django side, but like that is not technically hard to pull off.

I think the challenge most days, honestly, with JavaScript is the transpilation.

Like I have to go from one dialect to three dialects deep.

Like I need to go from like some modern TypeScript-y thing to some modern JavaScript-y thing down to like some compressed compatible layer.

And it's like making that process work is never fun.

And even early days, Century, we had built like a middleware, like a Django, I don't even remember what I call the project, but like a Django extension that would do the compilation for you.

And it would call out to like Webpack or whatever else.

Webpack was at the time, there was probably something else.

And it was a nightmare to maintain.

It just like it was so complicated.

And that to me is the gap with basically any framework these days.

And I actually think it's a lot of opportunity.

Um, because no matter what, you're going to be compiling some kind of thing, or you're going to be doing some kind of asset manipulation, right?

You need like that build pipeline.

And it's honestly, it's just like it's way too customized.

And it doesn't need to be.

Like, we all like we want to like like change a JavaScript from one thing to another.

We probably want to minimize like image asset size.

We we probably need to like write a bunch of like um manifests to help the CD ends or something.

They're all like exactly the same.

There's no reason to have like 50 different flavors of the same problem.

Like nobody cares about the syntax of the manifest.

Just use one and call it a day.

Um but I mean, but maybe that's a lead-in to I know with Century, a lot of what you're doing with air handling and performance is actually switching to the front end, right?

Is that correct, right?

Uh it changes every year or two and there isn't a great answer.

Yeah.

So I guess do you have what's what's your what's what do what do you make of the the front end, you know, in terms of error handling and performance these days?

I I I do not enjoy interactions with a lot of the JavaScript community, and going back to the conversation about CS, a lot of them could benefit from going and taking some CS classes.

Like, because everybody just wants to like completely reinvent everything, come up with new like vocabulary for already known problems, and it actually just creates a lot of churn.

Like if you look at like the just the amount of time wasted on reinvention where we make basically no progress, it's like what are we doing?

And maybe this is a little bit of like the tech bubble, but there's just way too much of that.

And there are some good things happening, to be fair.

I I think like React is a phenomenal technology.

Take away all the other NPM ecosystem stuff, but React itself is a great technology.

And I think if you think about like the servered component stuff that's coming, I think they've got some stuff to figure out on the APIs.

Like that is also good because that solves our Reactive UI layer, but with basically one like template language kind of thing, is how I would think about it.

And to me, that's exciting.

But I think all the other stuff is like, why are we just reinventing the wheel over and over and over and not maintaining it?

And like I think that's the risk these days is you like invest in like a technology, you have to upgrade it all the time.

Like, like if you've been working in like on the software or on the back end side of things or the infrastructure side of things, the rule is don't upgrade, don't ever upgrade.

Like even Django, like we were on an old version of Django until like I hired a bunch of people and they're like, no, no, no, we need to upgrade.

I'm like, why?

I don't need LTS support.

We can patch it ourselves.

There are no security flaws because we don't use any of that stuff, or it doesn't exist in our version of Django.

Like we can maintain that, right?

And that's a that's like a maintainer's philosophy of software systems, right?

Like software doesn't go old.

Like, yeah, there's some things that are problems, but like it works kind of forever, or it should.

And now the problem is in like JavaScript, like you basically have to update all the time because the dependency graph is just like a thousand deep, right?

And like one thing's gonna break and you can't fix it because the other thing's dependent on it.

And it's there is no solution other than to stop doing that, like to stop the dependency graph.

Like it's just not good.

And so I don't know, it's like that's my mini rant, but I think it's like there are good ideas, there's good execution, and we have to evolve it a little bit, but a lot of the stuff we're doing is actually not involving the conversation, it's just like you know, re-implementation.

The re I used to do front-end stuff, you know, and uh I I used um the way I got into Django was doing APIs, and Django was what I used to do, the APIs that went with the front ends I was building.

And over time I slowly moved more and more into um Django world and back end world because I just couldn't like take the constant you know, burn down, start again, burn down, start again, burn down, start again.

It's like no, like this isn't sustainable for me, and I just drifted all further and further away.

That's why I'm so excited by the you know the the recent emergence of things like HGMX and Alpine and these much more lightweight solutions that are like you know, actually that that they'll there are single scripts that you just bring in and then you've you've got everything you need there.

Um yeah.

It doesn't give you that.

We've accepted that because the only way most of this tech actually works today is if you actually separate the front and backend as like separate services, right?

And even if you look at technologies like Next.js and Remix, which have both server and client, the server's not a real server.

Like, as an example, good luck using middleware, which is like a known like I have to go like convince them that they need middleware as like a concept, and they're like, whoa, whoa, whoa, that doesn't make any sense.

I'm like, trust me, it makes sense.

Like, that's how the entire world works, is like we inject middleware and that solves problems.

And they just again, it's like reinventing the wheel.

And like a lot of this is like they don't have real-world experience of systems engineering that know that these things are like necessary to deploy to real production scenarios, or as I used to pick on Django, everybody's just building a blog.

And like, cool, you can solve the blog case really, really well.

Like, so Next, for example, is phenomenal, like e-commerce, and that's cool, but like I can't build Sentry in Next.js.

I can build Sentries front end in Next.js, and so I think and I that might be okay, but that world is still hard because then all of a sudden I probably run eDocker containers or something locally.

I I've got like I've got to spin up two different environments because it's not one ecosystem, two different package managers, and it's just that you go down that rabbit hole, right?

But I think that's where the world is going is some version of that service architecture where it's front end and back end where you don't need to solve every problem in one, but we've at least simplified it so something like Django or some abstraction can easily manage Django and whatever UI layer I want to use, just like you know, whatever CSS layer I want to use for that that phase.

Like I'm thinking we talked to Craig Cursons from Crunchy Bridge about Postgres, and we're you know saying, why doesn't you know the new generation of uh hosting platforms have managed databases?

And he was like, I don't think they're going to.

Um just because it's it's just so much more work and so this sense of just yeah, there isn't one all in one.

There's like, you know, for a website managed database, I guess dedicated front end, dedicated back end.

Sort of makes sense as things get more complicated.

I mean, it it would be nice to have everything all in one, but it's not gonna scale, it's not gonna be maintained.

Yeah, that we're just moving past that phase of the web.

Like they're not deploying real applications.

They're deploying like like as an example, like we use Vercel, but we use it for like our marketing website.

It's great for that.

We don't use it for anything else because it can't talk to our database.

And I'm not gonna like talk to a database that's exposed to the world because why would I?

Like, why would I add more security risk in what is like the scariest time for security in all of history, right?

Like, and I think this is the gap people are not realizing is like you can't cloud is not some magic you connect all the like random vendors together.

Nobody wants to do that.

Like, I want to buy stuff that's run on GCP, I want to buy stuff that's run on AWS because I can trust that vendor, or at the very least, that vendor has a lot of liability associated with them.

Um I think there's still a gap there.

But like what I see, they're not all the same.

Like fly is different, and DigitalOcean, of course, is different, but like a lot of them are just at the end of the day, they're almost like somebody's gonna get mad at me when I say this, but they're like glorified CDNs.

Um and that's fine.

That's a that's a good problem, like if you're just deploying like a front end, right?

But my back end's not going there because I need access to sensitive services, and those are gonna be like as firewalled off as I can possibly get them.

So I think that's still a gap, but it will change.

And you know, we'll we'll see.

Like Planet Scale is like cool, but I'd much prefer Planet Scale just be installed in GCP than some third-party service that's gonna hold all my sensitive data.

Again, which is why I think a lot of these are like they're toy projects right now.

Like they're they're used for prototypes and startups, and even I mean, this is Heroku, even at the end of the day, um, for the longest time, is like you're not building a technology company on top of these platforms.

You're you're maybe building like a media thing or or a prototype, but at the end of the day, like every real business that is technology to be clear, and that's different than say e-commerce or any of these other businesses, is running infrastructure on a cloud provider, and that's where everything is gonna live.

So I I don't know what that evolves to, but I just don't think a lot of this this view of like, yeah, we're gonna interact with these like crazy databases and these like uh if you've ever used uh Firebase, um, which is just like the most awful key value store, which is like the easiest thing in the world to expose all your data.

Yeah, yeah, yeah.

It's it's awful.

And you can't fix bad design.

Like, you know, we could talk about like the Twitter thing, right?

Like Mastodon, I don't think it's ever gonna take off because the design is so technically unachievable to do what it wants to basically re-implement Twitter at scale, right?

To collect that degree of social interaction in a centralized place, which is what it needs to do at the end of the day.

Nobody wants to like have to visit 20 of these, and so it's it's decentralized, but it's actually trying to be centralized.

And like the the solution to problems is to like change the problem so you can solve it, not to uh overcomplicate it.

So I don't know, we'll see.

Uh right, anyway.

Um so so you're talking about um people um wanting to deploy on infrastructure on a single cloud provider like you know AWS um GCP or whatever.

Is that the kind of uh model of people of people who are actually running their own century because they want to keep the data rule in in health?

Because I yeah or is it hobbies?

So like who's running it for themselves?

So sometimes it's a hobbyist that has convinced themselves this is a better idea.

Never is, okay, but whatever, you're gonna do you.

Um JavaScript developer.

And they they don't realize that it would just cost them $30 and like it's way cheaper no matter what to just pay for the SaaS service.

Like, there's no way you get your infrastructure cost below $30 to run it in a production app.

So so that that's like silly, but ignore that case.

There's the I am like privacy conscious or security conscious, and I I've convinced myself I'm better at it than Sentry.

Okay, the security thing is BS.

The privacy thing, maybe, maybe.

It depends on where you live.

Like, for example, we don't have servers in Germany, and Germany's got like a much more strict approach to GDPR.

So that's a little complicated.

So we get a little bit of that.

So a lot of like big enterprises in Germany might prefer to host it themselves.

Um, you also get things like sanctions.

Like it doesn't matter what your politics are, like governments are both right and wrong at all times.

It doesn't matter which government you pick.

And so some countries, for example, we're a US organization, we just can't do business with them.

And so, or we just refuse to operate there.

Like, as an example, like China, like we're not gonna operate in China, but people companies in China can run Sentry, like Yandex runs Sentry, for example, um, in Russia.

And like uh, I'm sure some of the big uh tech providers in China are also running their own Sentry.

And that's cool, that's fine.

Like for me, that still achieves our goal of market share, right?

That's like the case that I can get behind.

Um, there's also companies, uh, and I don't know if they do or don't use Sentry, but like a Lockheed Martin that have like a lot of government regulation, and maybe they need air-gapped machines.

We're not gonna solve air-gapped servers for them.

But Sentry can work air gapped, right?

And so so those kinds of cases are like real world, no question, like yes, makes sense, right?

But I I think a majority of it is like this kind of it's it's not maybe not the majority, but it's like split between those.

It's like, yes, this totally makes sense, you should run it yourself.

And then it's like, why have you convinced yourself this is a good idea, you're wasting your time.

Um and our solution is just like, don't worry about it.

Like, people are gonna be people, they're gonna do their thing.

Um, and it's it's kind of all over the map.

And to be fair, that that persona, the DevOps persona, it's not just the hobbyist, it exists at the finance organizations too.

And usually what happens is like, yeah, we can run century, this is fine.

We know how databases and stuff work, and then a year later they're like, okay, we'll buy your cloud service.

Right.

Okay.

Like, uh does that make sense?

How like how many commute community contributions do you get?

I mean, I imagine it's minimal, but I don't know.

So s I I think um, you know, I I've had to explain this to many investors over the years that open source is not a generic thing, and I think people often get confused.

So, first off, if I say it's open source, a bunch of people on the internet are gonna yell at me, and I'll challenge that, they are just wrong.

Um, but so Sentry's BSL license, which is proprietary, which basically says AWS and GitLab, you cannot sell Sentry, which is the intent of that license, specifically that intent, right?

Um, but it becomes Apache after three years, and so it's it's somewhat of our balance of like we need to fund the development of Sentry because nobody else contributes to it, and to get to your question.

Um but we also want to give back to the open source community, and we also believe in sort of the knowledge transfer of open source, like to not reinvent the wheel over time.

And so for us, it's actually like this tricky balance because it's actually not relevant that Sentry is open source, if you're honest with yourself.

Like the part that's relevant is can you self-host it for free?

That's all people actually care about.

They're not actually using the code.

Like we have a company that took our open source version and thought they were gonna spin up a competing service.

They probably have like 20 customers.

You know, they've they've gotten nowhere.

Like it doesn't make sense.

Just build your own if you're gonna try to like compete.

It's just it's silly to think you can leverage open source when it's like a product.

You know, if it's like Elasticsearch or something that's a little bit more complex.

Um, but from the community angle, Sentry kind of has like a bunch of different aspects.

We have our instrumentation side, which is liberally open source and people can reuse.

Now they're conforming to the Sentry API, which we're not gonna develop an open standard around, but like we have these SDKs that you could technically build a competitor on.

I think GitLab is, for example.

Um, again, high risk, but you can do that.

And so those are liberally licensed, which there's a lot of value the ecosystem can get off of that because instrumentation is a complicated thing, right?

It usually is internals, not well documented APIs, random edge cases.

And so that's actually a useful case of knowledge transfer and open source.

People will actually contribute to that, and more importantly, we basically employ every contractor who wants employed that helps us with our SDKs.

And so we've done that for years.

Um, we just try to like fund the development through anybody that actually is genuinely interested.

And we'll do that for other libraries too, for what it's worth, like RR Web, um, which is what powers our new session replay product.

We've just funded for you know a couple years, like the the main developer on.

Um and that that's kind of been one of our approaches, like, how do we better evolve that open source ecosystem?

But then we have the other side, which is pure like utility stuff.

It's not necessarily connected to the end end user product of Sentry, but it will be like some of it is, some of it isn't.

Some of it's like we have all this technology to symbolicate errors.

So basically, to take the machine readable errors and make them human readable, which you know, JavaScript has a version which is like source maps and it's just like deminifying basically and converting back to TypeScript or something.

But then iOS has a completely different version, C C has a different version, um, Rust has a different version.

Some of it's standardized, but like we now have, I think, the leading solution in the open source ecosystem to symbolicate code, um, to the point of uh where I think like folks like Mozilla actually leverage our open source.

And I think some of our competitors also leverage our open source to power that same behavior.

And they will contribute back sometimes.

Like, like, and that that's actually awesome because those cases are that's that's computer science.

Like that's actually a hard engineering problem, right?

And so we'll have stuff like that, and then we'll have like pure utilities, like like I wrote like um a test harness for requests a long time ago called responses, which literally somebody at our company just maintains now.

And and like maybe there's open source, but it's like a it's widely adopted in the open source ecosystem, and we barely use it at Sentry.

And so, as an example of like the different flavors we have going on of open source at our company, but the main thing is like everything we do basically has like a don't ask for permission open source model behind.

Like it's like if it's a server, you follow this licensing schema.

If it's not, do one of these other approved things.

We don't care.

Just like build a thing.

We're not focused on this idea that like technology is super secret and we're protecting some IP shenanigans.

So um the model is very much open source, even if the the literal implementations of each one are not like you know, proper now in open source.

Well, I mean I remember when um Redis um introduced a similar license because they were fed up of getting you know their business taken out from under them.

And I have a lot of sympathy for them, but the internet went mad and was like, oh it's like a from my perspective, it's still open source, right?

Because what I want to know is okay, look, you know, can I say it, can I see it, can I verify that it's you know um safe to run on my servers because it doesn't contain malware, that's important to know.

Um could I fork it if I had to?

I mean, not me personally, but you know, could it be forked if it had to be?

That kind of thing's important.

The fact that there's a clause in the license that says Amazon can't run our business,

it's I agree.

I'm gonna push the legal theme.

I want to relicense and just name it something obnoxious.

Uh my joke was like, it's it's a business source license right now.

I'm like, can we just make it the very serious business license and we will just like hard meme this on the internet because the whole idea that you should not have some protection is just like it's silly.

It's like immature, like right.

Like, what I value out of Redis again is that I can run it, that like if there's a problem, I can fix it, I can maintain it if I need to, I can hire people to maintain it.

I don't need to commercialize it.

Like the the business I'm in is not commercializing somebody else's infrastructure providing like software, right?

That's not everybody, right?

Like AWS, that is their business, and so it's understandable.

And for us, like when we relicensed, we didn't have to ask permission of anybody because like the entire contributor graph works for our company.

And so there's this like abstract idea that like, oh, you should be mad even though you have no claim over the software, which is just it's it's irrational, is all I can say.

Um, you know, I I want great software to exist.

Open source is great, I love it open source, but like I mostly just want great software to exist and us to not reinvent the wheel most of the time.

And so that in a lot of shapes is achieved through open source licenses.

And it doesn't matter if it's free, you know, open core, which I I would say is probably worse than BSL, or something like BSL, which is just a proprietary license with some protections.

So how

I would imagine it helps to have this attitude.

I mean, versus other, you know, I don't know, another company that's more proprietary.

Oracle.

Let's pick on Oracle.

Yeah, I mean, nobody wants to do that.

I mean, not

Not everybody cares, to be fair.

And I think there's a lot of different things people think about when they're joining companies.

Like Sentry is not an interesting thing to work on.

Like, we're not doing crypto shenanigans, we're not like AI air quotes, you know, we're not we're not any of these like hyped industries.

We're like, no, we're just gonna solve a problem and solve it really damn well, and we're gonna keep doing that.

And so you join a company for personal reasons, right?

Like when I joined Dropbox, I'm like, I want to write Python and I want to work something that has like serious scale, and it's it's awesome if my mom has any clue what that is, right?

What the product is.

Like those were kind of like the test for me.

Like, I don't care about file storage or like syncing files or any of those things, right?

Some people probably did.

Um, but you all you have your own reasons for joining companies, and so some people, you know, like Sentry because of the open source thing.

Like Armin uh Ronniker joined early on, and like we didn't even know what the company was going to be at in that stage.

And it was like, cool, we're gonna do open source stuff, you know, we can just do whatever we want, kind of thing.

And it's just like something we were passionate about, and like a number of people are similar in as Century.

But surprisingly, it is not a big uh source of pull in like Silicon Valley.

Like, yeah, some people care, but I actually think if you look like that that subset of people that care is actually pretty small relative to the the total ecosystem of developers.

We had one of the highlights for me of DjangoCon the this past October was um David Lord came by for the sprints and talking with him just about things and he had you know trying to make Flask maintainable, just thinking of Armin's web of software.

But yeah, you're right.

They just wanted a hard challenge.

At first, it didn't made no sense to me, but as I get older, I'm kind of like, well, at the end of the day, like I kind of see it.

Like, as long as it's not totally evil, it's like, am I gonna, you know, what I'm gonna do is interesting, and the rest of it is all kind of hand-wavy marketing sales stuff anyway.

So what?

Yeah.

You know, there there's the PR, ignore the PR angle.

Like, like Dropbox was, I mean, Dropbox I don't think has negative PR, but like it was well-intentioned, I think uninteresting over a period of time.

Like, Century is very well-intentioned.

I actually even believe like people love to hate on Facebook.

I genuinely believe Facebook is well-intentioned from everything I hear uh from folks that work there, right?

Um, and they also get to solve a lot of cool technology problems.

And they also actually contribute, like I'd say Facebook's actually one of the Facebook and Microsoft are probably two of the most significant contributors to open source in the last like few years, if we're honest with ourselves.

Like, and you've got to look at some of those things and be like, huh, you know, that that's like actually an important thing that sometimes we forget.

And I I think generally speaking, great people want to be around great people and they want to be challenged and continually solve like hard problems, right?

And you know, you you can only you know refactor the same UI so many times and still call it interesting, I guess, at the end of the day.

I mean, Sentry has moved far beyond error handling.

What's your quick take on on those areas and what's kind of exciting for you personally?

And what I mean by that is it's not going towards management or VPs or product managers or customer support or marketing or any of these other functions that exist at companies.

And the the the reason is like if you look at things like New Relic, once upon a time they were great and they serviced X persona, so cloud software developers, and they had great like kind of um APM stuff, and then they built a bunch of tools for other people in the company.

And I'm like, well, that's uninteresting.

And that's also why New Relic is basically failing over time as a business.

So, at the very least, a lot of people are kind of like taking their business away.

And so part of the business thesis is like, one, we should just service the same customer because it's the the easiest way to build a more sustainable and business because you can just sell more products to the same customer.

And you see this with companies like Atlassian, where this is literally their business model, right?

And so that's a business angle.

From the like the practical angle, it's like we want to just make it like easier to build software, and that should be everybody's job that's building tech for tech companies, basically.

And Sentry's core is is monitoring at the end of the day, and and there's like a thesis that maybe we can bring monitoring earlier in the lifecycle, um, because all it is is it's just instrumentation for errors and latency and all these other things, right?

Which technically you could get in CI, no problem.

Um, and so we kind of want to do that, and that's all for developers.

Like you'll you'll find we don't do any kind of like analytics or any kind of like product usability kind of things, it's only software defects, is what we focus on, right?

And that's a very specific focus.

Um, and it's because we just think we have to like do that thing and continue to do it well, and that's just such an easy concept for everybody to figure out.

And so then when you bring in Code Cove, there's a lot of reasons that like I was excited about them joining the company.

Um, one is because it it clarifies our position more.

We're not just building like, we're not gonna give you, you know, system monitoring or infrastructure monitoring with a bunch of graphs and widgets and stuff that frankly I just don't think is useful.

Um, we're gonna focus on like I want to ship the software and get back to shipping the software.

And I was always bullish personally, like I think code coverage is actually such a useful metric because what I would do, like, code review is a pain in the ass for everybody.

Like people just sit in code review forever.

And so I always optimize like just rubber stamp this, I'm accountable for if it works or not.

Like, if you want to review the logic, have I tested it well enough?

Like, start there.

Like, is the test coverage actually testing real-world use cases, right?

And the simple metric of like how many lines of this pull request are covered by tests is like that alone, like just that simple indicator tells you so much, and it's such an easy binary yes-no on it.

Should this actually be Greenlit?

Um, and so I I think that alone is useful, but also like just building more on like the CI side has always been uh a desire for me.

Um it's what I when I was at Dropbox, I I focused on CI and uh and CD kind of problems.

And I just think it's such an area that like nobody really builds, like everybody just builds infrastructure, like GitHub Actions, like the the sort of reporting angle of it, the analytics angle of CI is just completely awful.

The infrastructure to run the tests and everything, it works fine, right?

Like everybody just solves the infrastructure, and everybody that tries to solve the reporting realizes it's like a very hard problem.

It's like a very hard distributed systems problem, basically.

Um, and so I personally am excited to see what we can do pre-production, basically, and basically bridging production and pre-production, where our our kind of point of view is always like we just want to be able to enable fast decision making.

Like stuff's gonna go wrong.

Can we make can we minimize the consequence of things going wrong?

And like, as an example, I'm hoping in January we're gonna ship a feature in Sentry that will overlay CodeCove and basically tell you this this error.

For example, was it tested at all?

Like, is is the issue you just didn't write tests?

Because like people don't like Blaine, but Blaine is such a useful accountability structure at the end of the day.

Like, I want to know, like, I should be embarrassed if I just cause like a serious bug and it's all because I didn't write the test, right?

Like, if nothing else, that gives me validation for like I should spend the time on tests, and if that means I need to, like, some orgs, you know, it's hard to like push for how much time things take.

So that helps that that side too.

So I would say open-ended, we don't know where we're going with the code cov acquisition, but I'm bullish on investing in spaces that I think just help us build better software.

And so if I could like have like end-to-end, I would like I'd be like, cool, we're gonna we're gonna take you all the way from pre-production to production, and we're also gonna like ship the code for you.

But I don't know that we'll ever do that.

So we'll see.

Can I ask a question there then, David, that ties in?

You said you'd focus on software defects and and but one of the cool things you've bringing up in kind of recently is the performance monitoring and the pr or the profiling.

And how do you see that fitting into the century?

Because it's great and it's lovely, but it it's not the same as the exception reporting that started off.

Yeah.

We kind of pivoted our product roadmap recently, because we've been building a lot of these, what I would describe as dashboards.

And uh now internally I'm notorious for saying we don't need any more fucking dashboards because not not even just a century.

In life, we have too many things to look at.

We do not have the time to look at them, right?

And what made Sentry great, literally the one thing that made sentry great, you could take away everything else, was when there was a new error, it emailed you.

It was in your inbox, and it was like that.

And so you could kind of trust that like if you broke something, you're gonna know about it right away.

It's it was proactive in that regard.

Now, it might send you a lot of those emails, and there's you know, it's not a perfect model, but that idea is very important.

And so as we did APM or performance monitoring, which um for context, if folks don't know, performance means two things for us.

It's latency, is it fast or slow?

And is the throughput high or low?

Because as an example, if signups go to zero, that might be a software default defect that's not uh an error, and it's not a latency issue, right?

It's just, I don't know, maybe you deleted the signup page, right?

Um and so when we think about it from that angle, we're like, okay, what are the problems we can identify?

And that's been the change in our roadmap of like of we have the issues product, which is basically just error monitoring, and we released like our first kind of POC in this, which was like, oh, we can detect N plus one queries.

That's literally just a software defect.

Now, it matters because when when um if you've never experienced these things, when you have a like a query in a loop, and this is like a common thing you would do in Django templates, for example, uh, most days it's fine, but then all of a sudden you get a high load day and the database is overloaded, and that query in a loop is actually like hammering the database, and then everything falls down.

And so it's almost I I've been I've been talking to people about how to think about what these performance issues are, and I'm almost it's like it's like static linting but in production in a way, right?

It's not necessarily a problem.

It's almost like uh, this is a bad thing to do.

It might be okay for you, it might not be okay for you.

It's up to you if you should fix it or not, which arguably is the same as errors, right?

Like maybe this error is fine, maybe you don't care, right?

You just didn't handle it.

And so when we think about APM and profiling and um things like that, it's like it has to do one of two things.

It has to help you debug a problem better than you could before it.

So basically depth.

So profiling is kind of depth to some degree because it's like function level versus tracing is kind of like network level.

Um and then uh breadth, which is it should help you identify new problems.

And ideally, help you identify is not you go look at dashboards and wire up a bunch of custom things.

Like we actually try to curate a lot of those rules.

And so, as an example in profiling right now, with that data stream, they're actually looking at like main thread blocking I/O.

Like things where like if you're doing like hundreds of milliseconds of I.O.

in the main thread, like your app is hung, right?

And that's like, oh yeah, makes sense, but that's such an easy thing you can mess up.

Again, it's almost like static linting.

It may or may not be a problem for you, but we can we can certainly identify those and and call those out.

And so, you know, I I think a lot of stuff we're doing is in that vein, and I think it's gonna be exciting, but I will tell you, we have no idea kind of what we're doing in the sense of like, and plus one straightforward.

Like that was me saying, hey, this is a real problem.

Trust me, lots of Django developers are gonna put these in their their templates or other things that are equivalent to like Django's template abstraction, right?

Or even just API calls.

And so I'm like, known quantity thing, ship it, see what happens.

A lot of the others are like, okay, now what?

What what else is like an obvious kind of root cause or like key problem that is black and white?

Because as soon as it becomes subjective, it's kind of complicated.

Like an N plus one is subjective if it matters or not, but it's not subjective if it's actually like that behavior.

Yeah.

Should it be slow?

Is there actually something wrong with it being slow that you can fix?

What's the something that's wrong?

Can we even identify that?

And so we'll see where this goes.

We don't quite know yet.

So you'll see a lot of experimentation from us as we try to figure it out.

But I I will say I think it's a much better model of how monitoring should work at the end of the day.

So to it does not it doesn't help you debug particularly what's going on, but it does help you identify, oh, that you know what, that page is causing user pain.

Let's let's go and spend some time looking at that page and we can fix it.

And then you can see, did did did did that metric drop after we've released it?

Oh, it did.

Well, you know, there's progress.

So that's kind of yeah.

It's always like there there were always like these keys.

Is it fast?

Can we tell you about it quickly?

Can we help you understand if you should care or not?

Which is kind of that user pain, is one of those many ways you can think about that, right?

Um, and then can we can you reproduce it without having to go like actually take more steps, right?

Like if you have to ask a customer for more details, century has failed at like its job in this regard, right?

Which is very different than again a lot of monitoring.

A lot of monitoring is maybe you have the logs, you have a metric on a graph somewhere, and you have no idea what the actual problem is, or you don't have the right details to reproduce it.

And all of that, all of Sentry has always been modeled off of like the Django debug page.

Because I'm like, huh, what if you just put this in production?

And that's that's what Century V1 was.

Like literally, it was like in Django, it was like, I think I might have even just like straight up taking the CSS um or re-implemented, I don't know, but it looked like the debug page and it was just in the admin, and that was like your issue details page.

And and today Sentry is a little bit different, but it's the same thing.

It's just like let's get as much information as we can for you in production.

So I know you're not an AI company, but if someone wanted to not reinvent the wheel and you know, anonymize data, like people are making the same N plus one and other problems all the time.

Um is there any conceptual way in which there could be something helpful that would just go through your code, right?

And just say, you know, here's n plus ones, or here's here's all these known things that we see time and time again and all these Django sites, all these other sites.

Can you see that would potentially work, or is that just not feasible in any way?

Now I I don't think it's AI necessarily.

And imagine you could build a set of rules that look at Django instrumentation, basically look at the errors that come in, look at the traces that come in, and you could be like, okay, when you see this in Django, it's actually this is a problem.

Like you could recognize this problem and then create an issue out of that.

So we're actually trying to like make it so we can expose that in like almost like a JavaScript kind of language.

Um, because I actually think it's very exciting if you could build these rule sets, and they are gonna be like, they're gonna be very domain specific, which is one of our challenges, right?

Because there's so many different domains.

And I think, and then you can take that again, going back to CI.

Like centuries N plus one works fine in CI.

Errors work fine in CI.

Latency, okay, you need like real kind of load to show latency, but like those other things, like you could actually run in CI and identify problems before they hit production, right?

Now you still need the tests to run.

So maybe that's where CodeCov comes in line, like that you're actually testing the code.

But there's a very real world where we will bridge that CI gap with production monitoring.

And then all of a sudden you have like an interesting conversation about what could canary be?

What could production level QA actually look like if we if we change the story a little bit?

Oh, you need high o-rays coverage to write a test that sort of just tests loads of stuff all at once.

It's not a very good test per se, but it does execute a lot of code.

But that's actually

Um, I wrote a bunch of tests because it was so hard to actually like test the behavior that just like load the endpoint and check if like a simple element's on the page.

Kind of like I I don't think they were Selenium, but close enough, right?

And people are like, oh, but this doesn't test anything.

I'm like, no, no, no, no.

It tests that the code actually works runs, like that it it executes.

And that is like actually such a big deal because a lot of times you just break stuff because you didn't even run the code.

And you'll catch so many bugs by literally just running over the code and not even validating the logic, right?

And so, you know, I I think there's a long way to go in sort of like test uh paradigms, like how we can evolve that conversation.

But I I do think coverage is just like one of these useful metrics that is like it it actually adds a lot of value.

You just, you know, it's flaky historically, which is one of the challenges we got to get past.

So good.

Did it, you know, did it actually work so that when you start hacking around, you are, oh, do you know what?

We took down the home page?

Okay, well, that's fine.

Are there things we haven't asked you that we should or things you want to mention to people, people listening about Sentry and Django in particular?

I we'll we'll do it.

We'll say you like it's it's not controversial to say you're doing Django, you should use Sentry.

Like everyone's doing it.

That's true.

Price price point is reasonable, like and there's new features coming out.

So I I would actually challenge it.

And you should send me an email and explain yourself.

Uh, because like I have no idea why that would be the case.

And I I tell this often to like the go to market teams.

I'm like, you should know if if every single Django production app is not running Sentry, we've done something wrong.

Especially if they're using like an alternative to Sentry.

Because like we are just so good at the Python thing with like the local debugger, like kind of like the context locals and stuff.

Um, but but yeah, I don't I don't know.

Nothing, nothing to shim.

Check it out if you're not using it.

Um, you know, we're always open to feedback.

You know, we're on GitHub, so find us there.

Well, let me let me end with one quick one.

If you could, if you could wave a wand and change one thing about Django, what would you change?

I mean, you've sort of talked about a couple things, but what what will be the one thing?

Like that's the only thing that needs to exist because it's not about like changing a thing, it's about maintaining relevancy.

And I actually the the least favorite thing for me these days is going to like a Python conference because I know what inevitably is gonna happen is the majority of people are gonna work in data science, which is totally fine, and I have nothing to talk to them about, right?

And so I think we need to like rebuild that relevance of like traditional web frameworks, and I the only way you're gonna do that is by satisfying some of this JavaScript demand.

Um outside of that, I think Django's is it's always been good that you could plug like what you wanted and take away uh things you didn't want.

Um I see I'm not even familiar with it's probably on version four or something these days, and I know it's it's accelerated the majors a lot more, but I'm not familiar with a lot of the new models.

A lot of my complaints are probably from from older Django, but I I genuinely think it's it's been a great framework for a very, very long period of time and has solved sort of the core need since you know, probably like one, two or somewhere around that version.

I know you've you know a lot of things you could be doing.

I appreciate you taking the time to come on here.

This is what you know when we started the podcast a couple years ago.

Sentry was like, we need to have ideally you Sentry come on because it's part of the core toolkit of Django.

So thank you for taking the time.

Well, we'll have links to things in the show.

As ever, DjangoChat.com, and we'll see everyone next time.

Bye bye.