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

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

Hello, Carlton.

Hello, Will.

Hello, Russell.

Hi, nice to have you.

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.

In a positive sense.

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.90, 0.91 timeframe.

Um at that point in time, it was a period where there was a lot of low-hanging fruit.

Like it was it was there and it was being used, but there was a lot of stuff that could be improved.

Uh, 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.

Um, one of the first big contributions I made was around um many-to-many fields.

Uh so if you've got your, you know, you've got your models, you've got a many to many field where A is related to B.

Uh, Django, as of that time, you could query from A onto model B, but you couldn't query from B back onto model A.

Um, and so, you know, that was kind of useful.

And so I thought maybe I want to be able to do that.

I jumped into the code.

And after that and a couple of other little smaller pull requests that I had that I 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, uh, Adrian mailed me uh early January 2006 and said, Hey, do you want to do you wanna 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 would only be was like weeks away as soon as we could finish magic removal.

Uh magic removal was finished in about six months, and 1.0 took about another two and a half years.

Um, but I was there through that process and was involved in the introduction of the like a the user-facing test testing tools for Django.

Uh I I mentored a couple of students doing Summer of Code projects, uh, most notably Alex Gaynor and the introduction of multi-multiple database support uh and a number of other little projects along the way over the course of a couple of years.

Just because we like to tap upon the global nature.

Were you 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.

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

Uh and so I was I was working for them and we just happened to have a project uh 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 the project plan we'd been funded to build this thing, uh, 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 uh site for like the the idea was that you're gonna have uh assessors, like uh um teachers, trainers in a in a military simulation context, looking over students who were you know operating radars or flying flight simulators and assessing that they were identifying you know uh targets as they were approaching or whatever that whatever they had to do.

They met they met their criteria for training.

Uh and they were just gonna be like check checkboxing, yes, they met this criteria, comment, they could have done it a little bit better, or whatever.

And it's 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 um my immediate supervisor.

Uh, you know, I've been fiddling with this thing called Django.

I th I've got a feeling we could knock this project out in like about two weeks if we, you know, 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, you know, we can we can do this.

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 that because it was 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.

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

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

And that third piece is not always common.

I mean, some of our guests who are very involved uh, you know, have to code in not Django during the day.

And if I think some of the major contributors currently who you know they're there all the time, it's because they're working with Janguin Day job and have that time.

You know, people wonder how how is it possible to contribute because you know it looks like these people are giving out a lot of time, and they are, but you know, they have that opportunity.

Now there is 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 you know, the way that I entertain myself of a Saturday morning.

Some people do Sotoku 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.

Um, but particularly when you start getting to the really gnarly problems or the really hairy bugs, or the you know, 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 you know there is a reason to have this work be done, which which is a big, you know, the incentive matters there.

I think um particularly the ORM, uh like there's a couple of big 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.

Um, you know, the the there's a group of half a dozen people who work around the ORM that without them we'd really struggle to move forward.

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

Like uh if you cast back a few years, it was Ansi Karienan, uh Finnish guy who was working through his P uh, I think PhD, uh who did a huge amount of work uh in the 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 RM we have is almost entirely because Malcolm Trinic, uh who sadly uh isn't with us and uh died a few years ago, um spent six months almost on his own time.

Uh he was spent a lot of time working for banks, being paid very well to work for banks, and then salvaged uh salvaged his what was left of his uh uh um uh sense of contributing to the community uh by going and contributing to open source projects like GNOME and and and Django.

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

Like, yes, has been massively improved since, but the the frameworks, the bones of what is there is all all Malcolm's work and was done in like a period of about six months after about three or four rewrites.

Um and I think at one point I I have a recollection of a conversation with him where like he was uh he had a a big contract where someone didn't pay him, and like because he wasn't getting paid all of a sudden, oh crap, I'm like on I have no savings left because I've I've spent a lot of money contributing my own savings to Django instead of uh getting the next contract and patting my wallet.

Uh 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.

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

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

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

Um or and and but 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.

Um we I we I I am able to make a little bit of money uh through things like GitHub, uh GitHub contributors and uh you know other forms of small scale fundraising.

It is very welcome.

And I and I've 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 the the large amounts of money you need to be able to hire multiple people, to be able to 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.

Uh 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.

Um but that doesn't translate into large corporations that are making huge amounts of money through using Python, giving back into a format that is then that can then be operationalized and used by other um by by the groups that are maintaining the software that is being used.

And to my mind, the key 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.

Uh I've had convers many conversations with people that have said, you know, I've got a corporate credit card.

