Interview with an Open Source Contributor: Simon Charette (Django)

Zapier would not exist without open source software. From backend frameworks like Django and Celery, to frontend libraries like React.js, open source makes up a large percentage of our codebase. We are thankful for the individuals who maintain these projects. We are also curious: What is it like to be an active member in an open source community? To find out, we are launching a new blog series where we interview contributors of projects important to the web development field to see what the experience is like.

Our first guest in the series is Zapier’s own Simon Charette. He’s a core contributor of the Python web framework Django, where he specializes in the ORM and database migration systems.

Becoming a Contributor

To kick things off, I asked Simon how he got his start with Django. Simon told me that his first exposure came at a web agency in the early 2000’s, where the development team selected Django to replace an in-house system they were using. It was at this point that Simon got hooked. When he left the agency to do consulting, he chose Django for all his projects. In fact, during this consulting period, Simon made the jump from a user of Django to a contributor.

“Yea, my first contribution was a french translation of a string shown in the admin,” Simon said.

It struck me that this small update was the first addition Simon made to Django. When I think of contributing to open source, I often envision big features or complicated refactors. The reality is that contributions come in a variety of sizes and difficulty, and each one is valuable.

From that first translation, Simon soon upped the scope of his contributions. During one of his consulting projects, he built a email marketing platform which made heavy use of Django’s ORM. It got to the point where bugs in the ORM began to affect Simon’s ability to proceed. As Simon puts it,

“We were doing a lot of fancy stuff with content types and the models. When we ran into these bugs, it made sense to fix them because it helped our product as well as Django.”

These larger fixes kept Simon active in the project for a couple years. Eventually, the Django team invited Simon to be a core developer.

How Django Operates

Having covered the backstory, I turned my attention to Django itself. I was curious to find out how the project is managed.

For those not familiar with the story, Django underwent major leadership changes in the past few years. Jacob Kaplan-Moss and Adrian Holovaty, two of Django's creators, originally led the project (BDFL’s in Python community lingo). When they formally stepped down in 2014, Django made a number of changes to its internal structure. One of changes was establishing the Django Fellow program. The program pays for a single individual to manage many of the regular tasks for the project like triaging tickets, reviewing PRs, and building releases. Tim Graham currently holds this fellow position.

“Tim Graham is the shepherd,” Simon explained. “Since Tim made his way in, it has helped a lot. Before that, members of the team, which are really just volunteers, were feeling bad when the ticket queue grew and they weren't able to provide quick feedback. Tim focuses on figuring out if submissions are real bugs and if they are worth fixing. He’ll cc the right folks so if you ship a bug, you can go fix it.”

Along with Tim’s workup of issues in Trac, there are a couple other avenues of communication across Django contributors. The main one is the public mailing list, where anyone can receive announcements of new issues and discuss pending changes. For real-time communication, there is also an IRC channel (#django on irc.freenode.net) that some contributors keep a presence in.

Sometimes there are disagreements about what direction to take. When consensus cannot be reached on the mailing list, a contributor writes a Django Enhancement Proposal (DEP). The DEP outlines the change, gives a rationale for why the change should be made, and addresses other considerations like reference implementations and backwards compatibility. DEP’s are submitted to an elected committee called the “technical board,” which reviews each DEP and makes a final decision on whether to accept the change or not.

What it’s Like to Work on Django

With a better sense of the high level operation of Django, our discussion moved to what it is like to be part of the team. I asked Simon how he chooses what to work on.

“Right now, Django has all the common features a web framework requires,” Simon told me. “Really it’s trying to identify pain points and fix them as feature freezes come.”

Since Django is on a time-based release schedule, contributors decide when they want to slot in fixes and additions. There is no roadmap or rigid control. Contributors pick the areas they are interested in improving and schedule their effort so they can be included in a particular release.

An insight Simon gave is that larger changes can take about a release cycle (eight months) to finish because there has to be discussion on the mailing list and a review before the change is finalized. As a team of volunteers, most whom have full-time jobs, the team is constrained in the resources it can dedicate to any one initiative. For example, the weekends are typically when Simon does Django-related work now. Occasionally he can reply to a PR after-hours or slip a bit of time in at lunch, but the total amount of hours contributed does not come close to what a private company gets with a full-time developer.

Apart from the limited developer time, I wanted to know what else made working on an open source project different than a full-time job. There were a few aspects that stuck out to Simon, the first of which surprised me.

“When you want to work on a new technology…one of the best ways to do it is to try to contribute to the project,” Simon said. “I think that’s one thing that made me a better developer, where I had the opportunity to work with people that have incredible position and a lot experience in this field and would take the time to review my change and tell me what’s wrong and what’s not and discuss it. It helps you build the ability to try to defend your position and design features correctly, and be able to express why they were done this way.”

For me, and likely others as well, a lack of expertise prevents me from contributing to big projects. There is a fear of not meeting the quality bar, so the safe choice is to stay out. Simon proposed the opposite. Dive right in and you will quickly learn the internals. You’ll also get feedback from experts, helping you quickly build up your skill. It’s a bold approach, but according to Simon it works.

The other two aspects that Simon said make development in open source different, at least for Django, are documentation and a commitment to backward compatibility. On the documentation front, Django requires contributors to document each feature and change. For compatibility, the policy is to be backward compatible for at least two releases. That means supporting a lot of legacy code as users slowly upgrade and migrate their applications to support the changes.

Django in the Community

The last topic of our chat was about Django’s influence in the Python community. I wondered what kept Django healthy and if it impacted development in ecosystem as a whole.

To Simon, a key factor that keeps Django alive is backward compatibility. “Move fast enough, but not too fast,” as he put it. By using deprecation warnings and giving users time, Django has kept developer buy-in.

A second factor of Django’s health that Simon mentioned is the culture that has built-up around the project. Django has a code of conduct that governs all virtual spaces managed by Django, as well as physical events sponsored by the Django Software Foundation. This keeps the community welcoming and inclusive for everyone who participates.

In terms of leading development across the community, the move from Python 2 to 3 was a major accomplishment.

“We decided that we wanted a codebase that was running on Python 2 and Python 3 at the same time,” Simon explained. “It was a good example to show the community that a large project such as Django is able to do this, so move to Python 3 and also support both interpreters.”

Thank You

I’d like to thank Simon for sharing his experience as a Django contributor. Also, a big thank you to the rest of the Django team for their effort building the framework.

If you are interested in taking Simon’s advice and getting involved in Django, check out this listing of ways you can help the project.