Django changes its governance

The Django web framework has come a long way since it was first released as open source in 2005. It started with a benevolent dictator for life (BDFL) governance model, like the language it is implemented in, Python, but switched to a different model in 2014. When Python switched away from the BDFL model in 2018, it followed Django's lead to some extent. But now Django is changing yet again, moving from governance based around a "core team" to one that is more inclusive and better reflects the way the project is operating now.

Django actually started out with co-BDFLs; Adrian Holovaty and Jacob Kaplan-Moss filled that role until they retired in early 2014, which motivated the change to the core-team model. By 2018, some problems with that new model were being felt, so James Bennett spearheaded an effort to change it, which resulted in Django enhancement proposal (DEP) 10 ("New governance for the Django project")—adopted on March 12. Perhaps unsurprisingly, some of the problems identified for Django are sometimes heard in Python circles as well; the changes for Django could be a harbinger of Python's governance down the road.

The core team model relied on a select group of developers (the committers) to make all of the high-level decisions for the project. The BDFL "deadlock-avoidance" role was filled by a technical board that was elected by the committers; the core team of committers was responsible for all of the changes to Django. Around the same time as the governance change, the Django Software Foundation (DSF) started hiring "Fellows" to manage a lot of the day-to-day maintenance of the software and project; it turned out that the Fellows ended up doing most of the actual commits. As Bennett put it back in 2018:

So the proposal is to eliminate the core team entirely, which will have minimal to no effect on the project, while recognizing all of the existing and former core team members under the honorary "Django Core Developer" title. The technical board will still be there to break ties and such, but it will be elected differently. From the announcement of the change, also authored by Bennett:

To replace the job of committers, at least as it was originally envisioned, there will be two new roles: merger and releaser. Both roles will be filled by the current DSF Fellows, Carlton Gibson and Mariusz Felisiak; the technical board will appoint a few more people to those roles. The role names are fairly self-explanatory; mergers will merge pull requests that have achieved rough consensus, while releasers will be empowered to actually create Django releases and make them available in the Python Package Index (PyPI) and on the project's home page.

For the most part, the changes are, in fact, not really changes at all. They are simply recognizing how the development work has been done of late and formalizing it. But removing the perceived barrier of needing to be a member of the core team—thus opening up Django development to more people—is clearly the main driver for the change. The development process was working just fine, but the formal governance structure had not quite kept up; in effect, the core team idea simply outlived its usefulness:

The reaction has been somewhat quiet, perhaps because the idea has been floating around without any real opposition for more than a year. It did require that four-fifths of the core team, the technical board, and the DSF board all approve the measure, so it is pretty clearly uncontroversial overall. Kaplan-Moss was certainly in favor of the change, noting that a more democratic process was needed when he and Holovaty stepped down, but there are other considerations now. "This time our main obstacle is inclusion; to grow further we need a broader talent pool. I believe this change will get us there (or at least take some good steps in that direction)."

The belief that it requires "superhuman" powers to become a core team member has reared its head in the Python project along the way as well. Committers or core developers have evolved over time into a much more bureaucratic role; in the early days of many projects, a "commit bit" meant that one could add code to a project with impunity, or nearly so. These days, for Django, Python, and lots of other projects, committer simply means "the one who has to actually make the merge happen" in a mechanical sense. The decision-making process for those projects is handled separately.

It is also true that both Django and Python are mature projects at this point; there is much less of a "wild west" feel to their development these days. That may also be contributing to less interest in their "core development" in general. But both projects (and plenty of others) need an ongoing maintenance crew, for features, bug fixes, security problems, and so on, so it makes sense to try to ensure that those with an interest realize that they can actually fill those roles. People with a long-term outlook that will keep the best interests of the project to the fore, not necessarily some massive amount of technical know-how, is what will keep the projects going over the next few decades—or far beyond.