I can spend $1,000 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.

couldn't get

So finding out what we can operationalize to get those funds out, I think, is the is the piece that we haven't worked out yet.

And I'm I'm still searching for what that answer is.

Um I can't is that what it's called?

So Tidelift is one of

them, yeah.

Um the 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.

Uh I have

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.

Because they're they're they're they're saying that they will they will provide the resources to make sure that the issues that their subscribers have get resolved.

And I think that's a good thing.

They will pay the contributor to do that.

Um the the there are two like the one of the problems that exists 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 Lift, and they're essentially not interested in doing anything to do with BWAR because BWAR doesn't have a user base yet.

And so

So BWAR is uh

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

Uh bWare is my attempt to get Python running on all the new devices that people have, on iPhones, on Android tablets, on Android phones, uh in 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.

Um but, and as a result, BWare doesn't have users.

It doesn't have people who are using BWare to make money.

They're not being, they're not not the cornerstone of the company, the dot com that they're just the startup that they're they're running.

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

But this is this is Django a year before it was publicly open sourced kind of space.

It's there's still work to be done, there's a lot of work, like there's resources that need to be spent.

Tide Lift 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.

Like they're not in the yeah, 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, ten years ago, it's a lot lower.

So I suppose the 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?

And like why am I going to buy this support contract?

Yes, there are absolutely a you know, the the covering of covering of but making sure that it will be updated uh aspect that possibly will actually drive that.

And it'll be interesting to see if Tidelift does manage to sell that broader narrative of you know insurance against the thing that should we hope never happens.

Um so yeah, I 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 where that goes.

Uh 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 have 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

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 I've got to be able to there.

One is the the reason it's problematic is that if you're dealing with that budget, you're essentially like the the money that is spent on putting your logo on the website is either a marketing or recruiting budget, um, which is good money if you can get it, but very fickle and very prone to changing.

Uh, 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 you know global financial crisis or whatever, and all of a sudden marketing budgets are lower.

So 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.

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 uh, in particular, European, the European focused 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.

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

I just know that there was a lot of pushback.

Uh there was one of the one of the very early depths that Jacob Kaplan Moss put together was around tracking, uh just putting into start Django start project, tracking who run like putting in as an opt-out.

We are going to we we want to be able to log that you're using this just so we know how many people are using this so we can use this for for for recruiting purposes or fundraising purposes.

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

Um yeah, right.

They got um, 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.

Yeah, and it's it's difficult because it's it's this 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, no, we don't want to attract users.

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

I mean, Carlton, you must maybe we can ask Tom when when he comes on.

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

Um, and you know, pro pro mad props to Tom for everything that he's been able to do around that space.

Uh that yeah, he had he took a project

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.

And he but he's doing amazing work.

Yeah.

Um, I 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.

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

Because it's not their problem.

Um, and if there are these solutions out there, um Yeah,

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 and I 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 that's the part that really grates my gears.

So yeah, I think and it's I think it's important for people to highlight to the community um because these are real issues and and some other frame, 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, Vue links to uh it's Vue Mastery educational content where they give five, ten percent or something of the sales of the educational product to back to Vue.

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.

The what the the Laravel and the PHP WordPress is another example that does it as well.

So there's two levels at which these things operate.

Um, like we're talking before about the the fundraising coming from marketing and and uh hiring recruiting budgets.

The real goal is to get into someone's operational budget.

You know, 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 you know, 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, you know, 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, you know, there are 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 means

And it can be expense when I think.

Yeah, yeah, absolutely.

Um but Django is a little more custom and advanced typically in how it's used.

One is not saying put a paywall in front of Py PI, but at least put the ability such that you can charge instead of in front of PyPI.

So if I do want to release my package on PyPI, 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 PyPI, and I'll completely grant that.

But you know, PyPI Pro is uh 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, other conferences around the place, is to actually get to the AWS and the Googles and Google Clouds and the Azure um people and say, okay, you know all this software that you're, you know, you're 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 at a you know at your pro-rated 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 Microsofts and the Amazons and the Googles of the world to do that 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 that, that would pay for all of the Django development we ever needed.

It would pay for all the maintenance of all the open source tooling that we ever needed.

I mean, we're 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, and it's all the packages on PyPI in the Python ecosystem, and then the same for the JavaScript world.

And absolutely, absolutely.

Like fear being like, hey, maybe Django won't be around.

Hey, maybe, you know, uh uh and finding a way to do it in not a blackmail kind of way.

