Transcript: Django’s Evolution - Jacob Kaplan-Moss

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

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

Hi, Carlton.

Hello, Will. Today we've got with us Jacob Kaplan-Moss, who's the current board member

of the DSF, was one of the original contributors to Django, and was a one-time co-benign dictator

for life, BDFL. I can say the acronym, but what does it stand for?

Hi, guys. Thanks for having me.

Benevolent, right.

Thank you for coming on.

So we always ask, and we know we're excited to have you on,

but for listeners who don't know you,

could you give us your backstory?

I mean, we normally ask people how they got involved with Django,

but that's a slightly stranger question.

Yeah.

So in 2004, I was living in New Jersey

and working in New York City for a digital design agency

building websites in php and really hating it um and hacking on uh not php as much as the company

um uh the language was whatever but the company was terrible um uh and i was starting to get

involved in python had been following python people online for a while and i one of the two

of the people who i followed whose blogs i read were these these guys adrian holovaty and simon

Willison. And I hadn't clocked that they worked together until one day, I saw a really interesting

job posting on Simon's blog and read it and went, huh, that sounds like, you know, that matches a

lot of things that I would like to do. And then I clicked a little lower in my RSS reader. And

I saw the same job posting from Adrian and went, wait, these guys work together. This is the same

job. And I got really excited, sent in a resume, got a call back from their boss, a guy named Rob

Curley that afternoon. We talked for a while and he said, okay, great. We've got to get you out to

Kansas for an interview. And that was the first time I realized that this job was actually in

Kansas. I hadn't even paid attention to that part. I'd gotten so excited about the potential of

getting to write web stuff in Python that I just completely ignored where the job was.

So yeah, when I interviewed, I guess they liked me, offered me the job. When I started there,

what I found was that Adrian and Simon had been working for about a year at that point on a

set of tools to build web applications in Python. It didn't have a name yet. We called it the CMS.

And yeah, you know, what more should I tell you about that time?

Well, I guess for me, the interesting bit is the open sourcing. And then, you know,

this so i got into django i had the book that was you'd written you and adrian wrote this book and

it was and i was doing php development as well and it was like it was like written for people

who kind of knew a bit of php and here's django and it was you know oh my so that kind of thread

through there was for me was yeah yeah yeah i mean that was i think as far as i know both adrian and

simon had been working in php before starting to write what became django in python and yeah there

were i think a number of things in the early in the early framework that was sort of like

influenced by design decisions in in php um but trying to um you know build them in a way that

worked with python that sort of fit um you know this this was right around the time of like the

early web standards movement. And so there was this idea starting to percolate at the time of

separation of presentation and content. And that was something that there's sort of a similar idea

in sort of the back end of sort of separation of business logic from display logic or something

like that, which most frameworks at the time didn't really do. And a lot of, I think, the

criticism about PHP as a web development language has less to do with the actual

like language ergonomics and more around sort of the affordances of just kind of mixing everything

together in this one file that makes it really hard, hard to maintain. Well, it was kind of

glorious in a way. You'd be writing your HTML page and then you just, oh, I just need this to,

I need a bit of logic here. Right. Angle bracket, question mark, PHP, and you're off. Right. Well,

it's funny because, okay, so like skipping ahead a little bit, right, we get to this things that

One of the things I'm really excited about right now, Tailwind and HTMX, which are in a way like going back to like, hey, let's put more things into our HTML file.

But now we're doing it in a way that's informed by several decades of web development and isn't, I don't think, creating some of the sort of maintainability nightmares that we had back in the day.

You know, the big challenge that was facing the Lawrence Journal world, the locally owned

newspaper where Django was created was, you know, small local newspaper, not a lot of

resources, just a handful of developers with really lofty ambitions.

You know, we, Adrian especially, was kind of one of the, you know, creators of the sort

of idea of data journalism.

I think he coined that term.

And we had these ambitions of building these sort of interactive news apps that, you know, let readers not just read a story, but actually explore the underlying data.

You know, we did a story about the university's use of private airplanes to fly various people around, most notably coaches and student athletes for like recruiting purposes, which is a cool story.

That's an interesting story, but we did a thing that most newspapers wouldn't have done where we actually ingested all of the flight data and all of the flights that the university's planes had taken in the last few years and created an app that people could click around and see and actually look at those flights for themselves and see the dates.

And we didn't have passenger manifests, but you could infer from like recruiting information. Oh, this is, you know, this is head coach Bill Self flying to Texas to recruit some, you know, hot high school basketball player. And we wanted to be able to build that stuff. But we also didn't have like a big team. And so maintainability was like a really big deal.

You have to be able to sort of, you know, publish these applications on a deadline, but then they have to like, if you find a bug three years later and you come back to a big mess of spaghetti code, you're in a lot of trouble.

So we were trying to really balance this idea of being able to develop something really quickly on, you know, on publication deadlines, but also following our perception of sort of best practices at the time.

yeah that's that's really interesting because the last year i've been bootstrapping an application

single-handedly and it's only now with like the htmxs and the tailwinds and the alpines of the

world around that that's sort of realistic again two years ago would react i just couldn't have

done it because there's too many moving parts but it's like actually it's really possible with

django to build something small and tight with a very small team which i think now that money's

not free anymore it's kind of interesting as well that for me is one of the most like

gratifying and satisfying parts of you know looking back on um what's getting close to 20

years of janko at this point is how through everything that has changed that core of like

let i want to build something really quickly that is still maintainable and still

easy to easy to read the code you know years heck even decades later like that we've we've somehow

managed to stay true to that core principle and that makes me it makes me really happy and it

makes me feel like we were yeah we were actually on to something yeah good good good on the on this

podcast we've often talked about how someone fires up a project from 2011 and they you know they add

a non-delete clause and it just works and that's kind of thing on on this topic just before i let

We'll jump in with something or other.

But recently there's been discussion about the Django template language again

and comparing it to other Django template languages which let you do more things.

