Transcript: Funding Open Source - Jeff Triplett

Try for free at mailtrap.io.

Hi, welcome to another episode of Django Chat, the podcast on the Django Web Framework.

I'm Will Vincent, joined as ever by Carlton Gibson.

Hello, Carlton.

Hello, Will.

Welcome, Jeff.

Yeah, thanks for having me.

And so let's just let's just jump in there.

So this is about a year old.

But why why Neapolitan and why why has it changed how you develop as well?

So we're recording just the final week of March here.

Um and so it's basically a year since I started on my new project, which is parts, which is an application on the in the environmental and social governance space.

But the point isn't the application, the point was that I sat down to write it and I was like, nah, I haven't got the tools I need.

And specifically, I wanted um a simpler take on the class-based views that Django provides.

I for years, you know, you I know all the methods, I know what they all do, but can I remember what class they're on or which set of classes they're on, or what the exact imports for that?

No, I can't remember those things at all.

And um so I wanted to change that and I'd had this idea bubbling away, and I was like, right, no, I'm gonna I'm gonna sit down and I'm gonna write this class first, this this thing first of all.

So I've sort of bootstrapped it in an afternoon more or less, and then a bit of tidying it up to get it released.

But what it is is a sim is a single class-based view, which does all your CRUD methods.

Um so it does the, it's got gives you the list view, gives you the detail view, gives you the create, the update, the the delete views, and with the confirm delete, and and a few basic templates.

But the basic templates are more for bootstrapping purposes, and you replace them very quickly with your own.

But you said it's changed, it really has, it's been a revelation.

No more, no longer am I reaching for oh, where is it?

Oh that you know, it's I know exactly where it is, and it's just like, oh yeah, I'm overriding get context data now, I'm overriding get query set data now, I'm overriding get object data now.

And they're the same methods, but there's no like oh this this goes through three classes in order to resolve it so that one gets there's none of that, and there's no where is it?

It's all in the one place.

So I'm I'm loving Neopolitan, and I did it for me, and that Jeff has picked it up is a really nice thing.

So, you know, Jeff, you tell me about how great Neapolitan is.

Uh yeah, it's been pretty good.

I mean, my one of the reasons that I stay on Django is um the Django admin, and I think the ability to quickly like write Python code, have an admin where you can go in, add data, you know, quickly model what your application is going to look like.

But the issue has always been, especially with client work, because I'm a consultant at Revsys, when I'm trying to hook up a c a new client and I'm trying to give them the ability to write applications or to use an application, the Django admin is kind of a stretch for some people.

It's good, I think, for some of us.

If it's, you know, if it's your first project, it's great.

But whenever, you know, you need you need to kind of like create what's kind of like the admin with some permissions, and you need this kind of filler in the middle because you know, the Django admin being really nice to show like here's a list of all your models and your list views and your cred stuff.

Um, really what what the person using your website is going to want to do is just log into their dashboard and they want to see the kind of like objects they want to interact with.

Like I've written uh Django News Jobs is something Will and I have worked on, and it's a job website.

And so having the ability to use Neapolitan to just get in and see which jobs are available, make a quick edit if I need to, and be able to publish those.

Neapolitan does a really good job of kind of giving you that that middle ground of this is the front end, I can customize it a little more than the Django admin, but you also have the right hooks there uh to be able to customize a form.

Uh and this this is something like I'm I'm kind of uh probably putting words in your mouth because it takes a little bit more of a higher level to do some of the form customizations, but the right hooks are there and you're right.

You don't have to go uh find a website that's gonna show you the 18 layers you need to get to to know which class I need to override and how to override those.

So Diapolitan has been really nice for just here's my model, let's get something up on the front end and let's just start you know cutting away and customizing with templates to make this look like something a client would want to use or I want to use.

The thing that came to mind there was like, yes, you still need to know the patterns from because it just uses the same patterns from the Django class-based views, but they're just kind of squashed up together.

So that's the advantage of it, is they're squashed up together and you don't have this, but it's you you still kind of need that familiarity with, you know, oh yeah, I'd customize the form by doing this, or I'd I've got

So you get pagination that just basically works.

Um, you're shipping Tailwind templates as well for Tailwind, CSS people who like it, uh, which is kind of kind of funny that it's a little controversial today to say that Tailwind is I don't know what it is.

I'm I'm I'm happy for frameworks.

Like I like Django because it's a web framework and it means I don't have to write Python code, and I like CSS frameworks because it means I can just make things look pretty and fiddle with it so it looks right.

And I like HTMX because it's a framework for JavaScript, so I don't have to write as much JavaScript.

So I am all for new frameworks that make my life as a developer easier.

There's been a bit of pushback from the sort of pure what I think, you know, the CSS community that you know, but I kind of feel I feel a disconnect when I read those critiques because they don't seem to ever engage with the reason why I like Tailwind.

They don't, it's there's very little acknowledgement of any of the points that I see the positives.

And it's like, well, we're obviously talking from different places here, and that's okay, that happens.

But I found it a bit frustrating.

I think it's great to use CSS.

And if you really like if that's where you want to spend your time at, that's awesome.

I wish the people that make the critiques that I see retweeted or reposted or whatever it's called today, I wish they took the time to actually use the framework because they sound like people who don't know what they're talking about.

And it's kind of like with politics, like there are nuances to politics that I wish we could get over because we could have conversations about what we don't really like and we could have that tailwind discussion, but we can't get there from the hot takes that I see online because all that is doing is slam dunking and it's being reposted by people who already don't like this thing.

So to me, it's just not a productive use of time.

So yeah, but when I use Tailwind, I get a lot out of it for not much time, and I've learned a lot about CSS now.

So I can actually look at grid and look at Flexbox and understand what's going on, and it's it's just taught me a lot from through that.

So if Tailwind stops being a thing tomorrow, I'm happy to take my classes it generates and keep moving forward.

So for instance, the configuration for the theme is done with CSS variables rather than in this horrible JavaScript embedded CSS in JavaScript thing, which you know I it's that was necessary given the state of the tooling, but where to bring that into CSS variables is going to be much nicer, I think, and much more um forward-facing.

And so I think

I I forget the name of the company that's um that's working on it, but you've got this UV, which sort of kind of replaces pip.

Um, they also replace like pip tools.

And I and I say replace is kind of a bad, like nothing's ever gonna replace pip because pip is so close to PyPI and and Python packaging that they're always gonna create new features and do neat things.

And you need pip to make UV work, but it's nice seeing tooling that I can use and run.

It takes like a half second, something that used to take 30 seconds to resolve.

And like I've seen GitHub action build times drop in half.

Uh local development experience has gotten a lot better through these tools.

And so I'm not quite like, ooh, something is something is good because I see it written in Rust, but I'm liking what I'm seeing, which is people are really excited to start working on these hard problems, and they're using a language that in theory should be a lot faster.

So I'm I'm I'm happy to see that.

And just to clear just to sort of double back and clarify that, you've been using because I haven't had a chance to pick up UV and really play with it yet, but you've been digging into it and you've been having good success.

I've kind of written a couple of blog posts on it, um, just because it's just quick and I've yet to see it really fall down.

So I've kind of been documenting it as I go.

But yeah, I've used it for GitHub actions.

I do a lot with containers, as you know.

I do a lot outside of containers to kind of bootstrap my IDE, which is kind of a weird concept.

Like when I started writing code, I thought, ooh, I want to make websites or make video games or do something cool.

And now I feel like I spend a lot of time like making IDEs happy, which is something that nobody thinks about when they're a kid and says, I want to make my developer environment work better.