Um but that is the reality, right?

I mean, and you know, for if Andrew Godwin isn't able to be paid even at this massive discount, async's not gonna happen in 3.0, probably.

Yes.

You know, these are these stark terms, and I uh but you know, but anyway, so I 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 they came about and then how um right because it was what two 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 you played a big role in that.

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

Uh I think we did have a fairly regular release cadence.

It was just it was a it was a much slower release cadence and and all.

Um but it was 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 they were there were patches that were being contributed and not reviewed.

Um and there like the the the the DSF itself is an interesting uh legal structure.

So it's a 501c3, which is a US not-for-profit uh foundation.

Um 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.

Well, so I shouldn't say we.

The DSF can't hire someone to write software.

If you look at the you know the terms of the which which Carlton and Tim and Marius are are employed, they are there as community managers.

The community management process inevitably involves some writing of software, but it is they are there managing the ticket process, making sure the grease the wheels agrees that everybody's contributions are actually happening.

Um the DSF actively paying for Andrew to work on something gets into very, very weird, so very weird territory.

Uh, and I won't profess to speak to where that that like where that discussion currently is or anything like that in terms of the DSF, but I am aware that those those issues exist.

Even to the tune of like 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.

Um, so yeah, anyway, that's that's getting deep into the weeds and it's a lot of people.

I just asked Andrew and he vaguely referred to issues.

Um well, so perhaps a transition.

So you're you're wearing a Django Con sweatshirt that people can't see, but Django Cons, I've heard some stories of bright pink.

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

And uh I guess how have you how have you seen Django Cons advance over time to where uh the San Diego one's coming up in the US this fall?

Yeah, well

There is Django Con Australia happening in just two days.

Uh so I have been to every single Django Con except two.

Uh so I missed uh the uh the very, very first Django Con Europe in Prague, and I missed 2013 in uh Zürich.

But I've been to every Django Con US, I've been to every Django Con Australia, most of them because I was organizing them, and I've been to all bar two of the Django Con Europe's.

Uh so that's

Andrew has been to all the US and all of Europe, but has missed two pipe on Australia.

So we're we're down to monkey knife fight for last man standing on who's gonna who's gonna.

Yep, yeah, we're staying tied.

It's uh whoever

Um so yeah, uh it is it's been it's been a right.

Um, like the very, very first Django Con US, 2008, uh, was essentially Django 1.0 was about to happen.

Uh 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 organize it.

Um they managed to arrange with Google to for Google at the Mountain View campus to provide a space for two days.

Uh, and they did all the A V recording and whatnot.

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

Uh, we got Cal Henderson, who was the well, was the uh one of the founders of Flickr, is now one of the founders of Slack, uh, who did one of the opening keynotes, uh, which is still to this day one of my favourite keynotes of all time, well worth going back and watching.

Um uh soon it was it was and it also set an interesting theme that went ran for a couple of years.

So the talk is called Why I Hate Django.

Um, 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 at that level.

And they were, it was this combination of he's a very engaging speaker who had the entire of Flickr as his uh, you know, his his his slide deck image catalog.

Uh and amusing, amusing reasons, like I can't, we couldn't possibly use Django because it doesn't have uh doesn't have a mascot, preferably a mascot with magical powers, uh which is where the Django Pony comes in.

Right, yeah, yeah.

And then sometimes the problem of the problems is that it doesn't do multiple database support, and 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.

And at the time it didn't.

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

I think about went back and ordered them at one point, and we'd like 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.

Um so yeah, yeah, that was that was also also set the tone because for many PyCons after that, um, or sorry, many PyCons, many Django cons after that, uh, we had a habit of inviting someone to speak at Django Con as a keynote from a different language community to tell us what we were doing wrong.

So you have someone from uh you know the um the small talk community come and talk about why small talk is better.

You have someone come and talk from the the um you know the uh Zope community, come and talk about why Zope is uh why Zope is better than thanks.

Uh interestingly, we never we never managed to get David Hanson or anyone from the Ruby community that I can remember.

Uh 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 uh 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 WISGI, so they're gonna have a it's interesting to see how they'll adapt to an async world, for example.

Like uh uh Rails implementation of cross-site scripting, uh 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 you know, 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.

Well, I think that's because beginners see it as a competition, and then people working on it see them as complementary tools.

Um, so I think that's an important distinction to make for people.

Because I 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 uh advice to people, which is usually just pick one.

Django'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, and you'll be able to bounce around as needed.

Yeah, and

It is the most important thing because it it will literally be the thing you work on every day.

