Transcript: From Django 0.9 to Present - Russell Keith-Magee

Hello and welcome to another episode of Django Chat. I'm Will Vincent, joined as always by

Carlton Gibson. Hello, Carlton.

Hello, Will.

And today we are joined by Russell Keith-McGee, who has a huge imprint in the Django community,

and we're thrilled to have him on. Hello, Russell.

Hi, nice to have you. Thanks for having me.

So there's a lot of things we want to talk about today, but if you can give the 30-second

version of how did you get involved with Django and put the exclamation points on all the

ways you've been involved because you've been involved what 12 13 years i mean you're one of

the very very the elders of the community yeah yeah yes yes let me straighten my beard was i

positive sense in a positive sense um so yeah i joined the project i wasn't involved at the

journal world uh i was one of the first or one of the one of the early contributors who joined

the project i downloaded it for the first time around november of 2005 where it was about the

0.9, 0, 0.91 timeframe. At that point in time, it was a period where there was a lot of low

hanging fruit. It was there and it was being used, but there was a lot of stuff that could be

improved. And because it was Python, I could jump in and I could read the code and was able to work

out what was going on. One of the first big contributions I made was around many-to-many

fields. So if you've got your models, you've got a many-to-many field where A is related to B,

Django, as of that time, you could query from A onto Model B, but you couldn't query from B

back onto Model A. And so that was kind of useful. And so I thought maybe I want to be able to do

that. I jumped into the code. It was basically take all the code that was there for one,

copy it, reverse the direction of all of the variable joining order that was happening,

and submitted that as a pull request. And after that and a couple of other smaller pull requests

that I had that I put together because I was just kind of tinkering

and this looked interesting and I had some grand plans

of things I was going to do, Adrian mailed me early January 2006

and said, hey, do you want to join the project?

Now, at that time, what we were doing was a thing called magic removal,

which is this very large-scale rewrite which was only going

to take six months and 1.0 was like weeks away as soon

as we could finish magic removal.

Magic Removal was finished in about six months, and 1.0 took about another two and a half years.

But I was there through that process and was involved in the introduction of the user-facing

testing tools for Django. I mentored a couple of students doing Summer of Code projects,

most notably Alex Gaynor and the introduction of multiple database support,

and a number of other little projects along the way over the course of a couple of years.

And you were in Australia this whole time, right, just because we like to talk upon the global nature.

Were you doing your PhD or did you come out of your PhD program?

No, no, I was well out of PhD at that point.

I finished my PhD in 2001 and was working for a defense consulting company.

Western Australia, in Perth in particular, has a very large naval base and there's a big sort of U.S. naval presence and defense consulting is a thing.

And so I was working for them

and we just happened to have a project

at about the same time that I discovered Django.

Like I was looking at Django

for my own background tinkering side project stuff.

And we happened to have a project

where the project plan,

we'd been funded to build this thing.

We were going to build this giant Java client server application

with databases and user interfaces

and all sorts of things.

And I sort of had this sudden realization

in about February of 2006

that we're proposing to build a website except it's going

to be a lot more complicated and a lot harder to build.

So why don't we just build it as a website?

Like it was a data-gathering site for the idea was that you're going

to have assessors, like teachers, trainers in a military simulation context

looking over students who were operating radars or flying flight simulators

and assessing that they were identifying targets

as they were approaching or whatever they had to do.

They met their criteria for training.

And they were just going to be like checkboxing,

yes, they met this criteria, comment,

they could have done it a little bit better or whatever.

And it is literally just filling in forms,

which is exactly what the web is good for.

So why don't we just build the form in Django and say it's done?

And I pitched this to my immediate supervisor.

I've been fiddling with this thing called Django.

I've got a feeling we could knock this project out

in like about two weeks if we just did it as a website

rather than build this whole client server thing.

And he went off and spent a couple of days

and came back and said, yeah, we can do this.

And we had like first prototypes up in a couple of weeks

and we polished it extensively beyond that.

And it became a major line of revenue

for the company beyond that.

But because I was discovering an open source project

at its early phases,

I had got myself embedded as a member of the core team

And then I managed to work out that I could use Django for my day job.

It sort of became a self-fulfilling prophecy that I then had a reason to work on Django

and was getting not paid to work on Django, but at least paid to address some of the bugs.

And they didn't mind if I answered questions on the mailing list during work hours.

So it kind of meant that there was a reason to stay involved as well.

Right.

And that third piece is not always common.

I mean, some of our guests who are very involved, you know, have to code and not Django during

the day.

Yeah.

And I was very, very lucky in that regard that I did have – I was working for a relatively small company that had certain liberties in the way they're implementing things.

They didn't have to adhere to this huge spec that had been laid down by some huge contractor years before and an engineering manager who was open to the idea of trying something new in the name of getting something done well, so done quickly.

It does also work the other way. If I think of some of the major contributors currently who are there all the time, it's because they're working with Django in day job and have that time. People wonder how is it possible to contribute because it looks like these people are giving out a lot of time and they are, but they have that opportunity.

Yeah, and that I suppose ultimately is the thing, is that money ultimately is what decides what people's attention gets spent on.

Now, there is an extent to which the work that I do in open source, like outside of Django, in Django, everything else that I've done, is the way that I entertain myself of a Saturday morning.

Some people do Sudoku puzzles, I fix bugs in Django, or I fix bugs in an open source project.

And it is a fun intellectual exercise from that perspective.

Particularly when you start getting to the really gnarly problems or the really hairy bugs or the rewriting the website, which everyone really wants to do, having someone paid to do it makes a huge difference.

And having someone whose day job it is means that there is a reason to have this work be done, which is a big – the incentive matters there.

Yeah, I think particularly the ORM, like there's a couple of major contributors there who ongoing basis, if they weren't there, I think it would be really difficult for Django to continue. And we're just very fortunate that they're there and that they, because their work relies on it, they are able to give us that time.

Do you want to call them out by name, Carlton?

Well, Simon Chaletes in particular, Nick Pope, you know, Tom Forbes.