But yeah, I mean it cuts, it shaves minutes off your off of your, you know, context switching.

And anytime I merge a pull request, I have to rebuild, you know, the server has to rebuild, code gets deployed.

So it's it's kind of cool seeing like your bills get cut in half and developer experiences not be a thing that we joke about.

Like, I'm gonna build my containers, let's go get coffee.

So yeah.

But it's it's just it's boring tech and it seems to work well.

Good, good, good.

Uh I think you and I, Jeff, were just talking because you or you you posted about you you still like tower, right?

Whereas Carlton, you like fork, right?

Just to give a shout out.

I I'm not saying you do.

Like plenty of people don't know about UV.

Now they can go check it out.

I think, I mean, for me, I just use the GitHub desktop, but I don't do complicated Git stuff.

Um, but all these tools to have a visual representation is so helpful over I don't care how much you've configured your command line.

Like it's helpful to see all the branches and everything.

That they're few and far between, and they're not us normal mortals.

Um, but it's not necessarily a skill you need to have.

Yeah, well, you know, he has this whole um book-driven development, right?

Like in writing the book, he started contributing to Git, and now he's some way has you know, somehow involved directly in that community.

Um but yes, anyways, shout out to those tools.

I don't Jeff, do you know?

So it's Astral is the company behind UV.

Is I'm always suspicious of VC backed companies making open source tools.

Not that we can't use it, but like like how are they gonna make money?

How are they gonna like how is it all gonna work out?

Right?

I mean no, so HTMX to me, one of the things that's great about it is we've had uh Carson Gross, the founder on he's like he's just gotten some grants, but like it's not VC backed.

Like it's his thing, it's open source.

To that to me, that feels much more sustainable than something with a a clock ticking where they're gonna have to go into hosting or selling data or something.

Um I think I put my first website up on the internet in like 1997, and so I've kind of been seeing open source since the 90s.

Uh, that dates me or ages me.

Uh and I I think I tweeted this or blogged about this a while back, but I really want a couple of decades of us taking money for open source before we complain about like what the interests are or what's gonna happen with like the money used.

The worst case is this is open source software.

And as we've seen with Redis, as we've seen with other projects, if a day comes that they decide to change the licensing or change what the tool does, these things are open source.

We learn from what they have built.

People can fork those off and go advance it however they want to.

And you know, and and some of these VC, I've read a couple of the articles that they've linked to, and basically it was some acknowledgement, and I don't want to give VCs like a I want them to come out and like go to their conferences and say this for themselves because they're not paying me to show for them.

But there there was some talk about, and I believe I read this, where they said, we're okay putting money in the ecosystems because this helps our other businesses and this helps technology, which makes us indirectly money.

I think we should embrace that spirit.

And like I said, I I put that on their shoulders to go out and start saying this more publicly in a bigger platform.

But I think we need to see that because we have a lot of companies who do open source and they're not really projects that actually leave the companies and they pat themselves on the back because they're getting a tax break for RD, and they don't have to pay taxes when they when they pay, you know, they don't

Don't worry about that.

So, like if they're opening up their checkbooks to pay foundations or to pay smart developers to have a team of four or five people to work on stuff, then I think that's yes, let's do more of that for a while.

Then we can uh see the Netflix series for how things went wrong and how, you know, movie ruined the Python ecosystem, right?

I think it would it be too bad if we were in the position where the bad consequences had turned up, because at the moment they're just hypothetical bad consequences, and there's got to be a quite a bit of runway between where we are and where we where those bad consequences come out, which is a net gain, right?

Like that's the system working, right?

So totally, totally right.

I mean, the uh Django Olaf just got uh Raymond Penners just got a grant from I forget the name of the foundation, but that's seems like it's gonna be an amazing thing because he's been doing an unbelievable job with that project for over a decade, and now we'll be able to, you know, add add more features.

So yeah, we'll take we'll take the money and worry about the consequences.

You know, but because also like what was it, Nginx, right?

They uh the the developer sold it or something happened, and then now he's forked it and has I forget the name, but like you

Because it is open source, so you know it's it's not proprietary.

So that's that's interesting to see.

I'll give one more shout out to the other.

Oh, maybe I was thinking of Reddit.

Maybe I was thinking of Reddit.

No, it's both, it's both.

So they they both recently got forks which are you know more open source, but like the Redis has

just changed.

Um one more cool thing uh I was just gonna mention, and Jeff, this comes from you as most of my open source projects too, is is Zed as a text editor from the Atom crew, which I've only briefly played with, but seems quite cool in terms of a fast, you know, open source text editor.

I assume they're using Rust, though I don't know.

Um that's another

So yeah.

It's just a like the kids go to bed or whatever, and I'm watching Netflix, or it's been basketball because it's March Madness.

So when this comes out, everybody will have the madness will be over and there'll be a champion who's not Kansas, my my home team here.

Um yeah, I've been playing with it kind of like on weekends.

Um there's not a lot of configuration to it.

It runs the Dracula theme, which I really like.

So that's really the only perk I've seen, and it's fast.

So I've just been kind of using it to dabble.

Um, I'm not changing to it anytime soon.

The fact that you can't customize it more, or I'm just too stupid to know like where the extensions are and how to install them because they're written in Rust.

So I don't I I can't figure that part out, and there doesn't seem to be a package manager or anything.

So I'm probably wrong in that assumption.

But it looks pretty neat, and I've enjoyed that it's the closest thing to having a fast search since Sublime Text, which is one of the reasons I use Sublime Text over the Qt C IDEs.

So yeah.

But yeah, then they it went away.

So anyway, so yeah, so that's that's another cool tool.

I do want to sh shout out Carl, I keep I you I keep interrupting you, Carlton.

One thing I want to say, we'll put a link to your talk on Neapolitan, but I think the context is important, which is that there is uh for people who aren't as familiar with Django, um, classy class-based views, there's this amazing website that helps you understand all the uh methods and all the rest in classes you should look at.

And Tom Christie's vanilla views inspired both the project and the name Neapolitan, which I think most people think about.

Right.

But I think quickly, what are what are his vanilla views, which is not a a new project, but I don't like I didn't I hadn't heard about it until you mentioned it to me several years ago.

And so you end up with I think a basic form view and then a create view, a list view, a detail view, and a destroy view.

And that's all that's all it's wonderful, and it it they're really simple and it's worth going read the source code.

And once you've have a look at the vanilla view source code, all of a sudden it's like, oh, I see what the Django generic views are doing.

It makes it starts to make the control flow much more much more sense.

So you for years I was using um vanilla views, but say for instance, um I'm I've got a model, and um that model is restricted to uh for the current user, that it's a subset of all the instances that model.

So I'm gonna have a get query set model.

And it's gonna the first thing it's gonna do is my model.objects.for user and passing the request.user.

And then that's the base query set.

And I don't want to have to rewrite that every single time for a you know, so I write I do my list view, and then I need to sort of copy and paste it into the detail view, or and then then or I need to create a mix in.

It's like I don't want to do all that.

And so CrowdView, uh, Neapolitan's Crowdview is just takes the vanilla views and squidges them together and it adds like the Django filter support and a few other bits and bobs.

So it's a little bit more than vanilla, it's it's Neapolitan, which is the chocolate strawberry and um vanilla ice cream.

So that was that was the inspiration for the name.

Um and I'll just, you know, floosh and uh uh uh for a moment more is that I find it really amazing because I create a new model, I just create this the one instance of the CRUD view, and then I can work my list view quickly, and then there's a make template command.

So I go, all right, I now need to override the list template.

So I just quickly make that template, and then I'm like, I'm working on the detail view, and I just do make template detail, and then I override that and I can customize it.