But coming from PHP, it's one of the reasons why I still choose to use the Django template language

is that it's very restrictive in what it lets you do.

You have to create a template tag or you have to do it in the view.

And I don't know if you still have thoughts on that.

Do you still like it or do you prefer other things?

So, yeah, I think we, you know, it's always this tension, right?

Like, I think we were more dogmatic about the sort of restrictive nature.

We've become less dogmatic about that restrictive nature over the years.

I think this idea of like separation of presentation from content was, or presentation from logic

was like a really important one for us early on.

And it matched the way that a lot of web teams were composed at the time.

You had a pretty clear dividing line between sort of designers and developers.

That was a fairly stark line.

And so, you know, when we were building the template language, we were thinking about

people who didn't have sort of experience in traditional programming language.

They knew HTML and CSS, usually better than we did, but JavaScript kind of wasn't a thing.

I mean, it was there, and people used it a little bit, but mostly to do obnoxious things like marquees or whatever.

It wasn't at all anything like it was today, and so we were building a language for non-developers.

I think these days, front-end developers, designers, back-end developers, it's much more of a spectrum of a sort of bleed-through sort of set of skills.

There isn't that clear dividing line.

And I think it makes less sense. I think it's very, very hard to do any sort of web development without at least some foundation in, you know, what we're trying to, you know, a more traditional programming language, usually JavaScript, right?

Like, so what I, if I'm working on a web development team, what I can expect from the more front-end oriented people of my team is a lot closer to what I can expect from the sort of more back-end oriented folks on my team.

So it makes more sense. And so in that context, someone with with sort of a more traditional set of programming skills under their belt is going to feel chafed by, you know, the constraints of the early template programming language.

These days, honestly, I usually recommend that most teams start with Jinja as the template language.

I love that that's an option in Django that you can sort of pick and choose.

I still use the Django template language for myself because, you know, when all I've been using this particular hammer for a really long time, it's very hard to change to change those habits.

But, you know, I I think I think if I was if I was creating a framework from scratch today, I would not be building my own template language.

I would be using Jinja. Jinja is great.

Some of the design decisions are a little bit different than the ones that like I would make the ones we made back then.

but not in a way that's, like, meaningful or important.

Right, but there are always design decisions, right?

Everything you choose, there's something that you wouldn't do

if you did again, but you choose something else.

Yeah, I mean, for me, it's really important to identify

the difference between, like, I would have done it differently,

but it's fine, and, like, no, I actually have a problem with this.

And Jinja is definitely in the former category.

Like, I would have made different decisions,

but not in, like, an actually meaningful way,

just in sort of the sense of, like, we're all different people

and we and we have slightly different tastes um i don't i there's absolutely nothing wrong with it

and there are a number of things that are you know actually significantly better about it

partials being a big one that i know you you think about too yeah no i mean so yeah so the

template partials packages i'm just in love with that and i'm hoping we can um get that into 5.2

i'm gonna put a proposal to put it in oh cool um because it's just literally one tag um yeah and

We did a bit of preparatory work in 5.1, which is under the covers, and then hopefully 5.2.

Oh, cool.

That's awesome.

That's my goal anyway.

I wanted to give a plug.

We'll put it in the show notes.

You gave a PyCon 2017 tutorial called Let's Build a Web Framework, talking about, I think

there were six kind of big design decisions.

And certainly for me, I refer people to that all the time, because I think that's the first

time, that's a way to think about, well, what even is a web framework, and what are the

decisions?

And then, as you said, like some things vary and most things are, you know, what's really

important versus what's designed, but it's a really helpful, once you can get to thinking

of it that way, that's a big leap and understand, you know, thinking about Django or any other

web framework, because when you start out, you know, maybe you're new to Python and you're

new to web and you're new to Django and it's really just, everything is magical, but like

getting to the point where you can be like, oh yeah, templating, we're going to need a

solution there.

ORM, we need a solution there.

that's when you can abstract it away

and I think have a bigger picture of it all.

So anyways, I highly recommend that.

It's three hours long.

You can kind of skip some of the code yourself parts,

but I've watched that multiple times.

That's a fantastic resource for people.

I'd forgotten about that.

That'd be fun to revisit that

and see if I still agree with that 2017 joke.

Yeah, I think you were mentioned

also the bit about Jinja and the templates in that one.

But yeah, well, we want to talk about the current day,

But as a way to get there, one of the things that impressed me so much about Django community is the fact that you and Adrian both didn't feel like it was yours to hang on to forever and ever.

I mean, you set up the Django Software Foundation pretty early on, and it's still a relatively uncommon model for open source projects.

Like most seem to be solo person who monetizes it in some way.

I mean, like Laravel being an example or something that was open sourced inside a company, React Angular.

I guess, could you talk about why did you decide to do that? And what was that process like? And

that'll lead us to today where you're back on the board of the Django Software Foundation.

Yeah. So at the time, Django was not, you know, was not any was not the success that it was that

it is today. And honestly, we, we had we had no idea if you had asked me in 2005, like what,

you know what my sort of like greatest ambition for Django was I would have painted a picture

that's like 10 percent of what of like where it's gone now I mean like multiple not just one space

agency but multiple space agencies use Django like that's if you had told if you had gone back

in time to tell me that in 2005 I would have completely not believed you um we were thinking

at the time about um adoption by other by other news organizations and news organizations are like

weirdly competitive if you think software developers have not invented here syndrome

like wait until you meet reporters the the fact that django was owned by another newspaper

even if it wasn't in any way a competitor was enough to prevent or at least in our minds felt

like enough to prevent people from using it. I think we also kind of read the writing on the wall

for, look, like a small family owned local newspaper. You know, it was a little more

common back then, but it was already on its way out. And indeed, like the Lawrence Journal World

is no longer owned by the Simons family, by the local family that owned it. It's owned by,

is it gannett now it's owned by one of the big conglomerates i think we i think we not saw that