I don't know what his work is, but he gives a lot.

You know, there's a group of half a dozen people who work around the ORM

that without them we'd really struggle to move forward.

But with them we are able to do that, and it's fantastic.

And that is true historically as well.

If you cast back a few years, it was Ansi Karinen, a Finnish guy

who was working through his, I think, PhD, who did a huge amount of work

in sort of the 1.1 to 1.4-ish kind of time frame,

if I remember rightly.

And then even back before that, the reason we have the ORM we have

is almost entirely because Malcolm Trudinick,

who sadly isn't with us and died a few years ago,

spent six months almost on his own time.

He spent a lot of time working for banks,

being paid very well to work for banks,

and then salvaged what was left of his sense of contributing

to the community by contributing to open source projects

like Gnome and Django.

And the ORM we have is almost entirely his original design.

Like, yes, it has been massively improved since,

but the frameworks, the bones of what is there is all Malcolm's work

and was done in, like, a period of about six months

after about three or four rewrites.

And I think at one point I have a recollection of a conversation

with him where, like, he had a big contract with someone,

didn't pay him, and, like, because he wasn't getting paid,

all of a sudden, oh, crap, I have no savings left

because I've spent a lot of money contributing my own savings

to Django instead of getting the next contract

and padding my wallet.

Yeah, difficult, hey?

Perhaps that's a segue.

You've spoken on a number of topics, but one of them is talking about, I mean, PyCon Australia 2015, money, money, money was the title of talking about how to make open source sustainable.

I don't want you to repeat yourself, but where are you at with your thinking on that in 2019?

I don't know that I have any more answers, which is the unfortunate part of it.

Like there are a lot of little things that can work.

I think there are still some – I think the problem we've got is that there are lots of ways that we can make a little bit of money.

And also to be clear, when I'm talking about a little bit of money, I'm talking about money that is sort of less than one full-time employee.

I am able to make a little bit of money through things like GitHub contributors and other forms of small-scale fundraising.

It is very welcome.

I'm very glad, very, very grateful to the people who do sponsor me.

But I'm not quitting my day job anytime soon on the basis of the fundraising that I've

currently been able to do available.

And I have a very high profile, a very large microphone and frequent opportunities to use

it.

And I still can't crack getting people to donate to make things happen.

So we have lots of mechanisms of making a little bit of money.

But the large amounts of money you need to be able to hire multiple people, to be able

hire three or four engineers is remarkably difficult to shake out. And the problem that

I'm seeing is that we haven't worked out how to operationalize the fundraising process.

The altruism is clearly not enough to make it happen. The fact that Django is valuable

is, I don't think anybody who uses it or anyone who's in even the broader Python community who

doesn't necessarily use Django, very few people would say it isn't a good thing that it exists.

It isn't a good thing that Python exists. There is a huge amount of good that is being done with it.

And it is good that you can get at it and it's free to get available. It doesn't cost you anything

to download it. Django girls can use it without having to pay a tithe to some large corporation

to be able to get access to the software. But that doesn't translate into large corporations

that are making huge amounts of money through using Python, giving back into a format that

can then be operationalized and used by the groups that are maintaining the software that

is being used.

And to my mind, the key piece here is you need to find a way to express the ask in a

way that businesses can put on their expense claims i've had many conversations with people

that have said you know i've got a corporate credit card i can spend a thousand dollars a

month without even raising a question on anyone's anyone's eyebrows but i have to be able to say

this was necessary for my work and i couldn't have gotten it cheaper elsewhere and the core

thing is they couldn't get it couldn't get it cheaper elsewhere when the price is zero that's

a problem. So finding out what we can operationalize to get those funds out, I think, is the piece that

we haven't worked out yet. And I'm still searching for what that answer is. Yeah, because there's

things like the Tidelift subscription. Is that what it's called? Tidelift is one of them, yeah.

There's a couple of those around. Tidelift is one that's getting the most press at the moment.

It is definitely interesting. And effectively, what they're selling there is the support model

of, you know, we will guarantee there is someone there to support your software.

Because I think it prioritizes the tickets, right?

That's the idea.

If you contribute, then of the thousand open tickets on Django, you could say, I really

want this one done, Carlton.

Yeah, it's not quite that.

That's my sense.

Because they're saying that they will provide the resources to make sure that the issues

that their subscribers have get resolved.

And effectively, they'll pay the open source.

Yeah.

they will pay the contributor to do that um the the there are two like the one of the problems

that exist with that is that it does work for a maintenance capacity it works reasonably well for

fix the bug that's there it doesn't work well for funding work that need large-scale work that needs

to be done so i have actually spoken with the guys from tide left and they're effectively not

interested in doing anything to do with bware because bware doesn't have a user base yet

And so-

Can you just mention-

Oh, sorry.

Can you just mention what Beware is?

So Beware is a sort of project that I've taken on having,

I now have, I do less work in the Django community

on a code basis.

I'm still around, but I don't do as much in the code base.

Beware is my attempt to get Python running

on all the new devices that people have,

on iPhones, on Android tablets, on Android phones,

in the web browser as a client language

and things like that,

and provide the tools and resources

to get Python into those spaces.

It is still very much early days of that project.

Like most of the tools are version 0.3

and even that is optimistic in some cases.

But, and as a result,

Beware doesn't have users.

It doesn't have people

who are using Beware to make money.

They're not the cornerstone of the company,

the .com, the startup that they're running.

I'd like that to be where it ends up,

but this is Django a year before

it was publicly open-sourced kind of space.

There's still work to be done.

There's a lot of work.

there's resources that need to be spent. Tidelift isn't good for that model. It's only good for

fixing bugs in things that people are actually using. And ironically, it almost works. The same

problem almost hits when it gets to things like Django. Django is stable. Django is out there and

is working. Yes, there are bugs, but they're not that common. They still occur and there are still

things being fixed and whatnot. But compared to the rate of change of bugs that were there

five, 10 years ago, it's a lot lower. Yeah, it's very stable now.

