The key problem is that the desktop community desperately needs one or more architects who can act as a sheepdog and keep the sheep marching in roughly the same

The key problem is that the desktop community desperately needs one or more architects who can act as a sheepdog and keep the sheep marching in roughly the same direction. It's far more critical in the Desktop world than in the Linux kernel because in the kernel, there is enough development in the kernel that there is strong incentive to develop in the upstream sources, and not behind distribution-specific source trees. In addition, the Linux kernel releases on a regular 3 month cycle. So even if we don't have formal design documents, it's a lot easier for collaboration between key kernel subsystem developers, because our patches have to come together and _work_ every three months when we push out a release. (In practice, they had better mostly work by the end of the two week merge window, or there will be hell to pay, and Linus, as the great benevolent dictator, will yell at people, and Make a Decision --- which will usually involve reverting the change which broke things functionally.) In contrast, the Desktop world has a much harder problem, because (a) not everything lives in one source tree, (b) the kernel largely doesn't have a UI, and there are objective measures of "does it work", and "did the benchmark results go up or down", that either don't exist or aren't as important in the UI world. Questions of whether a UI is "good" or "better" than some other UI choice is a question which can't be easily answered objectively. And that, more than any thing else, is probably why we have three major design centers for desktop development: GNOME, KDE, and Canonical. One of the things that worries me is that all too often, people look at the way things are done in the Linux kernel, and assume that it will port over to their project. In most cases, the Linux kernel is a much larger and more complex project, and things which we do in the Linux kernel world probably aren't needed in other projects. But in the Desktop world, I think the reverse problem is true. It's a much larger and more complicated ecosystem than what we have in the Linux kernel, and so decisions such as allowing the major subsystem developers to negotiate major technical changes organically and informally might work for Linux, but not in the desktop world. (For example, in the storage stack, there are less than a half-dozen people I would need to consult with in order to come consensus about some change to accomodate PCI-attached flash, and we have multiple opportunities a year to get together and work things out). Hence in the desktop world, hiring a full-time architect who did nothing else but talk to the different stakeholders and try to come to consensus on a common vision is probably something which is necessary, even though we haven't found the need to have someone in that role in the Linux development community.