Hacker News Reader

Comment by mixmastamyk | Hacker News Reader

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.

View on HN

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.

In 2019 [0] they only had 2.5 million of total expenses, of which 75% was pycon. So even if everything else was on "outreach" (it was not), that would only be $642,500, which is not "several million a year".

In 2020 [1] 48.1% went to "Packaging Work Group/Infrastructure/Other" (I assume because in person pycon was canceled).

I also checked 2021 [2], which was 32.7% pycon and 31.2% pip etc...

Also 2022 [3], 57.8% pycon, 26.6% Packaging Work Group...

In 2023 [4], 60.5% pycon, and Packaging Work Group expenses decreased to 9.6% because of fastly now provides the bandwidth/hosting: "We are grateful to Fastly for making the online services that the PSF provides possible, so that we can invest time and resources into advancing our infrastructure to better meet community wants and needs."

So your assertion seems to have never been true.

[0] https://www.python.org/psf/annual-report/2019/

[1] https://www.python.org/psf/annual-report/2020/

[2] https://www.python.org/psf/annual-report/2021/

[3] https://www.python.org/psf/annual-report/2022/

[4] https://www.python.org/psf/annual-report/2023/

As mentioned covid changed everything, so please stop pulling figures from that once in a lifetime event.

I have looked at 2018-2016, where the expenses are almost completely the main pycon and more local pycons. Also sponserships like "Pallets group, which maintains projects such as Flask and Jinja" (2018). Everything other than the main pycon is less than 1 million dollars combined in expenses.

I feel it is important to look at the facts, not just vibes.

> Also sponserships like "Pallets group ...

Those are "fiscal sponsorships" meaning the PSF holds money for other organizations. The PSF is not funding Pallets (or Boston Python or North Bay Python, etc, etc). They accept money earmarked for those organizations and provide administrative support. Details: https://www.python.org/psf/fiscal-sponsorees/

Thanks for the correction!

A portion of pycon expenses are spent on outreach and teaching during the event. Arguably all of pycon is outreach. There are dedicated grants, aid, support as well. The 2019 PDF breakdown doesn't seem to be available any longer.

During the 2010s, the packaging group was begging for help. "We're only volunteers," a common refrain: https://news.ycombinator.com/item?id=46605018

During the 2020s, funding for packaging was provided by Mozilla and Chan-Zuck, as PSF wasn't doing enough. https://www.python.org/psf/annual-report/2019/

As we all know, Astral stepped in and solved the problem for them. I moved to their tools as soon as was possible. And not simply because they were fast, but because they work.

For example, here's one that pypa broke for my package a couple of years ago in pip, and never fixed: https://github.com/pypa/packaging/issues/774

> 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/

It seemed pipenv is more than sufficient, why should I use uv?

That's the thing, you don't have to :) While I think uv is a great tool and highly recommend it, you are more than welcome to use any of the other build backends or package management tools that fit your workstyle. By having these packaging PEPs (amongst) others, the ecosystem has been able to try out different approaches and most likely over time will consolidate on specific ones that work better than the others.

Anecdata, but uv served as a very good packaging mechanism for a Python library I had to throw on an in extremis box, one that is not connected to the Internet in any way, and one where messing with the system Python was verboten and Docker was a four-letter word.

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.

They didn't just write the PEP, they implemented them.

Not well enough, I linked elsewhere to a breaking release bug, but there were others. Astral made them reliable, usable, and incidentally fast.

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?

A foundation should invest in its technology first and resist the strong temptation to fund pet projects (of leadership) with donated money.

I'm not sure what you are labeling as pet projects of leadership? Is there something the PSF is doing that you consider a pet project rather than part of their core mission?

Yes, outreach before investing in packaging. It’s not that outreach is bad but that packaging was crumbling.

I'm not sure how you got to "before" here. The PSF runs PyPI, organizes the Python Packaging Authority, supports sprints and standardization efforts, funds developers in residence and so on. Packaging is improving, partly because of those efforts. It's not an either/or.

https://devclass.com/2025/03/10/pypi-repository-takes-steps-...

    > CPython core developer Paul Moore described his involvement in the
    > packaging community and said: “it’s struggling under the weight of its own
    > popularity … the individuals involved are doing their best under what are
    > frankly near-impossible conditions.”

    > Moore questioned whether the fact that so many businesses now depend on
    > Python and PyPI meant that “maybe a purely volunteer basis simply can’t
    > work any more,” though he hoped this is not the case.

Yes, it could use more funding. Glad to see that Anthropic is helping. It's still not an either/or situation. The PSF would not be fulfilling their mission if they only funded packaging until packaging was "solved" (whatever that might mean) and only then did they fund outreach.

I didn't say either/or, and was talking about priorities. One shouldn't install a fancy roof when the foundation is crumbling.

> The PSF would not be fulfilling their mission if they only funded packaging until packaging was "solved" (whatever that might mean) and only then did they fund outreach.

They did the opposite. So they still didn't fulfill it, to the extent that Mozilla, ChanZuck, and astral felt compelled to step in.

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...

Reply on news.ycombinator.com