Transcript: Django Community Survey

I'm Carlton Gibson, joined as ever by my co-host Will Vincent.

Hello, Will.

How are you?

It's been so long.

Hi, Carlton.

We had a little break for the first time.

We were just discussing before we went online.

We both have we have seven kids between us, all under the age of 12.

So that's uh been interesting, but everyone's juggling stuff.

But it feels nice to be back in sort of a routine, I guess, with school virtual and otherwise.

Like literally, the kids finished school on the 13th of March and they went back on the 14th of September.

So that's six months, literally six months out of school.

Um so you know, 2020.

I saw a tweet the other day when uh uh 20 there's only three months of 2020 left.

I but mentally I never left February.

I it really resonated with me.

I'm like, yes, that's that's exactly how this year's gone.

Yes, but there it's stuff has happened.

So as you as you mentioned in the intro, so we are gonna be going every two weeks going forward.

We did weekly for 72, 74 weeks in a row, but we're gonna be going um every two weeks.

This episode we're gonna be talking about the Django community survey, updating everyone on what's happened in Django the last couple of months, but most of the episodes are gonna be guests.

We have a whole bunch of guests lined up for the fall that we're excited about.

So it'll be mainly guests talking about using Django out in the wild.

What's happened?

You and Marius.

Yes, it did.

Mo Maris was um release manager for that, so he basically did all the hard work, and I I was there with like the supportive cup of coffee and metaphorical video, you know, remote coffee and remote donut.

I was like, you

know, yeah.

He's um been working on the cockroach DB back end.

I think there's there's prog progress there on making that more fully more more fully featured because Tim keeps uh making these little PRs, so that's nice to see him in action.

Well, that's good.

You and there's already been a security release, so 3.1.1 and 2.2, whatever, that came out a couple days ago.

Um and then so when you run collect static or whatever, you had to we had to make sure that we were setting the correct permissions.

It's not a particularly high um high impact one in that you know, if someone's got access to your file system, you've probably got bigger problems already.

But yeah, uh, you know, it was we got that out and we got a lot of um quick fixes out.

So three the point one, the the you know, the three point one point one, that that first point release is always quite hectic because there's new features, and then people finally try, you know, give them a try against their production environments and they find all kinds of issues.

So um a few with the new admin sidebar, CSS kind of issues will resolve those, or we resolved a lot of those, with a couple more that will get resolved in 3.1.2, and then hopefully it should be like, yeah, no, okay, we've we've got the worst of that.

JSON field, a couple of little ones there, and a few regressions in the ORM where you change, you know, if you've got particularly complex queries, which you know aren't antecedently covered by the test suite because it's like I'm aggregating here and then grouping by uh you know, or the group by and then ordering on the aggregation.

It's like these things can be tricky.

So a few of those.

Well, kudos to that.

I'm glad you know that came out.

Well, kudos

I mean Marish worked like an absolute Trojan, is the phrase.

He he really um you know, he really sweated it.

And it's my turn for 3.2, so I'm a bit like uh

Is that the plan?

Yeah, yeah, yeah.

Will be the LTS.

Like the LTS is just the same.

Um sorry, that was a mosquito trying to weep me, so I just had to attack it there.

Um the LTS is the same.

Uh you know, it's not

I just I'm smiling because we make a lot of efforts to have good quality audio and you're you're smacking your hands loudly for all the guests.

Yeah, no, but it's okay.

Yeah, no, sorry.

I do apologize.

What else?

Um I updated all my books.

So this time I was able to use the beta release, as you would say, and so they all came out.

I had to redo screenshots for every single admin view because there's the new admin sidebar, but also the Chrome browser changes.

So, anyways, it's complete, start to finish redo of everything, but I was able to get that out and then take a little bit of a break.

So that's

You you were you you read a wrote a post or perhaps just a series of tweets where you were saying that um rewriting the books is kind of like um uh I can't remember exactly what you said, but more like doing scales.

Yeah, you use the announcement scales.

So it's like because you go through it and you tweak it and

Yeah, I I think that's accurate.

