Whether this suggestion is true, I have no idea -- only strong suspicions. But the point is, neither do the innovators, and they need to find out the truth.
The fact that neither community nor commercial free desktop developers have seriously tried to do so reflects the extent to which free software is still driven by developers working on what interests or concerns them.
The problem is, the days when users of free software were also its developers are long gone, but the habits of those days remain. The result is that developers function far too much in isolation from their user base.
Yet taking users into greater account could create other problems.
Few developers would be pleased by the conclusion that the free desktop is now good enough, and all that is left to do is coding minor enhancements and fixing-bugs.
Innovative coding is simply more compelling than code maintenance. Canonical's One Hundred Paper Cuts -- the project to repair minor annoyances and inconsistencies in Ubuntu -- may be useful and necessary. Yet no amount of marketing can make it as compelling as Shuttleworth's grand vision of a desktop that outdoes Apple's in both form and function.
Even slowing the rate of change to one that the average user can handle would be hard for most developers to accept. Stall or slow development, and developers could start to desert for more exciting projects.
But these possibilities are extreme ones, and would hamstring innovation. The fact that some innovations -- sometimes even most -- are failures does not detract from the fact that others are breakthroughs that users quickly come to depend on. Somehow, innovation and user expectations need to be more balanced.
The trick, I suspect, is to have more usability testing or consultation to help sort out the wanted innovations from the unwanted.
Such testing is expensive and time-consuming, which is why most free software projects ignore it or carry it out on a small scale. It would also require an entirely new aspect of development in most projects.
Even more important, it would require more alternatives in coding. Less popular innovations could still be introduced, but a basic design principle should be that they can either be turned off or easily replaced. KDE 4, I would argue, has managed to outlast much of its initial controversy precisely to the extent that it has incorporated this principle.
Paying more attention to users would not be easy. But my concern is that the alternative would be far worse. Unless desktop developers consult users before building the next cool innovation, the alternative might be endless repetitions of the outcry that greeted KDE 4 -- and that is the last thing that the community needs.