Making Django Ready for the Next 20 Years

If you'd rather watch a video instead of reading an article, you can also have a look at my recent Djangonaut Space session on YouTube where I talked about similar topics.

As a member of the Django community for the past 10 years, I've had the privilege of witnessing firsthand the project's growth and evolution.

Over the decade, I've seen many exciting changes and improvements that have shaped Django into the powerful tool it is today.
However, I've also noticed a gradual slowing down of this evolution in recent years.

I have also benefited from said growth and Django's reliability and stability as I have been running a business who's main activity revolves around Django for that same amount of years. Whether it be creating, reviewing, maintining or updating software.
My application to the steering council is one of the ways in which I can give back to the community.

With my candidacy as a member of the Django Steering Council, I want to highlight my focus on ensuring Django remains relevant and sustainable for the next 20 years.

Being respectful of each other's time

Most code contributions merged into Django are bug fixes or cleanups. I believe this trend is not due to an unusual abundance of bugs within the project but rather due to an unsustainable barrier to contributing new features or code improvements. Contributing to Django's growth requires a significant amount of time, mental energy and effort, which can be discouraging to most. And often, those who have bit the bullet and gone through it once do not go through it a second or third time.

Myself and others have noted, more or less recently, that the process of contributing code to Django, including but not limited to DEPs, is daunting. The words "brutal" and "bureaucratic" have been used by myself and others to describe the process.

For starters, I want to focus on making the contribution process more respectful of contributors' time, while maintaining the quality, stability and integrity of our project. By doing so, we can encourage a more diverse range of contributors, including but not limited to those who have less time or energy available for social work and those who's primary language is not English. And ultimately make Django more robust and resilient for years to come.

If elected, I aim to identify areas that hinder effective code contributions to Django and work towards simplifying the process of contributing code to the project; while keeping the right balance to also protect the time, energy and sanity of the Fellows and the review team.

The realities of an aging code-base

As Django approaches its 20th anniversary, it's also worth acknowledging that it's now an older code-base with some amount of technical debt accumulated over time. This has been confirmed to me by someone commenting on the fact refactoring code in Django sometimes leads to unexpected breakages.

This can make it more difficult for new contributors, reviewers and mergers to navigate the code and feel confident about commiting changes.

I believe it's essential to acknowledge this reality and take proactive steps to address it. To that end, one of my goals for the coming 6.x series is to initiate a review process of the existing code-base. This will involve carefully evaluating the technical debt and identifying areas where improvements can be made without disrupting existing functionality.

Alongside this review, we'll also need to invest in adding more comprehensive tests to the existing codebase, ensuring that it's more robust and resilient to change. By taking these steps, we can make Django even more maintainable and easier for developers to use and contribute to.

Missing batteries and deadlines

One of the core principles of Django has always been its commitment to being a "batteries included" framework. However, in recent years, I've noticed that many of these essential features and tools have remained stagnant, without new additions or replacements emerging to support the evolving needs of our community.

This lack of innovation is concerning, as it means that Django's users are being expected to fill gaps with workarounds or third-party solutions. As a member of the Steering Council, I would propose to prioritize identifying the features and tools that are needed to keep Django ahead of the curve. To achieve this, I plan to use my position to champion "feature requests" – a critical aspect of the council's role that has never been utilized to this date. Feature requests being also a key part in being able to set a roadmap for Django and provide guidance to potential contributors on where to get started on their journey.

Furthermore, the third-party application ecosystem that was once thriving and a jewel of the community, has become harder and harder to navigate and discover. It has also become more time-consuming for developers to have to evaluate a large set of third-party applications to solve a specific need.

As a member of the steering council I would like to work on bringing better visibility and discoverability of those third-party packages by working with existing currators of existing lists as well as finding better ways of referencing those lists and packages.

I would also like to evaluate whether any such package should be brought into Django, either Django core or a spiritual successor to contrib or some other way. Some packages that come to mind are django-csp, django-cors and django-upgrade but this is in no way an exhaustive list.

Code ownership and groups

Another important aspect I want to consider is what I call "code ownership" – groups of people who are intimately familiar with one of more specific area(s) of the framework.

My belief is that, as an unexpected side-effect of the dissolution of the core team and the high barrier to contribution, this kind of expertise has begun to erode. However, this can be regained through targeted efforts. People involved in the aforementioned code review process would be perfect candidates for these roles, as they'd already have taken a deep dive in thoroughly understanding specific areas of the framework.

Moreover, frequent contributors to an area of the framework are often well-positioned to take on a leading role in "owning" that part of the project. However, this implies recurring contributions to said area. I believe that we need to find ways to incentivize people to become area specialists. I also believe that people with such inclination to nurture a specific part of the framework cannot be incentivized to do so by mostly "letting them fix bugs" which brings us back to need for lowering the barrier to contribution.

More generally, I think that the project can benefit from those specialized groups, starting with an ORM group.

Closing thoughts

Everything listed here fits in a single article but it is a lot of work to accomplish. I believe that it can all technically be achieved during the 6.x cycle but... things take time in the Django world. So, I don't want to over-promise either.

As the title suggests, my aim for the 6.x series will be to prepare for the futur of Django and set all of this in motion even if everything is not fully complete by Django 7.0