The Linux kernel is willing to sacrifice the time of individual developers on the altar of project efficiency. That works for the Linux kernel because there are a huge number of prospective developers, and on balance the project doesn't generally care if any specific developer wastes some time or duplicates some effort.
That, by itself, isn't an argument that remote work for a given company will work.
Linux kernel is also famous for a ton of input coming in, of which not a small percentage is discarded. It's quite an expensive model. For any 'normal' software project you have single teams responsible for single features. Not tens of teams competing who gets to create the version which gets accepted.
I'm not saying it's not a good idea to have competing delivery teams. But it's quite expensive.
The Linux kernel as a whole is developed by people who rarely see each other in person, but there are several caveats that make it hard to generalize from that.
* Individual parts of the Linux kernel are often developed by people who do work together in an office (e.g. I used to sit with a bunch at Red Hat).
* Top-level Linux folks do meet in person fairly regularly, especially at LF events.
* Collaboration via email etc. is the primary workflow for the kernel, so there's no in-office cabal that has to learn new habits (and likely will resist doing so).
I'm also tired of hearing how silly startups can't do remote, but I don't think I'd hold up the kernel as an example that they could/should emulate.
A significant part of it isn't though. For example, engineers writing a device driver for a piece of hardware are most likely sitting with each other and near the HW guys.
What is your argument? Those sound like two very different types of product development that I would expect to work very differently in nearly every conceivable way.
My argument is: if a complex project like the Linux kernel, or MySQL, or CMake, or pretty much any large piece of open source software, can be written by remote teams, I don't see what's specific about typical corporate or start-up technology that would prevent that.
Not true at all. In 2017, only 7.7% of contributions were unpaid [1], and it's been dropping for many years: "from 14.6 percent of contributions in 2012 to just 11.8 percent" in 2015 [2]
Maybe I should have been clearer. The payments to the contributors and the targets of their respective companies are not always identical. A team from redhat contributing to the kernel might not be remote and will have their own performance measurement stratergies.