And I I have only had to edit the URL conf the once.

I've only had to create the one view class, I've only had to create the get query set once, or the the form class once, or the filter set class once, and they apply, they're they're there and ready to use for all the different models or all this all the different uh methods related to that one model.

And so a good example is when I want to add an extra view.

I've got like um say you've got a user attachment field, and so it's got a name, it's got some metadata, it's got a link to another model, and it's also got a file field where you upload the actual file.

And then you want to do an authenticated download.

Well, you've got the authentication, you've got the deep the get object logic, you've got the permissions checks already in CRUDView.

So you just add an extra, one little extra handler and then and return your file response, and there's your authenticated download view.

And it was really quick and easy to do.

And you again, I didn't have to end it, edit the URL conf, I didn't have to find the right base classes.

That's why I like it.

Um yeah.

And you know, it's kind of all we're doing on a certain level is is that kind of stuff.

And you know, yeah, I can go get the user passes test mix in and update the test underscore func thing to for the user, but then I'm I'm like literally copying that logic, as you say, from list view to detail view, because it's the same kind of thing.

I'm just query set to a an object.

I'm just trying to improve them.

And one thing I want to do is have a little quote at the top.

And so um one quote I want on one page, Will, is you saying saying that 95% of all apps are crudged, you know.

Oh yeah, sure.

But it at the end of the day, it's it's kind of the same thing.

But you mentioned templates, um template partials.

Talk to me.

So, you know, we talked about Tailwind.

Let's just leave Tailwind on the side.

I'll just as it's there, it's like you get a file where you've used Tailwind, and the other things I use is HTMX, and then the other one I use is Alpine.js, and then I might have a couple of the Django template language with the all of that in.

And you get this file that it at first glance it looks like an utter mess.

And you're like, how would you how how can you live with this this file?

But actually, it's like, oh no, but that's that's that and that's that, and it's all in the one place, and it's this idea of locality of behavior of doing everything in one place, and it's not the end, it's not the end goal, right?

Locality behavior isn't the final position when it gets too complex.

Yeah, I can break that out into some separate JavaScript, or I can break that into its own CSS, or I can break this into a separate view.

But tell you what, when you're getting going, it really does speed you up because you're not having to cut and paste them which tab was it and where is it?

No, it's right in front of you.

So I like that.

Um, but HTMX, you you you'll replace, instead of doing replacing the whole page, say you've got, I don't know, a detail view and you want to quickly edit it and then I don't know, a book.

The example I used um used in my talk last year at DjangoCon Europe was um a bookmark, and you've got is it a favorite?

Well, okay, you just want to update and is it a favorite and then refresh.

And so instead of sending refreshing the whole page, submitting the form of submitting the whole page, you'll just send the Ajax request and then you'll just get a small snippet of HTML back, and you'll just slot that in in the right place in the template.

And that's amazing, but what normally happens is you've got um a big template, and then you just want a teeny weeny weeny bitty bit of it from it.

And template partials enables you to name those those itty bitty bits and then ask the server, just give me that one itty bitty bit rather than the whole document.

Um, and so I create this little package Django template partials, which seems to have been well received.

And again, I'm loving it.

There's no way back for that for me now, and I'm hoping that we can smuggle it into Django for 5.2.

I'm gonna make the F, I'm gonna make the F.

I'm gonna make the pull request, I'm gonna try and get it in, and it's um hopefully we can because it's you know it's been very important

It can, you know, by default it's rendering pages, it can render snippets, but it doesn't have that good way of saying, cool, only give me this one snippet.

And so I like it.

I use it for tables, I use it for forms.

Um it's it's just kind of a pattern that once you start using, it's like, why has this not always been there?

And so I hope that does make it.

What's new with you for those who are listening?

I think they're amazing.

So what I've noticed this trend is that people are very passionate about if you should use function views or you should use class views.

I just use whatever I need because I'm lazy, and sometimes that's a function view, sometimes that's a class view, and I don't think about it.

But my question for you is how come people that are so passionate about using function-based views argue with all of their life that we should use class-based tests?

And people who are like so pro on class-based views say just use functional tests, and it's this like weird divide where people are like it's all one and one and the other in these areas, but I've never seen an argument for both, like only functions in both areas.

Um, I'm I totally have to use PyTest, but you know, um the I think unit test has all the features we need, especially with subtest.

So the one the one thing that was really nice before subtest came along that I thought that PyTest brought was the parameterization where you can run the same test with different inputs time and time again.

And with subtest you get exactly the same thing, just a different structure.

But that's the thing, it's just a different structure, right?

Whether you a class, what's a class?

It's a namespace, it gives you somewhere to, it gives you like a scrap of paper on which you can doodle, which is safe from the sort of the rest of the code outside it.

So quite often you can break it, you know, break your code up and you're I'll put it there and you can, and it's might be horrible, but you've got a safe contained interface inside that class where it doesn't really matter if it's a bit dirty.

And I think the reality is certainly the reality when I'm coding, I don't know about you, but when I'm coding, I have often no idea exactly what it's gonna look like before I've written it.

It's in the process of writing the code that I find out how it's gonna work and exactly what it's gonna look like.

And sometimes I need to know that that's wrapped up nice and safely and tight.

And by doing it in a class, I've got that namespace which keeps it safe.

And I could do that in a module, I could move it into a module, I could just do functions in a module, but you know what are you trading then?

You're trading a file for a level of indentation.

Well, is that a good trade-off?

Well, it depends on your project and you know what it what the rest of your code looks like.

There is there's no point being religious about this, right?

It it function-based views, class-based views.

Well, the class-based view is nested in, it's got a self-parameter, but it's inside a namespace.

That's the trade-off.

I don't know about testing.

I don't know why people get so religious about the testing.

Like, but but maybe you've got a view.

Like, am I wrong on this assessment that people seem to be really like, you know, all the excuses they say are reasons.

The reasons they like they don't like classes, then they just it just flips over and they forget those.

It's like amnesia when they start talking about like why they like using them for classes or for tests.

I think it's fine either way.

But then, you know, how do you organize your tests?

Well, you might put them in a class, and that's okay, it lets you.

Um I like PyTest.

But I'll get that eventually.

We've got to get that going quickly.

It's it's did that answer your question?

I mean, that's my take, is that they're just different, it's it's different, different ways of looking at the same problem.

I I like PyTest.

I like using PyTest as a runner for Django.

It's fine.

Um, I I feel like it's easier to explain uh tests to somebody who's new and show patterns that don't have the the cruft of like what a class may bring.

But you can write class-based PyTest tests too, so that's fine.

Why are you on, Jeff?

What are you go you're on?

It's been uh what is it?

It's been a while, it's been over a year.

Um what I think we probably talked about Docker a bunch in the past.

Well, maybe you and I can talk about so we we still have the Carlton, go ahead.

I'll go.

Um you've got me started now, you can't shut me up.

I want to ask about Django packages, Jeff.

You've been doing a wonderful job there.

I want to see what's new and you know what your thoughts are and you know how that how's that all going?

Um I wish I had something more exciting to say about it.

Uh we basically have just been whenever I when I started maintaining the project, um, it had kind of been outdated for a while and it kind of needed help.

And so all I've tried to do is keep the lights on, keep it running.

Uh we've upgraded the latest versions of Django, so I believe it's running on Django 5 as of the time you're listening to this.

Um we're either on Python 3.11 or 312.

Um, so we we basically kept it up.

Um we've also started working on some rules behind like how packages get scored and how the um there's these grids which do comparisons of like Django all auth versus Django not all auth.

