Django's Brightest Timeline

Did you know that we’re in Django’s brightest timeline? One reason is that the process to add new features to Django is in a wonderful state. This is the result of several pieces being put in place over the past few years. Personally, I’m super excited about this, and I hope you are too.

Piece 1: The Django New Features repo

The Steering Council split off the new feature ideas from Trac and the Django forum into a GitHub repo and defined a process to get features into Django. Something the new features repo does is provide visibility to an idea, even if it’s just linking to third-party packages.

After a new idea is submitted, community members can weigh in lightly using the emoji reactions to effectively +1, 0, or -1 an idea. This allows the community to gauge general interest without generating a long “this is a good idea” thread. When an idea has enough support or a lack of detractors, it advances to the next stage, which starts by investigating technical feasibility.

In practice, pretty much every new feature that comes in is met with the question, “Can we make this a third-party package?” The goal here is for that idea to set up a shorter feedback loop from the community so that it can be iterated on and refined.

One reason ideas are recommended to start as a third-party package is to determine their utility. If an idea seeks to improve the DX, that improvement should be tangible. For example, django-extensions’ shell_plus and show_urls are features that were merged into core because they were proven in a third-party package.

The problem with this flow is that it’s really difficult to measure how much a package is used, much less a particular feature of a package. To this point, we’ve relied on testimonials, conversations, and personal advocacy. However, there is a way for us to make this easier!

Piece 2: Django Probe

Django Probe is a Python package that shares which parts of Django a project uses. It inspects the AST in the same way django-upgrade does, but instead of fixing things, it collects what’s being used and shares that to a central repository. It collects three kinds of information:

1. Django class and function usages such as django.shortcuts.render
2. Specific Django patterns that contributors are curious about, such as QuerySet.extra()
3. Dependency, Python, and Django versions

The package is opt-in, and it also has privacy dials that can be configured to reduce how much is shared. Dependencies and usage metrics can be turned off entirely if desired.

The package is intended to be added to CI and run once a month to share information with the Django community.

Being able to see, in aggregate, which parts of Django are being used would be immensely useful when considering changes to the framework. While this isn’t perfect in that it only reports on projects that are in a position to share, it is better than the status quo. It also allows for more fine-grained responses than what the Django Developers Survey collects. It would be fascinating to see the adoption of Django Tasks or async Django across the community.

Which brings me to the next piece. If we can collect which parts of Django are being used, we can see which parts of any package are being used¹, including an experimental Django package.

Piece 3: Experimental Django

Praful Gulani has been working on defining an experimental space for newer features to be explored. He’s been doing this as a Django 2026 GSoC project with Andy Miller as a mentor.

This is a fascinating area, as it would allow us a central frontier to accept more aggressive changes. Praful has proposed putting everything behind a feature flag or setting, which is perfect because Django Probe will pick up that setting usage and report it.

This means that we can see the number of projects that enable a particular feature of the experimental package and track their usage.

If a feature flag shows that a significant percentage of people have adopted it, it means it’s probably a viable candidate for being merged into main.

Whereas if a feature flag tapers off or decreases over time, it’s a candidate to be spun out into a separate third-party package. Which, because it’s already in a third-party package AND it’s behind a feature flag, will be a pretty straightforward effort. At that point, the people invested in it can take ownership of its future.

When the community tells someone to make a third-party package for a small feature, there’s a good reason. Django’s maintainers can’t take on every feature, and someone else may be willing to maintain it in their own package. But we’re also asking a lot. Who is going to add a whole dependency for one small feature, especially from someone relatively unknown? Good ideas can stall there, and Django loses features that probably belong in it.

The problem isn’t that the idea is bad; it’s that people don’t know about it or are unwilling to trust a small, new package.

That’s why experimenting in Django core is appealing to some folks, and why a single package for Django’s experiments is a great next step. It gives small ideas a trusted home, which solves the visibility challenge. It also provides a faster iteration cycle than Django and, if needed, a smoother on-ramp for changes to Django.

Piece 4: Django Commons

The last piece of the puzzle is to further legitimize the third-party ecosystem. Django has been moving to communicate that Django is more than what’s in Django core. It’s the entire ecosystem. This is one of the reasons why the Steering Council created the community ecosystem page. It’s why some features belong as a third-party package long-term.

What Django Commons does is make it easier for the community to maintain those third-party packages. It allows for maintainers to step up and step down as needed. Having the backstop of Django Commons for a package means fewer django-package-2s.

It also provides a framework for the community to align on a community-driven SLA for packages. Django Commons is striving to give all packages basic maintenance; There’s someone to review security reports, update the test matrix for the latest versions of Python and Django, and resolve deprecation warnings. Some of this has already been implemented with our new governance changes.

When a package reaches Django Commons, it already has a stellar set of features. It doesn’t need more. It needs someone to keep the lights on.

Having that level of support for dozens of third-party packages sustainably lets us go from a Django ecosystem to a Django expanse. It’s exciting to consider that we as a community could offer that to the world.

Why does this matter?

Open-source software is undergoing a reckoning with AI. The process of writing software has changed, and we’re sorting out what that means for our processes and community. One aspect of this is that it’s super easy to implement feature ideas. The question is, how many of those features are useful to the extent that they should be packaged up and maintained by the community? Usage data gives us a way to start answering that.

In a more immediate sense, all this work continues to make Django an excellent choice of framework. If you’re an individual or a company considering what framework to build your next project with, it’s appealing to pick the choice with an expanse of features that have the infrastructure to be indefinitely sustainable.

Lastly, this all creates a clearer path forward for people wanting to contribute to Django. By making the third-party ecosystem more robust and standardized and by establishing it as a legitimate way to contribute, it reduces the pressure to put changes into Django, which allows us to spread the maintenance burden across more people. This makes Django more sustainable and appealing, which becomes a positive feedback loop.

That is why we’re in Django’s brightest timeline.

Want to help make this our timeline?

There are a few places for folks to get involved:

• Django Probe - add your project, contribute to an issue
• Experimental Django - Collaborate on the project
• Django Commons - Sign up to be a member

Or maybe you have your own vision of the future that you want to share? Please do. Write about it, post on the forum, present at a conference, or just in general share your ideas.

Django is in an excellent position for the future, and I hope you’ll help build it!