Welcome to Once a Maintainer, where each week we interview an open source maintainer and tell their story.
This week we’re talking to David Wobrock, a Senior Software Engineer at Back Market. David is a maintainer of the Python framework Django and a contributor to many projects in the Python ecosystem. He lives in Berlin.
Once a Maintainer is written by the team at Infield, a platform for managing open source dependency upgrades.
How did you get into programming?
How far should back should we go? My parents are both university professors, and they do research on meteorology. So they always had computers around to do cloud modeling and stuff. My brother and I always wanted to play around, to tinker, to try things out. I remember that they installed games on the computer that we had when I was a child, and they wrote the commands to type in the terminal in order to launch the games on Post-It notes. I had no idea what it meant, but I just typed these characters and it worked. I always had computers near me.
When I started studying at university, I really fell in love with the entire field, both the theoretical aspects, the mathematical parts like linear algebra for databases and also the technical parts.
And have you always worked as a software developer since you graduated from university?
Yeah, I have. I tried the academic path of doing a master thesis researching how development and computer science applied to different fields, but it didn’t stick. I think I like the private sector where you have a bit more impact on the day-to-day life of people through software. But yeah, I've always been a software engineer.
How did you first get into open source?
I started at university a little bit. My first contributions were during my studies when I was very C# focused. I think a professor taught us that, so it's stuck with me. And I remember my first major feature, something that was not a typo or a link or whatever, my first major contribution was a Python plugin in Visual Studio - not Visual Studio Code, the big IDE Visual Studio. I don't know why I was writing Python in Visual Studio. What came upon me was like hmm, this integration is not working as I expected, I would like some auto completion features that I don't have, and so I contributed to that.
I’ve always admired open source maintainers. Those people were both incredibly smart, being able to write software that's used by hundreds, even thousands, millions of people and putting your work out there saying, OK, I think it works. I really admire the dedication, to spend some of your free time to give back to the community, to say hey look, I did this on my free time maybe it can be helpful to someone. They’re sort of a role model for me.
How did you get involved in Django specifically?
At university, we had to do some group projects where we could freely choose the technology that we used. And Python was the language to learn, right? That's where the industry was going for most jobs. So me and my fellow students, we thought OK, we have to learn Python. We want to make a web server. What can we use? The first Google search basically popped out Django. FastAPI didn't exist at the time, and Flask was less batteries included. So we were like well, everyone recommends Django, let's try it out.
Then when I started looking for jobs, I didn't specifically look for Django jobs, but they were what I qualified for. So I applied and I got one of those. And then, the more you play with the framework, the more you know the internals a little bit. You start diving into the source code. You start finding bugs. Sometimes we're like, that shouldn't work like this. Why doesn't it work like this? Then you're like, OK, I think I can add that. And then you think, hey, there’s no issue open, let's give it a try. That's how I got into Django - step by step let's say.
Is there a Django core team? How does the maintenance work?
So there are two fellows who are paid to maintain Django who accept contributions, triage tickets, they do a ton of things. Coding is probably a very small part of that job. And then there's the Django Software Foundation with the board that handles the finances. Then there's a technical board making technical decisions, and a security board that handles critical issues or security issues that could be in the framework. So it's quite a big organization in the end. I’m a tiny person in all of this.
How would you describe working with those people and working on Django versus how you do your work in your day job?
It’s very different in a way, because there are so many different interests at stake. The contributor wants their change merged, right? The maintainer wants the software to make sense, to answer the specific problem it was designed for. In Django, since it's batteries included, there are many people who want to add things that could be third party packages and they say hey, it's going to be even more batteries, but there's a limit to that. So there’s an interesting discussion of what should be inside the framework and what should be a third party package. These types of discussions are very interesting.
But in your company, you're all focused basically on making money for your company or pleasing your customers which is still working towards the same goal. Open source tends to take more time of course because it’s people’s free time. In a work environment things take a day, half a day because you can sit together, pair program and say let's do this together. You might have Slack or Microsoft Teams. In open source there is a back and forth and everything is much more asynchronous. For an open technical question or a new feature we’ll say let's ask the technical board. We'll give them maybe two weeks to discuss and come back with a solution or a suggestion. The communication is quite different. It’s also more relaxed in a way.
How do you dive into a code base that somebody else has written and many people have contributed to over the many years?
Talking to a person will always be ideal. I think that's the easiest way. But, you know, open source projects that are 10 or 15 years old or even older, it's going to be hard to find the contributor. What do I do? I probably dive into the code and try to understand who calls what. And then have a little notebook where I write things down and draw these big diagrams of arrows and boxes in all directions, but I can start making sense of it. And then it's really about trying out something. Maybe having a break point somewhere, or at the unit test launch it and see what are the code paths that you got into.
If you think back to when you first got into open source, to now feeling comfortable unraveling a large, established project - how do you get comfortable doing that?
Debugging skills are definitely useful there. The more you’ve had some weird, hairy bugs, the more you understand how to follow your stack trace and understand where you're going. I’m not sure it has to do with seniority. It's just getting comfortable with the code base. Once you understand the models, the different files, modules that are in the code base, it's basically just experience in this code base. When you start fixing a bug that affects one function and one file, that's one thing, right? You can write tests, you can test your function, it works. That's a really good start. And from there you start doing changes that imply two files, maybe two models that work together, and then step by step it's getting bigger and bigger.
Are there any other open source projects that you've been into lately that you think are really interesting?
There are many, many interesting people and interesting projects. Honestly, everyone in the Django community, it's amazing how they work, how efficient they are, how on point. Every review is always inspiring.
In the Python community there is Ruff, a linter and formatter. It's mind blowing how fast they had adoption on their tool and it's written in Rust, so it's faster than all the others. It solves a problem that you didn't know was there, and suddenly everyone wants to use it and it's amazing how fast adoption grew. It's a great project.
Personally I'd like to dive a little bit into the PostgreSQL community. Maintaining an open source database sounds really interesting. It's such a massive project that the governance around it must be quite interesting, and I’d love to get a better sense of how they do it.
To suggest a maintainer, write to Allison at allison@infield.ai.
If you’re interested in learning more about how Infield can help your team keep its open source dependencies up to date, write to hello@infield.ai.