So, you know, make sure you pick a community you like and there's documentation as good and it seems to be healthy and pr and progressing, because you don't have to replace all 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 the things that are simple there are more things that are similar than things that are different.

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's 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.

Um and I know you and Andrew um Pinkham have worked on Django Improved User Project, right?

Which I've talked with him about.

Um 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 you know match modern patterns?

Uh so the 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.

Um Django 1.0 did what every website does, it it sets up an internal user model that is first name, last name, um, and a password.

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

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

And if you've got a username, first name, and 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 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?

Uh yeah, 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 uh a lot of Chinese names, for example, which name is the first name and which one is the last name when you say Ma Zetong?

His given name is Dong, which is the name at the end of the list, but if he puts Mao, like if you put it in the order in which it's written, you're gonna 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.

Um if you go to uh uh the third Secretary General of the uh of the United Nations, his name was Tant.

That was his entire name.

He only has one name.

There is no first name, last name.

His name is Tat.

So was it what does he put in last name?

Uh if you've got a lot of a lot of uh um Islamic uh people will have uh a sort of a pre-given name of Muhammad to as a 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, yep, we are baked in that we have an existing user model, we need to move off of that user model.

Django having its uh its a hist 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, okay, now I on this website I'm building, this new website I'm building, I'm going to use a better pattern for that.

The one of the better patterns that exists uh is a sort of short name.

What name do you want me to use to a casual name, or what do you want to use me to refer to you as?

If I if I say if I write a letter to you, or do I say dear will, what 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?

You know, I want William Mate Vincent or whatever, you know, the full full name that's there.

Um those those are 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 like 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 you know people shouldn't have to reinvent the wheel over and over again.

But it turns out there's there are some problems with that around testing.

Uh and the biggest problem around the swappable model thing that that Django uh 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 that.

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

So the easiest way to manage that from a you know from a practicality 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.

Because that solves a lot of problems for people.

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

Now this adds complexity, but saying, you know, 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.

Uh, but I know it's a it's a tricky thing.

And I love the beauty of just not having these issues on Django, but there are the 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.

It's like, but I've started project, I've started code, I've created some models, and then I've come to look in, read the docs in more depth, and oh no, I've done the wrong thing.

And by then it's too late.

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 no one sat down and spent the you know, the the original uh contrib user getting that 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 then come with you know making sure there's a there's a uh

an onboarding path that makes it easy to adopt the the what you what should be the right thing when you come on board and and things like that.

I wonder if you could give or how would you sum up that talk?

Because we're gonna link to it.

It's an amazing talk, but it talks on some of these existential crises of or potential issues around how does Python die, and this might be one of the ways.

The point is that it can die if we don't pay attention to what is going on.

Yes, yeah.

I heard a really interesting comment today.

Someone pointed out that I think it was Luca uh was pushing a talk from Lucas Langer uh from his his keynote at Pylindinium, which was which was an awesome talk as well, um, mentioning that the rise of uh the 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.

Um 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.

Right.

And it's interesting to note that a lot of the uses where Python has historically had uh 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 web's being being seeded, 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.

You know, our next users, the example I gave in in my my keynote, is my son.

My son started high school last year.

Uh, he doesn't have a laptop, like a lot of schools will have everyone's gonna have a computing device and they do all their their high school work on on computers.

My son has an iPad.

All of his educational experience is delivered through an iPad.

Yeah, yeah.

Yeah.

Why why is he going to learn Python?

You can't, like you can run Python in a you know uh 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've if you're faced with a teacher who's looking to optimize their education outcomes, the way they're gonna 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 on a desktop machine, I write a, you know, we're gonna get a kid invited interested in in 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 all these dependencies and everything else they're gonna go through.

That's a problem.

Like that user experience, one of the big areas where Django has an or where Django and Python have advantages is in this space of people who are not computer science uh 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 is there are no standardized answers for that, or not particularly good standardized answers for that at the moment.

Even, even you know, just the the the perpetual bane of uh 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.

But 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.

It is, 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 uh than most people are willing to put up with to just get a website up and running.

I mean, I say that.

So you get it up, it's not particularly secure.

And um, but then yeah, Django for Professional is 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 uh Django Cookie Cutter, which is fantastic and does a lot of these things, but you're not gonna 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, uh, you know, like Rails, Roku 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 you can we can get pretty close to that actually.

So like the first chapter we deploy Hello World, but it is there are a couple extra steps.

Uh I mean I'm personally excited with containers, uh, the deployments are can be a lot easier.

