GNU projects and the free software movement are *far* bigger than one individual.
Demanding people stop using GNU software due to association is just the mirror take of those claiming the FSF can't survive without him.
He is not that important. Hold him accountable.
And I'm not exaggerating here - many of the big alternatives are essentially controlled by Google, and Google pays folks who RT harassment of trans children to work on it.
LLVM has a debugger, but see my above remarks. Autotools lacks a direct alternative because most of what it does is just wrong and doesn't need to be done at all.
Google is far from controlling LLVM. They were contributing a comparable amount to GCC, binutils, etc. back when they still used it and before they'd decided to migrate to LLVM.
The binutils replacements were a lot more focused on macOS and Windows before caring about Linux too.
The libc project fits into the overall ambitions of LLVM beyond Google.
They're very open to incubating those projects and accepting substantial code drops from big companies.
LLD and LLDB are pretty good examples. Originally, it wasn't clear LLD would do serious Linux support.
They have a much different attitude than most projects. They'll accept support for an entire architecture that's not an open platform and can only be used via proprietary development tools. It's a lot more corporate-friendly than even the Linux kernel approach.
That's only the case if it has corporate backing. They won't accept support for archs the community wants that aren't presently commercially viable (IIRC m68k folks hit this).
All I'm saying is Google doesn't have control over the project. They have about the same amount of influence as Apple. For the Linux platform support in particular, they have more influence simply based on doing more of the work than others there, similar to sanitizers/security.
I think it's very comparable to the Linux kernel but with a friendlier and more welcoming approach to proprietary software whether it's a proprietary Sony toolchain, Visual Studio, Windows software using Microsoft C and C++ extensions, Qualcomm DSP stuff, etc.
Google can happily land almost any kind of large sub-project in the Linux kernel too. As long as it's separate from the rest of the kernel and (unlike what LLVM is willing to accept) not entirely dependent on a proprietary software stack, they're probably going to take the code.