And you know, and there's and that's something that I wish we'd had more time to really tackle because I think that resource basically right now it shows you like how many GitHub stars something has, which is popularity, and it kind of gives you an idea of when it was updated.

And so we're we've kind of had some behind-the-scenes rewrites where we're trying to make like why does my package score higher than something else that looks like it's the same?

How do we normalize the number of like you know, we GitHub stars shouldn't determine what the best package is because something could be 10 years old, hasn't been outdated, hasn't been updated in forever.

And then like a newer package that has been maintained for four or five years doesn't quite get the light shined on it that it needs to.

So we kind of have some behind-the-scenes work where we've got a scoring system that's like semi-connected, and we're trying to write a UI around that that shows you like, look, you know, the here's why you don't get these 10 points because of this thing that you need to address.

And by going here, let's let's link you to the docs that shows you transparently, like, how do I improve my package?

Because you know, healthy packages, maintained packages, I think is good for the Django ecosystem.

And it's also just this big catalog of like, I think it's like five or six thousand packages in it.

Uh, I check PyPI occasionally, and there's probably like 14 to 15,000 Django packages.

We could pull all those in, but that's a lot of potential garbage.

So, yeah, it's a hard project, and the grids have gotten so kind of unmanageable that I've spent a lot of time thinking through like how do we restructure this, how do we rebuild it?

And so I've got some ideas.

I've been short on time.

Um, I was on the Django or the sorry, the Python Software Foundation board a couple for last five years.

My term expired in the fall, and so I have time again, and it's been really good.

It's um that it should have ended in the summer, but it took them a little longer to kind of like get their wheels, you know, kind of land on their feet and get the new board going.

So I still do a lot with them.

Like I'm in a couple of work groups and kind of advisory stuff for them as they need, which is it's a healthy place, but um it's just I don't have to think about it, which is is good because five years was a long time, especially pre-during, and it's not quite post-pandemic, but things are at least going a proper direction.

Where for a while we feared every winter, and so that's really hard with PyCon.

It's really hard, like with uh something the size of a Python and trying to worry about like are people gonna have jobs or what are we gonna do?

Or is there my family gonna be safe?

Is your family, you know?

So it just was a very stressful three of the five years.

And you you mentioned there um PyCon.

Um, are you still involved with DjangoCon or have you managed to step back a bit there as well?

I'm still on the board.

So my goal there was just to step back, be advisory, and then we have a new board.

And part of it too is like because I was the president for like seven of the eight years, I think.

Um there's just a lot of institutional knowledge.

And I also chaired for two or three of those years.

And so it's just not an easy thing to give to somebody.

And we haven't really had the same level of like, you know, PyCon tries to get someone to be the chair for four years, and so someone will be like the vice chair for two, and then they become the chair for two, and then they get the next one in.

And we've just never really had that.

A part of that was because of, you know, maybe the, you know, because DjangoCon is newer than PyCon.

Part of it was probably because of the, you know, the pandemic and not having a conference in person for two years.

Um, it's just it's harder to get that same continuity.

And so uh we have a wonderful group.

Uh last year, because we had an in-person conference, we were able to get like newer people who are more interested in continuing.

And it kind of, you know, poor Drew has been the program chair for four or five years, I think now.

And we've had Adam doing A V for four or five years, and we've kind of had the same people doing a lot of things that, you know, we kind of we kind of like burn ourselves out in some ways, and people are doing it for the right reasons, but it's also important to get, you know, new blood, new volunteers, get people, you know, who are more interested in doing things and bringing some new element to the conference.

So I just try to like help them with things.

Like last week I had to go to the bank and do a bunch of like boring tasks that nobody else wants to do.

But, you know, and we're looking for a new treasurer, which I hope, I don't know when this podcast comes out, but that news may be we may have already ended things.

Maybe so yeah, it'll be over by hopefully mid-April.

So we have a new board member we're looking for, hopefully a treasurer.

Uh, we're kind of rethinking how we do treasure, trying to find like a firm or something as well that we can pay to start doing some the day-to-day bookkeeping for us.

Um DjangoCon US too.

I think April 24th is when our CFP ends.

So that'll be over.

And you all would have applied, and we're we're hopefully like looking at your uh proposals by then.

I I applied.

Uh I you you helped convince me, Jeff.

Two talks actually.

I missed last year for you know family reasons, and I'm lining up that that I've got another four weeks to craft the the the perfect um submission, and I will I think I I will make it this year if I can.

Try for free at mailtrap.io.

How does this affect DEFNA?

How does this affect the PSF?

And you know, it wasn't like I didn't have a lot to do, anyways, because I've got two kids and they're young and we're just kind of hanging out.

But, you know, sometimes it's the it's just a lot of extra external pressure there that I'm kind of happy to not have to really think so much about it.

Like I do these office hour sessions on Fridays sometimes.

Um, I haven't had one in two weeks.

I thought I was gonna have one this Friday, but then I found out it's a holiday.

If I don't have it, uh, I don't have to worry about a conference not happening.

I don't have to worry about people not getting paid.

Uh, I don't have to worry about the same level of stress, right?

That sounds good.

I think what you've described there about bringing in new people and having a kind of continuity.

I think exactly the same thing is going on with Django at the moment in terms of lots of people have stepped back.

And okay, so there's lots of young people coming in.

And how do we how do we manage that transition?

Has that came out yet?

Wait, when did she start right away?

What's the timing on the start?

I didn't know.

Or would have started.

Would have started second

Will have started, yeah.

Well, I think it's also just it's interesting.

I mean, the this podcast could be three three uh retired uh volunteer people in a way.

You know, I didn't do five years, only two.

But yeah.

But I mean, right, you know, the old sayings, the meat grinder for Django, I certainly saw some of the older gener or the previous generation, you know, just completely step away.

And the, you know, it seems hopefully three of us are an example, it's like a little more manageable where you can step away and lose that just, you know, again, those little things that like grind away at you, but still be involved, still be, you know, you're doing open source, like we we do the podcast, Jeff and I do the newsletter, right?

Like you don't have to fully step away and having new people come in, you know, because there is so much knowledge just to pass on, it's a lot it's less burnout for the next people when there's a smooth transition instead of like walking into a situation that's on fire.

And you know, it's sort of like ah, we're in this this weird thing now.

I'm not I can't stop now.

Um, but I wanted to stop before it got to the point where I'm like, oh no, you know what, I'm fed up of Django.

I want it, I'm I'm I'm in I'm in love with Django, I'm love building with Django again.

But if I'd have stayed as the fellow for too long, I'd have become disenchanted.

It's not like you know, you you can bait like if Python has a bad release, there are hundreds of weird news sites that want to like put some headline and make it a security issue, right?

Like it's gotten really weird.

Like when we started doing Python, I never thought that there would be like every Friday when I check news, there's like made-up security stories because like Python has a module that can read and they can delete files.

And like that was literally a headline one time.

And I'm like, it's programming language, of course it can believe that.

Like, you know, you can you know, you're on terms now where like if Django has a bad release or there's something, like there's there is pressure there to do a release and to be solid.

And and the fellows get a lot of that, I assume, uh a lot of that stress and a lot of that pressure put on them compared to I go publish something on GitHub, and if it doesn't work, I may fix it in a week, I may fix it in a night, I may not ever fix it.

That's just you know,

There's when you release Django, there is a pressure, and that's why it's one reason why it's um so uh risk-averse to breaking changes because literally every time we change anything, there'll be five issues opened within about an hour saying you broke my you know, broken, and you're like, Oh no, now we have to fix it.

