Poor management has played a role. They refused to invest in packaging to the extent that a separate company (astral) had to do it for them. Bugs closed for years with the excuse “we’re only volunteers.” Meanwhile, “outreach” was funded for several million a year. Not confidence inspiring. Maybe would have improved if the funds had been spent more appropriately.
Where are you getting these numbers? Looking at the PSFs Report for 2024 [0], 50% of their expenses went to pycon. Would you consider that outreach? I believe conferences are very important as part of the health of a language, and reading the definition of outreach[1], I would not classify the conference as that. The second highest amount of expenses (27.1%) went to (surprise!) "Packaging Work Group/Infrastructure/Other", i.e. pypi, pip etc... "Outreach & Education" was only 2.8% of 12.9% of expenses, i.e. 0.3612%, which is $17846 (actual dollars, not thousands like in the report.)
The assertions above are my memory from pre-covid, I’d look at 2019 and before perhaps. Many things changed after that (and council too) but it takes a while to change perception.
> They refused to invest in packaging to the extent that a separate company (astral) had to do it for them
uv didn't just happen in a vacuum, there has been lots of investment in the Python packaging ecosystem that has enabled it (and other tools) to try and improve the shortcomings of Python and packaging.
There's PEP 518 [1] for build requirements, PEP 600 [2] for manylinux wheels, PEP 621 [3] for pyproject.toml, PEP 656 [4] for musl wheels platform identifiers, PEP 723 [5] for inline script metadata.
Without all this uv wouldn't be a thing and we would be stuck with pip and setuptools or a bunch of more bandaid hacks on top making the whole thing brittle.
Obviously, but writing PEPs is not enough. Read through the comments under any Python thread here from the late 2010s to early 2020s. Just ~two years ago you couldn't talk about anything Python-related without discussion veering far offtopic to complain about packaging.
I don't know much about the Linux Foundation if I'm being honest, even though I've been a 24/7 Linux user for decades, but they seemingly don't have the same image in the ecosystem, at least not close to how people see Mozilla today.
Why is that? Is there lessons to be learned from the Linux Foundation how to actually effectively and responsibly manage that sort of money, in those types of projects?
The Linux foundation is not a nonprofit. It is registered as a 501c6, basically a business consortium, unlike the Python software foundation which is a nonprofit (501c3).
The Linux foundation also stewards way more foundations and projects that just "Linux". They are, among other things, in the business of creating foundations and making money that way. For every organization under the Linux foundation, say the CNCF, to be a part of those subprojects, you need to pay a Linux foundation tax.
The Python Software foundation I don't know much about but their scope seems to be only stewarding python. They seem to have far less corporate outreach then the Linux foundation.
Linux Foundation 990 - note page 16-17 with the salaries - there are for profit entity salaries, not nonprofit salaries.
As far as I'm aware, Python was only recently (2020s) taught in most schools, so that's the reason it wasn't and isn't well funded. Schools will stick with legacy languages far beyond their market lifetimes, as that is what the instructors know best. So it's not that it isn't well funded, it's that it's still early in terms of global popularity. As we just witnessed, the funding is just now coming in big drops.
Poor management has played a role. They refused to invest in packaging to the extent that a separate company (astral) had to do it for them. Bugs closed for years with the excuse “we’re only volunteers.” Meanwhile, “outreach” was funded for several million a year. Not confidence inspiring. Maybe would have improved if the funds had been spent more appropriately.
Similar story with Mozilla.
Where are you getting these numbers? Looking at the PSFs Report for 2024 [0], 50% of their expenses went to pycon. Would you consider that outreach? I believe conferences are very important as part of the health of a language, and reading the definition of outreach[1], I would not classify the conference as that. The second highest amount of expenses (27.1%) went to (surprise!) "Packaging Work Group/Infrastructure/Other", i.e. pypi, pip etc... "Outreach & Education" was only 2.8% of 12.9% of expenses, i.e. 0.3612%, which is $17846 (actual dollars, not thousands like in the report.)
[0] https://www.python.org/psf/annual-report/2024/ [1] https://en.wikipedia.org/wiki/Outreach
The assertions above are my memory from pre-covid, I’d look at 2019 and before perhaps. Many things changed after that (and council too) but it takes a while to change perception.
6 replies →
> They refused to invest in packaging to the extent that a separate company (astral) had to do it for them
uv didn't just happen in a vacuum, there has been lots of investment in the Python packaging ecosystem that has enabled it (and other tools) to try and improve the shortcomings of Python and packaging.
There's PEP 518 [1] for build requirements, PEP 600 [2] for manylinux wheels, PEP 621 [3] for pyproject.toml, PEP 656 [4] for musl wheels platform identifiers, PEP 723 [5] for inline script metadata.
Without all this uv wouldn't be a thing and we would be stuck with pip and setuptools or a bunch of more bandaid hacks on top making the whole thing brittle.
[1] https://peps.python.org/pep-0518/ [2] https://peps.python.org/pep-0600/ [3] https://peps.python.org/pep-0621/ [4] https://peps.python.org/pep-0654/ [5] https://peps.python.org/pep-0723/
Obviously, but writing PEPs is not enough. Read through the comments under any Python thread here from the late 2010s to early 2020s. Just ~two years ago you couldn't talk about anything Python-related without discussion veering far offtopic to complain about packaging.
2 replies →
It seemed pipenv is more than sufficient, why should I use uv?
2 replies →
I don't know much about the Linux Foundation if I'm being honest, even though I've been a 24/7 Linux user for decades, but they seemingly don't have the same image in the ecosystem, at least not close to how people see Mozilla today.
Why is that? Is there lessons to be learned from the Linux Foundation how to actually effectively and responsibly manage that sort of money, in those types of projects?
The Linux foundation is not a nonprofit. It is registered as a 501c6, basically a business consortium, unlike the Python software foundation which is a nonprofit (501c3).
The Linux foundation also stewards way more foundations and projects that just "Linux". They are, among other things, in the business of creating foundations and making money that way. For every organization under the Linux foundation, say the CNCF, to be a part of those subprojects, you need to pay a Linux foundation tax.
The Python Software foundation I don't know much about but their scope seems to be only stewarding python. They seem to have far less corporate outreach then the Linux foundation.
Linux Foundation 990 - note page 16-17 with the salaries - there are for profit entity salaries, not nonprofit salaries.
https://apps.irs.gov/pub/epostcard/cor/460503801_201812_990O...
A foundation should invest in its technology first and resist the strong temptation to fund pet projects (of leadership) with donated money.
6 replies →
As far as I'm aware, Python was only recently (2020s) taught in most schools, so that's the reason it wasn't and isn't well funded. Schools will stick with legacy languages far beyond their market lifetimes, as that is what the instructors know best. So it's not that it isn't well funded, it's that it's still early in terms of global popularity. As we just witnessed, the funding is just now coming in big drops.
MIT was already using Python by 2009[1]; I think it's been one of the "standard" teaching languages for well over a decade at this point.
(By most metrics, Python became "big" in the mid-late 2000s, which is why the Python 3 transition was so painful.)
[1]: https://www.wisdomandwonder.com/link/2110/why-mit-switched-f...
For many of us the language itself has been feature complete for decades.