Creating canonical Django packages

Yesterday there was a fairly lively discussion on Mastodon started by @adamghill prompted by talks from LaraconUS. I jumped in with a few opinions, of my own, noting what Laravel as a framework does possibly differently and possibly better than Django.

Laravel takes a neat trick of marketing features of the framework (and certain third party solutions) as products in their own right. This is done by giving each feature a distinctive name and pride of place in the top navigation under 'Ecosystem'. Some have a well designed landing page to call home and a reasonable domain name, others are simply a link to the docs.

Each of these packages/features/products are a battery in building a modern day web application, meeting a fairly common pain point that exists for pretty much every developer and also providing a guide for what we need to include in a project at some point.

What can we as the Django Community learn from this? There are a few points that come to mind:

1. Know the audience we are targeting with the home page of djangoproject.com and related pages
2. Recognise which batteries we are missing from core or in general. To be 100% clear I am not saying we need to add these batteries to core.
3. Recognise when a package has 'won' for the moment.

Where does this leave us with creating canoncial packages for Django? To me, it is about bringing a sense of cohesion to the ecosystem, allowing newcomers to navigate what's available to get something shipped. This doesn't mean there cannot be overlap (Laravel has this) or changes over time as community opinion changes. What it does mean is us as a community recognising that we get to a consensus on what to recommend in terms of packages that complement core and give them the resources (eg a sub domain) and position they deserve.

However the next step to me is answering point 2 above, we need to identify which batteries are missing, then identify which packages fit the need. (Forum post incoming!)