coming but like knew that that was a predictable outcome for um you know for the paper and we

wanted to sort of ensure that um wanted to ensure that there was sort of a neutral a neutral owner

of the of the intellectual property that was really our concern we didn't we weren't thinking

about support, we weren't thinking about all the sort of sustainability stuff that's like

a big deal today, we weren't thinking about fundraising, we were purely thinking about

IP ownership. And at the time, the PSF did exist, but they weren't doing any sort of

fiscal sponsorship. I can't remember if we approached the PSF about possibly donating the

to them but i think i think it would have been a non-starter i don't think there was like a model

for that the only software foundation at least that i was aware of at the time was the apache

software foundation and they have a list of rules to join the asf that's about a million miles long

it's really intended for like it's really intended for like large companies that want to sort of like

not just like donate ip and have like a stable owner but like really like run a project under

the auspices of of the asf it's not i don't think there's anything wrong with the rules they have

but it's not intended for like what at the time was like a, you know,

a small project, right. Um, uh, um,

a handful of folks in a literal basement, our office was in fact,

the basement of the new center. Um, so yeah, so the, you know,

forming our own nonprofit kind of seemed like the only viable path forward,

uh, at the time it was sort of something, um, uh, you know,

we did reluctantly and kind of perfunctorily. Um, I made so many mistakes as the, as the first

president of the DSF, it's like pretty embarrassing to look back at. Um, uh, but, uh, somehow,

somehow it worked out. Well, I think the fact that you had that organization, you know, that both you

and Adrian were community focused from the beginning and that you had the organization

meant that it wasn't the case that if the two of you lost interest or had to step away, the project

would die right whereas that seems to be the case with most other ones where if it's one person you

know how do you maintain that 20 years yeah we were heavily influenced by a guy named carl fogel

who wrote a book called producing open source software um uh we we we knew him a little bit

personally and also both read his book and were um really sort of influenced by

i don't know like even though we didn't have grandiose ambitions it felt important to have

um you know have have good governance and like i've learned a huge amount about

open source and community governance since then like i said i made a lot of mistakes but

you know they they weren't you know they weren't mistakes out of uh like lack of care lack of

attention they were they were just they were beginner mistakes if i you know those those are

allowed right beginner mistakes were yeah yeah totally you know and i don't you know in the same

in the same way that like if you look at code that you wrote five years ago and aren't embarrassed

it means you're not learning anything if i look at like you know leadership decisions i made five

years ago and i'm not embarrassed it means i haven't learned anything i don't feel i don't

feel like bad or guilty about it but like i think there's a lot of like myth making that happens

around these type these types of things i think it's important to like acknowledge that we like

we barely knew what we were doing yeah right it's easy to look back and like draw this like really

clear story and like say like oh yeah of course we knew that you know it you know the the the

federal election committee would be using django and and the 2000s no we didn't we had no clue

yes yeah no no entirely i'm sorry i just want to ask one sort of opinion question which is

if you had to say, you know, why Django grew the way it did, there's the Django being awesome

component. And then there's also the rise of Python itself. I guess, how much do you,

where do you put that balance, right? Because there were some other ways to build a website

in Python back then. But I think it's hard for people to understand that there were very few

tools, like this is like Ruby on Rails was just getting started. Like this is before this idea

of a batteries included framework even existed, it was so much more manual. Um, so I guess to put

it to you, um, what's the question? I mean, you know, both Python and Django have really gone up

into the right. And, um, do you see anything specifically that Django did that some of the

other projects from back then didn't that, um, besides just being around that contributed to a

success yeah i mean like i've obviously thought about this a lot like like why like why why did

we succeed to the level that we did um and like you know a lot of it is luck to be sure um you

know timing what timing was everything to to large degree right like you met you mentioned

um you mentioned ruby on rails and i think that's a good that's a good sort of starting point to

think about it, because it incorporates both the luck and some of the deliberate decisions.

We were lucky in that we were able to release Django relatively shortly after Rails came out,

maybe about a year. And we made deliberate decisions that were influenced by Rails. Rails

was really the first backend web tool, at least that I was aware of, that focused on what today

we would call developer experience you know i don't think we had a

strong idea of like an opinionated sort of on rails um the name was chosen for a reason

like the sort of development path um web development was really hard at the time

especially in python um uh and um there was a lot of like what is python's answer to rails

python developers were leaving python in 2004 2005 to go to rails um because again like back

to the different design decisions ruby and python are totally one of those things they're different

design decisions but neither is like better or worse and so to a python developer looking at

hard web development in python or easy web development in a language that's like close

enough to python to basically be like good and good enough a lot of people chose to make to

make that leap so so yeah certainly like a thing we did differently from a lot of other frameworks

at the time was focusing on sort of like ease of use and and developer experience we also made a

really deliberate decision to focus on documentation which is still unusual um and still to this day

sets us sets us apart um uh you know which is which is pretty wild um but to your point about

python i do think there was like a there was a sort of like trying not to use the word synergy

because i hate that word but that's that's the right word there was a synergy there there was

you know python was growing but didn't have a web story and then django comes along and now

there's a web story and so that you know the fact that python was sort of starting to evolve into

the everything language everything includes web development and so you know you have this sort of

like positive feedback loop of like people people learn python for you know some other reason they

They learned Python in college for doing statistics, and then they get a job, and they're still doing statistics, but suddenly they need to do a web app as well.

And hey, look, there's Django.

And so they stay with Python, and so then Python continues to grow.

And so I think that there was sort of like a really, I think, not to get too grandiose about it, but I think Django deserves some credit for the growth of Python.

And I think the growth of Python into every domain deserves a lot of credit for the growth of Django.

Yeah, I mean, with machine learning and data science and all of that coming so big now, Django picks up a lot of traffic that way, I think, as well as the other web frameworks.

Yeah, exactly.

Let's pull forward, too, because you've been away from the board and then a couple of years ago you came back onto the board.

