For July 2025, we welcome Jake Howard as our DSF member of the month! ⭐
Jake actively shares his knowledge through blog posts and community talks. He is part of the Security Team Working Group and he created the DEP 14. He has been a DSF member since June 2024.
You can learn more about Jake by visiting Jake's website and his GitHub Profile.
Let’s spend some time getting to know Jake better!
Can you tell us a little about yourself (hobbies, education, etc)
I’m Jake. I’m a Senior Systems Engineer at Torchbox, where I’ve been for a little over 4 years. “Systems Engineer” is a fairly loaded title, and means different things to different people. I like to describe it as doing everything technical to do with Software Engineering which isn’t Programming (Sysadmin, Devops, IT support, Security, Networking), but also doing a fair bit of Programming.
Most of my hobbies revolve around technology. I’m an avid self-hoster, running applications on servers both in “the cloud” and in my house. There’s been a server of some kind in my house for the last 10 years. I’m generally quite a private person, so I like to know what’s happening to my data. Since I started working remotely at the start of the 2020 pandemic, I’ve channeled some of this passion into posts on my website, with posts about all manner of things I’ve done from self-hosting to general software engineering.
Away from my desk (sort of), I’m a volunteer for Student Robotics, inspiring college students into STEM through competitive robotics (no, not quite like Robot Wars). In school, I was always the quiet one, but now I seem completely at home with public speaking, commentary and otherwise being in front of large crowds of people. I wish I knew the secret - I’d make millions!
My GitHub is also pretty active, with contributions all over the place (OpenZFS, Nebula VPN, Gitea, Plausible Analytics, OpenCV, Ansible…).
I’m curious, where your nickname “RealOrangeOne” comes from?
Because a lot of life happens online (especially in the last 5 years), many people haven’t even seen pictures of me, let alone met me in person. I am not in fact a talking piece of fruit. For a while, I tried to stay anonymous, avoiding photos or videos of me on the internet. But since I discovered I enjoy public speaking, I’ve sort of given up on that (for the most part).
By now, I’m sure many people have speak. But, for those who don’t know: I, like my father before me, am ginger 🔥 (the hair colour, not the plant).
The exact specifics of how being ginger lead to “TheOrangeOne” are sadly lost to time. I’ve owned theorangeone.net for well over a decade at this point. Unfortunately, it’s not a particularly original nickname, and I have to be fast to claim it when signing up to new services. In some places (where I wasn’t fast enough) I’m forced to sub out “The” for “Real”, which has lead to some confusions, but not too many. Canonically, I prefer “TheOrangeOne”, but as we all know, naming things is hard.
How did you start using Django?
I’ve been using Django since around the 1.8 release. My job at the time was at a Django development agency, so it was the first real Python framework I’d used. The first few weeks there was my first exposure to Django, pip, package management and collaborative software engineering - it was quite a lot to learn at once. I didn’t realise it at the time, but I was working working as a junior alongside a couple fairly well-known names in the Django community like Tom Christie (DRF, Starlette, HTTPX) and Jamie Matthews (django-readers, django-zen-queries). We mostly built single-page apps with React, so I learned Django and Django Rest Framework at the same time, which means I now often have to look back at the docs to remember how forms and templates work.
As for contributing to Django, that came much later. My first commit to Django was in May 2024. Having used Django for a while, and written plenty of packages, I’d never stopped to look at how upstream was developed. Around the time of DEP 14 kicking off, I needed to look a bit more at the inner workings of the Django project, to learn what was in store for me. When scrolling through Trac tickets, I found an interesting looking ticket, and got to work. At the time of writing, I’ve now closed 9 Trac tickets across 12 PRs, and some pretty cool features (simple block tags, better Accept header parsing, performance improvements to the URL router) now have my name on them (metaphorically speaking).
I wouldn’t call myself an “active” contributor, but I try and keep an eye on the tickets and forum threads which interest me the most, and chime in when I can.
What other framework do you know and if there is anything you would like to have in Django if you had magical powers?
Since it’s the first framework I learned, and so far has done everything I need, I’ve mostly used Django. For a few smaller services, I’ve leaned more towards Starlette and AIOHTTP, but for anything even slightly large I’ve just used Django - since I’d end up recreating much of Django using the smaller frameworks anyway. A better (likely official) path for single-file Django (ie without some of the magic module handling) might help draw a few more people in and fill a few more of these “micro-service” style use-cases.
I’m a class-based views person - I like the encapsulation and easy extension of base views. As with any opinion on the internet, I’m sure many people disagree with me, but to me it’s just personal preference. I’m still surprised it’s a pattern not seen by many other Python frameworks.
Following in the footsteps of Python, I often wonder if Django could also do with some dead battery removal (or at least extracting into separate packages). Django is a pretty big framework, and whilst the contrib apps are intended to be separate, they also require hooks and assumptions in other areas of the codebase. I might be wrong (it happens quite a lot), but I suspect some of those packages would be better suited externally, perhaps improving some developer momentum - and lightening the load for the Fellows. Django’s sitemap and syndication (RSS) frameworks are 2 places I wish would get some more love.
Outside of Python, I’m a big fan of Rust (as cliche as it may be). Whilst Rust is a popular language, there isn’t really a “Django” like (batteries included) framework - it’s all composing the pieces you need yourself. However, that doesn’t stop people being very productive with it. As a result, most of the frameworks have very generic interfaces, letting developers pass state around as needed, rather than trying to do everything themselves. Outside of the obvious static typing debate (which I’m in favour of), I’d love to see Django embrace some dependencies, especially if they bring some performance improvements. It may end up being a bad idea, but it might also help those who want to use Django’s modules outside of Django.
Many years ago, I tried to be a polyglot - switching between different programming languages (and frameworks) to find new ways of working and match the problem to the correct solution. Now, I’ve settled mostly on Python and Rust. They fit my needs well, I’m very productive in them, and between the 2 there’s not much they can’t handle. Given my background, and the fact most sysadmin-y tools are written in it, I’m really not a fan of Go.
What projects are you working on now?
Over time, I’ve slowly stepped back from having big side projects - being a new dad sure takes up time and energy. Large projects ended up feeling too much like work outside of work, and I end up either getting distracted or bored. After work, I want to do something fun, not that seems like yet another job. I’m the kind of person who gets the sudden urge to research something interesting for an evening, dive in, then not think about it again for several weeks. It’s not the most productive way of doing things, which is why my posts are all over the place, but it doesn’t feel much like work for me - I lean heavily on what interests me at any time to drive what I want to do.
With that said, I’m currently in the process of rebuilding my website. Of course, both the current and new versions are built on Django, but the new build should be easier to maintain, faster, and hopefully won’t need rewriting again in just a couple years. Most of my other projects have been small tools to make my home server that bit nicer.
Professionally, I’m not really a developer anymore. As a sysadmin (ish), much of my day-to-day doesn’t involve much programming. I spend much more of my time deploying, monitoring and administering Django applications than I do writing them. My main project at the moment is helping port a large Java / JS deployment over to Django and Wagtail, running on Kubernetes with some very high and interesting stability and scaling requirements. Since most of my professional live has been at software agencies, I’ve tended to bounce between different projects, rather than sitting on a single one. So I’m also supporting on a few other smaller projects as and when I’m needed.
Which Django libraries are your favorite (core or 3rd party)?
django-tasks, of course!
…
Oh right, a serious answer…
I have to say, one of the most underrated modules in Django is django.utils. It’s not as glamourous as the ORM, forms or cache, but it’s a treasure trove of useful methods. I personally always like looking at the internal helper functions large frameworks use - see the problems they’ve had to solve time and time again. Whilst there’s not the same stability guarantees, I’ve definitely been helped out on a few occasions by some undocumented functions.
In that theme, I’m a fan of libraries which do one thing and do it well. I quite like small libraries which aim to solve a problem. There’s definitely a line before that becomes a problem (anyone remember left-pad?), but libraries which scope creep are often harder to work with than the more narrow-scoped ones, whilst the smaller ones just keep on working and making my life easier. For example, django-environ makes reading and parsing environment variables into settings really easy and clean, and django-decorator-include helps including other urlpatterns whilst wrapping them in a decorator - particularly helpful for 3rd-party package’s URLs.
Finally, I’ve got a real soft-spot for whitenoise (and ServeStatic for ASGI users). Django’s documentation deters people pretty hard from serving media and static files using Django - and rightly so in performance-critical environments. However, for most people, having to additionally maintain (and secure) nginx is more maintenance than necessary. whitenoise serves static files using Django directly, without any extra configuration, whilst also pre-compressing files for a nice performance boost. To me, it’s such a universally-useful library, I’d love to see it it included in Django itself someday.
I’ll throw a bonus shout out for granian, a new (ish) WSGI / ASGI server written in Rust. gunicorn has a near monopoly on running Python apps in production, especially in the WSGI space, so it’s nice to see a newcomer. granian isn’t always faster, but doing the HTTP handling in Rust (and using popular libraries to do it) can improve stability and throughput, without holding the GIL. I’ve not run anything in production with it yet, but I’ve been using it on personal projects for almost a year without issue.
What are the top three things in Django that you like?
Contrary to what I’ve already said, I actually like Django’s batteries. Sure, there’s quite a few “dead” ones in need of some cleaning up and TLC, but having most of what I need already installed makes me far more productive. I don’t need to think about how to render my form on the page, save the results as a model, or properly handle errors - everything “just works”, and works together. Sure, batteries have their downsides - it makes swapping them out rather difficult, but I’d rather ship my feature sooner than compare the trade-offs of different ORMs. The auto-reloading in django-tasks is only around 8 lines of code thanks to django.utils.autoreload being so easy to hook in to.
Secondly: Forms, but not for the reasons you might think. Most forms are created to take submissions from the user, validate them, then probably save them to a model. However, they’re great as general data validation. I’ve written plenty of views with complex querystring requirements, and leaning on forms to validate them saves a lot of boilerplate code. Sure, pydantic might be a bit faster and have more features, but given I’m already productive with django.forms, and it’s already installed and well understood by other developers in my team, I don’t feel the need to reach for something else.
Finally, I wouldn’t say it’s quite a “favourite”, and it’s well-known as being far-from-perfect, but I’ve got a real soft-spot for the Django Admin. It lets me focus on building the core of an application, rather than the internal interface - particularly when there are no strong requirements for it, or it’s only going to be used by me and a few others. Since it’s a fair raw view of the database by default, I’ve definitely been bitten by some less-than-restrictive permissions, but there’s generally all the hooks I need. I don’t like building frontends, so only needing to build 1 rather than 2 makes me a lot happier, especially if it comes with authentication, permissions, read-only views and a dark mode 😎!
How did you join the security team?
I’d love to say it’s an interesting story, stroking my ego that I saved the day. But the reality is, as usual, far less glamorous.
As an engineer, I’ve tended towards 2 specialties: Security and Performance, which usually go hand-in-hand. In early 2023, I was invited to join the Wagtail CMS Security team after reporting and subsequently helping fix a memory exhaustion issue. I was already involved in all things security at Torchbox, especially our ISO-27001 certification, so I was already known when I submitted a vulnerability report.
Thibaud mentioned to me late last year that the project potentially looking for new members of the security team, to help with resourcing and some potential process improvements within the foundation. I naturally jumped at the opportunity - since the team is generally closed to new members and “fully-staffed”. After a few gentle reminders (he’s a busy guy), I received a message from Sarah formally inviting me in March.
Since then, I’ve tried to review every report which came through, and helped author a few patches. A few reports even had to be raised upstream with Python’s Security Response Team (PSRT). It’s been an interesting experience, and I’m looking forward to seeing how the team developers over the coming years.
I’m aware that you have created DEP 14 on the Background Workers, how the work is going so far? Do you need support from the community on anything?
DEP 14 (the proposal to add a native background workers API to Django) has been a really interesting journey. I’m beyond humbled to see the community interest behind it. When I started down this road, I’d only intended to start the conversations and help rally the community interest. Since then, and 6000 lines of code later, I’m mostly single-handedly writing a database-backed production-grade task system.
Right now, we’re at a bit of a cross-roads. Many of the foundational parts work, relatively well. The difficulty comes with the more complex features: Retries, dependencies, robust execution. Building a task system is easy - building a reliable one people want to actually use is incredibly difficult. If anyone out there is interested in getting involved, please do! Report issues, fix bugs, contribute to design discussions. Most of the APIs are based on what I think looks sensible. Software this large, pivotal and complex can’t be built in isolation - so it needs a diverse audience to ensure we (I) make the right decisions, and design an API people actually want to use that will last and scale for years to come.
The next challenge on my list to tackle is timeouts - a highly requested feature. It sounds simple, but the reality is far from it. Many of those challenges sparked the topic of my upcoming PyCon UK talk later this year.
Django is celebrating its 20th anniversary this month. Any nice story to share?
My personal highlight was DjangoCon Europe 2024 - my first DjangoCon. I ended up bringing the stereotypically grey British weather with me, but I had a great week chatting Django with some interesting people, and putting faces to the names and handles I’d seen online. After the talk announcing DEP 14 and background tasks, I was inundated with people voicing their support - many wondering how it’d taken this long.
But personally, I’m more interested in what’s to come. Of course, there’s django-tasks, but the next sets of releases are shaping up to be pretty interesting. Over the last 3-4 years or so, I’ve personally noticed a bit of a resurgence in people’s appetites for change in Django. The 6.x Steering Council have a lot of interesting ideas, and clearly the community agree. People are happy with what Django can do now, but want to bring it a little more up-to-date - and are happy to put in the work to do it. Only a few weeks ago, django-csp was included in core, making it easier to make more secure applications. I’m sure that’s just the start. The fact people are still keen on working on a framework which just celebrated 20 years shows it must be doing something right!
Is there anything else you’d like to say?
I’d like to thank whoever nominated me to be a DSF member in the first place. To this date, I have no idea who you are.
Beyond that, I’m just looking forward to seeing what comes of Django, and Python in general over the next few years.
Thank you for doing the interview, Jake !