It is very stable. I suppose the theory is that you're going to pay Tidelift for this guarantee

that bugs are going to get fixed, but which bugs and why? Why am I going to buy this support

contract? Yes, there is absolutely the covering of butt, making sure that it will be updated

aspect that possibly will actually drive that. It'll be interesting to see if Tidelift does

managed to sell that broader narrative of, you know, insurance against the thing that should we

hope never happens. So yeah, Tidelift is definitely an interesting development. I have some reservations

about the fact that it's a VC funded company, which does sort of affect the economics of what

they're doing. Like they need to make a large amount of money out of this in order for it to

be viable, not just for open source projects to be viable. However, I will take them on faith that

they are doing what they are doing for good reasons. And we just have to shake out to see

where that goes so another i mean because i think a lot about this how to the craziness since i'm

newer to it than you are the craziness of how used and how much work people are putting into

django and then you have these large companies that we can't align their self-interest with

the projects and again i'm always curious about how decisions are made you know because it is

sort of a consortium i mean for example django rest framework if you sponsor it you can you

a prominent place on the documentation that seems to me like an obvious way to get you know probably

a developer's worth of salary on the django site to do something similar because i mean i donate a

lot of people donate if a company said oh for a thousand dollars you rotate through a place because

recruiting is a big issue for folks right like i wonder if has that i'm sure that discussion has

come up where is the to the extent you two know the consensus on something like that that seems

like a very easy win to me from the outside so i can't speak to where the conversation is uh right

now i can i can speak to where it was a couple of years ago um because i went through a period

being the dsf president so yeah i'm sure you i'm sure you did um the there's sort of there's two

pieces to it one is the the reason it's problematic is that if you're dealing with that budget you're

essentially like the money that is spent on putting your logo on the website is either a

marketing or recruiting budget, which is good money if you can get it, but very fickle and

very prone to changing. We see that in conference sponsorships. Some years it is trivial to get

conference sponsorships. You throw it out there, say there's a conference and money just falls out

of the sky. The next year, half the sponsors don't want to show up because priorities have

changed in the way they want to spend their money or revenues are tight this year because of global

financial crisis or whatever and all of a sudden marketing budgets are lower so right the money is

highly flexible and is not tied to how much the software is being used it's how much tied to how

much benefit they think they can get through being prominently placed on this on this website how

much easier it can make their recruiting task right well they don't really have analytics on

it per se yeah um and the other side of it is literally it's that it's the the community pushback

or at least historically has been a community pushback

to even putting analytics on the web page

because of, in particular, the European focus,

like the GDPR, data privacy type thing,

there is concern about how much data we are gathering

about our users and whether that information

is going to be exploited, whether people have the right

to use the software without being tracked, and so on.

I can't speak to whether that is still currently a problem.

I just know that there was a lot of pushback.

It was one of the very early depths that Jacob Kaplan-Moss put together

was around tracking, just putting into Django Start Project,

tracking who, like putting in as an opt-out,

we want to be able to log that you're using this

just so we know how many people are using this

and we can use this for recruiting purposes or fundraising purposes.

And there was a huge pushback against that as a concept.

Yeah, right.

And the same with Homebrew, the Homebrew package manager for macOS.

That had the same problem.

They've got, I don't know if they put it in in the end

or if they didn't put it in,

but I remember there being a really big hoo-ha

when there was a discussion about putting it in.

And it's difficult because it's this trade-off

between needing to justify your existence

and needing to say to companies,

hey, we're worth your money.

And then this whole open source free software thing

where it's like, no, no, we don't want to attract users.

And for, you know, those are all good reasons too.

Like, but that's not attracting users, right?

I mean, Carlton, you must,

maybe we can ask Tom when he comes on.

I mean, I imagine it's a sizable amount of funding for DRF.

Yeah, I will say that DRF is probably the one success story

that it has gone extraordinarily well for them.

And, you know, mad props to Tom for everything

that he's been able to do around that space.

That, you know, he took a project that was...

But he's still on an ongoing basis needing to re-find sponsors

and redo it and, you know, like if you read the monthly reports

that he puts out, he's very open on the funding situation

for Encode and it's not a done deal.

It's not like he's got sustainable forever.

It's like sustainable right now, but need to draw in more.

But he's doing amazing work.

Yeah.

Well, maybe it's a conversation at DjangoCon.

I'm happy to be a bull in a china shop on this because I have no past scars.

But it seems I would like Django.

I would like Carlton and Marius and others to get paid Andrew for the async work.

And it's such a hassle for these talented people at free or a discount to do it.

And I don't think the community realizes the problem, right?

because it's not their problem, and if there are these solutions out there.

Yeah, and part of the dilemma here is that if open source is working well,

magic software falls from the sky that everyone can use,

and you never have to think about how that sausage gets made.

And yet it gets built because Andrew Godwin is effectively taking a huge pay cut

to contribute some of his own time to work on this stuff.

Now, I don't think necessarily that open source contributors should be making millions of

dollars a year, but they certainly shouldn't have to be making a serious life decision

about, should I be in a position where I give up having a comfortable lifestyle so that

large corporation with billions of dollars in the bank can make a little bit more money

off of my efforts?

And that's the part that really greats my gears.

Yeah.

Well, this will come out probably a couple of weeks from now, but we just released last

week the interview with andrew which um a lot of people listened to and we had hoped to have

be able to put a link into the funding around that um and just the machinations of that it's not

available so yeah i think and it's i think it's important for people to highlight to the community

because these are real issues and and some other you know i'm always interested in how other

frameworks do these things i mean for example um laravel php is a one-man shop and he's very open

about uh he sells a there's a i think it's an e-commerce option for like 99 so consultants

can use it and you just download that and you have boom a sas product you can sell he also has

hosting so there's a lot of i try to find inspiration in other areas for how they do

things you know view links to uh it's view mastery educational content where they give

five ten percent or something of the sales of the educational product to back to view so yeah i try

to put my thinking cap on i know other django content creators i've had this discussion with