That because I go through for every every major release, I go through everything from scratch, new code base, new screenshots, and it is the you know the bane of the existence of people who create content is you have to update it all the time if it's technical.

And so most people don't, and I've I'm on now my fourth or fifth time updating for Django.

I think the first time I did was 110.

Um But yeah, I think it's I think it is sort of like musical scales.

So I I played music, my kids play music, and you know, my we spent a bunch of time during the break with my my brother-in-law, who's a professional violinist, and he plays, you know, five hours a day, and he plays scales every day on top of everything else.

So I think there is something true about that that you know, going through because there's things that change in Django, there's things that change in Python, there's externalities, but there's also just how I feel about teaching stuff changes.

Um so I try to, you know, it is an opportunity to do that.

I mean, for example, some of the changes that I made in the book, um, well, the book size changed actually.

So the paperback trim, it was eight and a half by eleven, and now it's more closer to seven by nine, which is more standard sized.

Um so people probably won't notice that, but that was a whole ton of work for me to do.

I mean I would like to have you know hire a professional develop uh designer and make it all perfect, but I I update all the time.

So um but anyways, I think it I think it's better.

Uh the pathlib is a big change in 3.1 in 3.1.

So the settings.py um file defaults if you do start project to pathlib.

I had so I update everything to use pathlib instead of just um OS.

What else?

And I guess the other one that I've had a bunch of questions about is I decided to, for project names, in the past I would, if it was a book project, I would call it book underscore project or you know, to do underscore project.

But I've adopted more the um calling everything config that's a project folder.

So it's it's completely superficial, um, but I made that I implemented that in the books as well as I've been doing that in my tutorials.

Because I think it's one less thing to worry about because it is one of those things that you have in every project, and so it just seems I like to standardize it, and I think Jeff Tripwood cued me onto that pattern.

Anyways, so yeah, those are out.

Um there's so many moving parts in a Django project and apps, so to the extent that some things are standard, try to name them as such and treat them as such across the different examples that I give.

Um what else?

Uh Django people has been sunseted.

So that was a project that's been around for a long time, not really maintained.

There's a post up on the Django site, we'll link to um it wasn't being used, so um it redirects to I think that blog posts.

Yeah, just a holding page.

Um I think that that's the point.

It wasn't being used and it wasn't being maintained.

Um and so whilst Django snippets is still being maintained and that's up to date, and you know, that lets keep going nicely.

Django people was in need of love, and then there's this folks who are like, oh, I need to um reset some credentials or I need to uh change some details that and they weren't able to log in and we weren't able to recover accounts, and uh at that point it's no longer sustainable.

Um what else is there?

There's there's a list of things that the ops team um is in charge of.

So, anyways, that's people won't probably miss it, but that's changed.

Um, Django News newsletter.

Is that something I've been doing with Jeff Triplett?

That's still going along.

Um we'll put a link.

That's a weekly uh link of all sorts of Django news projects, videos.

There's a whole bunch of conferences that have happened.

So PyCon Australia happened.

There's a Django track, um, we'll link to that.

PyCon Africa happened.

There is a whole uh number of Django talks, we'll have links to that.

And DjangoCon Europe is coming up this weekend, which you're speaking out.

So um talks about um yeah, my talk's very talks about uh optimizing model choice field.

And in order to have an example for that, I've got this crazy database query that you know goes insane.

And then trying to record the demo, I wasn't actually able to record the demo because my with my computer wouldn't capture the video and process all the database requests without doubling the time because it was busy, like I don't know what it was.

Oh god.

Time sharing.

And so basically I'm having to go slides only because I can't I can't do the demo.

But I hate live demos.

I knew even recorded live demos.

Like, you know, no.

So it's I'm actually happier that I'm doing slides, but that means I'm I'm still working on it, even though the deadline's really soon.

Um but it's fine.

I've I'm I'm quite excited about it.

So there's your talk.

Um Adam Johnson has one on how to hack a Django site that I'm really interested to see because he would know.

Tom Dyson of Wagtail has one on new ways to deploy a Django app.

Um Marcus Holderman has one on migrations, Aaron Bassett has one on HTTP headers, um Sage Abdullah has one on Cross TB JSON fields.

