Jacob is a co-creator of Django. We discuss Django’s early design decisions, community consensus vs the BDFL approach, HTMX, deployment, and more.
Carlton Gibson 0:06
Hi, and welcome to another episode of Django Chat podcasts on the Django web framework. I'm Carlton Gibson joined as ever by Will Vincent. Hello, Will!
Will Vincent 0:12
Hi, Carlton.
Carlton Gibson 0:14
Hello. Well, today we've got with us Jacob Kaplan-Moss, who's one who's the current board member of DSF was one of the original contributors to Django, and was a one time code, benign dictator for life be DFL. I can say the acronym and what does it say? Hi, guys. Thank you for coming on. And so we always ask, and we, you know, we know we're excited to have you on book for listeners who don't know, could you give me your backstory? And I mean, we normally ask people how they got involved with Django, but like, that's slightly stranger question. Yeah.
Jacob Kaplan-Moss 0:46
So in 2004, I was living in New Jersey and working in New York City for a digital design agency building websites in PHP, and really hating it, and hacking on not PHP as much as the company. Language was whatever, but the company was terrible. And I was starting to get involved in Python. I had been following Python people online for a while, and I, one of the two of the people who I followed whose blogs I read, were these, these guys, Adrian hollowbody, and Simon Willison. And I had clocked that they worked together until one day, I saw a really interesting job posting on Simon's blog and read it and went Ha, that sounds like, you know, that matches, a lot of things that I would like to do. And then I clicked a little lower in my RSS reader. And I saw the same job posting from Adrian and went, Wait, these guys work together. This is the same job and got really excited, sent in a resume, got a call back from their boss, a guy named Rob curly that afternoon. We talked for a while and he said, Okay, great. We've got to get you out to Kansas for an interview. And that was the first time I realized that the job was actually in Kansas, I hadn't even paid attention to that part. I had gotten so excited about the potential of getting to write web stuff in Python that I just completely ignored where the job was. So yeah, when I interviewed, I guess they liked me offered me the job. When I started there. What I found was that Adrian and Simon had been working for about a year at that point on a set of tools to build web applications in Python. It didn't have a name yet. We called it the CMS. And, yeah, you know, what more should I tell you about that time? Well,
Carlton Gibson 2:46
I guess the, for me, the interesting bit is the open sourcing, and then you know, this. So I got into Django, I had the book that was written you and Adrian wrote this book. And it was, and I was doing PHP development as well. And it was like, it was like, written for people who kind of knew a bit of PHP, and here's Django. And it was, you know, Miami, so that kind of thread through there was amoebas. Yeah,
Jacob Kaplan-Moss 3:14
yeah. Yeah. I mean, that was I think, as far as I know, both Adrian and Simon had been working in PHP before starting to write what became Django and Python. And yeah, there were, I think, a number of things in the early in the early framework that was sort of like influenced by design decisions in, in PHP, but trying to, you know, build them in a way that worked with Python, that sort of fit. You know, this, this was right around the time of like, the early web standards movement. And so there was this idea, starting to percolate at the time of like, separation of presentation and content. And that was something that there's sort of a similar idea in sort of the back end of sort of separation of like, business logic from display logic, or something like that, which most frameworks at the time didn't, didn't really do. And, like a lot of I think the criticism about PHP as a Web Development Language has less to do with the actual, like language or ergonomics, and more around sort of the affordances of just kind of mixing everything together in this one file that makes it really hard, hard to maintain. Well,
Carlton Gibson 4:30
it was kind of glorious in a way you'd be writing your HTML page and then you're just oh, I just need this to I need to be logic here, right? Angle bracket question mark, PHP, and you're off.
Jacob Kaplan-Moss 4:41
Right? Well, it's funny because Okay, so like skipping ahead a little bit, right, we get to this thing is that one of the things I'm really excited about right now at tailwind and HTML texts, which are in a way like going back to like, hey, let's put more things into our into our HTML file, but but now we're doing it in a way that's informed by several decades of web development and isn't, I don't think creating some of the sort of maintainability nightmares that we had, we had back in the day, you know, the, the big challenge that was facing the Lawrence journal world, the locally owned newspaper where Jenga was created was, you know, small local newspaper, and not a lot of resources, just a handful of, of developers with really lofty ambitions, you know, we Adrian especially was kind of one of the, you know, creators of this sort of idea of data journalism, I think he coined that term. And we had these ambitions of building these sort of interactive news apps that, you know, let readers not just read a story, but actually explore the underlying data. You know, we did a story about the university's use of private airplanes to fly various people around most notably, coaches and student athletes for like recruiting purposes, which is a cool story. That's an interesting story. But we did a thing that most newspapers wouldn't have done, where we actually ingested all of the flight data on all of the flights that universities planes had taken in the last few years and created an app that people could click around and see. And actually look at those flights for themselves and see the dates. And we didn't have passenger manifests, but you could infer from like recruiting information, oh, this is, you know, this is head coach, Bill Self flying to Texas to recruit some, you know, hot high school basketball player, and we wanted to be able to build that stuff. But we also didn't have like, a big team. And so maintainability was like a really big deal. You have to be able to sort of, you know, publish these applications on a deadline. But then they have to like, if you find a bug Three years later, and you come back to a big mess of spaghetti code, you're in a lot of trouble. So we were trying to really balance this idea of being able to develop something really quickly on you know, you know, on publication deadlines, but also following our perception of sort of best practices at the time.
Carlton Gibson 7:10
Yeah, that's, that's really interesting. Because the last year I've been bootstrapping an application single handedly. And it's only now with like the HTM X's and the tailwinds and the Alpines of the world around that that's sort of realistic again, two years ago, with React, I just couldn't have done it, because there's too many moving parts. But it's like, actually, it's really possible with Django to build something small and tight with a very small team, which I think now that money is not free anymore. It's kind of interesting, because that, for
Jacob Kaplan-Moss 7:41
me is one of the most like, gratifying and satisfying parts of, you know, looking back on what's getting close to 20 years of Genco at this point is how, through everything that has changed that core of like, let I want to build something really quickly, that is still maintainable and still easy to easy to read the code, you know, years, heck, even decades later, like that, we've we've somehow managed to stay true to that core principle. And that makes me it makes me really happy. And it makes me feel like we were we were actually onto something.
Carlton Gibson 8:19
Good, good, good. On the on this podcast, we've often talked about how someone fires up a project from 2011. And they you know, they add an On delete clause, and it just works. That's kind of on the on this topic, just before I let we'll jump in with something or other. But the recently, there's been discussion about the Django template language again, and comparing it to other Django template languages, which let you do more things. But coming coming from PHP, it's one of the reasons why I still choose to use the Django template language is that it's very restrictive in what it lets you do you have to create a template tag or you have to do it in the view. And I don't know, if you, you know, if you still have thoughts on that you still like it, would you prefer other things or so?
Jacob Kaplan-Moss 8:59
Yeah, I think we, you know, it's it's always this tension, right? Like, I think we were more dogmatic about the sort of restrictive nature. We've become less dogmatic about that restrictive nature of over the years, I think, this idea of like, separation of presentation from content was, or presentation from logic was like a really important one for us early on. And it matched the way that a lot of web teams were composed at the time, you had a pretty clear dividing line between sort of designers and developers. That was a that was a fairly, that was a fairly Stark line. And so, you know, when we were building the template language, we were thinking about people who were not, we didn't have sort of experience in traditional programming language. They knew HTML and CSS, usually better than we did. But like JavaScript kind of wasn't a thing, right? I mean, It was there, and people use it a little bit, but mostly to do obnoxious things like our cheese or whatever. It wasn't, it wasn't at all, anything like it like it was today. And, and so we were building a language for, you know, non non developers, I think these days, front end, front end developers, designers, back end developer, it's a much more of a spectrum of a of a sort of lead through sort of, you know, set of set sort of set of skills, you know, there isn't that clear dividing line. And I think it makes less sense. I think it's very, very hard to do any sort of web development without at least some foundation in, you know, what we're trying to, you know, a more traditional programming language, usually JavaScript, right, like, so what I, if I'm working on a web development team, what I can expect from the more the more front end oriented people have, my team is a lot closer to what I can expect from the sort of more back end oriented folks on my team, so it makes more sense. And so in that context, someone with with sort of a more, you know, traditional set of programming skills under their belt is going to feel chafed by, you know, the constraints of the early template programming language. These days, honestly, I usually recommend that most teams start with Jinja as the template language, I love that that's an option in Django that you can sort of pick and choose, I still use the Django template language myself, because, you know, when I've been using this particular hammer for a really long time, it's very hard to change to change those habits. But you know, I, I think, I think if I was, if I was creating a framework from scratch today, I would not be building my own template language, I would be using Ginger, Ginger is great. Some of the design decisions are a little bit different than the ones that like I would make the ones we made back then. But not in a way that's like meaningful or important, right. But
Carlton Gibson 11:59
there were always design decisions, like every, everything you choose, there's something that you you wouldn't do if you did again, but you choose something else. Yeah,
Jacob Kaplan-Moss 12:07
I mean, for me, it's really important to identify the difference between like, I would have done it differently. But it's fine. And like, No, I actually have a problem with this. And ginger is definitely in the former category, like I would have made different decisions, but not in not in like an actually meaningful way. Just just in sort of the sense of like, we're all different people. And we and we have slightly different tastes. I don't I there's absolutely nothing wrong with it. And there are a number of things that are, you know, actually significantly better about it. partials being a big one that I know you. You think about too. Yeah, no,
Carlton Gibson 12:41
I mean, so yeah, it's the template partials packages. I'm just in love with that. And I'm hoping we can get that into 5.2. I'm going to put a proposal to put it in. Because it's just literally one tech. Yeah. And we did a bit of preparatory work in 5.1, which is under the covers, and then hopefully 5.2. You know, that's, that's my goal. Anyway,
Will Vincent 13:04
I wanted to give a plug, we'll put it in the show notes, you gave a PyCon 2017. tutorial called let's build a web framework. Talking about I think there were six kind of big design decisions. And certainly for me, like I refer people to that all the time, because I think that's the first time. That's a way to think about like, well, what even is a web framework? And what are the decisions and then as you said, like, something's very and most things are, you know, what's really important versus what's design, but it's a really helpful once you can get to thinking of it that way. That's a big leap and understand, you know, thinking about Django or any other web framework, because when you start out, you know, maybe you're new to Python, and you're new to web, and you need a Django and it's really just, everything is magical. But, like getting to the point where you can be like, oh, yeah, templating, we're gonna need a solution there. ORM, we need a solution there. That's when you can abstract it away, and I think, have a bigger picture of of it all. So anyways, I highly recommend that it's three hours long, you can kind of skip some of the code yourself parts, but I've watched that multiple times. That's a fantastic resource for people. Awesome.
Jacob Kaplan-Moss 14:02
I'd forgotten about that. Hopefully fun to revisit that and see if I still agree with that. 2017. Jake? Yeah, I
Will Vincent 14:08
think I mean, I think they were mentioned also the bit about changing Jinja and the templates in that one. But, yeah, well, we want to talk about the current day, but as a way to get there. One of the things that impressed me so much about Django community is the fact that you and Adrienne both didn't feel like it was yours to hang on to and for forever and ever. I mean setting you set up the Django Software Foundation pretty early on. And it's still a relatively uncommon model for open source projects, like most seem to be solo person who monetize it in some way. I mean, like Laravel, being example, or something that was open sourced inside a company, react Angular, I guess, could you talk about why did you decide to do that and what was that process like, and that'll lead us to today where you're back on the board of the Django Software Foundation? Yeah,
Jacob Kaplan-Moss 14:59
um, Um, so at the time Django was not, you know, was not any was not the success that it was that it is today. And honestly, we, we had, we had no idea if you had asked me in 2005, like what, you know, what my sort of like greatest ambition for Django was, I would have painted a picture that's like 10% of what of like where it's gone now. I mean, like, multiple, not just one space agency, but multiple space agencies use Django. Like, if you had told if you had gone back in time to tell me that in 2005, I would have completely not believed you. We were thinking at the time about adoption by other by other news organizations, and news organizations are like, weirdly competitive if you think software developers have not invented here syndrome, like wait until you meet reporters, the the fact that Django was owned by another newspaper, even if it wasn't in any way a competitor was enough to prevent, or at least in our minds felt like enough to prevent people from using it. I think we also kind of read the writing on the wall for look like a small family owned local newspaper. You know, it was a little more common back then. But it was already on its way out. And indeed, like the larger in a world is no longer owned by the Simon's family by the local family that owned it. It's owned by its genetic, now it's owned by one of the big conglomerates. I think we I think we not saw that coming. But like knew that that was a predictable outcome for, you know, for the paper. And we wanted to sort of ensure that wanted to ensure that there was sort of a neutral, a neutral owner of the of the intellectual property, that was really our concern. We didn't, we weren't thinking about support. We weren't thinking about all this sort of sustainability stuff. That's like a big deal. Today, we weren't thinking about fundraising, we were purely thinking about IP ownership. And at the time, the PSF did exist, but they weren't doing any sort of Fiscal Sponsorship. Can't remember if we approached the PSF, about possibly donating the IP to them. But I think I think it would have been a non starter, I don't think there was like a model for that. The only Software Foundation, at least that I was aware of at the time, was the Apache Software Foundation, and they have a list of rules to join the ASF. That's about a million miles long. It's really intended for like, it's really intended for like large companies that want to sort of like, not just like donate IP, and have like a stable owner, but like really, like run a project under the auspices of the ASF. It's not I don't think there's anything wrong with the rules they have. But it's not intended for like, what at the time was like, you know, a small project, right? A handful of folks in a literal basement or office was in fact, the basement. So, yeah, so you know, forming our own nonprofit kind of seemed like the only viable path forward. At the time, it was sort of something you know, we did reluctantly, and kind of perfunctorily. I made so many mistakes as the as the first President of the DSF. It's like pretty embarrassing to look back on it. But somehow, somehow it worked out?
Will Vincent 18:34
Well, I think the fact that you had that organization, you know that both you and Adrian work community focus from the beginning, and that you had the organization meant that it wasn't the case that if the two of you lost interest or had to step away, the project would die. Right? Whereas that seems to be the case with most other ones where, if it's one person, you know, how do you maintain that? 20 years? Yeah,
Jacob Kaplan-Moss 18:56
we were heavily influenced by a guy named Karl Fogel, who wrote a book called producing open source software. We we knew him a little bit, personally, and also both read his book. And we're really sort of influenced by I don't know, like, even though we didn't have grandiose ambitions, it felt important to have, you know, have have good governance and like, I've learned a huge amount about open source and community governance since then, like I said, I made a lot of mistakes. But, you know, they weren't, you know, they weren't mistakes out of, like, lack of care or lack of attention. They were they were just they were beginner mistakes, if, you
Carlton Gibson 19:45
know, those, those are allowed, right. beginner mistakes.
Jacob Kaplan-Moss 19:49
Yeah, totally. You know, and I don't you know, and they say, in the same way that like, if you look at code that you wrote five years ago and aren't embarrassed that means you're not learning anything. If I look at like, you know, leadership decisions I made five years ago and I'm not embarrassed. It means I haven't learned anything. I don't feel I don't feel like bad or guilty about it. But like, I think there's a lot of like mythmaking that happens around these type these types of things. I think it's important to like acknowledge that we like, we barely knew what we were doing. Yeah, right. It's easy to look back and like draw this like really clear story. And like, say like, oh, yeah, of course, we knew that. You know, it. You know, the Federal Election Committee would be using Django and the 2000s. No, we didn't. We had no clue.
Carlton Gibson 20:31
Yes, yeah. No, entirely.
Will Vincent 20:33
i Sorry, I'm gonna ask one sort of opinionated question, which is, if you had to say, you know, why Django grew the way it did. There's the Django being awesome component. And then there's also the rise of Python itself. I guess, how much do you where do you put that balance? Right? Because there were, there were some other ways to build a website in Python back then. But I think it's hard for people to understand that. There were very few tools like this is like Ruby, and Rails was just getting started like this is before this idea of a batteries included framework even existed, it was so much more manual. So I guess to put it to you. What's the question? I mean, you know, both Python and Django have really gone up into the right. And do you see anything? Specifically the Django did that some of the other projects from back then? Didn't that, besides just being around that contributed to his success? Yeah, I
Jacob Kaplan-Moss 21:28
mean, like, I've obviously thought about this a lot. Like, like, why, like, Why? Why did we succeed to the level that we did? And like, you know, a lot of it is luck, to be sure. You know, timing with timing was everything. To a large degree, right. Like you met, you mentioned. You mentioned Ruby on Rails. And I think that's a good, that's a good sort of starting point to think about it because it incorporates both the luck and some of the deliberate decisions. We were lucky in that we were able to release Django, relatively shortly after rails came out, maybe about a year. And we were in and we made deliberate decisions that were influenced by rails, Rails was really the first back end web tool, at least that I was aware of that focused on like, what today we would call developer experience, you know, I don't think we had a strong idea of like an opinionated, sort of, on rails. The name was chosen for a reason, like, the sort of development path. Web development was really hard at the time, especially in Python. And there was a lot of like, what is pythons answer to Rails, Python developers were leaving Python, in 2004 2005, to go to Rails. Because, again, like back to the different design decisions, Ruby and Python are totally one of those things. They're different design decisions. But neither is like better or worse. And so do a Python developer looking at hard web development in Python, or easy web development in a language that's like close enough to Python to basically be, like, good and good enough. A lot of people chose to make to make that leap. So So yeah, certainly, like, one thing we did differently from a lot of other frameworks at the time was focusing on sort of like, ease of use end to end developer experience, we also made a really deliberate decision to focus on documentation, which is still unusual. And still, to this day sets sets us apart. You know, which is which is pretty wild. But to your point about Python, I do think there was like a, there was a sort of like, trying not to use the word synergy, because I hate that word. But that's that's the right word. There was a synergy there. There was, you know, Python was growing, but didn't have a web story. And then Django comes along, and now there's a web story. And so that, you know, the fact that Python was sort of starting to evolve into the everything language. Everything includes web development. And so, you know, you have this sort of like, positive feedback loop of like people, people learn Python for, you know, some other reason they went Python in, in college for doing statistics, and then they get a job. And they're still doing statistics, but suddenly, they need to do excuse me, suddenly, they need to do a web app as well. And they look, there's Django and so they stay with Python. And so then Python continues to grow. And so I think that there was sort of like a really, I think, not to get too grandiose about it, but I think Django deserves some credit for In the growth of Python, and I think Python deserves the growth of Python into every domain deserves a lot of credit for the growth of Django. Yeah,
Carlton Gibson 25:10
I mean, with machine learning and data science and all of that coming. So big now like that Django picks up a lot of traffic that way, I think as well as the other web frameworks. Yeah, exactly. Let's, let's pull forward to because you, you've been away from the board. And then a couple of years ago, you said, you came back onto the board. This is your second year now on the board. So I guess, listening to the last few minutes, we've been talking about the developer and the growth, the one thing that kind of sticks with me is that Django is kind of that python two to three thing, we've kind of avoided that. There's been no kind of equivalent in Django, at least since the 1.8 days 1.91. With 10, it's increasingly stable. And so as a sort of old hat, I'm really like, oh, that's for me, that's kind of Django is killer feature is its state stability. But it's also a really exciting time in web development. And so how do we now balance those kind of two? Those two really important things. One is, you know, Django stability, and its, you know, API Stability Policy, and all the rest of it long term, at least long term support. lts is, but we want to keep growing. And we want Django to keep pushing forward at the front of web development, not, you know, we use this phrase boring from that talk about but use boring technology, because it's safe. But we don't want Django to be boring. It's not boring. It's super exciting. How do we balance? So what's your, you know, why did you come back to the board? Like, what's
Jacob Kaplan-Moss 26:34
those? It's funny, those two things were not related, sort of the opportunities facing Django, sort of from a technical standpoint, and the reasons that I returned to the board, were not related in my head at the time, although I'm wondering if there was something kind of knocking around connecting the two. I think so I'll talk about the board stuff. I'll talk about why I can make the board in a minute. But like, you know, yeah, that that tension between, you know, stability, being being conservative about introducing new features, and still wanting to be, you know, trying to sort of like be maybe not cutting edge. I don't think we've ever wanted to be cutting edge. But I think we've always wanted to be, you know, on like the leading edge of the adoption curve of web of web technologies, right. That's been like that's been a tension in in Django development the entire time. I mean, like, as early as the first couple of years after Django is out. I remember having conversations about whether Django was moving too slow, right. I mean, it's been it's just, you know, it's been, it's been all along. And like, you know, there there, there are upsides and downsides, right? Like, there was a lot of talk, oh, I want to say, you know, as as sort of, like, react primarily, but other similar frameworks, view, etcetera, were starting to become super popular, there was a lot of talk about like, maybe Django should just just drop templates, the template engine drop, any HTML generation becomes just a pure, pure API driven web framework. I'm glad we didn't do that, you know, I'm, we're starting to see we're starting to see a lot of limitations of, you know, these these sort of really heavyweight front end frameworks in performance. Well, in performance of the website, and in performance of the people developing the website, both we both were seeing some real, some real struggles there. And that's not to say that's not like a useful niche, right, like, you know, fast API, for example, like, shows off what you can do when you start with a sort of API first are kinda API only. Not API only. But I would say API first kind of approach to building a framework. And I'm super glad something like that exists. But I'm also really glad that that's not the direction that Django went in, you know, going back even before there there was like, remember, there was a brief moment when object oriented databases were like this huge thing. There was a discussion about like, Should Django you know change to support object oriented databases? I'm glad we stuck with the boring old SQL because it turns out works super well. Or non relational databases. After that, you know, like, like, it is very, very hard in the middle of a bubble to tell the difference between a fad and something that's actually going to stick around. For all the talk of you know, hT hT Max and Alpine. I'm not convinced it's not a fad made me I don't think it is like my my feeling in my judgment is that no, this is actually a solution to a problem. We've had for a really long time and not sort of like a flash in the pan. But do I've been wrong about that before? Yeah. So I'm not convinced. So, yeah, we are at this, we are at an inflection point. And I think we're at a point where the we've swung a little too much towards the conservatism angle over the last few years. And I think some of that is related to a lot of a lot of people who've been deeply involved in, in, in Django development, have been stepping back over the last few years for, for all sorts of reasons, in small ways, and in big ways. I mean, Carlton, you're one of them. You used to be a Django fellow. And yeah, now you're not, although you're still doing a bunch of, arguably, you're doing more work on Django now than you were when you were a fellow. So
Carlton Gibson 30:49
I actually get to work.
Jacob Kaplan-Moss 30:51
Right. But But anyway, but my point is that, like, I think, I think we're at we're at an interesting inflection point, one of the reasons I wanted to come on the podcast is because we're at this point where things have slowed somewhat, a lot of longtime people who have been involved are, you know, stepping back being being less involved. And there's, and there's a lot of, there's a lot of excitement in the community. Django con us this year had so many new faces, and so much energy and so much just like, raw, like, I want to do stuff. But it's been, it's always been hard to get from, you know, I'm excited, I've written a little patch, or I've done a third party package to like, really being involved in in the in the core community. And so I think the challenge facing jangles leadership right now is like, how do we get that new blood into, you know, into the community, because with that new blood are going to come? The types of things that are going to sort of revitalize and make and make, you know, the move the technology forward, the technology always follows the people there's not, we're not Django is not going to, you know, my, my pet feature is I want Django to have first class h2, it szymek support, I want that to be built into core. But like, that's probably not going to, that's not going to just sort of magically happen. Someone's going to do that. Yeah. And that someone is probably going to be someone, hopefully, it's going to be someone relatively new to Django development. And so, yeah, we're at, we're at a moment where there's a lot of opportunity, but also a lot of sort of uncertainty and like a bit of a leadership vacuum. And that's the thing that's like the deepest out of my mind these days. Okay, so
Carlton Gibson 32:50
the words use their leadership button vacuum, and I want to it's a question I have for you was about the contrast between the BFL model, the dictatorship, the dictator life model, and then the sort of community consensus model, because both have benefits right in it. So why, you know, what's wrong with the BD FL model? And then what what is it that we, how do we inject a bit of the kind of direction giving that that can bring back?
Jacob Kaplan-Moss 33:16
So my experience of leadership over, you know, the 20 years that I've been in any sort of, like leadership role, is that every time I step back, and give and sort of give power to to someone else, it's a net positive. Okay, which says some interesting things about my sort of direct leadership ability. No, but it's not about you know, not No, I'm not to be self deprecating about it, I think, I think what it says to me is that I'm a better I'm a better coach, sponsor, mentor, than I am sort of a more directive style leader. And, and like, that is the thing that I've realized about about myself and like, has helped me be a lot more effective over the last, you know, over the last few years is one of the reasons why I felt sort of ready to take a leadership role on the board is like, I know, I understand my own leadership style, my own leadership successes. Now, I think that's I think the PDF l model only works as long as you have a more direct a more directive and opinionated style leader. And only as long as that person has the attention and the time and the like, lack of burnout to to give to give that attention. Right. And Adrian and I didn't write I mean, there was a there was a long period of stagnation in in Django development, because everyone was waiting on Adrian and I to make decisions and we didn't want to, we weren't interested in that. And and it wasn't until the sort of, you know, it wasn't until We We stepped back and advocated that power that that things like really took off honestly, like,
Carlton Gibson 35:05
yeah, there was a gag I saw and I fostered on some of the other day. It was a while but but the idea is that the reason that project needs a project needs to be DFL is the very reason vflw stepped down because
Jacob Kaplan-Moss 35:19
you Yeah, I mean, like, that is it is very, very rare to find someone who is a good a good leader in a dictatorial model and is not and is not doing it because of their ego or doing it because they're a jerk. I mean, like, gosh, I Guido is truly a special person to have been the BDF for Python for so long. With a long track record of like, being nice. Yeah, like usually usually pedia usually PDF files are either ineffective or assholes. And, you know, like, I was pretty ineffective. I'd rather I'd rather fail them that way than in the other way. But like, yeah, it's it is super, it is super rare for that for that model to actually survive for for a long time. I want to pick up on one thing you said though, because you use the word consensus, and that this is the other reason I wanted to sort of return to a leadership position. My understanding of consensus has changed a lot over the last decade or so having done a lot more like, you know, community, community building community governance, community leadership, honestly, mostly in ways outside of outside of technology, other nonprofit work, other other sort of like, intentional community type stuff. And I think most people have this naive idea of consensus, meaning sort of like everyone agrees, and that's not what consensus means as practiced by organizations that truly have like a mature and, and sort of well developed, consensus driven process. Consensus is not everyone agrees consensus is a group of people who are they are more aligned with the process than they are with any particular outcome. And they've all agreed on how decisions will be made, the goal is to make a decision that makes everyone that makes everyone happy, or at least content. But when there are situations where not everyone does agree, you've laid the groundwork ahead of time that everyone is more invested in the community health than they are in getting their own way. And so you have all sorts of mechanisms like standing aside, which is a way of saying like, I don't agree, but I'm not going to block this. You have various mechanisms for sort of hard and soft blocks and what needs to happen to overcome the blokes. And I think those sorts of things are the type type of work that Django needs to needs to invest in. We sort of replaced the BFL model with this rotating technical board now called the steering committee, which is an improvement over a BD FL model, but it's still not more largely community driven. And I think, in my mind, the next iteration of Django is governance model involves a broader, a broader slice of the community involved in decision making processes. another board member, Tebow just held a
Carlton Gibson 38:49
roadmap session roadmap
Jacob Kaplan-Moss 38:50
sort of brainstorming session, which is awesome. So great, I'm so glad that he did that. I hope that something like that becomes a more consistent and even like, like binding part of Django of Django is governance model, not binding in the sense of like, we're all volunteers, we're, we're mostly volunteers. We can't force anyone to do to do anything. But having a well defined roadmap and a process for developing that roadmap that listens to as many voices from the community as possible. I think is sort of the big missing piece from Django is governance governance right now. Yeah.
Carlton Gibson 39:29
I mean, so I went to that session and the the 10. There's a post on the forum about it, which gives the details, but there were 1015 ideas came out on all of them that like, you know, positive, there's, there's, you know, whether you agree with every single one or not, it's like, you know, what, if Django had all of these, that would be a massive win. That would be a massive move forward, even if it you know, the cost of it was the ones I didn't want, as well that I take that it goes in a blink, you know, it's to having a way of driving that because what's happened in Recent Posts that people have felt very frustrated that we can't get this agreement of exactly how to proceed on a feature. And so it just kind of hits into the long grass and in some ways that served Jagger Well, in that we haven't gone down various dead ends. But in other ways it does risk atrophy.
Jacob Kaplan-Moss 40:14
Yes. Precisely. Yeah. And and like, I think that think that, you know, we, like, look, we've made mistakes before we've we've put things in, we've put things in Django that turned out to not be a great idea from, you know, in in with 2020 hindsight, and in retrospect, and I'm not gonna mention any specifics, because I don't want to, like, call anyone out. And I might be, and I might be wrong. But like, I feel like we've made some mistakes, and it's all bad. It's all mostly been fine. And so like, I think we need to like, ratchet up our risk tolerance, like just a little bit, you know, like, you know, of those 15 ideas is, is one or two of them going to prove to be a bad idea in the future, maybe Absolutely. Like, whatever we can recover from that. It's just code. Yeah.
Will Vincent 41:04
So I wanted to ask you about so there's deciding, and then there's doing and we just had last week, we we interviewed Deb Nicholson, who's the executive director of the PSF. And she was talking about things that executive director does, where are the PSF? More broadly, the board there, which I know you've been on, is, decides and others largely implement, sometimes it's board members on a working group. When I was on the Django board, I felt like the board kind of had to do both. And as for volunteers, that's a lot to ask. I mean, I know you're now the treasurer, again, which is the role I had. And you know, that that's a lot of work. So that's a long winded way of saying, How do you feel about do you feel like there's a disconnect there between the deciding and doing because me personally, I came away, part of the reason I stepped down as I felt like it's more more than a volunteer can do to go to the next level, these organizational things, fundraising that people keep talking about, absent an executive director, but I've been away from the board two years. And I'm curious what your feelings are on that? Yeah,
Jacob Kaplan-Moss 42:04
this was the main, this was my main motivation for returning to the board. So there are two models of two sort of big buckets you can put nonprofit boards into, you can have an activist board where the board does the work of the nonprofit's if someone needs to file taxes, the Treasurer fills out the tax form. If someone needs to talk to a major donor donor, a board member calls that major donor and has a conversation with them. Right the board does, the board does the work. The other model is a directive board, the board, the board directs the board sets high level goals, the board allocates money, the board makes large strategic decisions. But the most of the work is actually is actually delegated the board delegates, most of its power to individuals, to employees to working groups, et cetera, et cetera. I'm, this is not this is not a consensus opinion of all nonprofit people. But my opinion is that the directive board is more effective. And then as a long term better model for a stable functional, you know, effective nonprofit organization. Django, the DSF, has historically been an activist board, and has made a couple of steps towards being a directive board. You know, you mentioned that being the treasurer is a lot of work. It's actually not my experience, because we've hired an assistant who does the vast majority of that of that work. Well,
Will Vincent 43:37
I guess, when I joined it, then people she hadn't, she wasn't part time doing that role. So it was I could feel why and yeah, the fact that Catherine has an accounting degree and is amazing. Makes it doable for anyone, for me or anyone else. Yeah.
Jacob Kaplan-Moss 43:53
And that's like a small scale model of like, what I mean by like, like, why should we be so shocked that hiring someone with an accounting background to do accounting is more effective than having a software engineer with no accounting experience? Do the work? Like that's not surprising? That's the least surprising piece of information we could we could possibly have. So and that's a small scale model for where I'm hoping to hoping to take the DSF and, like the board's pretty the board's pretty aligned on this. This is not this is not a like a me. Me fighting the board thing this is pretty much all of us have have this same idea that like the DSF will be more effective. Django itself will be more healthy if the board can sort of transition to a more to more sort of community driven and more broader base of people working on DSM stuff, so we've done I want to plug a couple of things that we've done over the last six months to sort of like to To that end, the first is that we've made becoming a DSF member. Easier, we've it used to be that in order to be a DSF member, you had DSF, membership recognized, recognized contribution of intellectual property. So you had to write code or write documentation. Or sometimes we sort of would stretch to, like, include conference organizing as like a guest, you're creating videos. So that's IP, like, but you know, that that was a very narrow and restrictive version of what being a DSF member was. The new definition is basically contributing to Jango as mission, which is supporting the framework, which is advancing web development, which is protecting the intellectual property of Django. That's a pretty broad, that's a pretty broad set of activities and it and enables us to really, like, admit people as members, with all sorts of different backgrounds like but by the new definition, if pretty much anyone who works on an open source Python package is now eligible to be a DSF. Member, because can you use that package with Django? Well, yes, you can contributed to sort of advancing the state of the of the framework done. Anyone who, you know, writes a series of blog posts about Django is eligible, anyone who records a podcast about Django is eligible, we've sort of much broaden that definition in the hopes of getting a lot more people and a lot more voices sort of in into the community and giving them a direct vote of voice. The other thing that we've done is we've created a structure for creating working groups. And this hasn't moved as fast as I as I would have, would have liked, but it is moving along a little bit. We've created a mechanism basically, for people to spin up, spin up working groups and to ask for delegated powers from from the board. And it's pretty broad that that can really be anything right the board, the board can approve a budget, and then the working group can go directly spend that budget. Without individual approval from the board, right, the working group can ask for you know, we've we've just formed a sort of a social media working group to sort of own gencos sort of social social media presence. And if you look at that group's charter, we've sort of enumerated a list of things that that working group can do, without, without explicit approval from the board, the board does not need to approve every tweet, the board does not need to approve, who, you know, who we follow, or what social, you know, or like, what platforms we post things to, et cetera, et cetera, there are a couple of lines that we've reserved for the board, like, the board is reserving the right to review any sort of like sponsored post type activity, because we're not sure if that's something that we necessarily want to want to be doing. Or, and if, and if we do how we want to be doing that. So we've sort of delineated some lines, but that's kind of the model for where I'm hoping a lot of a lot of lead sort of leadership at the sort of DSF level will will happen, I'm sort of hoping that a lot of the sort of informal groups that we've spun up around around Django, the the ops team, the security team, the you know, those sorts of groups will kind of eventually reform as working groups so that we can more like, we, we ought to just give the ops team a designated budget, we shouldn't have to approve spending on hosting, they should just have a credit card and like buy the things they need to buy to host the the, the Django site, right, there's, there's no there's no need for that to be a board decision, and so on and so forth. So I'm hoping that like we're at this point where we, we've, we've I think, created the sort of formal mechanisms, we need to sort of transition the board into a into a directive model. But we're kind of not there yet. And we need we need people who are interested in Wheeling in getting involved in in any way large or small. And we now have the capability and the sort of mechanisms to make that happen. And sort of we just need to kind of keep plugging away that's why I ran for another term like my first term sort of culminated in getting getting these two things done. But lay you know, those are just the that's just the foundation like now now we're trying to build the house.
Carlton Gibson 49:23
Yeah, perfect. Perfect. So call out to people call out to like if you're in the Django community and you want to get involved and you want to douse a good time.
Jacob Kaplan-Moss 49:36
Now's a really good time. I mean, like I said, there's like this sort of, there is a little bit of a power vacuum not not an entire not an entire one, but like a lot of the the old heads or are are less involved or stepping away and that's, that's scary because it means that people who, you know, have a lot of experience are no longer contributing, but it's also like a super Big opportunity because it means that it like, you know, it means that you know, new people bring, bring new ideas and often like, honestly, better ideas and so like, you know, have like there's, there's there is a really there's a moment right now where it's a really good time to get involved. And I don't want to like, I don't want to sugar sugar coated too much, it's still it's still harder than it needs to be. There's still there's still a number of barriers, you know, there's still some sort of difficulty. But you know, I'll make I'll make a general offer that anyone who wants to get involved in Django in some way should feel free to reach out to me and ask for help. Like, I can't promise I'll be able to, but I can least try to point people in the right direction and possibly more than that. Yeah. Cool.
Carlton Gibson 50:48
It's not the first time though, like, I kind of think that Django is kind of, at least on it's third or fourth and coming up to its fifth generation of active leaders. Really, it's not the first time people have dropped away and a new generation has come in. Yeah,
Jacob Kaplan-Moss 51:03
I'm not. I'm not worried about it. Exactly. It's just like, something that needs to be focused on because you're right, like, every, every time we've had sort of like a leadership challenge, we've emerged from it stronger after, you know, at afterwards, and I don't see any reason to suspect that this that this will be this will be different. Okay.
Carlton Gibson 51:29
Good question. Well, if you've got one, or Yeah, but go ahead. Okay. So one thing that we've talked about a few times on the show, and perhaps it hime and others, but is the gap is still still feels, to me, there's a kind of gap between the narrow Django community of thought the actual active contributors, those are on the forum, and, you know, the maybe the discord and around and about, and then the wider community, which is the user base? And do you have any thoughts on how we can sort of, I mean, there's the social media working group is one great way, I think, but we can kind of get the bridge out a bit better to feels like it's a big gap. Sometimes.
Jacob Kaplan-Moss 52:07
I mean, I think to some degree, that's just true of that's just true of like software development, and open source communities in in general, right, like, you know, for every one person on the forum, or listening to this podcast, or coming to Django con, there's probably 100 1000, who punch in, right Django code for eight hours, punch out and go home. And that's fine. In fact, that makes me super happy, right? I don't think that just because you write code in your day job, you need to think about it outside of your outside of your day job, I'm completely fine with that. And I don't, I would love to be able to reach those people to find out what we could do to make their their, like jobs easier, their lives better. You know, like, I'm not really sure how, but I don't think it's a problem that they're sort of not engaged in, in the in the community aspects. Okay. But the part that I do think about a lot is how do you take the person? Like, okay, so let's talk about Django con us, I think about half the attendees of Django con us it was their first time going going to a Django con. And most of them had not sort of contributed to at least like the the core of Django or like a major, sort of popular third party app in any sort of like, concerted way. They all have, they all have the interest. There are the vast majority of the people at that conference, you know, several 100 People are sitting in a room are relatively new to the community, have the excitement came to the conference, set aside their time, you know, all of that stuff, how do we how do we convert them? How do we help them take the next step? That's, that's something I don't think we've ever done particularly well. And that's the place where I want to really like I really want to extend the effort and I don't I don't have answers here. I just have questions. But like, it's, it is the foremost thing on on my mind right now is like, I've been using the term on ramps, like how do we build on ramps, into into the community, you know, like, we we consistently get people who kind of like, come out of nowhere and build something, you know, something really big and cool and new and, and exciting. But it's a pretty, you know, it's a pretty big effort. It's a pretty big Lift. And it takes like, an almost unreasonable degree of confidence to be like, I'm going to write 1000s of lines of code, and I'm going to get it into Django by by force of will. That should not be required to sort of like, Get get more directly involved. Likewise, you shouldn't have to run for the board of a nonprofit organization to, you know, help out with community leadership, or fundraising or governance. You shouldn't have to, you know, plan a conference to get involved in conference organizing, right? Like, you know, how do we sort of how do we build on ramp so that people can dip their toe in contributing to Django can dip their toe into working on conferences, right. And we have, we have some of those, but we don't have enough and we don't have, like, clearly divide, like, defined like, progression pads for various different forms of contribution. And that so I've been thinking about, I've been thinking a lot about, like building those on ramps, yeah.
Carlton Gibson 56:05
And like people who are good at making contributions to the ORM, and writing the docs, to that they need to do to do that and write the tests, and they may not be good at these other tasks as well. So we need you know, we need I'll give you,
Jacob Kaplan-Moss 56:19
I'll give you an analogy. So like, a hobby I've started to pick up over the last couple years is is packrafting. This is gotten combining backpacking and, and, and river kayaking, they're these inflatable boats, they're small, they're lightweight, you can fold up, put it in your pack, hike for a while on folded, float, float down a river. It's very hard to get into, like, it requires a lot of backpacking skill, it requires a lot of reverse skill. Whitewater is dangerous and requires a lot of sort of technical ability in order to like, stay out of trouble, do this, this this blogger. And like longtime packraft, or Dave Chinotto, wrote a blog post that he titled something like packrafting progression, which is basically like, so you're interested in packrafting here's what it looks like to go from this sounds fun to I am executing, like, you know, high, you know, like, high difficulty level trips, and he had just sort of the series of like, you know, I mean, step one was like, get obsessed, watch a bunch of YouTube videos, read a lot of books, you know, step two is get a boat, get out on a lake, a flatline, around, you know, figure out how to blow it up, et cetera, et cetera, like, we need like a contributing to Django progression guy. Yeah. Right. You know, and, and, like, that's, that's the type of thing that I'm that I'm,
Carlton Gibson 57:54
that I'm thinking about. Marvelous. So we will have you got any questions?
Will Vincent 58:00
So we're coming up on time, Jacob, but what are the things in Jake? What are the things in Django that you're currently excited about that are in the works, you know, solutions to long standing problems? Is anything come to mind?
Jacob Kaplan-Moss 58:11
I mean, I mentioned htm x a little bit earlier. I'm I am. I'm just so excited about it like for, for close to 20 years, it's been like, what is Django is front end story. Have a front end story, it's gonna, it's gonna, you know, the sky is falling. You can't do front end development in Django. Django is dead, because you can't do front end development in Django. And, like, almost the first time I saw htm X. Maybe the second time I think the first time I didn't get it, but but really the second time, and certainly the first side I built in it, it was like, oh, no, this this is this is this is what the front end story projecto looks like. Yeah. Like, it was like, Oh, wait, we got we have an answer now. It's just, it's just so easy. And it fits with jingoes philosophy. It's not a silver bullet. If you're trying to build something like, I don't know, figma, like an actual, like, appy app that runs in the browser. I can't imagine doing that. Mm hmm. That seems that seems ridiculous. But for the vast majority of what people are building with Django, which is still Database Driven crud apps, that's like, we still, those are still incredibly important. You know, even in 2024. HTML, it's really just feels like the missing piece.
Will Vincent 59:29
Can I just say, I think you you told me at Django con that I think you'd build basically XL with Django and htm X, like, quickly. Do I have that? Right? Yeah, I
Jacob Kaplan-Moss 59:38
essentially replaced a workflow that revolves around an Excel spreadsheet with a with a Django app that had you know, yeah, I mean, it was essentially it was essentially like, capturing a bunch of data about our clients security, maturity at work. So there's a bunch of, you know, there's a bunch of practices and we record, you know, yes, no partial and a bunch of notes, you know, that that sort of stuff. And we've been capturing that in a spreadsheet. And yeah, I built a little Django app that, you know, lets people capture that data includes, you know, I prototyped what we call like multiplayer functionality, letting, letting multiple people updated simultaneously with push push sent through server side events. And it, you know, having that level of interactivity was 10% more work than building a sort of old school, you know, form submit workflow, like it's just, it's just easy, and it just fits with it fits with Django philosophy in a way that feels like it was designed for, for for building Django apps.
Carlton Gibson 1:00:53
That was my take, when I first started using it was the way it just literally, you just do Django, and then you use the AC and it's like, it haven't changed anything, basically, and my Django and it just works, it goes with the gray.
Jacob Kaplan-Moss 1:01:06
And there are and there are some there are some missing pieces like the, like I mentioned template partials earlier, like temporary partials plus HTML unlocks the ability to do part partial rendering, so that you can have the same view, either render a full page or with an HTML request, just render the sort of small snippet that you need to update. That's like a really, that's, that's the thing that's harder than it needs to be right now. In Django, so, you know, there's like little, there's little little bits and pieces that people are sort of reinventing on their own projects, and and need to be sort of like, consolidated a little bit, but by and large, you know, it just sort of it just sort of magically works. And it's super, it's super exciting.
Carlton Gibson 1:01:47
And how you, how are you getting your things online these days? That's, we always like that.
Jacob Kaplan-Moss 1:01:53
Yeah, you know, I mean, so I think I think many people know that I used to work at Heroku. And I still, it makes me really sad that Heroku is still around, but I don't, I don't trust it that much anymore. I think I think it has been unfortunately, kind of slowly circling the drain for for a long time. I had a major security breach about a year ago that really struck my confidence in, in the platform. And there are a bunch of new things coming out that are kind of like, exciting. I'm personally pretty excited about about fly.io. Deployment is still like way harder than it needs to be. It's still super, like, you know, we started, we started Django, and it is in no small part to like replace php. But we still have never come anywhere close to the ease of deployment with with PHP, you still can't just throw a python file on a server and have and have it work. And like, so many people are, you know, like, you know, deploying, like most deployment stories, at least at companies now are like Kubernetes, or like the sort of manage managed services, like you see, like ECS, like Amazon ECS, or deploying to lambda. And all of these things are quite cool technologies. But boy, they are heavyweight, I have, I still think there's a big gap in the Python community around around deployment. People who are interested in this place should play with demo demo dot land. Demo is a JavaScript variant kind of with a deployment environment, really baked into the language from the core. It's kind of incredible. And it makes me sad that there's nothing like that for Python. Now. Denno is proprietary, and you're sort of tied into their cloud platform. And it's, you know, it's VC backed, so it's going to crap up sooner or later, et cetera, et cetera. There's a bunch of reasons why I'm not just gonna like say everyone should drop everything and switch to demo, but like, it does make me sad that we have, you know, 25 years of complaining about how hard it is to deploy Python apps and it's basically so as hard as it's always been
Carlton Gibson 1:04:33
good. Do
Will Vincent 1:04:34
you have any recommendations for what well I just personally asked you so I've I've taught both Heroku and fly in my books and I I liked fly a lot seeing it, but it is also having Growing Pains trying to recreate Heroku which makes sense it's a lot of work specifically though, the the lack of a managed Postgres option, like a truly managed one. You know, in Heroku is fake maybe
Jacob Kaplan-Moss 1:04:59
do you have They do have one now, the Super Bass is that no fly has like a first party Postgres option. They do. Yeah, it's relatively new three to six months. Yeah. Okay. Okay, two services that I that I am keeping a really close eye on our fly we mentioned and render render.com I think right now, right? I think right now render is if you're new if you're new to web deployment, render is probably your best choice fly is a little more, a little more complex, a lot more powerful. But it's more of like a more of like a set of building blocks, than it is sort of like a super slick clean, easy to use experience render is much closer to sort of the the Heroku experience down to sort of like, first party managed services like Postgres and Redis. And, and a really, render also has a sort of non non Docker deployment option I do. I do like Docker, and I do think containers are a good, good idea, generally, but I hate teaching them to newcomers. I don't want to have to explain what a Docker file is, until someone's been writing Python code for a year
Will Vincent 1:06:12
1000 1,000%. That was really the biggest thing is for the 4.2 update for one of my for my beginners book, I switched to fly. But I had to talk about Docker. And it's like, oh, man, it's just I will
Jacob Kaplan-Moss 1:06:25
now fly will now detect a Django app without a Docker file and generate one for you. Which is, which is nice. But then you have this if you're teaching so I've been here, you're teaching someone and they go, what is this? And you have to be like, don't look at the man behind the curtain. That's exactly.
Will Vincent 1:06:40
That's exactly what it is. Right? It's just like, just Yeah.
Jacob Kaplan-Moss 1:06:44
Yeah, I don't think that's a good experience for newcomers, right, like telling someone telling someone, Oh, that's too advanced for you. It's like so patronizing. And so, and so frustrating, but also, it's unfortunately, it's also true. Like, I actually can't explain this to you right now.
Will Vincent 1:07:00
Right? Well, it's like visible enough that they're like, oh, I don't know that. Whereas like, oh, there's so much other stuff. You don't know, either, but you're not worried about it. But that was I mean, for me, my beginner's book, I wrote it in large part because there was the rails book, which I don't know if that's still there, where it was like, Hello, world. And then you know, Heroku was built for Rails. So it's just like, boom, and I was like, back 10 years ago, like, why can't we do that in Django? Like Django is awesome. Why can't we do that? And so I have continually been trying to get as close as we can to that. Yeah, but there's
Jacob Kaplan-Moss 1:07:29
there's another project to plug which is Django simple deploy, just trying to sort of solve this problem. Different Eric's right app for deploying Django apps. I haven't used it myself because like, I have Docker Stockholm Syndrome. So I so I'm, like, tied into that platform. And like, it's easy for me now. And I forgotten that it sucks. But I think like, I should spend some time playing with it. I've heard good things, I think it's probably a promising a promising idea. And hey, maybe this is one of the exciting new things that someone could take to being built into Django someday manage that py deploy would be a pretty amazing thing, wouldn't it? Yeah. I
Will Vincent 1:08:07
mean, it's like, well, we could go on and on. Is there any way we? Yeah, I was gonna ask you though. What would you change about Django question, but you've I think you've kind of answered it. So that's the is there anything you know? So you do have a day job? Well, we'll put links to it working on security at ladder core. Did I saying that right? Yeah, correct. But people can reach out to you if they have more questions about everything. Yep,
Jacob Kaplan-Moss 1:08:30
I'm easy to find, please, please feel free to reach reach out to me my email is fairly obvious. You can you can DM me on Mastodon etc. I'm, I'm like, I don't get I don't get so much random email that it's overwhelming. So please feel free to reach out like, I can't promise to respond. I can't promise my response will be helpful. But I can't but I can promise that I won't be annoyed or frustrated or the or any sort of negative emotion. So like anyone who's listening who wants to reach out about anything, please like, please feel free. So
Carlton Gibson 1:09:08
Jacob, thank you so much for coming and really, just such a good shot. I've enjoyed it so much.
Jacob Kaplan-Moss 1:09:13
Yeah. Thanks, guys. I really appreciate it.
Will Vincent 1:09:15
So we're Django chat.com. And we will see everyone next time. Bye bye. Bye bye.