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 !