them i mean i would love django to have a page of current educational resources and to get an

affiliate fee but i know that has been discussed to death and the community doesn't want to pick

favorites is the django view on that yeah that and that has been historically a push the one the

laravel and the the php wordpress is another example it does it as well so there's two

levels at which these things operate. Like we were talking before about the fundraising coming

from marketing and hiring, recruiting budgets. The real goal is to get into someone's operational

budget. Now, AWS is never going to not get paid because if you don't pay them, they turn off your

website. Their bill gets paid every month on time. That is the budget you want to be in on.

Now, in the case of Laravel, they've got, here is a product we can sell that you can use. It is

cheap enough that anyone can get access to it, but it's enough to make sure we can fund the rest of

the development that's there. WordPress then takes it sort of a step further in generating the

marketplace of saying, this is where you can get your plugins. This is the place where you get all

your stuff. And as a result of that, there is now, just as much as there are, this is how to build

your WordPress website, there are training courses about this is how to build your company building

wordpress plugins because there is there is an expectation in the community that money will be

part of the process and there is a mechanism by which that money can change hands uh and that

and it can be expense to the client too and it can be a huge one i think yeah yeah because maybe

why i mean we had uh tom dyson on with wagtail that would be a context where it would be easier

to yeah because my friends they're just like yeah nine nine dollars whatever expense it to the

client and it saves them a thousand dollars of time but django is a little more custom and advanced

typically and how it's used yeah well or at least the the core of django is and they're like the

there are two places where i can see this potentially you could potentially

get into the into the chain here one is not saying put a paywall in front of pi pi but at

least put the ability so that you can charge instead in front of pi pi so if i do want to

released by package on pi pi still be open source but if you want to pip install it you have to you

know swipe the credit card and money goes through the till that radically changes the dynamics of

pi pi and i'll completely grant that but yeah you know pi pi pro is a mechanism that is that is the

operational point at which you get into someone's budget the second one is one that i i would love

to be able to get in front of someone to propose this uh and i'm hoping to be able to have some

conversations at PyCon this coming weekend for me and hopefully you know others or other conferences

around the place is to actually get to the AWS and the Google's and Google Clouds and the Azure

people and say okay you know all this software that you're you know you're putting up the platform

you are in some cases actually operationalizing open source software in the case of stuff like AWS

can you like put a check like if if you are selling microsoft um if you sell a microsoft

license for ec2 you buy a microsoft license that are you know at your prorated rate of a

microsoft license can can you put a checkbox in there that says that i'm using the open source

license charge an extra half a percent of the of the money that's going through there and then

funnel that into open source foundations because that is a trivial box for any engineer to check

it is a bill that you can guarantee will get paid every month and that money can then funnel into

the community actually convincing the microsoft's and the amazons and the googles of the world to

do that i is a much harder sell but i would love to see that kind of program in place

because that is the operational that is where the money is that is where the money is changing hands

at volume and if we can if we can funnel even the smallest portion of of that that would pay for all

of the django development we ever needed it would pay for all the maintenance of the open source

tooling that we ever needed and it's not just jang i mean with this podcast is about django but

it's not just django it's every little project out there you know it's all the third-party apps

in the django ecosystem it's all the packages on pi pi in the python ecosystem and then the same

for the javascript world and absolutely absolutely none of it's fun well and i love that the

engineering mindset is to appeal to people's better nature because perhaps because i have an

mba you know fear works better unfortunately right like fear being like hey maybe django won't be

around, and finding a way to do it in not a blackmail kind of way. But that is the reality,

right? If Andrew Godwin isn't able to be paid, even at this massive discount, async's not going

to happen in 3.0, probably. These are these stark terms. But anyway, so I love that we're all

thinking positive, but there are real costs, right? I mean, before, that's why... I mean,

Actually, maybe you could talk about, I know you were actively involved, we had Tim Graham on, the Django Fellows, kind of why that came about and then how, right?

Because it was, what, two plus years between releases?

And then part of Tim's work was to standardize that to the schedule we have now, right?

I believe you played a big role in that.

I played a big role in getting the fellowship program going.

That was like one of my last hurrahs as I walked out the door of being DSF president.

I think we did have a fairly regular release cadence.

It was a much slower release cadence and often slipped by months at a time.

Yeah, we did go like 18 months or two years at one point, yeah.

But it was kind of more of a realizing that we were having this slow increase in the number of tickets that were being opened and they're not even really looked at.

And there were patches that were being contributed and not reviewed.

So the DSF itself is an interesting legal structure.

It's a 501c3, which is a US not-for-profit foundation.

The US tax office doesn't consider software development

to be a charitable activity, which is a problem

when you're a software-based foundation.

So the DSF, there's a number of things the DSF can't do,

and one of them is we can't hire someone to write software.

so I shouldn't say we. The DSF can't hire someone to write software. If you look at the terms of

which Carlton and Tim and Marius are employed, they are there as community managers. The community

management process inevitably involves some writing of software, but they are there managing

the ticket process, making sure the wheels agrees that everybody's contributions are actually

happening. The DSF actively paying for Andrew to work on something gets into very, very weird

territory. And I won't profess to speak to where that discussion currently is or anything like

that in terms of the DSF, but I am aware that those issues exist. Even to the tune of, there's

been some recent discussions about paying members of the DSF board for the roles they're doing.

Like, you know, the person doing the accounting, which absolutely has to be done right and has to be done on time, but also gets very weird if you pay them because of the way the 501c3 operates.

So, yeah, anyway, that's getting deep into the weeds.

No, that's interesting context because I didn't know that.

I just asked Andrew and he vaguely referred to issues.

Well, so perhaps to transition.

So you're wearing a Django con sweatshirt that people can't see but Django cons. I've heard stories of pink

So pink it comes over the audio maybe when did you?

You were at the first DjangoCon, right?

Because I've heard stories of you giving multiple talks in the early days when you couldn't get enough speakers.

And I guess how have you seen DjangoCon's advance over time to where the San Diego one's coming up in the U.S. this fall?