And yeah, it's it is pressure compared to oh yeah, do you mind just pinning to the last version while we work this one out?

It's yeah, you know, which again is available for Django, but somehow it's not quite the same, you know, that same level of like acceptance of that.

I don't know.

As you said, Jeff, these little things like a Friday, and just at some point you go, hmm.

But then it also takes, I think it takes a good six months to kind of have that dissipate a little bit, right?

I mean, both because whoever comes in still probably needs some help with things, but also just to like settle your mind around the idea that um you don't have the separate email account or you don't have these regular meetings, like it it you're you're there's a transition to that openness that then lets you do new things, do fun things, you know, maybe do the same thing but without the pressure um or less of the pressure.

We're like when I was done with the PSF stuff, then I didn't think about it.

It's like cool, I can I can go do these other things now.

And uh it was a little weird because of some of the advisory stuff, but you know, they're in a good place and a healthy place, and I am too.

So that's that's good for me.

The uh about you know working out kind of a not I use this, a kind of package role.

Like how you know, it is this something we could do with Django packages, maybe like to you know have a user account and tag our favorite packages or something.

Because if we had an ecosystem of of users, we'd it would help to bubble up to the top, the good the good ones or something.

I mean, do you have thoughts in that space?

I'm not giving you work here, I'm just sort of

Would love uh both contributions to the code and the docs to help people get on boarded.

Touche.

I I don't know if it's the right place or time, but Django Knots is kind of we've we've talked back and forth about like would this be a good project to try to get somebody from Django Knots to work on, and maybe if it's not the next session, maybe the next one, and maybe that's the right level of feature somebody could do.

Some of this already exists in Django packages, it just isn't really turned on at the moment.

I don't know if that was a spam issue or something in the past, but that's something I need to look at because we were talking about it on, like you said, the social thingies.

Um, I like the idea.

I also like the telemetry kind of idea as well.

Like, I would really like for somebody to be able to like install something and in a non-bad way be able to say, like, you know, go report my packages that I'm using in a secure way so that we could start inventorying like what packages are actually in production, versus like I like Carleton and he writes four or five projects that I basically install in everything.

So those are always going to be popular, but like, is it popular because I tell people about it versus like I would really like to get to the core of like what are the boring, maybe there was it HTTPX libraries that replace requests.

Maybe those are really core and we should know more about them, other than just uh Amazon uses it, so it gets downloaded a lot because everybody uses Amazon CLIPs, right?

So like I I would like some level of like being able to do that as well.

So yeah, from a user perspective, the ability to go in, I think that's kind of there.

I think we just need to dust it off and put a better UI around it.

And also because there's 6,000 packages, I don't want a lot of spam where people misspell a package name and stuff like that.

So there's got to be some level of like, does this already exist or does it get queued up?

And then how do we go?

Because most of my time spent on Django packages is removing spam.

I wish I had more time to write code.

And I, you know, like I spend maybe once a week I'll upgrade uh security updates and stuff on the site just to make sure, like, you know, that that's a big enough site that people will try to hack it, and I want to prevent that.

And just one more one more thought that came to mind um was you were talking about the grids and them getting out of hand.

But I use I find them they're they're still a really good um research tool.

So, you know, if I I've got I need a feature, oh, this has been done before.

Let's have a little search around what exists, what options were taken.

It may be that you know the 10-year-old package that's on Djang Django packages I don't use, but it had a kernel of some good idea that you think, oh yeah, I could do a similar approach.

And so I still I think there's value in keeping that that that size of packages and those grids.

I think there's something you know useful to be able to see the one thing Django always has is like, oh, Django plus the thing I just thought of, and then there's always a package that someone took it on, right?

At this point, to be able to keep that would be is useful.

I don't want to I wouldn't want to see that disappear.

That would be sad.

I'm not saying you're saying that.

I might the issue I think is um most of the metrics it uses are things that get collected, and there's not the curation.

And Will and I are big on curation, you're good on curation, like you're curating guests that come on your podcast.

Uh in the newsletter, we curate things that we just like, and then same thing with awesome Django is curation.

It's a project that Will and I run as well, which is like curating packages.

And so I don't think the tools exist that make um curating Django package grids easy.

And I would like to make that an easier perspective because I think they're outdated.

I think there's this tendency that someone comes up with a new package and they think of here are the eight things my package does, which is cool.

So they'll go and they'll add features to it that maybe don't apply to other things.

And there's not really any motivation for them.

I don't think anybody's being dishonest, but it's also there's no real motivation for them to go back and see a grid with 80 different packages in it and want to go ahead and fix that.

So, like I played with like making it more that you see a list of things and you can compare maybe two or three together, and we kind of rank things by like a percentage based on quality scores.

But I want that curation bit, I want that to be factored in a way so when you look at a grid that you can get some kind of a quality metric as well.

And that's where it's it just takes a lot of time to come up with that.

But that's like if I had nothing to do, if you if somebody is listening to this and we'll write some Rust code in it so we can get the VC money, but if you want to fund this, we can totally make this happen where we focus on the curation, and that's something that could apply to Flask, it could apply to Fast API, it could apply to other bits as well.

So that's my pitch is come up with some money.

We can do a podcast about it every week or two weeks, and we can also like you know, like fix that issue.

But you're absolutely right.

And there's a couple of tickets about bringing back like grids of the week and packages of the week, and those tickets there, if you're if people are interested, go to those tickets on GitHub and put put your thoughts in because really we just need like we need bodies, we need people who really care.

And if you took one grid a week or one grid a month, even and just go through and just try to clean it up.

And I think we've got enough people helping that we could probably develop the tools a little faster.

Hell, we could throw Neapolitan and make it make it even even quicker to do the cred views on it, right?

There's things we can do to facilitate that to get there, but it is a community project, and we need more community with it because there's basically three of us working on the project right now.

So yeah.

I'm so bad with names.

So I'm trying my best to just not

So don't worry about it.

Well, there is um there's this uh uses this site, you know, uses this.com, which like that's that could be a cool thing if somebody's even you know slightly less technical, right?

If Django Packages had just you know a member of the community or just a regular person to anecdotally share their packages because that is an interesting way to I mean it depends on if somebody, you know, in terms of what someone's using, they could be if they're a consultant, they maybe have a little more leeway to try things, but a lot of people are at one company, and so it's like, okay, what am I using at work?

But what am I using for a new project?

But maybe my new project is very specific, so I would reach for these other tools, but I don't need them in this case.

So you know so that could be a cool I love seeing things like use as this or just you know quick takes on stuff.

I now you say that I seem to recall that um you you did a blog post on this, Will, right?

Recently.

This is how the conversation started because you posted your 20 my your 20 packages that you can see.

Yeah, yeah.

No, there it's on the forum.

Yeah.

I mean, there is a yeah, we'll put a link.

It's on the forum, I think it was a a couple years ago now, and people still um add their things.

You know, it was like top five or top ten packages.

But yeah, it'd be it'd be great if that was a little more systematic because uh, you know, actually I just I just peeked at the site and I see that our our next guest, um Justin Duke from Button Down is on use is this, right?

So you know, we could do just a Django subset of uh of that.

Anyways, that would be a nice idea because again, yeah, it's the discoverability and it's the curation.

And as we've talked about, everyone wants curation, but creation is hard and it takes time.

And um you know, one I mean it it's been so great having Jeff on awesome Django, because I definitely would have stopped doing it the way the person years before stopped doing it um because you get pull requests and stuff.

But even now with like Django News, now it's big enough that we get uh very corporate emails sometimes from people who want free publicity for stuff.

