The Google way: Force the rest of the world adjust to your new "cool thing", and then kill it because it wasn't that great.

Google isn't really forcing anyone to do anything in this case. Another RISC backend that was made clear would be ripped out of upstream the instant the Google maintainers stopped responding isn't really an imposition.

The relevant discussion: https://lists.llvm.org/pipermail/llvm-dev/2016-February/0951...

Seems the maintainers were more than happy to accept it, and even had policies in place for such contributions. One maintainer even mentioned it's a good policy because it brings more developers into using LLVM's ToT, which is overall good for project health.

Would something like this be accepted in open source projects that are not significantly driven by Google?

E.g. would Linux accept code for drivers / architectures that are not available to the public? I'm genuinely curious.

> E.g. would Linux accept code for drivers / architectures that are not available to the public?

Drivers is an unequivocal "yes". Here's an example -- from Google, in fact:

https://github.com/torvalds/linux/commit/e561bc45920aade3f8a...

Architectures is less likely. But the pendulum has swung away from "making your own architecture" anyways.

But hey, even with that example, the same mechanism got adapted to Chromebooks+Coreboot and now uses that same driver here:

https://github.com/torvalds/linux/commit/d384d6f43d1ec3f1225...

xcore (mentioned in that thread) is pretty obscure and still in trunk last I looked. Extra backends don't carry that much of a maintenance cost, mostly patching them up on api changes. Weirder targets hit bugs that the common ones don't so there's a benefit from having them in tree too.

I'm not sure that generalises beyond modular compilers though.

Given how ridiculously strict the Linux folks are being with the DXGKRNL stuff that MS is working on (which is public as part of WSLg), I would say definitely not.

I think that has more to do with DXGKRNL coming from Microsoft than any policy that would be applied to other contributers.

Other Microsoft contributions got into the kernel just fine.

And other thin veneers over closed source paravirtualized VM graphics acceleration pipes get in as well, even from companies that flagrantly violate Linux's license.

I think that it's a difference of subtree maintainer as to why some Microsoft code gets in and some is fought tooth and nail; you can't treat Linux developers as a monolith, and the graphics side is significantly more Microsoft adverse.