Yeah.

Well, there's another one before then.

There is DjangoCon Australia happening in just two days.

That's right.

So I have been to every single DjangoCon except two.

So I missed the very, very first DjangoCon Europe in Prague,

and I missed 2013 in Zurich.

But I've been to every DjangoCon US.

I've been to every DjangoCon Australia, most of them because I was organizing them,

and I've been to all but two of the DjangoCon Europes.

That's quite a commitment.

Yeah, and actually I tied that record with Andrew.

Andrew has been to all the U.S. and all the Europe,

but has missed two pipe on Australia.

So we're down to monkey knife fight for last man standing

on who's going to take it.

Well, I saw he was tweeting about just landing in Sydney,

so you guys will tie this coming one.

Yep, we're staying tied.

Whoever drops out first.

So, yeah, it's been all right.

They have changed a lot over time.

Like the very, very first DjangoCon U.S., 2008,

was essentially Django 1.0 was about to happen.

Someone went to Jacob and Adrian and said,

hey, how about we have a conference?

And they said, well, yeah, sure, as long as you organise it.

They managed to arrange with Google,

for Google at the Mountain View campus,

to provide a space for two days.

And they did all the AV recording and whatnot.

And we called in a bunch of favours with friends and whatnot.

We got Cal Henderson, who was the, well,

was one of the founders of Flickr, is now one of the founders of Slack,

who did one of the opening keynotes, which is still to this day

one of my favorite keynotes of all time, well worth going back and watching.

And it also set an interesting theme that ran for a couple of years.

The talk is called Why I Hate Django.

And it was basically Cal Henderson as a person who builds a website

or was responsible for a website that was several hundreds of orders

of magnitude larger scale than anything Django was operating with,

talking about why Django wouldn't scale to that level.

And it was this combination of he's a very engaging speaker

who had the entire Flickr as his slide deck image catalogue

and amusing reasons.

We couldn't possibly use Django because it doesn't have a mascot,

preferably a mascot with magical powers,

which is where the Django pony is.

Hence the Django pony, right.

After that comment.

And then one of the problems is that it doesn't do multiple database support.

Multiple database read-write support is absolutely essential if you've got large traffic because you have to be able to charge your reads across multiple sources.

At the time, it didn't.

One by one, we've actually been hitting off most of his criticisms.

I think I went back and ordered them at one point.

We'd only missed two or three of them, and they were fairly edge case things that only Flickr needed or were of marginal utility.

So, yeah, that was also set the tone because for many PyCons

after that, or sorry, many PyCons, many DjangoCons after that,

we had a habit of inviting someone to speak at DjangoCon

as a keynote from a different language community

to tell us what we were doing wrong.

So you have someone from, you know, the small talk community

come and talk about why small talk is better.

Have someone come and talk from the Zope community.

Come and talk about why Zope is better than Django.

Or Ruby.

Interestingly, we never managed to get David Halmy Hansen

or anyone from the Ruby community that I can remember.

Right.

Well, I just emailed him actually, blind emailed him yesterday to say,

hey, you should come on our podcast since he's on every other podcast.

Yeah.

And also David Lord about Flask.

So I'm glad.

I didn't know this was a thing, but I'm glad it is.

Because I think ultimately, you know, 95, it's like, you know,

our DNA with chimpanzees,

like 98% is the same.

And then the differences

are actually really helpful

for both communities to discuss.

Like Flask, Andrew was talking about,

in Flask, they're tied to WSGI.

So they're going to have a,

it's interesting to see

how they'll adapt to an async world,

for example.

Yeah, and that shared DNA thing

is absolutely a thing.

Like Rails implementation

of cross-site scripting,

CSRF handling,

is almost, you know,

mod the language changes and squinting,

is essentially the same approach the same implementation when we have had security

reports against django's csrf handling you send an email to the rails guy to say hey by the way

you might want to just check to see if you're affected by this as well because chances are you

are and we've had a couple of those go back and forth of they find a bug and tell us we find a

bug and tell them and yeah it turns out we're both affected by the same bug and we do almost

parallel security releases around the same problem right well i think that's because beginners see it

as a competition and then people working on it see them as complementary tools so i think that's

an important distinction to make for people because i mean i'm asked all that as an educator

of beginners all the time rails flask this and that and you know i i want to say it doesn't

matter but i want to give advice to people which is usually just pick one jango's a great choice

but just pick one and get into it and once you've learned one you'll see the similarities between

all the others you'll be able to bounce around as needed yeah i think it is simultaneously the

most important thing and the least important thing. It is the most important thing because it will

literally be the thing you work on every day. So make sure you pick a community you like and

there's documentation that's good and it seems to be healthy and progressing because you don't have

to replace your code in two years' time. But once you've met that basic requirement, it honestly

doesn't matter which one you pick as long as you are comfortable with your choice because

Ruby and Python, yeah, okay, there are significant differences, but there are more things that are

similar than things that are different absolutely uh what else there's a lot of things we want to

cover so i'll i'll jump to so actually one thing that i wanted to talk to you about i think this

is the first time i emailed you out of the blue and you responded about your talk on authentication

red blue user because this is back when i was wrapping my head two years ago around uh the

multiple user models in django and um i remembered yeah i was like why would you need a custom user

model and this is a great talk we'll link to it but you were giving the example of not everyone's

name fits a first and last name paradigm especially yours and i know you and andrew pinkham have

worked on django improved user project right which i've talked with him about yeah so maybe to tee

that up perhaps you could talk about so why do this django improved user project what's how do

you handle i think the interesting question is how do you deal with a legacy thing like the user

model that's built into django yet there are these limitations that we want to make it forward facing

to match modern patterns.

Yeah, sure.

So the work I did with Django Improved User is effectively

the public-facing contribution of something that's very difficult

to add into Django's core itself.

Django 1.0 did what every website does.

It sets up an internal user model that is first name, last name,

and a password.

And it turns out that is a serious anti-pattern.

And it is one that it normally ended up hitting people not because of that anti-pattern, but because people wanted to log in with an email address.

