Some context

Since I'm catching up on LWN a bit today, I thought I'd post a few random things I know about the situation that others might find relevant:

1. Kiraly is no stranger to the politics of the open-source world. He leads the "sktime" project (something to do with analyzing time-series data with scikit-learn in Python), which apparently had to deal with a hostile fork; and in the fallout, he ended up facing Code of Conduct charges filed with NumFOCUS (a nonprofit that supports a lot of scientific-Python OSS development, including Numpy, Pandas, Matplotlib, Jupyter etc. as well as the Julia language and many other things). It comes across to me that his mode of communication in that thread is typical. Personally I think the community is better off for having people willing to levy such criticism, even when it turns out to be misguided or irrelevant.

2. Paul Moore, in my experience, has a gift for understatement and humility. His "close involvement with the packaging community", for the record, is mainly that he is a major contributor to / maintainer of Pip.

3. PyPI, per the PSF's reporting, serves on the order of 600 petabytes of data per year, graciously handled by an in-kind donation from Fastly. If assessed at 2 cents per gigabyte (the going bulk retail rate from CDNs like AWS, the last time I checked) this would amount to a few times the PSF's entire operating budget. It's not at all a small concern, and I would agree it's a good thing that the volunteers maintaining it can have this much sovereignty. But I think we would be much better off if someone could find the resources to staff it properly, and if we could reduce that download burden.

(A lot of things could help: offering slimmed-down distributions for major packages like NumPy, e.g. by allowing tests and documentation to be omitted or making the functionality more modular; enabling better compression methods and writing the standards language to get installers and build systems to work with that; making it easier to set up local private indexes; teaching workflows that don't redundantly download many copies of Pip and Setuptools; figuring out if/why Pip's cachings is being defeated in that regard....)