First, I have also seen this x86 arrogance on behalf of the chiefs with platforms such as the PowerPC. Those that work hard on the PPC platform do not receive their fair representation. People love to claim that Linux is extremely cross-platform, but in reality it only exists in a perpetual state of brokenness for many non-x86 platforms. I know that I have had to deal with many problems related to indifference towards the PPC platform.
Some in the discussion have claimed that an organization would merely repeat what is already been done, or would not work as well. This is untrue. The reason that the organization is a better option is a more equal representation of parties involved. In the current system, you've got one or two bosses who frankly are not concerned by non-x86 machines. In a well-designed organization, you've got groups responsible for powerpc, alpha, sparc, etc development. The development will not race off without them.
Additionally, when the social organization is done right, code organization starts looking better as well. For example, take a look at the BSDs, especially NetBSD. They use a distributed structure mechanism. Their entire kernel structure is also more organized. They've got some incredibly cool stuff in there--for example, drivers that are abstracted from the bus. Where we've got particular drivers for this-type-of-card on PCI, and this driver for the same thing on ISA, or for buses on other platforms, they've got one driver for all the different busses. This, as well as a bunch of other interesting designs, leads to a cohesive codebase that -- time for a shocker -- generally works well for each platform involved. Not only that, but they keep each platform maintained and working with a fraction of the workforce required in the Linux dictatorship system.
(Note that in some cases, dictatorships work well. Programming languages like Python are a good example. However, programming languages do not (should not, at least) change with the frequency that an OS does -- no new drivers, no big structural belches, and so on. Operating systems and their kernels do not work as well with dictatorships as with BSD/Debian style nonprofit organizations.)
Some here are equating the organization of kernel development with commercial backing. Erase that thought from your mind, as it is not empirically proven by the other similar organizations out there (Debian, NetBSD, OpenBSD, only recently has FreeBSD gotten involved with BSDi).
Of course, it is unlikely this will happen, because while Linus would not be overly bothered by a fork, he would be bothered by his loss as a 'leader' in the current system. Actually having to expend occasional energy to make sure that all sections of the kernel are operating nominally sure is a pain, especially when it is not a personal concern. (The fact that it is not a personal concern would be acceptable if the responsibility were delegated to someone who was concerned.)
People, the egotistical "coolness" system has got to stop if we want a streamlined, functional, transparent kernel development. It is quite entertaining to endlessly write about it (ESR), but as far as efficiency and functionality of the cohesive unit, it is a flop. There are examples out there of better methods of development -- all it needs is a good look at how they work and a little emulation.