And if you've got a username, first name, last name, and username is capped at 16 characters or something like that, you can't put an email address in it.

And so people say, oh, but can't you just increase the length of that to 40 characters?

No, it can't be 40 characters.

How many characters do we have to make it to be able to allow it to accept an email address?

And so on and so on.

But even once you get past that problem, you then end up with, okay, well, but then you've got first name and last name.

And not everybody has what you could reasonably call a first name and last name.

You go to things like a lot of Chinese names, for example.

Which name is the first name and which one is the last name when you say Mao Zedong?

His given name is Dong, which is the name at the end of the list.

But if he puts Mao, like he put it in the order in which it's written, you're going to get it in the opposite order to which it is useful if you're thinking the last name is the one that's the family name.

If you go to the third Secretary General of the United Nations, his name was Tut.

That was his entire name.

He only has one name.

There is no first name, last name.

His name is Tut.

So what does he put in last name?

If you've got a lot of Islamic people will have a sort of a pre-given name of Muhammad

as an indication of piety.

That is their first name, but it's not the name you'd ever call them.

So there are a bunch of these problems that exist when you say first name and last name

that aren't immediately obvious.

And so I wanted to get in there and say, okay, yeah, we are baked in that we have an existing

user model.

We need to move off of that user.

Django having a history of essentially not breaking anyone's code unless we absolutely have to means we need to find a way of migrating out of that.

So that means we need to find a way to allow users to opt into a new user model such that they can then say, OK, now on this website I'm building, this new website I'm building, I'm going to use a better pattern for that.

One of the better patterns that exists is sort of short name.

What name do you want me to use to a casual name?

And what do you want to use me to refer to you as?

If I write a letter to you, do I say, dear Will, what's the Will bit?

That's that name.

And then full name, how do you want me to address you when I send you the legal filings?

I want William H. Vincent or whatever, the full name that's there.

you're then capturing the role that you want the name to fill

rather than some preconceived notion

of there's always a first name and a last name.

The problem is that my original goal

was to see if we could actually get that

as a contrib module in Django itself

because there are like that short name, full name

is a common enough pattern

that at least people shouldn't have to reinvent the wheel

over and over again.

But it turns out there are some problems

with that around testing.

And the biggest problem around the swappable model thing

that Django user models do or does is around migrations

because if you change the user model,

like Django's migrations don't trace the state of the settings file

and you can change your user model by changing a setting.

So you need to then have an audit trail for some of the settings

in your configuration file and hilarity ensues from there.

That is ultimately the technical reason why it wasn't done.

So the easiest way to manage that from a practicality perspective

is let's have a completely standalone project

that does it the right way and is tested

and does all the things it needs to do

and has all the integrations with all the things

it needs to be integrated with and is being tested

against recent versions of Django and so on and so on.

But let's keep it external and deal with it that way.

Well, I remember tweeting with Tom Christie about this very issue when I was first wrapping my head around it.

And I was saying, well, why can't we just default to a custom user model because that solves a lot of problems for people.

And he suggested potentially you could do it with the start project command.

Now, this has complexity, but saying there's like advanced version where from the beginning you maybe and then you could sort of stuff in all these other things that are legacy issues without breaking.

But I know it's a tricky thing.

And I love the beauty of just not having these issues on Django.

But there are, yeah, these general legacy questions.

There's a number of things that would be nice to be addressed in a non-breaking way.

Yeah, no, I agree.

I think this issue that the start project template doesn't give you a custom user.

And yet the docs say you should have one.

It's like, but I've started project.

I've started code.

I've created some models.

And then I've come to read the docs in more depth.

And oh, no, I've done the wrong thing.

and by then it's too late and yeah but it's one of these it's a complexity it's a complexity you

only know it exists when it's too late to know it exists um and so then you've got to start your

project again which is kind of a bad user experience but yeah it's it's awkward and one

of these things that you know because it is just awkward enough and there is just enough of an easy

enough way to work around it that the no one sat down and spent the you know the original uh

ContribOrth, getting that landed was like a three, four months worth of all of my open source

contribution time just to get that landed, let alone all of the other problems that come with

making sure there's an onboarding path that makes it easy to adopt what should be the right thing

when you come on board and things like that. Speaking of onboarding, I'd love to have you

talk about your PyCon speech from this year that I was able to sit in the audience for,

where you spoke about the challenges around Python itself, around installing if you deal

any beginners and then packaging i wonder if you could give how would you sum up that talk because

we're going to link to it it's an amazing talk but it talks on some of these existential crises of

our potential issues around how does python die and this might be one of the ways yeah so i mean

it's it was a weird one and that there's what was sort of standing up and being cassandra talking

about how how the world was all like the python world is going to die um which actually ultimately

wasn't really the point of the talk. The point is that it can die if we don't pay attention to what

is going on. I heard a really interesting comment today. Someone pointed out that, I think it was

a talk from Lucas Lange from his keynote at Pylandinium, which was an awesome talk as well,

mentioning that the rise of the AI and data science community coincided with a switch from

Python 2 to Python 3. And that may have been what saved Python from the Python 2 to Python 3

transition. Because we had a sudden influx of new users just as we were adopting a new code base.

And so they weren't coming with the hangover legacy of the old Python 2 code base.

And it's interesting to note that a lot of the uses where Python has historically

had a lot of use in the web space, in system administration and whatnot,

those groups are less common than they once were.

Now that doesn't mean it's the doom and gloom

and the web's been ceded JavaScript and systems language,

everyone's using go for systems.

But it is an interesting observation,

if only because it means you have to look for

where your next user is coming from.

And there are a number of things that exist

in the Python ecosystem at the moment that are not good for

our next users. Our next users, the example I gave in my keynote is my son. My son started high

school last year. He doesn't have a laptop. A lot of schools will have, everyone's going to have a

computing device and they do all their high school work on computers. My son has an iPad.

All of his educational experience is delivered through an iPad. Why is he going to learn Python?

Yeah. Why is he going to learn Python? You can run Python in a simulated shell or something