This is your second year now on the board.

And I guess listening to the last few minutes where you've been talking about the development and the growth, the one thing that kind of sticks with me is that Django is kind of that Python 2 to 3 thing.

We've kind of avoided that.

There's been no kind of equivalent in Django, at least since the 1.8 days, 1.9, 1.10.

It's increasingly stable.

And so as a sort of old hand, I'm really like, oh, for me, that's kind of Django's killer feature is its stability.

But it's also a really exciting time in web development.

And so how do we now balance those kind of two, those two really important things?

One is, you know, Django stability and its, you know, API stability policy and all the

rest of it, the long-term release, long-term support LTSs.

But we want to keep growing and we want Django to keep pushing forward at the front of web

development.

You know, we use this phrase boring from that talk about use boring technology because it's

safe but we don't want django to be boring it's not boring it's super exciting how do we balance

what's your you know why did you come back to the board like what's those it's funny those two

things were not related in sort of those opportunities facing django sort of from a

technical standpoint and the reasons that i returned to the board were not related in my

head at the time although i'm wondering if there was something kind of knocking around connecting

the two um uh i think so i'll talk about the board stuff i'll talk about why i can't make

the board in a minute but like you know yeah that that tension between um you know stability

being being conservative about introducing new features and still wanting to be um you know

trying to sort of like be maybe not cutting edge i don't think we've ever wanted to be cutting edge

but i think we've always wanted to be um you know on like the leading edge of the adoption curve of

of web of web technologies right um that's been like that's been a tension in in django development

the the entire time i mean like as early as the first couple of years after django was out i

remember having conversations about whether django was moving too slow right like oh yeah i mean it's

been it's just you know it's been it's been all along and like you know there there are there are

upsides and downsides right like there was a lot of talk oh i want to say you know as as sort of

like react primarily but other similar frameworks um view etc were starting to become super popular

there was a lot of talk about like maybe django should just just drop temp the template engine

drop any html generation become just a pure pure api driven um web framework i'm glad we didn't do

that you know i'm we're starting to we're starting to see a lot of the limitations of you know

these these sort of really heavyweight front-end frameworks um in performance uh well in performance

of the website and in performance of the people developing the website, both, we both were seeing

some real, some real struggles there. And that's not to say that's not like a useful niche, right?

Like, you know, fast API, for example, like shows off what you can do when you start with a sort of

API first or kind of API only, um, not API only, but I would say API first kind of approach to

building a framework. Um, and I'm super glad something like that exists, but I'm also really

glad that that's not the direction that django went in you know going back even before there

there was like remember there was a brief moment when object-oriented databases were like this huge

thing there was a discussion about like should django you know change to support object-oriented

databases i'm glad we stuck with the boring old sequel because turns out works super well

um or non-relational databases after that you know like like it is very very hard

in the middle of a bubble to tell the difference between a fad and something

that's actually going to stick around um uh for all the talk of you know h htmx and alpine

i'm not convinced it's not a fad maybe i don't think it is like my my feeling and my judgment

is that, no, this is actually a solution to a problem we've had for a really long time

and not sort of like a flash in the pan.

But, dude, I've been wrong about that before.

So I'm not convinced.

So, yeah, we are at this – we are at an inflection point.

And I think we're at a point where the – we've swung a little too much towards

the conservatism angle over the last few years.

And I think some of that is related to a lot of people who have been deeply involved in Django development have been stepping back over the last few years for all sorts of reasons, in small ways and in big ways.

I mean, Carlton, you're one of them.

You used to be a Django fellow, and now you're not, although you're still doing a bunch of – arguably, you're doing more work on Django now than you were when you were a fellow.

I actually get to work on Django now.

Right, right. But but anyway, but but my point is that, like, I think I think we're at it. We're at an interesting inflection point. One of the reasons I wanted to come on the podcast is because we're at this point where things have slowed somewhat. A lot of longtime people who have been involved are, you know, stepping back, being being less involved.

And there's a lot of excitement in the community.

DjangoCon US this year had so many new faces and so much energy and so much just like raw,

like I want to do stuff, but it's always been hard to get from, you know, I'm excited,

I've written a little patch or I've done a third party package to like really being

involved in in the in the core community and so i think the challenge facing django's leadership

right now is like how do we get that new blood into you know into the community because with

that new blood are going to come the types of things that are going to sort of revitalize and

make and make you know the move the technology forward the the technology always follows the

people there's not we're not jango's not going to you know my my pet feature is i want jango to

have first class htm htmx support i want that to be built into core but like that's probably not

gonna that's not gonna just sort of magically happen someone's gonna do that yeah and that

someone is probably gonna be someone hopefully is gonna be someone relatively new to jango

development um so yeah we're at we're at a moment where there's a lot of opportunity but also a lot

of sort of uncertainty and like a bit of a leadership vacuum um and that's the thing that's

like the deepest on my mind these days okay so you the words you use there were leadership

vacuum and i want to uh it's a question i have for you it's about the the contrast between the

bdfl model the dictatorship the dictated life model and then the sort of community consensus

model because both have benefits right in a so why you know what's wrong with the bdfl model

and then what what is it that we can how do we inject a bit of the kind of direction giving that

that can bring back so my experience of leadership over you know the 20 years that i've been in any

sort of like leadership role is that every time i step back and give and sort of give power to to

someone else it's a net positive yeah right okay which says some interesting things about my

sort of direct leadership ability no but it's not about you no i'm not not to be self-deprecating

about it I think I think what it says to me is that I'm a better I'm a better coach sponsor

mentor than I am sort of a more directive style leader um and and and like that is the thing that

I've realized about about myself and like has helped me be a lot more effective over the last

you know over the last few years is one of the reasons why I felt sort of ready to take a

leadership role on the board is like I know I understand my own leadership style my own leadership

successes now and i think that's i think the bdfl model only works as long as you have

a more direct a more directive and opinionated style leader and only as long as that person has

