Brendan wrote:
Note that if you look at the most successful OSs/distros that use the Linux kernel; you'll notice that most of them involve some kind of cooperate governance/structure (Google/Andriod, Redhat/Redhat, Canonical/Ubuntu) that mitigates at least some of (and in Google's case, most of) the "herding headless chickens" problem.
Note also that one needs to separate the Linux
kernel from the various GNU utilities and scaffolding used to make it a working OS, and those in turn from the tools, conventions, and in some cases, shovelware, added on top of
that by various distro developers. No matter what you might think of the kernel - and there is plenty about it to criticize - Linus Torvalds has for the most part kept a very tight rein on it as the (not-at-all-)Benevolent Dictator for Life of the project, and he is infamous for just how ruthlessly he attacks anything he sees as a bad addition to the code base. When it comes to the kernel, it is no bazaar, it is the Cathedral of Torvalds and he makes everyone working on it know it.
In other words, the chaos is mostly in the tools that make Linux usable (to the degree any OS today is usable at all). Now, many of those tools have their own BDFL running the show, or a committee managing them, but the majority of them don't, and more to the point, there is no one at the top who coordinates between them - Linus appears to want as little to do with userland as possible, and seems to dislike even talking to other groups working kernel-space element such as drivers and loadable kernel modules (and when he does, it is usually in the form of an obscenity-filled screed about how they are ruining it for him,
Blue Velvet style), while Stallman is busy being the politician he insists he really isn't, and Raymond is similarly occupied (when he isn't busy building his own cult-of-personality). The problem isn't that the individual projects are mismanaged (though they often are), but that they don't communicate with each other, and there is no one with the clout to make them do so, or at least no one who is willing to take that role.
But that's not even relevant, because the problems in question mostly predate GNU, never mind Linux; most of the issues Brendan is talking about are with tools and conventions which are direct imitations - often bug-for-bug recreations, as can be seen with continued requirement for leading tabs in
make - of tools that were casually hacked together back when Unix was little more than the hobby project of a a few Bell Labs workers. This is what set the tone of later development at Berkeley and elsewhere; the lack of standards came about because no one saw a need for them when they were being written, and while some attempts have been made to retro-fit some on them later (e.g., the 'standard' of using '-h' for the help menu, the addition of things like optget for people to use when re-writing the tools), most of those efforts are hamstrung by decisions made by some guy who came back to the Labs at 3 AM to get some work done after a night of drinking.
Is starting over an option? Well, you can take the Linux kernel and use a completely different set of tools on top of it; it isn't as if that hasn't been tried a dozen or more times before, with Android being the most prominent example. However, Android could get away with it because it had to work in an environment where neither Bash nor X Window System were practical, and the project was being run by a major corporation who were only using Linux to avoid reinventing the wheel for the parts that weren't user-facing - it may use the Linux kernel, but calling it Linux is a stretch. Other projects that have tried it have run aground on the problem of replacing all those tools with equivalent ones, and then getting people to use those unfamiliar tools rather than ones which they know so well that they run them more through muscle memory than by cognitive decision-making.
This is already a problem Linux has, because (to use the allegory P. J. Plauger came up with long and long ago when discussing text editors, back before CUA was near-universal) no duckling who is already imprinted on Windows or MacOS is going to want to go follow Mama Linux into a strange new world of unfamiliar usage models, bizarre thought processes, and criminally short utility names without good reason. Programmers and system admins often have reasons to make that leap, and FOSS enthusiasts might try to, but the average user wouldn't leave Microsoft for a new OS even if it gave them a telepathic user interface, no administrative problems, perfect security, free gold, and frequent sex with their ideal lover, because different is scary. Without the existing user base of Unix ducklings, a new OS built on the Linux kernel but throwing away all the things that make Unix Unix is quite unlikely to catch on, no matter how much better it is.
(Here, too, Android was an exception, as they were looking at a market where most of the ducklings hadn't imprinted yet; while a handful of the people trying it out had used an iPhone or Blackberry already, most of the customers buying smartphones had never set their hands on a computer interface more complex than that of a microwave oven or a DVR before they started using Android - hell, I have heard that in places like Lagos, São Paulo, Manila, Cuidad Juarez, and
Flint, Michigan 
, it is easier to find a smartphone for sale than a bottle of clean water. They had nothing to unlearn, so Google had free rein in making them addicted to their particular flavor of cyber-crack.)
