The problem is that ARM is a licensable architecture, so there are lots of minor variations in sub-architectures.
The companies maintaining these have no motivation to consider the problem of maintaining /all/ of these, they're happy to basically copy/paste some other code until their CPU work.
Linus is saying that that's not going to work anymore, that they're going to have to come up with a way to consolidate their codebases.
That's probably the right solution, but it's a hard problem. NetBSD is probably the kernel that goes to the most effort to make clean, modular, orthogonal abstractions across hardware families and components, but it took them a lot of design effort up front, and continual policing of the abstraction boundaries and debugging of weird variants to make things actually work that way.
I don't think it's any coincidence at all that the most successful open source effort ever is the same one where there is the greatest force of personality in charge, who insists on maintaining top-down control. I'm not convinced that lateral organization between developers can ever work very well.
This is quite the opposite of what he insists on. He insists on good code, not control. He maintains control because of the former. He went so far as to design git to avoid top-down control and make sure that anyone can fork the code at any time.
The funny thing about the ARM "blow up" is that all the ARM devs for the most part agree with him. Things needed to change, he knew it and they knew it. He just provided the push.
Besides your hyperbole "most successful" I point to FreeBSD for a quite successful open source project which is not controlled top-down by one person. Apache httpd (or other apache projects) also come to mind.
While some of those 84 Top Level Projects aren't well known, many of them are the standard implementation used in their respective places -- and many of them have strong communities years after their project started.
I think Apache is important in this sense, because its building up new projects with similar community expectations, rather than just being held up as a 'good way' to do things.
While the FreeBSD people didn't have their momentum to market themselves in a way Linux community had, they still manage to produce better system.
The other thing is that most people, even who consider themselves OS hackers, don't need such sophisticated and cohesive system. Or they don't have an opportunity to really dive in to see the difference.
You can't really compare the two. If you want to compare you'd have to look at GNU/Linux.
Attributing that success to just the genius of Linus goes a bit too far.
If you include the personality-driven schism between FreeBSD, OpenBSD, and NetBSD, it's not so clear the 'core-team' maintainer model works so well. That's what Ted Tso was warning the Linux community about back in '98.
What personality-driven schism? (I'm serious: you could reasonably argue that the OpenBSD/NetBSD split was personality-driven, but to the best of my knowledge, FreeBSD has no personality conflicts with either.)
Singling out Linux as the most successful open source project is not literally true in my opinion. It is successful, other projects are successful too - how do you want to determine "most successful"?
for the sake of just finding a counterproof to something I agree with: maybe perl for the second?
There is basically no *nix without perl (I recall it was also part of the MS build system for rotor), it has influenced basically every programming language in the last decade and it's been a dependency of the linux kernel build for a long time, though I seem to recall it's now removed :)
This explanation, while popular, always seems to willfully avoid taking social capital into account.
"There's there door, you can leave any time" isn't an answer to the people who are invested in a community and actively seeking ways to ensure its success.
There might be comparable forks to Linux out there right now. Does anyone switch? No. Linux is the windows of Unices. You can't dethrone it just by coming up with a better fork.
There's a difference between being slightly better than something that's still satisfactory, and being good in comparison to something that's no longer satisfactory. Look at X11: everyone used XFree86, even though forks were possible—until they decided to go in a direction people didn't like. Then people started using X.Org pretty damned fast.
That was something of a palace coup, though--- x.org wasn't really an upstart fork, but a secession of a large portion of the XFree86 core team. They also managed to get the X Consortium to hand over the old x.org domain to them and bless their version as the new official reference implementation, which cemented their new status.
While I agree with what you are saying, your analogy is not completely accurate. Switching GUI is nowhere near switching the kernel in terms of risk and the hassle that might come with the change. The main reasons for inertia are the linux servers and the development stack that's built on top of linux servers. Most deployed Linuces have neither X.Org nor XFree86 installed on them.
The kernel is already evolving constantly, and a major version upgrade has to be thoroughly tested before rolling it out on a production system. A fork won't be that different - if Linus switches the license tomorrow, most kernel devs will just move to the forked codebase.
A license change is a bad example. Nobody can switch the license for Linux. It has always been GPLv2-only, you'd need the approval of all contributors to the kernel to switch.
Of course there is also a limit in our time about how much the kernel community can grow.
That limit probably increases somewhat asymptotically to the human population. The actual kernel community size will probably increase slower, though. I think that increase is lower than the increase of how development in IT will simplify things.
I.e., if my assumption stays true, there wont be any problem.
Like Windows, Facebook, and others; it is the platform that makes Linux scalable. With that being, we'd like to create a platform for other developers to collaborate and develop their own.
The companies maintaining these have no motivation to consider the problem of maintaining /all/ of these, they're happy to basically copy/paste some other code until their CPU work.
Linus is saying that that's not going to work anymore, that they're going to have to come up with a way to consolidate their codebases.