Um Andrew Godwin's there.

So there's a whole list of people.

I'm really excited to see the talks.

I'm I'm excited about Tom Dyson's talk because he's um gonna look at three different ways of deploying from um uh from the first one being like a static site.

So what I want to know is well, how's he gonna get a static site get out of his Django thing?

Is he gonna use WebGet and mirror mirror the Django side or like uh or has he got a little command line tool to do that?

I'm quite interested in that.

I think the second one's like a more normal deploy, and then the third one's some sort of containerless, serverless all in space number.

I think it's gonna be great, and I'm glad that that that the conference is happening.

I think there's there uh two more things and then we'll get into the survey.

Um, so Django technical board vote is coming up.

So this is a really big deal.

This has been in the works for two years, I think.

But um Django will have a technical board of three members who will be the final deciders when there is a big issue.

Is there anything more you want to say on that?

So people should there'll be so people who are members, there's 200 odd um individual members of the Django Software Foundation will be the ones who vote on that, um, and that election is important and upcoming.

I mean, all I'd say is that this is the culmination of the whole dissolving Django Core or renaming Django Core and um the introducing a more modern government governance.

Um, Django's such a big project now that it needed something more formal than what it grew up with when it was a much smaller project.

Uh and you know, we've talked about Django Core and how it became stale and you know various other things, and not representative of the wider community.

And the the technical board, this final technical board election is kind of like the final piece of that debt 10 change.

We've had the mergers, we've had the um, so Maris, myself, and Claude are the mergers, and then we've got you know, Maris and I do the releases, and that was all part of DEP 10.

But the thing we've been missing is this this official election of the technical board.

Yeah, so I was excited about that.

Yeah.

So corporate members um will now have something they can show on their sites that'll be up soon.

Okay.

Community survey.

We get should we get into it?

Yeah, no, this was super.

I saw I sort of just like you know, put out the charts and was like a piece for a couple weeks.

Um but we had fantastic responses.

We had four four thousand three hundred and seventy-nine people responded, uh, which is great.

And we hadn't done a survey in five years.

The last one was Tim uh Graham had had done one in 2015.

But you know, Python has an annual survey, and there's I for the fellows and for the you know the core not the core teams, but the Django developers, it's important to know what usage is because Django does not track anything.

So we're very much in the dark on what people are using.

So this was really, I think, will hopefully guide future discussions around, you know, we'll go through them, but how is it actually being used, which database backends, all that kind of stuff that we can only wonder about?

And it's nice, you know, but so you know, let's jump the gun.

There was one on the test framework.

Well, which test framework are you using?

And we do a lot of work on the Django test client um to keep that up to date and keep that running.

And who's using well, it turns out a massive proportion of the user base are using it.

So those are the same things.

Why do we bother?

That was that's one we'll come back to that when we as we let's go through them in order because otherwise we'll get lost, we'll cut back and forth.

So there's links to them, it's up on the site.

Um so the first one, the question and is what is your primary operating system?

And so I think for next year, I'm gonna rephrase this because I think the better question would have been what is your local operating system and what is your server operating system?

So 45% said Linux, 27% Mac, and um 27% Windows.

I think the l I suspect the Linux question is your, you know, there's some combination of your server, not just your local client, because anecdotally at least, yes, people use Linux, but I was surprised by this.

So we could ask it in a way to confirm that it's actually you know local client versus server.

Yes, yes.

And it's like we always think Windows is the minority um operating system.

No, it's not, right?

It really isn't.

And yeah, you know, especially if it's

You know, I I don't have two fancy computers I work on.

I'm I use mainly Mac.

I mean use a Mac.

Um, you know, Andrew Godwin's on Windows, other people are on Windows.

I know from uh my install Python 3 site there's tons of people looking for Windows installs.

Um but if anything, I thought that Windows would be bigger than Mac, you know, or demonstrably bigger.

Um it seems about the same.

Um so that was an interesting question.

I think for next year, hopefully this will be an annual survey that we can do.

I would want to distinguish between client and server because I s I suspect some of the Linux is that.

But um moving on.

So what do you what do you so when you start a new project, what do you use?