on a website but you can't build an ipad app in python so why is he going to learn python

now that doesn't mean it is python is still a good language to teach people to program in

but if you if you're faced with a teacher who's looking to optimize their education outcomes the

way they're going to do that is by exciting the kids to be able to do something practical with

their device the actual device they've got in their hand if python can't do that we have a problem

similarly the how do you even outside of actually on a desktop machine i write a you know we're

going to get a kid invited interested in in writing writing code uh we want to uh they want

to write a game they want to give their game to their friend point me at the page of instructions

where i can teach a 15 year old who has just written their first game how to package their

game to give it to their friend where which doesn't involve their friend also reading the

same page of instructions about how to set up their python environment install these dependencies and

everything else they're going to go through. That's a problem. That user experience, one of

the big areas where Django and Python have advantages is in this space of people who are

not computer science geeks. They are people who are using computers as tools to get stuff done.

And our tool chains don't well support that use case. You need to have a very deep understanding

of environments before sandboxing and virtual environments makes any sense whatsoever.

Once you understand it, it makes a reasonable degree of sense. But getting to that point is

huge. And packaging that code to give it to someone else is a non-trivial activity that

there are no standardized answers for that, or not particularly good standardized answers for

that at the moment. Even just the perpetual bane of Django Girls workshops. You get a bunch of

people into a room. You teach them how to use Django. You teach them how to build a website,

which works fine on their local machine. And then you tell them we want to deploy it

on any environment, be it Heroku, be it Python Anywhere, whatever. Python Anywhere is a lot

better than what it used to be when it was Heroku instructions. But deploying a Django website is

not a one-button-click thing. You've got to get multiple configuration files and paths set up in

the right place and configurations going in the right direction. And that is a lot more than most

people are willing to put up with to just get a website up and running well yeah you don't have to

but you should i mean i say that so my jenga for beginners book we handful of steps but i mean we

don't we don't do all those things so you get it up it's not particularly secure and um but then

yeah jenga for professionals my new book i have multiple chapters on just like the bare you know

80 20 minimum and it's yeah it's a lot of steps um and i i think the challenge too for teaching

is that you can, people can use something like Django cookie cutter, which is fantastic and does

a lot of these things, but you're not going to understand it. If you just drop that into your

tool chain, you kind of have to learn how to build it up yourself, which is, um, at least in that

book, I spent a lot of time building up how to do that. But yeah, your point is directly accurate.

I mean, you know, like rails, Heroku was built for rails. They did have one click deploy. Uh,

and that was sort of the rails. Was it rails tutorial? I think, um, I modeled a lot of things

on the Django for Beginners book saying we can get pretty close to that, actually. So like the

first chapter, we deploy Hello World. But there are a couple extra steps. I mean, I'm personally

excited with containers. The deployments can be a lot easier. I mean, it is sort of like trusting

that the image and everything works. But for Django girls, I mean, I think about this with my

Django X starter project. There is a degree of, should I add a Docker part where it's like,

just trust that this works and, you know, fixing it will be a lot more work, but you can get pretty

close to a one-click deploy and then at least give people the confidence that it's, you know,

I find the moment that someone can not just deploy it themselves, but I say, show it to someone else.

That's when it really clicks. And, oh, now we can add Google Analytics and you can prove and you can

see that they actually did it for beginners. You know, that's sort of like the face in the

New York Times website. You know, it's like these like booms in people's head around what you can do.

And I agree.

If you compare it to the deployment experience of PHP is copy a file with FTP to a website, and your website is up.

So that's what we're competing against in terms of degrees of simplicity.

I agree.

The Docker experience, other than the fact you have to sort of download the universe before it works for the first time, the containerized model is definitely very interesting.

and seeing that sort of evolve into more tutorials

is definitely something that's interesting.

But then you're also right in that having a cookie cutter

that spools out thousands of lines of code,

which is all boilerplate,

and you're trying to work out what that boilerplate does.

Actually, for work purposes,

I had to play around with Falcon,

which is a web framework that's asynchronous by default.

That was delightfully refreshing getting going.

It is literally three lines of code and you have a web server type territory.

There's a lot of stuff like this is the classic Flask versus Django thing.

There is a lot of stuff you don't get, but the simple stuff works so quickly that it's

compelling.

And that zero to kick ass time, that time it takes you to go from, I know nothing about

this to doing something useful that I can see is applicable to my personal situation.

And I understand what it was that I did.

It wasn't just me copying and pasting this hundred lines of code and hoping I understood that it did what I meant it to do.

That's a powerful thing and often overlooked.

Yeah, well, I think you, I mean, that, and that's possible with Django.

I mean, if you Google like Django Hello World, I believe I have the top hit for that because you can really do it in just a couple lines of code, which I think if you're an expert, you sort of, you know, go, oh, that's not correct.

It's like, well, it's enough.

At the same time, I think, you know, cookie cutter, like I've learned so much studying that project, but certainly when I was starting out, I was just, what is going on here? And so a long term goal for me is I kind of laid it out in the book. And once I've my Django X project, I'm going to basically say, here's this project. And if you want to know how I built it step by step, the book will show you just because there are so many steps.

And again, you have to make some opinions as an educator or as a designer, but opinions are better than sort of going, well, it depends, which Carlton and I joke is the tagline of this show.

Well, yeah, it depends.

That's every episode.

But I think it's like you mentioned with Docker, it can be easy one-step deploys.

Well, yeah, I've got a one-step deploy, but I've got years of putting together playbooks to make that deploy happen.

But can you share it, Carlton?

Can you share it, though?

Yeah, it's, well, more or less templatable and shareable.

And yeah, and you give it to clients and you, you know,

but that knowledge isn't something you can expect a kid

picking up a Chromebook to have.

They've got to have a much smoother story than that.

Otherwise, but you know, I look at Mac apps or Windows apps.

It's not a trivial process to package one of those.

If you build a, you know, a Mac OS app with Xcode and,

okay, once you've got the final executable,