I mean, it is sort of like trusting that the image and everything works, but uh, you know, 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, is 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 of the New York Times website.

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

Yeah, no, I know I agree.

So, you know, that is that is what that's what we're competing against in terms of degrees of similar uh agreed degrees of of uh of simplicity.

I agree, like the the Docker experience, you know, other than the fact you have to sort of download the universe before it works for the first time, but more lines sort of the the the containerized model is definitely very interesting, and 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 that spools out thousands of lines of code, which is all boilerplate, and you're trying to work out what that boil plate does.

Um I had actually for work purposes, I had to um I had to have play around with Falcon, which is a web framework that's asynchronous by default.

That was delightfully refreshing getting going.

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

Um, 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 worked so quickly that it's compelling.

And that zero to kick ass time, that that time it takes to go from I know nothing about this to doing something useful that I can see as 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 I and and often overlooked.

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, um, 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.

Um 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 uh 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 uh 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, uh the book will show you just because there are so many steps, and um again, you have to make some opinions as an educator or as a designer, but uh opinions are better than sort of going, well, it depends, which is Carlton I joke is the uh tagline of this show.

But like I think it's the like you mentioned, oh, that 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.

Can you share it though?

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

Otherwise, but you know, I look at I look at Mac apps or Windows apps, it's not a trivial process to package one of those.

If you build a uh 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.

Glitch.

I mean, if you're a teacher, a lot of times, yeah, stud you need a way you can automate testing, and all uh 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 the challenge I think Python Anywhere and Heroku and others have is um people eject at a certain point.

Anyways, well we're 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, uh Russell, before we head out?

Oh, well, let's throw me on the on the throw me on the spot there.

Uh that is for me one of the big unanswered questions of how Django moves to the next level.

Um I you know Django Django is what it is, and it is great at what it is, and it will saddle, you know, it does more than enough for more for plenty of people.

But you know, async is a thing, it exists, and there are there are things you can do or do more of increasing the life the lifespan of Django if if that's uh better supported.

The other the other end is like the and this is it plays a little bit into BWAR, it plays a little bit into things like Wagtail, is uh the front-end story.

Like I I very badly would like to see a much a much less JavaScript, much more Python front-end story.

Um and I don't know that I have any good answers, like I can't point at anything there.

Be what Bware is doing is kind of part of that big picture.

Seeing that you know we're having there is there is wagtail is there, and is you are able to build rich widgets and rich rich containers and rich experiences through things like Wagtail uh is certainly interesting.

Um I don't but I don't think either of those projects are by themselves the end of the story.

Like there I think there is there is an opportunity here to reclaim some of what the ground that Python has ceded in the web space to JavaScript as a client at the front end through things like uh better use of tool of technologies like WASM uh WebAssembly.

Um but that is a much longer project and one that uh you know is going to take eyeballs and attention and who's who's going to spend the time to build the thing and then open source it so that we can all use it is the

Like, because it like do we have the the uh currently the ability to, for instance, um script the DOM there?

Oh yes, no, absolutely.

So it's you know uh full full CPython, full numpy, full scipy, uh full mapplotlib, all compiled to run in your browser.

So it's not 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 as Wasm, as WebAssembly.

Uh 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, like the full the full payload download, which is not.

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

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 um HTML file, a CSS file, and a Python file.

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

Batavia's not doing 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 you can certainly do it.

Uh and I have had at one point in the not too distant past a demonstrator of uh like one of the talks that I gave at PyCon Australia two years ago, I think, uh 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 uh GTK uh 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 no 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.

I can do, I can use Python for um 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 pretty interesting.

And some of it

There are occasions where you have logic that needs to exist in the client and needs to exist in the server.

You know, if you've got like 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?

Like why should I just use the same implementation?

Why should I have to re-implement it on the back end?

But if we can push it the other way, that's incredibly powerful.

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

Um even if it's syntactical.

Exactly, exactly.

Right.

Um if people want to get in touch, what's the best way?

I mean, obviously, uh give you a fun bware will get your attention, but how else can people get in touch?

So on on Twitter, on GitHub, all of those.

Uh you can get me through the Beware project.

There uh bware.org uh is sort of the hub of all the work that I'm doing in open source at the moment uh 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 bware a commercially viable project.

I just need to kind of find the person to be the 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 if in the meantime you can sponsor me through the bware project, the bware.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.

Great.

Well, thank you so much for coming on.

My absolute pleasure.

Thanks for having me.

All right, take care.

Bye.