So 75% said they use the latest stable release, and 30% the LTS.

Um and I guess maybe if you're starting a new project, why wouldn't you be on the latest one?

It's more a question of you know, in practice, it's the upgrades, which maybe we can we can even skip to where people say how often do you upgrade?

And the majority say every stable release.

Um I think it's probably the difference, you know, there's a difference there between a corporate site and a personal site because that's fantastic to see, but most companies I know are behind.

Um they're not on the latest release.

But like why for me at the moment, why would you be on the LTS?

There's just no reason to be on the LTS, you should be on the latest version because like if you're not gonna maintain maintain your application, then fine, you might think, oh, we're not gonna maintain it, we'll be on the LTS because we don't have to maintain it.

But if you're not gonna be maintain it, you might as well be on the latest version because it's got loads of bug fixes which the LTS doesn't have.

Right.

And if you're not maintaining it, well, what's the difference?

Uh and I think one of the one of the things people point out is that you know it's always your dependencies.

So it's third-party packages.

Yes.

You know, the major third-party packages, by and large, are excellent at staying up to date.

But you know, who knows how many you're using, dozens and dozens, and then maybe you have something custom.

And you know, so I think I know that that is why companies fall behind, is because the dependencies, it's not Django itself.

And then what are you gonna do?

Are you gonna dedicate the re resources to commit back to that upstream package and fix it?

Are you gonna somehow patch around it?

Are you gonna, you know, you've got to be really cautious about taking on develop um dependencies.

You know, a lot of Django third-party apps are awesome, but a lot are something you could build in an afternoon, especially if you've had a look and you've you've sort of seen, oh, okay, yeah, that's a nice, I'll take inspiration for that.

But I'll write my own version because then I'm on top of it.

Well, you and I are in that camp.

I think that is definitely as as you progress in your Django career, you are more wary of taking on something.

And so, absolutely for me, if I I'll take a look at the source code and if I think I can reverse engineer it pretty easily, easily being within a couple days, then I'll do that.

Um but yeah, so that's part of it.

Um someone had a good there was one of the good comments was someone was asking about a Django admin command to show deprecation warnings.

Because I do think that a lot of people don't use the dash big W to see the warnings flags.

You know, I don't know if we can make that clear in the docs or I mean that's a little bit of superficial.

Yeah, it does say this.

There is a whole guide.

Like it's I understand that if you don't know how to run with the warning flags enabled, then that might help you discover it.

But but if you just read the doc one time, you'll know about it.

It it's we don't want to just put wrappers on wrappers and wrappers.

Um, it is there.

If you search for it, you'll find it.

Once you do it, once you know about it, you use it all the time.

Um, you know, I don't know if we I think we do is it linked to when there's a new version that comes out?

I don't know if we put it in the if it's put in the release notes.

You learn about these flags by the first time you need them, but um let's have a look.

Yeah, there's so right, it's at the top of the 3.1 release notes.

It says see the upgrading Django to a newer version side if you're updating the project, right?

That's in the that's right in there in the first before we get anywhere.

And then it says about Python compatibility.

So I don't know, I just think that adding that kind of stuff is it's great in principle if we had much more human power available to developing code on the framework, and we don't.

So we have to be very selective about what code we take on and what code we add, and people are, you know, can we have this really minor feature that will add a teeny bit of complexity for this for this corner case?

It's like, well, no, implement a subclass, keep that in your own project, because if we implement each little minor edge case, it becomes unmaintainable.

Well, speaking of resources, so one of the questions um which built-in database do you use?

Uh so Postgres, the dominant one, as expected, um, SQLite, second, um, MySQL and MariaDB.

So MariaDB is just basically a different version of MySQL and an open source version of MySQL.

Um Oracle's at 2.2%.

You know, uh Oracle is always one of those ones in terms of resources.

I mean, I think if if this is still the case, that for you and Marius, it's more work to make Oracle work than the other databases just on its own.

Is that still the case?

Um like Maris is a good is uh an Oracle expert.

He knows it, he uses it well.

But yeah, at times it's it's it's fundamentally different from the other databases.

Um I would say it certainly takes more than 2.2% of the time to maintain.

