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 Vinson.
Hello, Will.
Hi, Carlton.
Hello, Will.
Today we've got with us Jacob Kaplan Moss, who is one of 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 say?
Thanks for having me.
Benevolent, right?
Thank you for coming on.
Um so look, we always ask them.
We're you know, we we know we're excited to have you on, but for listeners who don't know, could you give us your your backstory?
And I mean, I we normally ask people how they got involved with Django, but like that's a slightly stranger question bring it to you.
Um so in 2004, I was um living in uh New Jersey and working in New York City for a digital design agency building websites in PHP and really hating it 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 Halivati and Simon Willison.
Um 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 uh got really excited, sent in a resume, got a call back from uh their boss, a guy named Rob Curley, that afternoon.
Uh we talked for a while and he said, uh, 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 had gotten so excited about the potential of getting to write web stuff in Python that I um uh uh just completely ignored where the job was.
Um so yeah, when I I 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 um about a year at that point on a um set of tools to build web applications in Python.
It didn't have a name yet.
We called it the CMS.
Um and uh yeah, um, you know, what more should I tell you about that time?
Well, I I guess the for me the interesting bit is the open sourcing and then you know the this so I got into Django.
I had the 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 his Django, and it was you know mining.
So that kind of thread through there was for me, was yeah.
Yeah, yeah.
I mean that was I think I 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 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 like um separation of presentation and content.
And um that was something that um there's sort of a similar idea in in sort of the back end of sort of separation of like business logic from display logic or something like that, which most frameworks at the time didn't didn't really do.
And and like 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 it was kind of glorious in a way.
You'd be writing your HTML page and then you just go, oh, I just need this to, I need a bit of logic here.
Right.
Angle bracket, question mark, PHP, and you're off.
Um 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, uh uh at Tailwind and HTMX, which are in a way like going back to like, hey, let's put more things into our into our HTML file, but but now we're doing it in a way that's informed by several decades of of web development and isn't, I don't think, creating some of the sort of maintainability nightmares that we had we had back in the day.
You know, the the big challenge that was facing um the the Lauren Shuttle world, the the locally owned newspaper where where Django was created was you know, small local newspaper, not a lot of resources, just a handful of developers, um with really lofty ambitions.
You know, we Adrian especially was kind of one of the um, 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, I we did a story about the um universities use of uh private airplanes to fly various people around, most notably um 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 on 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 um uh 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 that 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, um, you know, on publication deadlines, um, but also following our perception of sort of best practices at the time.
Yeah, though that that's that's really interesting.
Because the last year I've been bootstrapping an application single-handedly, and 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.
F two years ago with 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 Django 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 that makes me really happy and it makes me feel like we were yeah, we were actually onto something.
Good, good, good.
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 the on this topic, just before I let Will jump in with something or other, but the the the recently there's been discussion about the um Django template language again and comparing it to other Django um template languages which let you do more things.
But coming 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 you know if you still have thoughts on that, do you still like it, or do you prefer other things or so
Yeah, I think we, you know, it's it's always this tension, right?
Like I think we were more dogmatic about the sort of restrictive nature.
Um we've become less dogmatic about that restrictive nature over over the years.
I think this idea of like sep separation of presentation from content was um, 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 that was a fairly that was a fairly stark line.
And so, you know, when we were building the template language, we were thinking about people who who were not who didn't have sort of experience in traditional programming language.
They knew HTML and CSS, usually better than we did.
Um but like JavaScript kind of wasn't a thing.
Yeah.
I mean it it was there and people used it a little bit, but mostly to do obnoxious things like marquees or whatever.
It wasn't it wasn't at all anything like it like it was today.
And and so we were building a language for you know non non-developers.
I think these days front end front-end developers, designers, back end developers it's a much more of a spectrum of a bl of a sort of bleed through sort of um you know set of set sort of set of skills you know I 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 programm
ing language, usually JavaScript, right?
Like so what I if I'm working on a web development team, what I can expect from the more 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 in that context someone with with sort of a more you know 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 uh 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 you 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 I would not be building my own template language.
I would be using ginja.
Ginja's 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 were always design decisions like every everything you choose there's something that you 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 ginja is definitely in the former category like I would have made different decisions but not in not in a 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 um the template partials package is just 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 I would because it's just literally one tag.
Yeah and we did a bit of preparatory work in 5.1 which is under the covers and then hopefully 5.2 it you know 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 like I refer people to that all the time because I think that's the first time that's a way to think about like 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 design 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 gonna 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 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.
Awesome.
I'd forgotten about that.
That'd be fun to revisit that and see if I still agree with that 2017 Jake
I mean I think that were mentioned also the the bit about uh ginja and the templates in that one um but yeah well um we want to talk about the current day but as a way to get there um 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 and for forever and ever.
I mean setting you set up the 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 example or something that was open sourced inside a company React Angular um 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 um back on the board of the Django Software Foundation.
Yeah um so at the time Django was not you know was not any it 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 I would have painted a picture that's like 10% 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 come 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 a 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 um you know it was a little more common back then but it was already on its way out and and indeed like the Lawrence Runner World is no longer owned by the Simons family by the local family that owned it.
It's owned by is it Gannette 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 uh the PSF did exist but they weren't doing any sort of fiscal sponsorship um I can't remember if we approached the PSF about possibly donating the IP 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 sm you know a small project right um uh um a handful of folks uh in a literal basement our 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 vi viable path forward uh at the time it was sort of something um uh you know we did rel
uctantly 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 I think the fact that you 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 Fogle who wrote a book called Producing Open Source Software?
Um, 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 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 allowed.
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 mythmaking 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 you know the the the the federal election committee would be using Django and in the 2000s.
No, we didn't.
We had no clue.
Yes, yeah, no, no, entirely.
Well, I'm sorry, I was gonna ask one sort of opinionated 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.
Um I guess how much do you where where do you put that balance, right?
Because there were there were some other um 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 and 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 uh to put it to you, um what's the question?
I mean, you know, both Python and Django have really gone up and to 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 uh like I've obviously thought about this a lot.
Like, like why, like, why why did we succeed at a level that we did?
Um and like, you know, a lot of it is luck to be sure.
Um, you know, t timing was timing was everything to to a large degree, right?
Like you meant 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.
Uh we were lucky in that we uh were able to release Django relatively shortly after Rails came out, maybe about a year.
Um and we were in and we made deliberate decisions that were influenced by Rails.
Rails was really the first back-end web tool, at least that I was aware of, that focused on like 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 you know, 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 enough good enough, a lot of people chose to make to make that leap.
So, so yeah, certainly like one thing we did differently from a lot of other frameworks at the time was focusing on sort of like ease of use 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 learn Python for, you know, some other reason.
They learn Python in in in in college for doing statistics, and then they get a job and they're still doing statistics, but suddenly they need to do excuse me.
That's okay.
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 um, I think, uh, not to get too grandiose about it, but I think Django deserves some credit for the growth of Python.
And I think Python deserves the growth of Python into every domain deserves a lot of credit for uh the growth of Django.
Yeah, I mean, with machine learning and data science and all of that coming so big now, like that Django picks up a lot of traffic that way, I think, as well as the other web frameworks.
Yeah, exactly.
Let's let's pull forward to because you've you've been away from the board and then a couple of years ago you stepped, you came back onto the board.
This is your second year now on the board.
So, and I guess listening to the the the last few minutes where you've been talking about the the development and the growth, the one thing that kind of sticks with me is that Django's kind of that Python 2 to 3 thing, we've kind of avoided that there's been no kind of equivalent in Django for 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, we that's for me, that's kind of Django's killer feature, is its state 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's stability and its you know, API stability policy and all the rest of it, the long-term release, long-term support LTS is.
But we want to keep growing and we want Django to keep pushing forward at the front of web development.
Not, you know, it we it we use this phrase boring from that talk about book 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 those?
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 uh I think so I'll I'll talk about the board stuff.
I'll talk about why I can't mic 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, you know, 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 are 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 we're 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 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 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 maybe I 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.
Yeah.
Um, 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 um a lot of a lot of people who have been deeply involved in um in in Django development um have been stepping back over the last few years for for all sorts of reasons, um, in small ways and in and in big ways.
Um I mean, Carlton, you're one of them.
You used to be a Django fellow and now 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.
So yeah,
I should get to work on Django now.
So Right, right.
But but anyway, but my 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 um things have slowed somewhat.
A lot of longtime people who have been involved are you know stepping back, being being less involved.
Um and there's and there's a lot of 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 been 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, Django's not going to, you know, my my pet feature is I want Django to have first class HTML 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 Django 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 the deepest on my mind these days.
Okay, so you the words you use there were leadership um vacuum.
And I want to uh it's a question I have for you, which is about the the contrast between the BDFL model, the dictatorship, the dictator life model, and then the sort of community consensus model, because both have benefits, right?
In uh so why you know what's wrong with the BDFL model, and then what what is it that we kind of 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 to someone else, it's a net positive.
Yeah, right, okay, cool.
Which says some interesting things about my sort of direct leadership ability.
No, but it's not about you,
you know, not not to no, I'm not 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 and like that is a 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.
It's one of the reasons why I I felt sort of ready to take a leadership role on the board.
Is like I know I understand my own leadership style and 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, right?
I mean, there was a there was a long period of stagnation in 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 and it wasn't until the sort of you know, it wasn't until we we stepped back and abdicated that power that that things like really took off, honestly.
I like you yeah, the the there was a gag I saw on and I fostered on or somewhere the other day.
It was a while back, but the idea is that uh the the reason that project needs a project needs a BDFL is the very reason BDFL stepped down.
Yeah, I mean like you it is it is very, very rare to find someone who is a good a good leader in a dictatorial model and is not and is not doing it because of their ego or doing it because they're a jerk.
I mean like gosh, I Guido is truly a special person to have been the BDF all for Python for so long with a long track record of like being nice.
Like usually usually BDF usually BDFLs are either ineffective or assholes.
And you know, like I was pretty ineffective.
Um I I'd rather I'd rather fail in that way than in the other way.
But like um, yeah, it's it is super it is super rare for that for that model to actually survive for for a long time.
Um I want to pick up on one thing you you said though, because you used the word consensus, and that's this is the other reason why I wanted to sort of return to a leadership position.
Um 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, um, honestly, mostly in ways outside of outside of technology, other nonprofit work, um, other other sort of like um intentional community type stuff.
And um 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 um and sort of well-developed consensus uh driven process.
Consensus is not everyone agrees, consensus is a group of people who are they they 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 happ 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 type of work that Django needs to needs to invest in.
Um we sort of replaced the BDFL model with this rotating uh uh technical board, now called the steering committee, um, 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, a broader slice of the community involved in decision-making processes.
Um another board member, Thibaut, just held a um Django roadmap sort of brainstorming session, um, 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 binding part of Django's governance model.
Not binding in the sense of like, we're all volunteers.
Well, more 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.
Um, I think is sort of the the big missing piece from Django's govern governance right now.
Yeah.
I mean, so I I went to that session and the 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 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.
I take that in a 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 served Django 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 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 gonna 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 is is one or two of them gonna prove to be a bad idea in the future?
Maybe.
But like whatever, we can recover from that.
It's just code.
Yeah.
So I I wanted to ask you about so there's deciding and then there's doing.
And we just had um last week we 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 well, the PSF more broadly, the board there, which I know you've been on, is decides and others largely implement.
Sometimes it's board members on a working group.
Um 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.
Um 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?
Because me personally, I came away.
Part of the reason I stepped down is I felt like it's more than a volunteer can do to go to the next level, 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, uh this was the main this was my main motivation for returning to the board.
Um, 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 of the nonprofit.
Uh if someone needs to file taxes, the treasurer fills out the tax form.
If someone needs to talk to a major donor 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 to individuals, to employees, to working groups, etc.
etc.
I'm this is not this is not a consensus opinion of all nonprofit people, but my opinion is that the directive board is more effective and then as a as a long-term better model for a stable, functional, you know, um, effective nonprofit 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.
Yeah, well, I guess when I joined it, then people had 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 um 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, why should we be so shocked that hiring someone with an accounting background to do accounting is more effective than having an a software engineer with no accounting experience do the work?
Like, that's not surprising.
That's the 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 the DSF.
And and like mo 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 will itself will be more healthy, if the board can sort of transition to a more to a more um uh uh um com you sort of community driven and more um uh uh 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 recogn 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 um with all sorts of different you know backgrounds.
Like but by the new definition, if pretty much anyone who works on an open source Python package is now eligible to be a 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 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 is eligible.
We we've sort of much broadened that that definition in the hopes of getting a lot more people and a lot more voices sort of in 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.
Um and this hasn't moved as fast as I as I would have would have liked, but it is moving along a little bit.
Um we've created a mechanism basically for people to spin up, spin up working groups and to ask for delegated powers from from the board.
Um and it's pretty broad.
That that can really be anything, right?
The board, um, the board can approve a budget and then the working group can go directly spend that budget um without individual approval from the board, right?
The the the working group can ask for um, you know, we've we've just formed a um sort of a social media working group to sort of um 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 without explicit approval from 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, et cetera, et cetera.
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 lead 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 like buy the things they need to buy to host the Jang the Django site, right?
There's there's no there's no need for that to be a board decision and so on and so forth.
So I'm I'm hoping that like we're at this point where we've we've I think created the sort of formal mechanisms we need to sort of transition the board into a into a directive model.
Um, but we're kind of not there yet.
And we need we need people who are interested and willing in getting involved 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 plu 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 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, no, like call out to um like if if you're in the the Django community and you want to get involved and you want to now's a a good time.
Now is 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 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 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 leadership challenge, we've emerged from it stronger after uh, you know, at afterwards.
And I and I don't see any reason to suspect that this that this'll be this will be different.
Okay.
I have a good question.
Will have you got one now?
Yeah, but go ahead.
Okay, so um one thing that I had we've talked about um a few times on the show, and perhaps with Haim and others, but is the gap it still feels to me there's a kind of gap between the narrow Django community of thought, the actual 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 it feels like it'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 a hundred, a thousand 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?
Like, 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, um 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 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 DjangoCon US.
I think about half the attendees of DjangoCon 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.
There, 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?
Uh, 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 gonna write thousands of lines of code and I'm gonna get it into Django by 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 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 of contribution.
And that so I've been thinking about a 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 to that they need to do to do that and writing the tests that they may not be good at these other tasks as well.
So we need, you know, we
need to.
I'll give you I'll give you an analogy.
So like uh uh a hobby I've started to to pick up over the last couple years is is uh pack rafting.
This is um combining backpacking and um and and uh river kayaking.
They're these inflatable boats, they're small, they're lightweight, you can fold them up, put it in your pack, hike for a while, unfold it, float, float down a river.
Um uh it's very hard to get into like it requires a lot of backpacking skill, it requires a lot of ri river skill, white water is is is is dangerous and requires a lot of sort of technical ability in order to like stay out of trouble.
So this this this blogger, um uh and and like longtime pack rafter, uh Dave Channel, wrote a blog post that he titled something like pack rafting progression, which is basically like, so you're interested in pack rafting.
Here's what it looks like to go from this sounds fun to I am executing like, you know, high, you know, like 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, a flat, get in and out of the boat a bunch, paddle around, you know, figure out how to blow it up, etc.
etc.
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.
Um, so we're good.
Will have you got any questions?
So we're we're coming up on time, Jacob, but what are the things in Jake uh what are the things in Django that you're currently excited about that are in the works, you know, solutions to longstanding problems.
Has anything come to mind?
I mean, I 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's dead because you can't do front-end development in 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've 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 with HTMX.
That seems that 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 run 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 DjangoCon 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, uh 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 had 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 letting multiple people update it simultaneously with uh push push sent through server-side events, and it, you know, having a level that level of interactivity was 10% more work than building a sort of old school, you know, form submit work
flow.
Like it's just 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 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 HT.
And it's like it it it 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 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 both.
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 a 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 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 with PHP.
You still can't just throw a Python file on a server and have 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 I have I still think there's a big gap in the Python community around around deployment.
Um people who are interested in this place should play with Deno, Deno.land.
Um Deno is a JavaScript variant kind of with a deployment environment really baked in the language from the core.
Um it's kind of incredible, and it makes me sad that there's nothing like that for Python.
Now, Deno 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 Deno, 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 as hard as it's always been.
Good.
Do you have any recommendations for what well I'll 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 the lack of a managed um Postgres option, like a truly managed one.
Um in Heroku's.
No, Fly has like a first party Postgres option now.
They do.
Yeah.
It's relatively new, three to six months.
Yeah.
Okay.
Um the 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, red, 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, is 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 and Redis and and um and um a really render also has um a uh sort of non non-docker deployment option.
I 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.
1000%.
That was really the biggest thing is for the 4.2 update for one of my for my beginner's book.
I switched to Fly, but I had to talk about Docker, and it's like, oh man, that's just I can I'm gonna be able to do that.
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 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 for newcomers, right?
Like telling someone, telling someone, oh, that's too advanced for you, is like so patronizing and so 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 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's awesome.
Why can't we do that?
And so I I've continually been trying to get as close as we can to that.
Um 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 uh 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, yeah.
I mean it's like, well, we we we could go on and on and on.
But I mean that's is there any I we have um yeah, I was gonna ask you the what would you change about Django question, but you've I think you've kind of answered it.
So that's the um is there anything, you know.
So you do have a day job.
We'll we'll put links to it working on security at Laticora.
Did I saying that right?
Yeah, correct.
Um but peop 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 reach out to me.
My email is fairly obvious.
You can um you can DM me on Mastodon, um, etc.
I'm 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 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 thing.
Jacob, thank you so much for coming on.
Really just such a good chat.
I've enjoyed it so much.
Yeah, thanks, guys.
I really appreciated it.
So we're DjangoChat.com, and we will see everyone next time.
Bye bye.
Bye bye.