And while we like getting quick emails about hey, check this thing out, it's a little different when it's like, hey, check out this thing that like my company did, you know, blah, blah, blah, blah, blah.

Um, that's kind of where the curation falls apart when it's people doing it.

So, anyways, I'm all for it.

I kind of wish other people did the creation, but I think it has value to have some curation out there.

Um so sustainability.

I've followed that site for I feel like 15 years or something.

It's been out forever.

Um, I ideally like I would love to have more of a product hunt like vibe to Django packages where you can go and if you're logged in, you see like what are your friends liking?

And we kind of deal with this like well, there's this pattern that happens where somebody comes to like either Django News or they come to Awesome Django and they're like, here's my cool shiny thing that nobody is following, nobody's using, or I'm a really big company and you look like you're an employee of this company.

Here's this new open source project, and I'm air quoting for the podcast listeners.

Here's this new quality product that we found.

We kind of get both of these things, and those things are fine to get.

We've just tried to refine a little bit of like when you go to Awesome Django and you submit something, like we have a list of questions which are like, Did you write this?

Are you a company?

Like, just just tell us exactly the situation here, and then we'll probably include it anyways, or not.

But like it just kind of steps through the let's not be disingenuous about these these things.

And so I would like to see like this product hunt kind of view too, where you can go to Django Packages, take that energy that you have and actually submit it, and then get people excited about what your package is and try to make this more of a positive energy thing, where then you can go and get 20 of your friends to like your up, you know, upvote or comment or do something, and then we can kind of facilitate like, hey, here are the cool new things people are liking this week and give people kind of a reason to want to go and you know get behind Django packages as well.

Like, I would love to have more of the positive kind of experience like that, and less of the just like, I get it, this is your job, you need to show your your corporate service, and it's probably really good.

Like it may be a value, but like I don't know that Django news people want that.

Um, or there's sponsorship and just go sponsor this thing.

And then people understand, like, cool, this is a product, maybe I need it, but at least it says sponsored and they understand that this is what the this is what the relationship is instead of feeling tricked by something.

And I think from an ecosystem point of view, something like that would just be amazing because you know, we're always like, oh, you know, Django's secret source, or one of the secret sources is the third-party package ecosystem, but then we say nothing about it, and you're kind of on your own about on discovering which of the packages you can use or should use.

Uh yeah.

So there's that.

But yes, otherwise it's fairly it's fairly quiet.

Um, but you know, again, that's because rightfully so, the the Django Software Foundation, the people behind the uh official docs don't want to be in a curation position, which I don't

Um the other piece of curation, I mean, specifically thinking about awesome Django is you know, the whole point of curation is eliminating things, right?

So it's like we do add things, but then you also need to go through and eliminate things, and that's not fun to do.

Or it, you know, like we don't have awesome Django so we can take the shine away from other projects, but if it's a dead project or a project that hasn't been updated in forever, um that's also part of it.

And that's kind of the like not as you know, that's that's where like the pressure kind of builds.

You're like, ooh, I'm not, you know, I'm not getting paid for this.

Like, this is really not enjoyable what I want to do, and I'll do it occasionally, but like we could probably remove things more that are a little more dead.

Um but actually, but speaking of things coming back from the dead, Django Rust Framework, uh, Carlton, 315 is finally out.

Um is there anything you want to quickly say about this?

Because, you know, so uh just as context, I I still like Django Rust Framework.

I know Django Ninja is very popular as well, but Django Rest framework has been both pretty feature complete, but also it didn't have support for 5.0.

There's there's a long list of things on it, and so I was so happy to see uh the first feature release since in a while, a couple of years.

A couple of years, yeah.

Yeah, I mean, what would I say?

There it's been a slow tick of not really anything on on the main branch, just you know, like for instance, when 312 comes out, somebody adds a a PR for the test matrix, and the test matrix passes.

And okay, so it's compatible, but it's not it's not, you know, on the on the official stamp, it's not there's not a new release that says it's it's compatible.

And it's like, well, okay.

And so anyway, it there's finally been a release, and that that the problem is not the problem, it's a good position to be in, but REST framework is feature complete, it's a job done, but it's also used by so many people that changes you might want to make are kind of no longer makeable.

You can't restructure the generic views because you'd break too many projects.

Um, and so uh it's very difficult to then take take a feature request and say, Oh, we could restructure the mix-ins to make them reusable, you know, in this way or that way.

It's like, but you're literally gonna break everybody if you do that.

And so ultimately the only responsible thing is to say, hey, it's kind of it's frozen, and it, you know, we'll update it for you know the new Django version or the new Python version, or we'll fix a security bug.

But beyond that, it's kind of this is what it is.

Um, now I you know, and I don't think there's a way around that.

Um so you know, Jeff, you've been using Django Ninja.

Tell us about that.

Uh Django Ninja, I like, but it is underwhelming in the ways that you have to go back to Django and see how to do something with Django.

So I just want people to know that if you go get Django Ninja and you start looking for things like how do I do authentication or how do I do permissions, you need the you need the bail back on Django's docs, where if you're coming at it from a DRF perspective, DRF has its own, it's enough of its own ecosystem that the docs are gonna tell you how to do the common things that you want to do.

Um and I think it's just a smaller project in general.

That for me, like, and I've written, to me, it's just fast.

Like, I just want to but look fast as in very quickly putting up an API.

I've not done anything that's super robust.

I think you're still gonna have the same issues where you have like nested serializers are still gonna be hard.

Um, and it especially if you try to update those.

What I like about it, and even if I'm not launching APIs with Django Ninja, I find that model schemas, which is Pydantic, which is written in Rust, you knew this was gonna come back to Rust.

Pydantic is incredibly nice to work with, and it's really nice because it has a wrapper.

And I would, and honestly, I would love to see DRF consider at some point like what it would look like to use something more like Pydantic.

Because not only does it validate, I've been using like model schemas, which is just kind of like a data structure, but you can say this schema is gonna read from a Django model and it's gonna understand, like, oh, you have a created date, you have Boolean fields, you have these things, and it can marshal and kind of like massage data.

So if it sees a text string that looks like a date, it's gonna parse it for me and give it to me for free.

It also just natively works as JSON and as a dictionary, and it just does this like converting from one format to another.

So uh Lacy uh Hinschel and I are working on a project for a client and we've been doing a lot of data imports with like CSV files.

And I don't have to massage much as far as data goes with Pydantic and these model schemas because it can pull the data in and know, like, cool, Booleans, trues, falses, sure.

Dates should just work as dates and get cast correctly.

And it's just been really nice to be able to change, and I've got a blog post about this too, where I talk about kind of changing the shape of like one data format to another.

And it's just as incredibly nice to work with in that perspective.

Uh DRF, I still, that's what's going to pay the bills for a while.

I hope that there are improvements made over time.

I totally get that it, you know, I understand why you want to keep it frozen and why that makes sense.

Um, I would just explore like what is the difference between a model serializer and the model schemas.

And and I would actually like to see model schemas come out of Django Ninja.

And that's something that I don't know.

I don't I don't have any say in in Django, but I would like to see some of those bits eventually land in Django itself, whether that's the model serializer approach, whether that's model schemas.

And I feel like model schemas is more forward-facing right now than than some of DRF's bits, but it's a nice experience to work with.

Uh Frank Wiles, my business partner, um, he says hi, by the way.

Um, he really likes Django Ninja too, but we're both kind of at the same point.

It's just like, what can I, what kind of speed do I get out of Django Ninja?

Because it's not having to do as much.

You know, it's not doing the 80 things that DRF does and is battle tested, but it makes just the simple API views just kind of nice and quick.

And, you know, you're like, wow, that's not a lot of code to do that.