Yeah.

And what really gets me is that Oracle Corp aren't prepared to support the Django Software Foundation, or apparently, uh you know, as we've had various conversations which haven't gone anywhere, Oracle Corp aren't prepared to um support the Django Software Foundation.

At that point, you think, come on, people, like this isn't this is a massive corporate enterprise, a massive corporate database.

One license for Oracle would be, you know, we cover that.

And and there's just it's just like crickets when we talk to them.

So I do get a little bit upset with the lack of um I don't know, input from Oracle there.

Yeah, I try to be positive in in public, so I'll just move on, we'll move on from Oracle, but it seems a piece of of a piece with how they how they operate.

So Memcach uh excuse me, Redis was the twice as much as memcached, which I think that makes sense.

Reddit, if you're starting from scratch, Redis does seem like it's the default choice.

Um not there's anything wrong with memcache, but Redis more powerful.

I think people um like they've they've got Redis in play, or they were thinking about Redis in play, or Redis is you know on their radar, so they go with that.

The interesting thing for me is we don't have a back end in core for Redis, and yet 76% of our users say they're using it.

So um we really need one.

I mean, we're we're at the point where we're gonna have three versions of the memcache backend in core and none for Redis, and that just seems wrong.

So what is it?

So what is what does it take to have that happening?

some somebody to um sit down and write the back end.

So the API is quite small, it's only half a dozen methods, and you know, wrap that around Redis Pi, whatever.

There's so there's Django Redis and um Django Redis cache, which are the two third-party packages, they could be used for inspiration.

It's just a question of the time to sit down and pull them in.

But I think at this stage with the survey results as they are, I think there is a clear case for um a Redis cache backend incore.

And then, you know, the third party packages can add can expose the further capabilities of Redis in the Django environment.

So moving along.

That was something I think had suspected that was the case, but was very very much validated that that is what the usage is um in the community.

Uh moving on to so apps that people contrib apps, um admin, number one, that's probably not a surprise, auth.

Number two right there.

Um, I don't know what else.

I mean syndication, not a lot of people people using syndication, but I guess you know that's not a terrible surprise.

Flat pages still being used, but smaller amounts.

So um, yeah, the the Python packages one was really interesting to me.

Uh and I will say, so I did not so the list came from looking at the top um PyPI downloads, and uh, Wagtail was added, was only added after a couple days.

So the Wagtail numbers are low, lower than they would be.

Um that would be the two things I would change for next time is I would include Wagtail and I would um from the beginning.

It was only a couple days, but I think it it was it was like two or three days

after the survey came out.

I was like, wait, I I can I can add that in.

I should have added that in.

But that's so that I think I know that's underrepresented.

Um, but you know, top one, psycho PG, if you're using Postgres, that makes sense.

Requests sort of make sense.

Pillow, that was a little surprising.

Pillow, I mean, what we would use for image uploading manipulation.

So any kind of upload an image, minimize it.

Um uh Gunicorn is there, GUnicorn, um, PyTest.

I mean, not surprised that PyTest is there.

You know, Botto3, so that would be for S3 storage for your um your media files or whatever else.

So the Python formatter, that's which is now part of Python, I think, or it's official, I think, in some way.

I think it's uh the PSF, I believe, is supporting it.

USGI, yeah, that makes sense that I would think uh uh G Unicorn would be a little bit higher than U Whiskey, but also quite popular coverage.

You know, that makes sense for testing as well.

Um so, anyways, it was interesting to see.

I mean, there's clearly there's you know what, 10 that jump out and then not a lot of others.

Yeah, it's yeah.

Right.

So we got Django Rest framework, debug toolbar, and then Django Celery.

I'm like, come on, folks, there are other cues.

Was it?

Yeah, I mean it's so it's you have to hover over.

So this is the default Google layout.

I don't have control over it.

Um yeah, course headers is actually number two, then debug Django filter rolling in there, Django Celery.

Django Celery, that you know, Django Celery and Django Redis right there in what, fifth and sixth.

So you know, Django Extensions right below that.