the attention and the time and the like lack of burnout to to give to give that attention

right and adrian and i didn't

I mean, there was a long period of stagnation in Django development because everyone was waiting on Adrian and I to make decisions and neither of them, we didn't want to. We weren't interested in that. And it wasn't until we stepped back and abdicated that power that things really took off, honestly.

Yeah, there was a gag I saw on Foster Donner somewhere the other day. It was a while back. But the idea is that the reason that a project needs a BDFL is the very reason BDFL stepped down.

Yeah, I mean, it is very, very rare to find someone who is a good leader in a dictatorial model and is not doing it because of their ego or doing it because they're a jerk.

I mean, like, gosh, Guido is truly a special person to have been the BDFL for Python for so long with a long track record of, like, being nice.

Like, usually BDFLs are either ineffective or assholes.

And, you know, like, I was pretty ineffective.

I'd rather fail in that way than in the other way.

But like, yeah, it is super rare for that model to actually survive for a long time.

I want to pick up on one thing you said, though, because you used the word consensus.

And this is the other reason why I wanted to sort of return to a leadership position.

My understanding of consensus has changed a lot over the last decade or so, having done a lot more like, you know, community, community building, community governance, community leadership, honestly, mostly in ways outside of outside of technology, other nonprofit work, other other sort of like intentional community type stuff.

I think most people have this naive idea of consensus meaning sort of like everyone agrees, and that's not what consensus means as practiced by organizations that truly have like a mature and sort of well-developed consensus-driven process.

Consensus is not everyone agrees. Consensus is a group of people who are more aligned with the process than they are with any particular outcome, and they've all agreed on how decisions will be made.

The goal is to make a decision that makes everyone happy or at least content. But when there are situations where not everyone does agree, you've laid the groundwork ahead of time that everyone is more invested in the community health than they are in getting their own way.

And so you have all sorts of mechanisms like standing aside, which is a way of saying, like, I don't agree, but I'm not going to block this. You have various mechanisms for sort of hard and soft blocks and what needs to happen to overcome the blocks.

And I think those sorts of things are the type of work that Django needs to invest in.

We sort of replaced the BDFL model with this rotating technical board, now called the Steering Committee, which is an improvement over a BDFL model, but it's still not more largely community-driven.

And I think, in my mind, the next iteration of Django's governance model involves a broader slice of the community involved in decision-making processes.

Another board member, Thibaut, just held a Django roadmap sort of brainstorming session, which is awesome.

So great.

I'm so glad that he did that.

I hope that something like that becomes a more consistent and even like, like binding part of Django's governance model, not binding in the sense of like, we're all volunteers, we're mostly volunteers, we can't force anyone to do to do anything. But having a well defined roadmap and a process for developing that roadmap that listens to as many voices from the community as possible, I think is sort of the the big missing piece from Django's government.

governance right now yeah i mean so i went to that session and the the 10 there's a post on

the forum about it which gives the details but there were 10 15 ideas came out and all of them

are like you know positive there's there's yeah you know whether you agree with every single one

or not it's like you know what if django had all of these that would be a massive win that would

be a massive move forward even if it you know the cost of it was the ones i didn't want as well but

I take that in a blink, you know, it's, so having a way of driving that, because what's

happened in the recent past is people have felt very frustrated that we can't get this

agreement of exactly how to proceed on a feature.

And so it just kind of hits into the long grass.

And in some ways that's served Jenga well in that we haven't gone down various dead

ends, but in other ways it does risk atrophy.

Yes, precisely.

yeah and and like i think that um i i think that you know we like look we've made mistakes before

we've we've put things in we've put things in django that turned out to not be a great idea

from you know in in with 2020 hindsight and in retrospect and um uh i'm not going to mention

any specifics because i don't want to like call anyone out and i might be and i might be wrong

but like I feel like we've made some mistakes and it's all and it's all mostly been fine and so like

I think we need to like ratchet up our risk tolerance like just a little bit you know

like you know of those 15 ideas is it is one or two of them going to prove to be a bad idea in

the future maybe absolutely like whatever we can recover from that it's just code yeah so I wanted

to ask you about so there's deciding and then there's doing and we just had um last week we

interviewed Deb Nicholson, who's the executive director of the PSF, and she was talking about

things that an executive director does where, or the PSF more broadly, the board there, which I

know you've been on, decides and others largely implement. Sometimes it's board members on a

working group. When I was on the Django board, I felt like the board kind of had to do both.

And as for volunteers, that's a lot to ask. I mean, I know you're now the treasurer again,

which is the role I had. And, you know, that, that's a lot of work. So I, that's a long winded

way of saying, how do you feel about, do you feel like there's a disconnect there between the

deciding and doing? Cause me personally, I came away, part of the reason I stepped down is I felt

like it's more, more than a volunteer can do to go to the next level of these organizational things,

fundraising that people keep talking about absent an executive director, but I've been away from

the board two years and I'm curious what your feelings are on that. Yeah. This was the main,

this was my main motivation for returning to the board. So there are two models of two sort of

big buckets you can put nonprofit boards into. You can have an activist board where the board

does the work of the nonprofit. If someone needs to file taxes, the treasurer fills out the tax

form. If someone needs to talk to a major donor, a board member calls that major donor and has a

conversation with them right the board does the board does the work the other model is a directive

board the board the board directs the board sets high-level goals the board allocates money the

board makes large strategic decisions um but the most of the work is actually is actually delegated

the board delegates most of its power to individuals to employees to working groups

etc etc i'm this is not this is not a consensus opinion of all non-profit people but my opinion

is that the directive board is more effective and then as a long-term better model for a stable

functional you know um effective non-profit organization django the dsf has historically

been an activist board and has made a couple of steps towards being a directive board you know

you mentioned that being the treasurer is a lot of work it's actually not my experience because

we've hired an assistant who does the vast majority of of that of that work well i guess

well when i joined it then people she hadn't she wasn't uh part-time doing that role so it was i