but to get that executable is really quite difficult.

think the answer which i find exciting is these on these web-based containerized uh programming

platforms like replit like yeah like glitter what is it glitch yeah they're all doing the same thing

i mean if you're a teacher a lot of times yeah you need a way you can automate testing and

students don't have to have their own laptops they can have any computer uh you know in some

ways i i wonder if that will solve some of these issues because it's all just in the cloud the

problem there is the business model which is it's hard to get money from students and at some point

You want to eject and go to the real thing, sort of the challenge, I think, Python Anywhere and Heroku and others have is people eject at a certain point.

Anyways, well, we're coming up on time.

We've thrown a lot of questions at you.

Are there any projects or things you want to highlight, Russell, before we head out?

Oh, throw me on the spot there.

Like, I am very excited to see what Andrew has to say this Friday he's talking about async and sort of where that's going.

That is, for me, one of the big unanswered questions

of how Django moves to the next level.

Django is what it is, and it is great at what it is,

and it does more than enough for plenty of people.

But async is a thing.

It exists, and there are things you can do or do more of,

increasing the lifespan of Django if that's better supported.

The other end is like, and this plays a little bit into Beware,

it plays a little bit into things like Wagtail,

is the front-end story.

Like I very badly would like to see a much less JavaScript,

much more Python front-end story.

And I don't know that I have any good answers.

Like I can't point at anything there.

What Beware is doing is kind of part of that big picture,

Seeing that Wagtail is there and you are able to build rich widgets

and rich containers and rich experiences through things like Wagtail

is certainly interesting.

But I don't think either of those projects are by themselves

the end of the story.

I think there is an opportunity here to reclaim some of the ground

that Python has ceded in the web space to JavaScript as a client

at the front end through things like better use of technologies

like Wasm, WebAssembly, but that is a much longer project

and one that is going to take eyeballs and attention

and who's going to spend the time to build the thing

and then open source it so that we can all use it.

Can I ask about WebAssembly?

Do we have currently the ability to, for instance, script the DOM there?

Oh, yes, absolutely.

So if you go to Pyodide, well, Zilla has been playing with this

with Pydide, if you go to the Pydide sort of the demonstration page,

that is effectively a Jupyter notebook running entirely in your browser.

So it's, you know, full CPython, full NumPy, full SciPy,

full Matplotlib all compiled to run in your browser.

So there's not like Jupyter kernel running that your web browser

is talking to like the normal sort of Jupyter model.

It is all running in the browser as WASM, as WebAssembly.

And it is literally just the CPython sources and the SciPy sources and the NumPy sources compiled into WebAssembly.

The downside is that it's a little bit big.

Like it's about 12 megabyte, I think, for the full payload download, which is not…

Which is quite a lot on a page load.

It's fine if you're downloading a Jupyter notebook that you're going to use once, like load once and then use persistently.

It's not if you want your homepage of your website to be that.

Yeah, I was thinking like a sort of jQuery, but using Python, you know, so you're actually scripting the DOM and doing so you instead of having an HTML file, a CSS file and a JavaScript file, you'd have a HTML file, a CSS file and a Python file.

Yeah, it is entirely in the realms of the possible.

And that is kind of what I have been playing around with Batavia.

Batavia is not doing it with WebAssembly,

although I have some thoughts about how that might progress.

It is entirely possible.

You can, from within Wasm, access the DOM,

and there are multiple channels by which you can get to that.

There are some garbage collection issues you kind of need

to dance around a little bit, but you can certainly do it.

And I have had at one point in the not too distant past

a demonstrator of, like one of the talks that I gave at PyCon Australia two years ago, I think,

was a demo where in the space of 17 minutes, I took one Python file, one Python application,

deployed it as a native Mac app, a native Windows app, a native Linux app, a native iOS app,

native Android app, and as a single page web app. And it was only a Fahrenheit to Celsius converter.

But in every one of those steps, there was nothing other than the 40 lines of Python

just deployed in different ways and it would work natively on all those platforms so it can be done

yeah and that would be awesome because that's kind of the missing thing i can do i can use python for

analyzing data frames i can use it for scripting system administration tasks i can use it for

building a website but if i could somehow build a gui on front of that for a native app that would

be ah brilliant and some of it is actually it's part of the reason why like what are these to my

mind part of the reason why node has become such a big thing is that javascript is the language

it's in the client, there are occasions where you have logic that needs to exist in the client and

needs to exist in the server. If you've got a credit card validation algorithm or something,

it needs to run client-side and server-side. If I have to write it in JavaScript in the client-side,

then why shouldn't I write it? Why should I just use the same implementation? Why should I have to

re-implement it on the backend? But if we can push it the other way, that's incredibly powerful.

Right. Especially as JavaScript is becoming more Pythonic over time anyways,

even if it's syntactical again coming yeah again coming back to the fact that you know all the

ideas there's only only a half a dozen ideas and we all just keep stealing off each other

as time goes by um yeah well good artists borrow great artists steal right exactly exactly right

thank you so much for coming on and uh sharing your story with the community and we'll have

links to everything so people can check out your work uh if people want to get in touch

what's the best way i mean obviously i'd give you a fun beware we'll get your attention but

how else can people get in touch uh so yeah i am i'm freakboy3742 on almost every platform so on

on twitter on github all those uh you can get me through the beware project there at beware.org

uh is sort of the hub of all the work that i'm doing in open source at the moment

around getting python running on all these platforms um you can and in terms of funding

that work you know i am i am always on the lookout for people who can either help me

pay for that development work contribute to that development work any ideas about how to

commercialize that development work i am i still haven't completely given up hope of finding some

way of making beware a commercially viable project i just need to kind of find the person to be the

the business end of that and because i can i can talk business but i'm not good at it um so yeah

uh but yeah either way so you can if in the meantime you can sponsor me through the beware

project or the bigway.org or you can sponsor me through github sponsors i was uh i'm on that on

that program as well um or uh yeah super great well thank you so much for coming on

my absolute pleasure thanks for having me all right take care bye