DSF member of the month - Benjamin Balder Bach
For August 2026, we welcome Benjamin Balder Bach as our DSF member of the month! ⭐
Benjamin has long been part of the Django community, serving for years as an organizer of Django Day Copenhagen and as Chair of the Social Media Working Group. He is a DSF member since June 2020!
You can learn more about Benjamin by visiting Benjamin's website and his GitHub Profile.
Let’s spend some time getting to know Benjamin better!
Can you tell us a little about yourself? (hobbies, education, etc)
Hello! I like DIY in general, so whether it's software, cooking, sewing, growing plants or building stuff with wood - I really like practical things with a finish in sight. I really don't mind when it's not a software project, though 😇
I'll try to nail what my education and work is about: I started as a self-taught programmer when I had a job at 15 (as a web designer). Before that, I had been delivering newspapers and cleaning toilets at my school, so it was a pretty big leap forward. I knew HTML but learned about SQL and ASP classic (not .net) because my employer back in 2000 let me learn while working. Fast-forward, I studied Computer Science from 2005 and took my masters degree in Digital Design and Communication - heavily inspired by years of PHP and Django experience, my thesis ended up being about "Risky and Rapid Design Spaces" (2013) - a concept/anecdote that I still stand by. It becomes relevant in the context of Django because the front-and-center message and goal of the framework is to "encourages rapid development".
"Rapid" means that we iterate and deploy changes quickly (with lots of aspects of what that means). But I think we need to understand and frame the "risky" part, especially understanding that a GIANT risk-avertion factor is to have developers understand and share context with users, whether they are clients, customers or staff colleagues. For instance, while I was working at Read the Docs, we had developers rotating on frontline support, meaning that everyone in the team would understand the users's experience and build solutions based on that. I've also been part of smaller organizations where I would read the exception traceback data, fetch the customer's email and write/call them to ask for more details and fix their problem immediately. This was before GDPR, but I can attest that the customer satisfaction of being cold-called by a system developer that was working on their technical issue was high! I think the Django Fellows are a perfect example of how this works: People doing software development are directly engaging with the stakeholders, and the design is happening within that process. It's not to say that UX or architecture shouldn't happen, but more to say that context overlaps are desirable to risk-avertion, not the opposite.
Silo... nobody wants a silo. But context! Everybody wants that!
Currently, I look forward to Carlos Alcaraz making his comeback. And then I hope that in 2027, I can make it to Django on the Med - and I envy everyone going there this year!! I'll try to make up for this by having a nice time at Django Day Copenhagen.
I'm curious, where your nickname "Benjaoming" comes from?
I picked a nickname as a teenager and used it so many times that it became impossible to get rid of. But let's be honest: Out of some random teenage thought, I wanted my first name "Benjamin" to sound Chinese. The first variation was "Ben Jao Ming", but eventually it just became "benjaoming". I had a childhood friend with a Chinese name who changed his name to an English name. I think possibly hundreds of millions of people have changed their names to some Anglo version, so if I have to make an excuse about why this is somehow cool over 20 years later, that'll have to be it!
How did you start using Django?
In 2008, I had learned Python by building a distributed file system in FUSE (if you don't know it, don't worry.. but let's just say FUSE and Wobbly Windows were an insane period in the Linux Desktop era). Back then, I was actually using PHP for everything involving websites, but almost instantly, I was happy with Python and became involved in founding an organization to advance computer reuse and refurbishment - which of course needed a website - back then, Django was the one-stop shop for building websites with Python. And it still is 🥳
Can I be excused with a quick interjection? This history of Django was something I was trying to figure out when Django turned 20 years (last year). There is an un-published timeline here that I think we can leak, and it contains instructions to get in touch about finishing it.
The organization I was building with my first Django projects, FAIR Allocation of Infotech Resources, turned out to be a 10+ year engagement where me and others built a platform for reusing computers. This spanned everything from embedded systems that scanned and wiped the subject of reuse, to Gnome desktop applications and an online warehouse. We reused tens of thousands of computers in Denmark and Norway. We couldn't have done all this without Django - people would ask for a feature for the operation, and we'd just turn it into reality immediately. I don't even think we had an issue tracker for the initial years. To begin with, it was just emails/meetings/workshop fire-fighting, commits and manual deploys.
Can I be excused with a SECOND quick interjection? There's a lot to learn from the simplicity of the past. People may think that a proper operation requires CI/CD, full test coverage, AI integration, project management etc. But if we want to know what "rapid development" means in 2026, we shouldn't accept all the current standards.
At some point during this venture, I needed a wiki in Python, which was called django-simplewiki in 2009. MIT sponsored some development work because they were using it for edX, and it became a popular project called django-wiki.
At this early stage, I didn't know so much about the Django community, but when I met another Django developer in Copenhagen (valberg), we ended up going to Poland for DjangoCon Europe 2013 in Warsaw. Because there's such a long history of DjangoCon Europe, I've added a whole table to the Wikipedia article. The table is in the general Django article, but because it's so long, I think we might need a new separate Wikipedia article about DjangoCon ✌️
I've done a lot of professional work with valberg, and today we're running an association called data.coop for people in Denmark to break free from Big Tech. Together with valberg and emilkjer, we've been been running Django Denmark since 2018, and that's been quite a journey!
What other framework do you know and if there is anything you would like to have in Django if you had magical powers?
I did some evaluation of FastAPI and SQLAlchemy - and also django-ninja! I think it's interesting how SQLAlchemy approached typing and async, especially how beautifully they curated the transition from SQLAlchemy 1.0 to 2.0 (typed). When people object that Django's ORM doesn't utilize types, I would say: Try using SQLAlchemy, Alembic and FastAPI yourself, maybe try putting all the bits and pieces together for a full project. You might end up concluding - as I did - that for many many cases, having Django's ORM, migrations and other batteries included is just a simpler, cleaner, more maintainable solution. And there's django-ninja which gets you very close to the FastAPI experience, while staying in the Django world.
I really liked building APIs with FastAPI and dependency injection. I think it's a promising idea to combine FastAPI and Django, so in no way do the two frameworks need to contradict one-another.
On that same note: I've tried a 2 times to combine Hugo and Django, and they both went well: So you build all the frontend with Hugo, and it outputs the templates and static files that Django renders. An example is from the 2019 DjangoCon Europe's website. That way, you can have a static website AND a dynamic website in the same project/repository etc.
What projects are you working on now?
I've been migrating django-money from GitHub to Codeberg. That means the project is now on a platform that protects FLOSS from LLMs and is owned by an Open Source community rather than Silicon Valley/Big Tech. Together with my co-maintainer, Dmitry Dygalo, we acknowledge that we have taken on some extra work and costs to operate our own independent CI for testing. I look forward to seeing what a self-hosted CI can do, for instance we can customize our own base images moving forward to have something that's fully tailored for Python projects and don't need to install other actions to do the work.
Which Django libraries are your favorite (core or 3rd party)?
Here's a list of things on my mind these days:
- django-admin-action-forms is a project I think is so good (💌 Michał Pokusa!), it needs to be adopted somehow for the Django Admin itself. It proposes a very simple way to configure forms for Django Admin actions... and I need that all the time!
- django-markdownfield makes its way into many projects I work on as a very easy way to enhance an otherwise boring TextField.
- django-migrations-ci is an application that can possibly help speed up the CI and save CPU and energy resources on many larger projects. Of course, the simple answer could be to manage and squash migrations - but the enterprise reality might be different.
- django-money is a project I was handed commit rights to and it's been following me around in most Django projects up until now. It's just really good to make sure you get money values correct in e-commerce.
- Wagtail is a flagship Django project that doesn't need further introduction. But some of the key points of this project is that the organization and worker-owned cooperative Torchbox keeps lending resources to help Django itself advance.
What are the top three things in Django that you like?
-
Reliability of the admin : I've been almost entire engaged professionally with the Django Admin for the past 2 years, in the sense that building administrative interfaces has been a prime my clients. The primary win of the Django admin is that custom-built functionality rarely breaks - so if we're a company and we pay someone to build something in the Django Admin, we still have it many years after, most often passing cleanly through upgrades.
-
Matureness of the ORM : I can do what I need with the ORM. Many advanced needs are covered, and debugging queries is easy and efficient with tools like django-debug-toolbar.
-
Matureness of the community : My favorite example is that we still do not have typing. Why not? You will need to dive into on of Carlton Gibson's talk Static Islands, Dynamic Sea. But basically, we are taking advantage of both worlds and not suddenly band-waggoning around a new trend. Discussions are allowed to take time. I also really like the new features where we've found a similar path of patience between the issue tracker and Django Enhancement Proposals (DEPs).
You are one of the board members of Django Danmark and organizer of Django Day Copenhagen since multiple years, that's great! How did everything started?
Actually, we were a lot of people from Copenhagen that met at a couple DjangoCon Europe conferences outside of Copenhagen! So let's not underestimate the impact of this, we may have known one another from professional settings and studies, but at the end of all that, we were inspired at the DjangoCon Europe events to go home and do more...
So up until 2018, we had lots of small, informal gatherings as meetups. For a few years, often 50 people would show up. Companies hosted, paid for the pizza etc. People put in efforts to prepare talks. That way, a community formed and friendships were made.
However, we were seeing a dip in normal meetups back in 2017 and wanted to have more momentum for the events, so we opted for a single-day, annual conference with tickets. We needed to incorporate an association for this to happen, but it happened with Django Day Copenhagen 2018. And then a year later, we hosted DjangoCon Europe 2019 in Copenhagen which boosted the economy of the association dramatically.
We've always volunteered and never taken out any payment for anyone involved. That way, we've kept the profits to give back to community activities and supported other communities around the world.
I was never alone in this, but thanks to Víðir Valberg Guðmundsson (valberg) and Emil Kjer, we've been able to sustain the setup for many years through Django Denmark.
You have organize different type of events, including bigger one like DjangoCon Europe. What are the things to consider to start an event and keep it sustainable according to you?
This is gonna be an even longer rant then! I'll try to vary it, but otherwise my pet peeve is Code globally, meet locally.
So firstly, start small, meet some people, get a network. Use whatever you have to start the first meetups. Don't get overwhelmed, but instead focus on meeting other people that you enjoy being with.
We've always looked for other local non-profits and municipal venues to do what we want. We explore our networks. We don't have any principal issues around working with commercial partners, but once we reached the state of paying for venues and food, then in order to keep things affordable, we like to work with like-minded organizations and people, so we've often had to skip the commercial venues.
This also echoed a larger mission: It's very helpful when a company lets their employees do community work in work hours, and it's certainly the right thing to do. Because companies benefit from open source communities, and when they contribute back in the open, it gives them other benefits, too! But if we were to establish a budget around a fully commercial event activity (it's more expensive!), we would lose a lot of aspects of actually having a community. So even though it's not strictly speaking a problem to pay a profit-making entity to do things, we would have had a dramatically different pricing of events, making them either impossible or exclusive in way that the full community could no longer be included. You might have a different situation.
Sponsors are almost impossible to get around no matter what: We've varied it a bit. From working with "sponsors" and having dedicated a process to try and sell sponsorships, we changed to just "corporate supporter" tickets, which is a ticket for companies that give them benefits included in a standard corporate ticket.
Events don't have to be at commercial conference venues: The most important part is that people are together and someone prepares something for the event - talks, food, drinks etc. If you want to just do something social, then announce a park or a bar where people can meet! If you want talks, then maybe you just need a library - we did that several times! Or even better, you're a university student and can use the university!!
For DjangoCon Europe 2019, we ended up with an amazing circus and theater production school. And actually most cities have very similar options. So if you see Django as something cultural, you will likely find inspiring cultural options for both the venue, the food, and the content.
Related to events, you are a member of the DSF Events Support Working Group, can you tell us a bit more about this working group?
Yes, absolutely! We're a new working group that grew out of a previous working group established to support new organizers of DjangoCon Europe. The idea was that experienced organizers could help new organizers. There's a special situation for the DSF where DjangoCon Europe doesn't actually have its own organization, but everytime a new episode happens, someone local/new is fully responsible for all the finances etc. That's a lot of work. As a consequence of that, the Portuguese team from Evolutio has also been hosting a lot of events.
We decided to have a working group to support EVERYONE, EVERYWHERE doing Django-related events. So if you have an event brewing and you have questions, you can always write to events-support@djangoproject.com.
We would like more organizers to join the working group.
I know you have a deep interest in data privacy, what are the recommendations you would give to someone who would like to do their best in their Django applications?
I don't think we're close enough to have a privacy-by-design setup in Django. We could do much more for model/ORM design to have support for anonymization, right-to-be-forgotten, consent etc.
I've been working a lot with consent, and one of the things that I learned was that the agreement made with a user when they consent to something needs to be manageable both the user - and the data controller, too.. but I hear "consent management" all to often ONLY refer to the data controller's ability to manage. The real change would be to design for the user's ability to manage their consent.
But we can't go around and re-invent bespoke solutions for this every time. We need a simple solution. And again, like I pitched in the beginning with Risky and Rapid Design Spaces - here's another option for the developer to gain enough context to produce relevant solutions out of their own thinking and intutition. From my experience, many developers LOVE privacy, so having a developer-oriented implementation of consent-based data management could add a great ally of the legal department to guard the user's interests. Developers are writing the data models and processing, so they're very like likely to be the first ones to go "oh! that needs the user's consent!"
You are the chair of the DSF Social Media Working Group, one of the people behind the Official Django account, that's really nice! How does it look like?
We're around 8-9 active members in the group, but everyone is very low-key active, meaning that there's always someone posting stuff! It works very well in the sense that no one has taken on a lot of work. And it leaves some room for improvement, too, since the DSF has a lot of accounts with a lot of followers and a lot of stuff to post about!
We have a flow similar to working with code on GitHub: Someone suggests a post, and someone else reviews/approves it. We might do a very simple post to get something out quickly, and other times we talk about the content and plan something for a longer time, for instance Feature Fridays.
At the moment, we are mixing two kinds of flows: first, sometimes we notice news and post it on our own initiative, and second, sometimes we are asked if we can help another working group or the DSF board to post. We have a kind of inbox for that.
But I would say we are always happy to receive tips of something that would make for a great post. We have a form if you have suggestions and our DMs are open!
After so many times in the Django community, what makes you stay?
I think Django was always the ray of hope and inspiration for me to build software: The world never needed more software nor web frameworks, so I always loved that Django had a respectful and inclusive community where we were able to talk about other values than just "l'art pour l'art". We don't necessarily need more software, and we don't necessarily just need better software, in that framing everything remains a technical question - we need purpose. And to be in a diverse community that is able to talk about making itself more inclusive, opening the job market and opportunity space for the whole world, and understanding and addressing privileges and disadvantages is key for our community to maintain its purpose.
How do you envision the future of Django from your perspective?
Simple answer: Our community attracts smart people that collaborate well, and thus we'll keep having a smart framework.
Is there anything else you’d like to say?
I love that we use the green heart emoji in Django settings 💚
Thank you for doing the interview, Benjamin !