could feel why. And yeah, the fact that Catherine has an accounting degree and is amazing, makes it

doable for anyone, for me or anyone else. Yeah. And that's like a small scale model of like what

I mean by like, like, why should we be so shocked that hiring someone with an accounting background

to do accounting is more effective than having a software engineer with no accounting experience

do the work like that's not surprising that's that's the least surprising piece of information

we could we could possibly have so um and that's a small scale model for where i'm hoping to hoping

to take the the dsf and and like the board's pretty the board's pretty aligned on this this

is not this is not a like a me um me fighting the board thing this is pretty much all of us have

have this same idea that like the dsf will be more effective django itself will be more healthy

if the board can sort of transition to a more to a more um uh um sort of community driven and more

broader base of people working on dsf stuff so we've done um i want to plug a couple things

that we've done over the last you know six months to sort of like to to that end the first is that

we've made becoming a dsf member um uh easier we've it used to be that in order to be a dsf

member you had dsf membership recognized contribution of intellectual property so you

had to write code or write documentation or sometimes we sort of would stretch to like

include conference organizing as like i guess you're creating videos so that's ip like but

you know that that was a very narrow and restrictive version of what being a dsf member

was the new definition is basically contributing to django's mission which is supporting the

framework which is advancing web development um which is protecting the intellectual property of

django that's a pretty broad that's a pretty broad set of activities and it uh and it enables us to

really like admit people as members with all sorts of different, you know, backgrounds.

Like by the new definition, if pretty much anyone who works on an open source Python

package is now eligible to be a DSF member, because can you use that package with Django?

Well, yes, you can.

You've contributed to sort of advancing the state of the framework.

Done.

Anyone who, you know, writes a series of blog posts about Django is eligible.

Anyone who records a podcast about Django is eligible.

We've sort of much broadened that definition in the hopes of getting a lot more people

and a lot more voices sort of into the community and giving them a direct vote and a voice.

The other thing that we've done is we've created a structure for creating working groups.

And this hasn't moved as fast as I would have liked, but it is moving along a little bit.

We've created a mechanism, basically, for people to spin up working groups and to ask for delegated powers from the board.

And it's pretty broad.

That can really be anything, right?

The board can approve a budget, and then the working group can go directly spend that budget without individual approval from the board, right?

the working group can ask for, you know, we've just formed a sort of a social media working

group to sort of own Django's sort of social media presence. And if you look at that group's

charter, we've sort of enumerated a list of things that that working group can do without

explicit approval from the board. The board does not need to approve every tweet. The board does

not need to approve who you know who we follow or what social you know or like what platforms we

post things to etc etc there are a couple of lines that we've reserved for the board like the board

is reserving the right to review any sort of like sponsored post type activity because we're not

sure if that's something that we necessarily want to want to be doing um or and if and if we do how

we want to be doing that so we've sort of delineated some lines but that's kind of the model for where

i'm hoping a lot of um a lot of sort of leadership at the sort of dsf level will happen i'm sort of

hoping that a lot of the sort of informal groups that we've spun up around around django the

the ops team the security team the um uh you know those sort of groups will kind of eventually

reform as working groups so that we can more like we ought we ought to just give the ops team

a designated budget.

We shouldn't have to approve

spending on hosting.

They should just have a credit card

and buy the things they need to buy

to host the Django site, right?

There's no need for that

to be a board decision

and so on and so forth.

So I'm hoping that

we're at this point where we've,

I think, created the sort of

formal mechanisms we need

to sort of transition the board

into a directive model.

But we're kind of not there yet.

And we need people who are

interested and willing in getting involved in, in, in, in any way, large or small.

Um, and we now have the capability and the sort of mechanisms to make that happen.

Um, and sort of, we just need to kind of keep plugging away.

That's why I ran for another term.

Like my, my first term sort of culminated in getting, getting these two things done,

but lay, you know, those are just the, that's just the foundation.

Like now, now we're trying to build the house.

Yeah.

Perfect.

Perfect.

So call out to people, like call out to, um, like if, if you're in the general community

and you want to get involved and you want to, that was a good time.

That was a really good time.

I mean, like I said, there's like this sort of, there is a little bit of a, of a, of a

power vacuum, not, not an entire, not an entire one, but like a lot of the old heads are,

are, are less involved or, or stepping away.

And that's, that's scary because it means that people who, you know, have a lot of

experience are no longer contributing but it's also like a super big opportunity because it means

that it like you know it means that you know new people bring bring new ideas and often like

honestly better ideas and so like you know have it like there's there's a there is a a really

there's a moment right now where it's a really good time to get involved and i don't want to like

i don't want to sugar sugarcoat it too much it's still it's still harder than it needs to be

there's still um there's still a number of barriers you know there's still some sort of

difficulty um but um you know i'll make i'll make a general offer that anyone who wants to get

involved in in django in some way should feel free to reach out to me and and ask for help like i

can't promise i'll be able to but i can at least try to point people in the right direction and

possibly more than that yeah cool um it's not the first time though like the i kind of think that

Django's kind of at least on its third or fourth and coming up to its fifth generation of active

leaders, really. It's not the first time that people have dropped away and a new generation

has come in. Yeah. I'm not, um, I'm not worried about it exactly. Um, it's just like something

that needs to be focused on because you're right. Like every, every time we've had sort of like a

um leadership challenge we've emerged from it stronger after you know at afterwards and i and

i don't see any reason to suspect that this that this will be this will be different okay

i have a question will if you've got one or yeah but go ahead okay so um

one thing that we've talked about um a few times on the show and perhaps with haim and

others but is the gap it still still feels to me there's a kind of gap between the narrow

Django community

I thought the

active contributors

those are on the

forum and you

know maybe the

discord and around

and about and

then the wider

community which is

the user base and

do you have any

thoughts on how we

can sort of I

mean the social

media working group

is one great way I

think but how we

can kind of