But again, it's not coming with permissions, it's not coming with authentication.

You still fall back on Django, and sometimes it's overwhelming because you're trying to figure out, like, oh, it's been so long since I've written permissions.

How do I actually do that in Django?

And yeah, and

Just go to this chapter of the Django docs and go to the section to read it.

So, but you know, it's a young project, it's promising.

Um, I think it's worth checking out.

Like uh Django just gives it to me.

Now there's four options by default and this and that.

And so uh Yeah, and then extending that to permissions further, it is confusing stuff.

Uh Carlton and I are actually talking before we started.

I'm dealing with some permissions issues right now, and it's uh it's challenging.

You know, on the one hand, it ultimately comes down to a Boolean on a model that you need to flip with a form, but on the other hand, like there's a lot around that that's important.

And because it's permissions.

Yeah, it you know, you don't want to mess it up, right?

Um so I think that I think in some ways that's the biggest thing is like if you're giving permission to someone, it's like, ooh, I hope this is correct, and then maybe you have to tie it into a a payment processing webhook.

Um so yeah, the level of don't mess it up feels harder.

But anyways, I would maybe I'll add that to my 95% of is you know, CRUD plus auth plus permissions.

It's it's hard because it's up, it's literally up to you.

Like it's not something that, you know, these are schemes are gonna work 90% for most people, but that 10% is what makes it like, you know, with what you're doing and your specific what what kind of like business requirements you have are gonna be just different enough from somebody who's either bigger or smaller or whatever.

So that's kind of the hard part is like you defining what it is you actually need.

And it's kind of hard where that's why Django kind of gives you some of the pieces to use, but uh it's like models, like we can teach you what a model looks like, we can teach you what a poll looks like or a blog post looks like, but you can be very quickly under or overwhelmed based on like, well, how do I use a JSON field?

The Django docs show me how to use these fields now.

When do I ever use this and how do I use this, right?

Like there's a certain level of until you need it, then you at least if you know where to look, then you can you can implement it.

And sometimes it's just there Django docs are so big you can never fully dive into a fully fleshed out example for absolutely every feature.

So that's why people should blog.

Was you mentioned this uh Django Jobs, which um tell us about that.

And and and you know, I'm I I'm not hiring, but say I'm hiring.

What uh what do I do?

How do I how do I hire with Django Jobs?

Um, I don't know why I'm really going with free as a feature.

Uh, but basically it's kind of an offshoot of doing Django news for you know as long as well, we've done it almost five years, four and a half years, something

like that.

Yeah, someone congratulated us on, I forget if it was the podcast that I think it was the podcast.

We hit like five years.

Yeah, and then and then it was like, wait, how long have I doing the newsletter?

I think it's four years.

So yeah, it's it's time flies.

How do I find somebody?

Or I'm looking.

So I there's not been a resource, and there's a couple of sites that do Django jobs, and so the idea is that maybe if we go and we collect the jobs from the common places where people post stuff, then let's just put it in one area.

We can curate it a little bit, we can we can push it through the newsletter, and if that's useful to people and help somebody find a job or find somebody great, and then I kind of modified the site too to allow you to go and post your own jobs, and so we're probably getting four to five a week right now, which seems better than what I thought we were gonna have, uh, because a couple of the other Django sites, and I don't, and I'm I'm all for it.

Like I I hope I hope there's a dozen Django job sites spring up, and I hope everybody has tons of jobs on it.

But we wanted to kind of aggregate everything into one place so that you could see them.

And also some of those sites don't get updated but once every couple of months.

And so to me, that was kind of frustrating to see.

And I was kind of curious about like how many eyeballs see some of these places, and so I thought, you know what, the newsletter, at least we've got a couple thousand people.

Well, I think we just hit 2,700 or 3,000.

I don't know.

We've got a bunch of people on the newsletter.

See, I don't even know.

Almost 4,000 people view the newsletter.

Um, and then we also have social media for that too.

So, you know, if we can kind of create this pipeline that people can see where the Django jobs are, they can go hire people, or if you need to find a job, you can use it.

I think that's good for the ecosystem.

And I just want I want Django's ecosystem to be healthier.

And I just felt like that was an area that no one had really put a fingerprint on.

And I thought, you know what, this is something that I don't know that we can fix it, but we can at least help people have a couple resources to use.

Uh the Python job board is very, very underappreciated, and so that's probably like half of our jobs just come from people going to python.org/slash jobs, but it's also kind of hard to find just the Django jobs.

So we're pulling jobs in from there.

We've I don't even know how many hundreds we've had go through so far.

It's probably up to like, you know, three or four hundred jobs have come through.

And so I felt like that's a pretty good success for something that I kind of fiddled with for probably a decade.

And then at PyCon uh DjangoCon US last year, I was like, you know what?

I'm just gonna go ahead and make this thing public, and half of it doesn't work.

And every week I find uh an embarrassing bug, and we hear from people who are like oh don't have to finish the job.

So but it is, but I mean that's also the fun part of like just just throw the thing out there and then fix it and you know make improvements on it as you go.

I think given how expensive and difficult hiring is, a nominal fee would be you know perfectly uh okay as well.

property right.

Yeah, we work we work Django with Rust.

And you know, just to the to the health of the ecosystem, I think also it's worth uh shouting out the fact that uh John Gould and the Foxley talent team exist doing at the moment more bespoke Django hiring and um is so healthy for the ecosystem.

And it's fantastic that they exist, they're active at the Django cons, and then again, having closer to a default job board like should exist.

There are a couple out there, but none of them seem as up to date as Jeff mentioned as the community actually is around these jobs.

Like I I hope John he wants to do a community-based one.

Ours we might open source at some point.

Uh it kind of has open source roots, and then it's just it's gone so far.

And my my goal wasn't to run an open source project, it was just to get the jobs out there.

And so I definitely put a lot of time in open source and may open it up at some point, but for now it's just I can go do things on a Friday and not be embarrassed by it publicly.

Or like if I have a question to you on something, right, that's like a non-client thing, you can point to and be like, oh, I I did it this way.

Like, here's exactly how I did it.

So that's been actually educational for me.

I do that a lot.

You know, because it's because I can share stuff with I can share stuff with you too, but my you know, you you have a lot of you know client work that you you can't share.

So that makes sense.

Oh, like this.

You saw the pull requests.

Yeah, here it is.

And that's also been helpful for me working with you too, to be able to have that kind of and that's why I think about like at some point maybe opening it up again is just to get it in a space where I can, you know, because like there's a couple of people that want to help with it as well.

And I've just been again, I my goal wasn't to manage a project, the goal was just to kind of help people find jobs.

And so at some point, you know, I probably will just cause I think it's the healthy thing to do, but for now, I'm just gonna do my little Friday updates and uh do dumb shit.

It's hosting or it's job related.

So, you know, it might be okay if there's some monetization there.

I'll also call out um since I have two months before this comes out, uh I shared with you, Jeff, a list of uh Django interview questions because people are asking me, and I sort of procrastinate on something and did a deep dive of like what would my 6570, you know, beginner intermediate advanced questions be with a short one-paragraph answer.

So we will I will commit to putting that up either somewhere.

There'll be a link to it.

And if I think the three of us are would ask the same kind of basic ones, you can go through, you know, how do you know someone's Django ability?

Like there's some kind of core concepts, talk to me about this, and then you can go a little bit deeper.

Um, but there is a bat there's a line between, you know, don't recite, don't recite what's the method for this permission thing.

Like nobody knows that, but like talk to me about how you would do it.

Um sorry, so I think that would be helpful for both sides, both people giving interviews and also taking them.

