Social engineering takeovers of open source projects

I think they are using community to refer to F/OSS projects as a monolithic entity, rather than a million separate and often competing and disagreeing fiefdoms that have always had issues with toxic assholes worming their way into too much power.

There are a lot of dismissive folks who think this is some kind of one-off event because you can't prove it's not- oh wait, the other attempts we can prove aren't enough evidence either!

I understand being wary of America trying to solve this the only way we know how (PRIVATIZE IT!), but dismissing it as a non-issue makes that more likely because you're basically saying you plan on ignoring it rather than putting your own controls in place.

Yes, FOSS projects need to be welcoming to new devs. No, they don't need to pretend malicious actors aren't an issue in order to do that.

You can vet new people, and be welcoming, at the same time.

Is it a different situation? Seems similar to me, except the examples we know about (the obvious ones) are the low skill examples. If someone played the long game like xz and made some helpful improvements to the project in that time, we wouldn’t know about it.

People have also done the same thing (to great effect) on the chrome extension “store” to get all manner of malware into chrome extension updates.

“Nobody unsubtle was successful” tells us nothing about the success rate of subtle attackers. It’s like looking at all the dodgy ssh and http requests any host on the internet is connected to and concluding “yep, 0% of low effort script kiddie attacks get through. I’m 100% safe from hackers!”

The fact that you don't recognize how TypeScript adds a massive number of dependencies into your project is proof of how deeply entrenched the mindset of unnecessary complexity is.

Let's not even dive into the question of how `tsc` relies external dependencies written by third-parties outside of Microsoft (it definitely does). Let's not even talk about how many people are working on TypeScript and how big of a target it is for foreign state actors. Let's not discuss how easy it would be to introduce vulnerabilities into `tsc` due to how well it can hide them inside its mangled JS output. An even bigger issue is that TypeScript forces you to add a ton of dependencies into your project.

Once you add TypeScript to a project, you are essentially forced to use a bundler on the front end. Also, it forces you to add a lot of special add-ons for whatever front end framework you're using. You need special add-ons for testing, e.g. `ts-jest`, you need additional linting dependencies and you need to import a large amounts of external type definitions. You now need 2 config files instead of 1 (tsconfig.json + package.json)... 2 engines instead of 1 (tsc + node). The code you write is no longer the same as the code that's running in production; you're running a transpiled version with incorrect line numbers... Now you may need a special library to manage client-side errors with source mapping. E.g. you may need to install the `source-map-support` module or other or you might rely on third party services to help figure out the source of production errors. Your trusty older version of `mocha` now may not show the correct line numbers when tests fail; also `mocha` is now too slow for you since TypeScript takes so long to build... So you end up using the far bulkier `Jest` instead (and all of its dependencies).

Most devs these days don't even realize that it's possible (in fact, easier) to build fast front ends without a bundler. Browsers can now pre-load scripts easily and it's way more flexible than bundling. With native Web Components, you don't even need a framework these days, you can achieve similar results as reactivity using the `attributeChangedCallback` inside custom Web Components. Many people have been successful with this approach in production environments; it's far more lightweight and less error-prone than React development. It also makes it feasible to share components between different physical web pages and services since you don't need to load the entire React framework to use those components. You can follow DHH (founder of Ruby on Rails) if you need proof that you don't need a bundler.

I'm not sure what you are proposing. You declare cop-out, but then fail to describe a mechanism.

Who exactly would initiate this change? Shareholders? Board members? C-suite? Employees?

What do you propose an initiator should argue to convince colleagues? Why should an initiator spend political capital on this rather than on themselves?

Of course they have the money to give to random OSS projects for no return. What your post lacks is any motivation for doing so.