Um someone was actually asking me, I don't know why they're asking me, but they're saying, Oh, I wish Shell Plus was part of Django itself itself, because it is true that Django Extensions has, I mean, I use that, a lot of people use that.

If we had unlimited funds, there's probably some things from there we could just roll into Django itself, but it's

So what Shell Plus does, it automatically imports your model files, right?

That's the same thing.

Yeah, exactly.

So it's

So um and then Ren Server Plus, I forget what that has some extra goodies.

Though it's you know, Django is updating, but Ren Server Plus is another one of the I mean it's a Swiss Army knife for Django stuff, but certainly for the shell I always use that.

Django Alloth, you know, that's fantastic package, up to date, always used.

Django Celery Beat, you know, that's I actually haven't used that myself, but that got 700 votes.

So oh and then

And then uh scheduled tasks.

So there was a whole side channel discussion about JWTs.

And I suppose we might as well.

It's not it's it's sort of insecure by default because there are too so many configuration options that people simply can't help but get it wrong.

Not it's just far too complicated, and as as a result of that, there are frequent security breaches because of it, uh, or security holes because of it.

So it came up, well, what should we be using for uh um authenticating my our um you know single-page application?

Well, probably just sessions still, you know.

You should if you're in a browser, use sessions.

If you're in another other client somewhere else, well they can use cookies too.

So hey, just use sessions perhaps.

Um but perhaps Django needs a more rounded story here.

But JWT perhaps isn't the go-to option it should be.

Your your iOS or your Android app just wants to deal with a cookie, but

But pretty much every um library is able to handle cookies.

So it's not like you're writing network code yourself, you're using some networking library, and most of those have the ability to start um to get a cookie from one request and then attach it to subsequent requests.

It's no different than the token, right?

A cook the cookie is just the header that you send with the request.

It's it's cookie and then there's your cookie string, right?

Whereas um a JWT goes in authentication, right?

And then there's your token, or you know, or auth token.

So it's just it's from a sort of HTTP request perspective, it's just setting a different header.

So do you think the

So um that kind of simple cookie setting login view is is is a is not going to change at all.

What can we do?

I don't know.

I mean, it's is it our job to go through and say of every login option, no, this is the one you should use, this is the one you shouldn't.

But I think we could perhaps call out that hey, JWTs aren't the way to go, and you should be using session authentication still where you can.

So you have a session ID for your web client, and there would be a separate one for your iOS.

Yeah.

That that I mean that's why tokens exist as a way to have a token generated for your different things.

So you can have Safari open, and you can have Chrome open, and you can have Firefox open.

You can be logged into your Django site and all three, and all three of them will have a separate session ID and separate sessions.

So look, okay, back in the day I wrote mobile clients using JWT because I was learning, came, um, picked up REST framework, and I was like, I need some sort of authentication for my iOS client back, you know, when I, you know, IS345.

Uh, what do I do?

Uh, here you are, I can use JWT.

So they're the new hotness, everyone's recommending them.

Fine, brilliant.

They work per perfectly well.

I don't think about it anymore.

But okay, with now knowing more and you know, with reading more in the last few months, it's like, hang on, I should have been using sessions all along.

I just never thought, oh no, I can I'll I'll implement Session Auth.

Um, I don't know, it's difficult because developers don't know any better.

And I didn't know any better at the time when I was using token auth.

And that you know, for for things like OAuth, that's what you're still using a kind of token auth.

You've got a bearer token and you which you've got off of the server when you did the OAuth login, and you use that as your credentials.

I mean, Django Rest framework, the site lists, you know, there's almost a dozen different ways you can do authentication, in part because it doesn't want to be the arbiter of what you should do, but perhaps it's something Django itself could look at, other than saying, you know, don't use JWTs if you're gonna ask some people.

Um but then that would need a you know that would need a Django Rest framework simple disall rather than JW JWT.

And so the top place is the blog, um, which is good because it's infrequently updated, but it's important things on there.

Stack Overflow was number two, which I s not sure how you'd follow development of Django on Stack Overflow, but I suppose there's advice and questions on there, and everyone's on there anyways.

