The thing is, the full level of the demand isn’t being supported on a volunteer basis, and essentially never has been. I personally started using Python professionally on the ActiveState distribution back in 2002 or so, and I believe they were founding sponsors back when the PSF first formed. Python has been shipping with commercial Linux distros since before even RHEL existed (it was still RHL back then). And Peter knows the somewhat turbulent history of the commercialisation of the Scientific Python stack better than I do, so I won’t even try to recap that
Despite the impression we might sometimes get from the plaintive complaints of eager students running into brick walls as they try to pursue do-it-yourself environment setup across various Windows, Mac OS X, and even Linux environments, the practical fact is that the vast majority of current and prospective Python users are using (or going to use) a Python environment provided and maintained by someone else that is being paid to provide and maintain that environment. Maybe they’re in a Windows shop and using ActiveState or Anaconda. Maybe they’re using a commercial Linux distro. Maybe they’re using an academic high performance computing environment. Maybe they’re using a cloud-hosted development workspace instead of doing things locally. Maybe they’re using a bespoke solution put together by their corporate IT department or their academic institution. Regardless of the details, they’re not on their own, and they have local folks to ask for help before they have to reach out to the wider internet, just as most folks running (or otherwise using) Linux aren’t hitting up kernel.org
as their first resource when they run into problems.
Do we want the online docs published on the various python.org subdomains to set people up as best we can to be successful with a completely free (both gratis and libre) set of tools? Absolutely. But we don’t need those docs to be all things to all people.
What they do need to cover is at least 4 main audiences:
- technical info for the upstream contributors actively working on the various collectively maintained tools and libraries, as well as any of their own individual projects
- technical info for the redistributors trying to get different parts of the ecosystem to play nicely together on behalf of their users (hence my recently suggested tweaks to the way we cross-reference some of the specifications from the Python Packaging User Guide)
- educational info for folks using the community documentation as inspiration to produce their own more tailored introductory sessions (whether that’s other community maintained tutorials like Django Girls or Software Carpentry, or more commercial training programs)
- introductory info for folks that genuinely want to pursue their own “do it yourself” journey on their own machine, rather than using one of the many pre-integrated options that are out there
And honestly? I put those audiences in that order not because that’s the overall relative significance of that audience in general. I put them in that order because that’s the relative degree to which PyPA is the only community that can address the needs of that audience.
Folks that just want to use Python can find hundreds of books and websites looking to help them out (and some of them don’t even charge for the privilege). Even folks that want to write updated guides for new versions of tools can usually get a long way with the documentation of specific tools covering already released changes, rather than looking to the overall meta-documentation for the ecosystem as a whole or trying to understand where the ecosystem is headed (more forward looking educators will want to know the latter though, hence this audience making my list).
The folks who can’t get the info and guidance they need anywhere else, though? It’s the folks actively working on tools and platforms that they’re trying to get to play nice together, even though almost all the pieces are being developed independently. When PyPUG fails those audiences, PyPA is the only group that can improve the situation.
For the rest? The Python ecosystem as a whole does not live or die based on the state of its upstream community documentation. Folks definitely get value out of it, and being able to write comprehensible tutorials is a key validation of the current state of the toolset’s overall user experience, but building a personal software development environment from a box of interoperable parts is always going to be harder than obtaining a pre-defined environment from someone else (the pay-off being that the environment ends up working exactly the way you want it to work, rather than being a take-it-or-leave-it set of design decisions that may or may not be to your taste).
And at the technical level, I see three main drivers for ongoing improvements:
- developers of individual tools and libraries looking to develop systemic solutions to problems that end users may not even know they have (the recent PEP aimed at the dependency confusion problem comes to mind, but there are a lot of PEPs and other past improvements that fall into this category)
- folks getting frustrated with UX problems that have their roots in specific underlying technical limitations, and setting out to resolve the latter, so the former problems at least become theoretically resolvable (even if the technical inteoperability fix doesn’t solve the UX problem on its own)
- redistributors looking to collaborate more effectively on the undifferentiated heavy lifting parts of their jobs (like repackaging software for a different build system) so they get to spend less time on that in the future and instead work on other things that are more directly related to the needs of their particular customers
While the folks working on those improvements may formally be volunteers in terms of their interactions with PyPA, that doesn’t necessarily mean they’re pursuing them for free on their own time - there have definitely been non-trivial investments of commercial time in the past decade of Python packaging ecosystem improvements, and that’s unlikely to change in the future.