Um so that'll be up somewhere.

There'll be a link.

So I think that was a for the advanced ones, anyways.

I was like, I kind of know, but if I actually put some.

I think it's a good list.

You know, this is kind of where when somebody asks this question, this is what they're looking for.

Like the talk I gave at DjangoCon two years ago um was sort of a blueprint of all of Django.

Uh and some of these things get questions get to, you know, like more advanced questions would be like, what are signals or middleware?

Give me an example.

You know, that's something that you may not know about if you haven't touched it, but you can quickly, you know, know enough to talk about it, right?

To say like, you know, what's the signal?

There's a receiver, and you might use it if a user signs up for something, right?

That usually is sufficient to round out your knowledge of Django if you're applying for jobs.

You don't have to point to a project where you've implemented it because you're just gonna have to figure it out anyways in the job.

Anything else where I know we're up on time.

Was there anything specific that we haven't mentioned that you was on your list of things you wanted to?

So that was uh, and then yeah, and uh Carlton, I think you're doing a lot of fun stuff right now, so I don't I don't know.

Anything else from uh I don't know, like I there's there's fundraising stuff coming up, and we probably don't want to total dive into that, but I do want to make a push that the DSF needs an executive director.

Um, I think the the boards that we've had in the past are amazing.

Um I'm really happy.

I think it's a really nice service that people put their time into it, but I've been around long enough that I'm kind of tired of Django being ran like it's a hobby.

And I think with fellows like yourself, I'm not gonna ask you to share your thoughts on something that you may not feel comfortable with, but I want the fellows to have a boss.

I want them to have somebody that they know um is there and spends a certain amount of time a week.

And I think that's just more constructive to them to have that person they can go to.

I think it's healthier for Django too.

Uh when I look at web standards, I think, gee, it's pretty cool.

Like, look at the HTML spec and the consortiums that are coming out.

Why doesn't Django have somebody that can sit at that table?

Why aren't we in conversations for that?

And I feel like if we had the right person that's connected, uh, we should be at the table for open source conversations.

We should be able to have fundraising at a different level that it's hard to do.

And, you know, and and like one thing that I think is underappreciated when it comes to being on a board or just being in a professional is it's really hard to find people who will put something in an envelope, put a stamp on it, and walk it down to a post office.

And that's not a criticism of that's criticism of me from boards I've been on before as well.

But just having that person who that's their job is to be able to once a week go and put something in the mail, or it not take two to four weeks to set up conversations where we're gonna have, like, say, a fundraising thing, or we're gonna have a let's get these two people to meet, because I think it's important that this foundation and that foundation talk.

And again, this is not directly Django, this is my like decade of being on different boards and seeing that these are the things that fall through the cracks.

And so Django is successful despite our model.

And I really want to push us to like more committed fundraising, get an executive director and see what this thing looks like with some funding and with somebody who's like able to do the day-to-day stuff so that you can go on that trip around the world with your family, or you can take a month off to go hike something, or you can go on whatever trip with your family you want to do, or just take a sabbatical.

I don't want like things to have to pause or stop because of like life getting in the way of volunteer positions, because you should be able to go do those things.

No problem with that, but like family has to come first, and so the volunteer position has to be.

We had Deb Nicholson on a few episodes ago this season, and you know, just asking her about her role as the executive director of the PSF, and absolutely clear that you know Django needs one.

I was on the board at the time.

Um, and Deb just shined from the beginning.

We started interviewing.

There were other amazing people too, but Deb definitely brought something that uh was unique and it's hard to find.

And um, you know, a couple years ago, I had a conversation with Deb and Anna, who was past DSF president, and Will, and we kind of talked about like what would it be like if the DSF had an executive director?

And then um I think you both were sold on it, and then I think you both left the board, and so we kind of had to restart these conversations again.

Yeah, I know at the same

I will say, like, uh I felt a little bit about a little bit bad about that because there were a couple uh some other things that were in the works.

Um, but I was definitely reaching that boiling point, and you know, the the new people, it was a good move because they have, you know, maybe they need to catch up on some knowledge, but they have enthusiasm and energy and a different perspective that I was lacking.

And that's not a down on you by any means to say that we don't have an executive director because of you.

That's just a that's the nature of how boards work.

Like they're things that you brought, and every board member brings because they have time and they want to put the energy into it.

And it's just really hard to run something like a foundation that is literally a billion dollar, multi-multi-billion dollar a year industry is built on Django.

It's probably tens of billions when you figure in the Instagrams and everybody.

And so I'm just again, I'm surprised that Django is as successful as when I started on it, it was in a newspaper and it was very small.

And so I worked at the journal world way back.

It had already been open source for a year, maybe when I joined.

And I just thought, hey, this is pretty cool.

And it's you know, 200 miles from where I was living at the time, why not come work for them?

And then thinking back to how big it is and how much of a, you know, it has its own orbit.

And nobody thought it would be that.

But I also think like we're probably we're probably underselling Django and you know, funding.

And and I, you know, I'm glad that we have the fundraiser every year for the fellows, and that stresses people out.

And that to me is like it's absurd that we should ever have to worry and think about like, are we going to meet our funding goals versus like why don't we have every company that's over a certain level?

Like, why don't we have the relationships with these companies to secure fundraising that you can't have when your board turns over every year or two?

Speaking of doing things during COVID was extra stressful for everyone, but Anna did so much.

And it just, yeah, the fundraising piece is just is probably not gonna happen with volunteers, no matter how committed and how much time, just because it burns you out.

There's an expertise to it, imagine that, and um that continuity of of just giving companies what they want, right?

I mean, because it's also like yeah, I mean, and I know there's separate things you've been involved with, Jeff, to maybe help around funding, but um it makes sense that people with a lot of money want a certain level of service that a bunch of volunteers can't provide.

So things are happening.

I'm glad you bring that I'm glad you bring that up.

You know, like if I need a plumber at my house, if I have a pipe problem or whatever, I could try to fix it myself, and I may end up replacing the floor, the ceiling, who knows what all.

I might flood my basement.

But, you know, and I can try to fix some things myself, and I'm fairly handy, but I'll probably screw things up to a level that it costs me more if I just would have had a plumber come in and fix it.

And we're kind of that way with fundraising too.

This is only a hard problem because we make it a hard problem.

Other organizations and fundraisers, I get stuff sent to my mailbox at home every day from some foundation that's raising money.

And Django doesn't need a postcard or anything like that.

But watching, you know, somebody who's good at fundraising work for the PSF and work for other organizations, like these are skills that people are good at.

And honestly, this is probably not that hard of a job if you're a fundraiser.

That could be something that people look forward to and go, wow, tech has a ton of money and a lot of people uses Django.

So I I just think we need an ED or somebody to anchor off of to kind of be that consistency so that you know a board member can take six months off.

And, you know, uh there was a while where I felt like the the DSF struggled to even have quorum, and that's bad.

And so I think the newer boards, I think they've figured that out and they've kind of are, you know, I they I think that I don't think that's as much of an issue today as maybe it was a couple years ago.

But I I hate that that's an issue, and that just means that things probably aren't able to get done because you know people have life stuff happen and they should be able to.

So, anyways, that's my uh that's my soapbox.

That was the

Good.

All right, I'll have to think of a title for this episode, but Jeff, thank you for coming on, sharing your thoughts, of course.

Thank you.

Jeff just finished up a month of blogging every day, so we'll have links to some of those, but check those out.

It'll be two months plus when

you're gonna be able to do that.

I can see

Yeah.

Bye bye.

Bye bye.

Try for free at mailtrap.io.