> ask why so much engineering time and money is being wasted on [Linux]
Most likely the corporations will say "because that is much cheaper than developing our own; 10 of our devs on Linux an 99% of devs from other corporations are much cheaper than 1000 of our devs on our own OS". And the shareholders will likely accept that.
The key thing is that for most corporations that contribute to Linux, Linux is not the product (except Red Hat, SuSe etc). Google, Facebook, etc, just need a good OS to run their billions of servers on.
> so we can fork when their interests stop aligning with ours
You can fork but you likely cannot maintain Linux as-is. Where do the 1M hours/year come from? That's hard to do in free time.
That is also fine from the perspecitve of Free Software. The 4 freedoms do not include "the program must be maintainable with little enough manpower for people to do it in their free time, free of independence on corporate interests":
The GPL is great in that it gives large power to users of the software, no matter if those users are corporate or personal, and even if the makers of the software are mostly corporations.
> You can fork but you likely cannot maintain Linux as-is. Where do the 1M hours/year come from? That's hard to do in free time.
Maybe a question too radical for Hacker News, but why does Linux need 1M hours/year? How much "worse" would Linux be for the end user if this year, that time spent dropped to 100k or even 10k? And which "type" of Linux user was benefiting most from that time spent (person or corporation)? Why is more automatically treated as better than less?
> The GPL is great in that it gives large power to users of the software, no matter if those users are corporate or personal, and even if the makers of the software are mostly corporations.
Indeed, I respect the wisdom and forethought of Stallman greatly in drafting the GPL.
I think it's a reasonable question to ask, and there's surely some churn that we could do without. But don't underestimate the effort that goes into device drivers.
A. How do you contribute to the kernel in a way that only benefits the contributing organization? That's quite literally impossible in this kind of project. Even the more niche stuff like virtualization support is used by homelab enthusiasts. It's also not like Linux has 100,000 APIs for every customer under the sun.
B. Most of the effort goes into hardware enablement; CPUs, GPUs, power management, etc. Without corporate interests, try running Linux 2.2 from 1999 on a modern PC (which came out just before the $1B IBM investment). See how well it works. Fork modern 2025 Linux, and try running it on a computer that comes out in 2028. See if it even boots. If Intel's only done a minor refresh, it might work; if it's something bigger like the split to P cores and E cores, expect a brick. Even if it does boot, don't be surprised if it crashes, acts unstable, has borked performance, broken sleep/wake, broken audio, broken USB, you name it, it's probably broken.
C. A forked Linux would not have the same level of security research behind it. For example, the Linux 4 era was marked by the introduction of fuzzers and the fixing of countless bugs. A C codebase with handwritten Assembly is rather unlikely to ever become bug-free. How well would your forked non-corporate codebase handle Spectre and Meltdown, just an example, with Google's experts contributing the technique for fixing these problems efficiently (Retpoline)?
D. Added to the above, this isn't a hypothetical: The FSF didn't like the practice of proprietary firmware blobs being in the kernel; so they made their own commercial-interest-free version of Linux called Trisquel. It still uses commercially written code if it's open source; so even it can't be called completely free of commercial influence. The kicker: It runs on almost nothing, and people were complaining about how it works on nothing 13 years ago.
TL;DR: A forked Linux, is a broken Linux, that will never run well on newer hardware, and will quickly become insecure.
> Most of the effort goes into hardware enablement;
Which is why Linux is primarily corporate funded. The corporates want to sell their hardware. To sell their hardware they need to get it running on Linux, so they fund that. As hardware support constitutes most of the code contributions, most of the code that goes into Linux was because corporate actors made a decision to pay for it's development - purely in their own interests.
That's nice - this symbiosis between FOSS and corporates works well for both sides. But it's a stretch to say Linux would not exist today without it. The most you can say for certain is Linux would not have it's great hardware support without it. The BSD's don't get anything like the amount of corporate funding Linux does. They are doing fine, and notably work on common modern hardware. So could Linux even without corporate funding.
In particular, most of the interesting stuff that happens in the kernel, the stuff that determines what the kernel will look like in 10 years time, stuff like adopting Rust, is driven by people scratching itches in the FOSS tradition. Not all of it - pKVM is Google initiative. But eBPF was scratching an itch. Jens Axboe developed io_uring probably as a consequence of wanting storage to run faster at Meta - but it was definitely an itch of his. It's nice that Meta to paid him while he developed it, but saying its creation was "driven by corporate interests at Meta" is a bit of a stretch.
I believe most of this is hardware support, followed by refactoring. The core kernel functionality certainly doesn't change to the tune of 1M hours/year.
Most likely the corporations will say "because that is much cheaper than developing our own; 10 of our devs on Linux an 99% of devs from other corporations are much cheaper than 1000 of our devs on our own OS". And the shareholders will likely accept that.
The key thing is that for most corporations that contribute to Linux, Linux is not the product (except Red Hat, SuSe etc). Google, Facebook, etc, just need a good OS to run their billions of servers on.
> so we can fork when their interests stop aligning with ours
You can fork but you likely cannot maintain Linux as-is. Where do the 1M hours/year come from? That's hard to do in free time.
That is also fine from the perspecitve of Free Software. The 4 freedoms do not include "the program must be maintainable with little enough manpower for people to do it in their free time, free of independence on corporate interests":
https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms
The GPL is great in that it gives large power to users of the software, no matter if those users are corporate or personal, and even if the makers of the software are mostly corporations.