You know, Twitter, Twitter a lot of us are on Twitter, Reddit, a lot of people on Reddit, I'm not on Reddit, but um Django News newsletter, it's nice to see on there.

We're trying to fill in the gap a little bit.

Um Google groups, you know, down the list.

Do you have any thoughts on things that are how people follow Django development?

I mean, it'd be nice if the Google groups were higher, since that's actually how development is being talked about.

But I think this is more the the broader community who has questions about Django as opposed to cutting edge features.

I want to make sure I've followed the blog.

And then, you know, if I'm on Twitter, I can follow a few people there.

Django News, I think for a week weekly update is just a super resource.

I mean, it it's brilliant.

You and Jeff are doing an awesome job there.

Do I think more people need to be following the day-to-day conversation on Django developers?

It would be nice, you know, if you've got some time to think about, yeah, come along, join in.

Um, because that, you know, quite often someone will post, hey, I've got a proposal for this kind of thing.

And there's half a dozen people who are like, you know, well, let's not have that because it can change.

Um but maybe you maybe you need that feature, maybe you want that feature, maybe you can talk about it.

And uh, and if you do hang out on Django developers, then well, you know, you can you can have a say, you can be involved in it.

Um you know, it's it's it's the official forum, so to speak.

It's like you we've got the the the forum, which is good for discussion, but if there's anything that's gonna get discussed as is this going into Django, it'll be on Django developers.

And we seek consensus there, and we just you know, we take a kind of um yeah, we try and seek consensus.

We try and see, you know, oh some there's this objection.

Can we do can we work with that?

Can we can we resolve something where there is a general consensus?

And if there is a general consensus, we'll make a change.

Yeah.

No, I mean, but that's what we aim for.

That's super book as well.

Like that's yeah, if

we're gonna do that.

I'm about a third a third of the way through.

You finished it, but it is um working in public, it describes the the plot the the uh dilemmas facing open open source projects, and it kind of describes Django to a T.

Like, you know, yeah, I mean the the issues we face on a day-to-day basis.

And so I'm a third of the way through, I'm really excited.

I mean, it's not because it's got different axes and different um labels, but it's the exact same graph as I put up a Django con a couple of years ago in my uh webnique niche talk.

It's like that's the situation we're in, you know.

And uh I mean I love the the analogy someone made reviewing the books, described the goodwill hunting analogy for open source.

Do you recall this?

But like that's the fellow role, right?

We're very much now um handling the incoming requests, triaging the incoming requests, and we do a little bit of the um uh the code around the the side, but the fellow's job is is to um be the janitus, to keep it clean, to keep it from moving forward.

It didn't have regular releases.

Um, you know, because there's the the three types of projects are you have a solo developer, basically, you have something corporate sponsored by Facebook or Google or whatever, and then you have a nonprofit, and there's not a that's that that structure is not as common, as well as having paid contributors is less common.

Because I think uh one of the, you know, as we're wrapping up the podcast, one of the things um she noted is that what really takes time away from maintainers is is just attention, right?

It's the volume of you know, maybe relatively low quality uh interactions you want to encourage people, but that becomes very draining, and so it's you spend all your time kind of doing maintenance and and inbound as opposed to coding and moving forward, which is the rewarding part.

Yeah.

But sometimes I think I wish I had had fewer emails, but I can't there are these fantastic emails from random people asking me either a really deep question I hadn't thought about or uh rephrasing how I show something or finding a subtle bug.

Um there's fortunately very few bugs in my books because they're kind of out, but um you know I can't just look at something and tell if it's quality or not, it it deserves attention.

Um but there is a cost to that.

It's sort of it can be draining, but it's also educational.

Um anyways, I think we've believed.

We'll put a link to that in the show notes.

Um yeah.

We will have um got a whole bunch of guests coming up.

We'll have guests in two weeks, and that'll be the new schedule, and we're gonna try that out.

It's hopefully be fine for everyone.

Anything else as we head out, Carlton?

I miss talking to you, Carlton.

We haven't talked, you know.

Uh yeah, it's been uh it's just been a funny yeah.

But yes, I've missed uh yeah, missed our little tet that

Looking forward to your talk.

Yeah, join us next time.

Bye bye.