get the bridge out a bit better to feels like there's a big gap sometimes i mean i think to

some degree that's just true of um that's just true of like software development and open source

communities in in general right like you know for every one person on the forum or listening to this

podcast or coming to DjangoCon, there's probably 100, 1,000 who punch in, write Django code for

eight hours, punch out and go home. And that's fine. In fact, that makes me super happy, right?

I don't think that just because you write code in your day job, you need to think about it

outside of your outside of your day job. I'm completely fine with that. And I don't I would

love to be able to reach those people to find out what we could do to make their their like jobs

easier, their lives better. You know, like, I'm not really sure how, but I don't think it's a

problem that they're sort of not engaged in the in the community aspects. Okay, the part that I

do think about a lot is how do you take the person like okay so let's talk about django con us i think

about half the attendees of django con us it was their first time going going to a django con

um and most of them had not sort of contributed to at least like the the core of django or like

a major sort of popular third-party app in any sort of like concerted way they all have they

all have the interest they are the vast majority of the people at that conference you know several

hundred people are sitting in a room are relatively new to the community have the excitement came to

the conference, set aside their time, you know, all of that stuff. How do we, how do we convert

them? How do we help them take the next step? That's, that's something I don't think we've

ever done particularly well. And that's the place where I want to really like, I really want to

extend the effort. And I don't, I don't have answers here. I just have questions, but like,

it's, it is the foremost thing on, on my mind right now is like, I've been, I've been using

the term on-ramps like how do we build on-ramps into into the community you know like we we

consistently get people who kind of like come out of nowhere and build something you know something

really big and cool and and new and exciting um uh but it's a pretty you know it's a pretty big

effort it's a pretty big lift and it takes like an almost unreasonable degree of confidence to

be like, I'm going to write thousands of lines of code and I'm going to get it into Django by

force of will, you know, like that should not be required to sort of like get more directly

involved. Likewise, you shouldn't have to run for the board of a nonprofit organization to,

you know, help out with community leadership or fundraising or governance. You shouldn't have to,

you know, plan a conference to get involved in conference organizing, right? Like, you know,

how do we sort of, how do we build on ramp so that people can dip their toe in contributing to Django,

can dip their toe into working on conferences, right? And we have some of those, but we don't

have enough and we don't have, like, clearly defined, like, progression paths for various

different forms of contribution and that so i've been thinking about i've been thinking a lot about

like building those on ramps yeah and like people who are good at making contributions to the orn

and writing the docs that they need to do to do that and writing the tests they may not be good

at these other tasks as well so we need you know we need i'll give you i'll give you an analogy so

like a a hobby i've started to to pick up over the last couple years is is uh packrafting this

is combining backpacking and river kayaking.

There are these inflatable boats.

They're small.

They're lightweight.

You can fold up, put it in your pack, hike for a while, unfold it, float down a river.

It's very hard to get into.

It requires a lot of backpacking skill.

It requires a lot of river skill.

Whitewater is dangerous and requires a lot of technical ability in order to stay out

of trouble.

This blogger and longtime packrafter, Dave Chennault, wrote a blog post that he titled something like Packrafting Progression, which is basically like, so you're interested in packrafting.

Here's what it looks like to go from this sounds fun to I am executing high difficulty level trips.

And he had just sort of these series of like, you know, I mean, step one was like, get obsessed, watch a bunch of YouTube videos, read a lot of books.

You know, step two is get a boat, get out on a lake, get in and out of the boat, paddle around, you know, figure out how to blow it up, et cetera, et cetera.

Like we need like a contributing to Django progression guide.

Yeah. Right. You know, and and like that's that's the type of thing that I'm that I'm that I'm thinking about.

Marvelous. So, Will, have you got any questions?

So we're coming up on time, Jacob. But what are the things in Jake?

What are the things in Django that you're currently excited about that are in the works?

You know, solutions to longstanding problems. Is anything come to mind?

I mean, I mentioned HTMX a little bit earlier. I'm, I am, um, I'm just so excited about it. Like for, for, for, for close to 20 years, it's been like, what is Django's front end story? Django doesn't have a front end story. It's gonna, it's gonna, you know, the sky is falling. You can't do front end development in Django. Django is dead because you can't do front end development in Django.

and like almost the first time i saw htmx maybe the second time i think the first time i didn't

get it but probably the second time and certainly the first site i built in it it was like oh no

this this is it this is this is what the front end story for django looks like like it was like

oh wait we got we have an answer now um uh it's just it's just so easy and it fits with django's

philosophy it's not a silver bullet if you're trying to build something like i don't know

figma like an actual like appy app that runs in the browser i can't imagine doing that in htmx

that seems that seems ridiculous but for the vast majority of what people are building with django

which is still like database driven crud apps that's like we still those are still incredibly

important you know even in 2024 htmx really just feels like the missing piece um can i just say i

think you, you told me at Django con that I think you had built basically Excel with Django and

HTMX like quickly. Do I have that right? Yeah. I, I, I essentially replaced a workflow that

revolved around an Excel spreadsheet with a, um, with a Django app that had, um,

you know, yeah, I mean, it was essentially, it was essentially like cap capturing a bunch of data

about um our clients security maturity uh at at work so there's a bunch of you know there's a

bunch of um practices and we record you know yes no partial and a bunch of notes you know that that

sort of stuff and we've been capturing that in a spreadsheet and yeah i built a built a django app

that you know lets people capture that data um includes you know i prototyped what we call like

multiplayer functionality, letting multiple people update it simultaneously with push sent

through server-side events. And it, you know, having that level of interactivity was 10% more

work than building a sort of old school, you know, form submit workflow. Like, it's just easy. And

it just fits with it fits with django's philosophy in a way that feels like it was designed for

for for building django apps um that that was my take when i first started using it was the way it

just literally like you just do django and then you use the h and it's like it yeah i haven't

changed anything basically in my django and it just works it goes with the gray and there and

