a) the huge influx of beginners into IT,
b) lots of intro material available in Python and
c) having a simple way to run your script and get feedback (same as PHP)
I say that as someone urging people to look beyond Python when they master the basics of programming.That's not like a widespread/by-default/de-facto standard across the ecosystem, by a wide margin. Browse popular/trending Python repositories and GitHub sometime and I guess you can see.
Most of the AI stuff released is still basically using conda or pip for dependencies, more times than not, they don't even share/say what Python version they used. It's basically still the wild west out there.
Never had anyone "frown" towards me for not using MyPy or any typechecker either, although I get plenty of that from TS fans when I refuse to adopt TS.
I can name an absolute handful of languages I've used that have that flexibility. Common LISP comes to mind. But in general you get one or the other option.
We should applaud their donation today, and at another time assess the meager contributions of many companies that should be shamed.
I've worked at a few that use the 'mold' linker to dramatically reduce their build times. Again, very few contribute. In this particular case, I managed to get one former employer to make a donation.
But the list goes on.
Short arms, deep pockets, as the saying goes.
A more impactful change from firms might be to celebrate and reward community contributions of their own employees. This can establish a more productive culture than just money. If an engineering company is willing to donate money (yay!), perhaps consider making sure that employees are celebrated for contributions they make in a manner that is similar to how we currently celebrate monetary transactions.
For an example of the opposite, Google laid off their entire Python team, something that also made HN front page: https://news.ycombinator.com/item?id=40171125
But also they rely heavily on Python and want to support the ecosystem.
May or may not benefit the community.
One of her biggest projects was shepherding a large group of very old donations through a legal process to remove provisions in the donation agreements that were now illegal. In these cases the donors were long deceased, and the most common rule that needed to be changed was targeting race or ethnicity (e.g.: funds setup to help black people, or Irish, etc...).
The sheer number of different variations on "donor intent", or even just the wording on that legal document was astounding. There was always a tension between my wife's group and the group that was bringing in the money ("stewardship"), her group wanted things to be simpler and the "stewarding" group wanted nothing to get in the way of donations. It was remarkably similar to the tensions between sales and engineering in many software firms.
For example, Wikimedia just recently claimed that they can’t chase some political project that critics wanted them to because most of their funds are earmarked-for/invested-in specific projects. So it does happen with US-based tech non-profits to at least some extent.
> $1.5 million over two years would have been quite a lot of money for us, and easily the largest grant we’d ever received.
Similar story with Mozilla.
[0] https://www.python.org/psf/annual-report/2024/ [1] https://en.wikipedia.org/wiki/Outreach
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/
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?
(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...
https://www.fordfoundation.org/learning/library/research-rep...
The hippies writing that software may not be compensated at the level you'd expect given the value they provide, but they'll never go hungry.
[1] LLVM and Linux get more cash than they can spend. GNU stuff is comparatively impoverished because everyone assumes they'd do it for free anyway. Stuff that ships on a Canonical desktop or RHEL default install gets lots of cash but community favorites like KDE need to make their own way, etc... Also just to be clear: node is filled with povertyware and you should be extremely careful what you grab from npm.
EDIT: or are you rather thinking about the book Working in Public: The Making and Maintenance of Open Source Software?
From a 2022 email:
> (P.S. I have a new last name! Still transitioning everything over, but I’m now Nadia Asparouhova.)
NPM is the other major source of issues (congrats for now, `cargo`!), and TIL that NPM is A) a for-profit startup (??) and B) acquired by Microsoft (????). In that light, this gift seems even more important, as it may help ensure that relative funding differences going forward don’t make PyPi an outsized target!
(Also makes me wonder if they still have a Microsoft employee running the PSF… always thought that was odd.)
AFAIU the actual PSF development team is pretty small and focused on CPython (aka language internals), so I’m curious how $750,000/year changes that in the short term…
EDIT: there’s a link below with a ton more info. This gift augments existing gifts from Amazon, Google, Microsoft, and Citi, and they soft-commit to a cause:
Planned projects include creating new tools for automated proactive review of all packages uploaded to PyPI, improving on the current process of reactive-only review. We intend to create a new dataset of known malware that will allow us to design these novel tools, relying on capability analysis.You might be confusing the Python Steering Council - responsible for leadership of Python language development - with the PSF non-profit there.
The PSF is lead by a full-time executive director who has no other affiliation, plus an elected board of unpaid volunteer directors (I'm one of them).
Microsoft employees occasionally get voted into the board, but there is a rule to make sure a single company doesn't have more than 2 representatives on the board at any one time,
The board also elects a chair/president - previously that was Dawn Wages who worked at Microsoft for part of that time (until March 2025 - Dawn was chair up to October), today it's Jannis Leidel from Anaconda.
Meanwhile the Python steering council is entirely separate from the PSF leadership, with their own election mechanism voted on by Python core contributors. They have five members, none of whom currently work for Microsoft (but there have been Microsoft employees in the past.)
If you missed it, they bought Bun a while back, which is what Claude Code is built in: https://bun.sh/blog/bun-joins-anthropic
According to multiple articles, Anthropic expects to reduce its cash burn to around one-third of revenue in 2026.
This implies total spending is roughly revenue + cash burn ≈ $23 billion + $7.7 billion ≈ $30.7 billion
When you divide the total spending to the length of the whole year, $1.5 million would sustain Anthropic for roughly 0.43 hours, or about 26 minutes.