Would you they rather used these man years to implement it behind closed doors & never release the build?

They use Python. They want to donate engineering time. They think this is a good idea. Why does there have to be a sinister motive?

Calling it a "donation" is even too generous. They use python and would save a lot of money running it (less severs) if it could run multi-threaded. Implementing it themselves and maintaining a fork may be cheaper in the short term but due to ongoing maintenance and third-party extension incompatibility it would likely cost them more in the long run. So they are effectively investing 3 engineer/years of resources to A) ensure the project gets done and B) help it get done faster.

I don't see any charity here, this is just a smart business move by them. When you run as many servers as Meta does being able to run 1/4 as many instances is huge RAM and therefore money saving. It won't take long to add up to 3 engineer/years.

I agree charity is not the right way to frame it. But if this was a pure money decision they would save time and effort forking the language and improving it as closed source.

They have the expertise to run a language fork and because of the scale they run at they would easily save more money doing so. Meta contributing to OSS is not an economic decision. It is about branding, trying to attract technically strong individuals (who tend to contribute to OSS or want to), and sticking to their open culture.

> they would save time and effort forking the language and improving it as closed source.

Actually, experience has shown the opposite to be true. Time and time again even large organisations find their fork falling behind the community version and the pain of merging new versions from upstream grows and grows

They use Python as the basis for instagram, which is a large growing service.

And now Threads as well.

GIL has been a major pain point when training machine learning models, where every library is Python first. The data preprocessing phase must happen quickly enough and in parallel with respect to the GPU operations. The simplest option is doing data processing in several threads other than the one driving GPU operations, but that is not possible with GIL. TensorFlow and PyTorch each has their workarounds for this problem, but many difficulties remain. Removing the GIL will be greatly beneficial to this domain at least.