there are and there are some there are some missing pieces like the reason like i mentioned

template partials earlier like template partials plus htmx unlocks the ability to do part partial

rendering so that you can have the same view either render a full page or with an htmx request

just render the sort of small snippet that you need to update that's like a really that's that's

a thing that's harder than it needs to be right now um in in in django so you know there's like

little there's little little bits and pieces that people are sort of reinventing on their own

projects and and need to be sort of like consolidated a little bit but by and large

um you know it just sort of it just sort of magically works and it's super it's super

exciting and how are you how are you getting your things online these days that's we always

like to dig into people yeah you know i mean so i i think i think many people know that i used to

work at heroku and uh i still it makes me really sad that um heroku is still around but i don't

i don't trust it that much anymore i think i think it has been unfortunately kind of

slowly circling the drain for for a long time um they had a major security breach about a year ago

that really shook my confidence in um in in the in the platform um uh and there are a bunch of

new things coming out that are kind of like exciting i'm personally pretty excited about

about fly.io um deployment is still like way harder than it needs to be it's still super like

you know we started we started django in in us in in in no small part to like replace php

But we still have never come anywhere close to the ease of deployment with PHP.

You still can't just throw a Python file on a server and have it work.

Um, and like so many people are, you know, like, you know, deploying like most deployment

stories, at least at companies now are like Kubernetes or like the sort of managed managed

services like EC, like ECS, like Amazon ECS or deploying to Lambda and all of these things

are like cool technologies, but boy, they are heavyweight.

I still think there's a big gap in the Python community around deployment.

People who are interested in this place should play with Denno, denno.land.

Denno is a JavaScript variant, kind of, with a deployment environment really baked in the language from the core.

it's kind of incredible and it makes me sad that there's nothing like that for python now denno is

proprietary and you're sort of tied into their cloud platform and it's you know it's vc backed

so it's gonna turn into crap sooner or later etc etc there's a bunch of reasons why i'm not

just gonna like say everyone should drop everything and switch to denno but like

it does make me sad that we have you know 25 years of complaining about how hard it is to

deploy python apps and it's basically the same as hard as it's always been good do you have any

recommendations for what well i'll just personally ask you so i've i've taught both heroku and fly

in my books and i i like fly a lot seeing it but it is also having growing pains trying to

recreate heroku which you know makes sense it's a lot of work specifically though the lack of a

managed um postgres option like a truly managed one um you know in heroku they do have they do

have one now the super base is that no fly has like a first party postgres option now they do

yeah it's relatively new three to six months yeah okay um okay two services that i that i am keeping

a really close eye on are fly we mentioned and render uh render.com i think right now rent i

think right now render is uh if you're new if you're new to web deployment render is probably

your best choice fly is a little more as a little more complex a lot more powerful um but it's more

of like a more of like a set of building blocks than it is sort of like a super slick clean easy

to use experience render is much closer to sort of the the heroku experience down to sort of like

first party managed services like postgres and redis and and um and um a really render also has

um a uh sort of non non docker deployment option i i do i do like docker and i do think containers

are a good good idea generally but i hate teaching them to newcomers i don't want to have to explain

what a docker file is until someone's been writing python code for a year one thousand one thousand

percent that was really the biggest thing is for the 4.2 update for one of it for my beginner's

book i switched to fly but i had to talk about docker and it's like oh man it's just i and i

fly will now fly will now detect a django app without a docker file and generate one for you

which is which is nice but then you have this if you're teaching someone i've been here you're

teaching someone and they go, what is this? And you have to be like, don't look at the man behind

the curtain. That's exactly what it is, right? It's just like, I just, yeah. Yeah. And I don't

think that's a good experience for newcomers, right? Like telling someone, oh, that's too

advanced for you. It's like so patronizing and so frustrating, but also it's, unfortunately,

it's also true. Like I actually can't explain this to you right now. Right. Well, it's like

visible enough that they're like, oh, I don't know that. Whereas like, oh, there's so much other

stuff you don't know either, but you're not worried about it. But that was, I mean, for me,

my, my beginner's book, I wrote it in large part because there was the rails book, which I don't

know if that's still there, where it was like, hello world. And then, you know, Heroku was built

for rails. So it was just like, boom. And I was like back 10 years ago, like, why can't we do

that in Django? Like Django is awesome. Why can't we do that? And so I have continually been trying

to get as close as we can to that. Yeah. But there's, there's another project to plug, which

is uh django simple deploy um which is trying to sort of solve this problem for um for eric's right

app for deploying django apps um i haven't used it myself because like i have docker stockholm

syndrome so i so i'm like tied into that platform and like it's easy for me now and i've forgotten

that it sucks um but um i think like i should spend some time playing with it i've heard good

things i think it's probably a promising a promising idea and hey maybe this is one of the

exciting new things that someone could take to being built into Django someday.

Manage.py deploy would be a pretty amazing thing, wouldn't it?

Yeah. I mean, it's like, well, we could go on and on.

Is there any... Yeah, I was going to ask you, though, what would you change about Django

question, but I think you've kind of answered it. So that's the... Is there anything... So you do

have a day job. We'll put links to it working on security at Latakora. Am I saying that right?

Yeah, correct.

But people can reach out to you if they have more questions about everything.

Yep, I'm easy to find.

Please, please feel free to reach out to me.

My email is fairly obvious.

You can you can DM me on Mastodon, etc.

I'm like, I don't get I don't get so much random email that it's overwhelming.

So please feel free to reach out.

Like, I can't promise to respond.

I can't promise my response will be helpful.

but i can't but i can promise that i won't be annoyed or frustrated or or any sort of negative

emotion so like anyone who's listening who wants to reach out about anything please like please

feel free brilliant that's a lovely that's incredibly generous jacob thank you so much

for coming i'm really just such a good chat i've enjoyed it so much yeah thanks guys i really

appreciated it so we're jango chat.com and we will see everyone next time bye-bye bye-bye