Actually it's not at all a democracy. It's a market. There are two different marketplaces, which are distinct. One market is for developer time, and one market is for users. Each of those affects the other. For the most part, developers aren't going to pour huge amounts of resources into a project no one uses. Users can vote with their feet. If enough users are fleeing because of dumb decisions by developers, a fork might happen, or Shuttleworth might back down. See Pidgin/Gaim/Empathy.
The developer arena is generally a meritocracy. If you've shown up and written lots of code, your opinions carry more weight. If you show up and snipe on a list, and never contribute your opinion carries less weight. User's just want code that helps them get stuff done. If you do that by voting, by fiat, or some other mechanism, they generally don't care. So a developer can fork a code base, and that forces them to take on the burden of doing a lot of work. If they can attract more users, they'll generally attract more developers. That's exactly what Ubuntu has been doing to Debian (and most other Linux distro's for that matter, they built the stuff everybody wanted to use, so they have scores of users, which makes developers want to hack on that). Debian still has users and developers doing a lot of heavy lifting in development and testing. XFree86 vs. Xorg was a revolt over license terms by the devs (Thanks Keith P, et al.). A couple of guys decided that what was happening was stupid, and they fled and put up their own playground, bringing over the last copy of the "free" ball. The users followed, and XFree86 has pretty much dried up (I haven't heard anything about it for years). Look at the old gcc vs. egcs and you'll find that the developers got tired of stupidity, and the users followed the best code base (so much so that the "fork" became the "offical" version after the dust settled). Look at Lucid Emacs vs. GNU Emacs, there it sounds like there's enough compatibility that a clear winner/loser never appeared. Look at the various BSD's, they all split off due to various issues. NetBSD was the "original" and wants to be really portable, FreeBSD decided to make the fastest x86 version of BSD they could, OpenBSD was when Theo had pissed enough folks off they told him to go away, and Dragonfly BSD exists because one guy thought that the new threading/process change over from FreeBSD n to FreeBSD n+1 was a bad idea (I think that was 4->5, but it might be 5->6). Linux ran roughshod over all of those mostly because the Linus was much nicer to deal with, and it wasn't a total distribution. All of the various BSD's are total systems, not just kernels. Linux proper is mostly just a kernel. The reason forks are so uncommon especially of large/critical components, is the burden of doing all the work. Especially as a one man band. You have to start gathering a bunch of followers to help, or you'll fall behind the base code base, at which point, you'll have an old version of the software with a tweak or three. Unless you can attract enough folks to pull over the fixes from the mainline code base, or enough developers that the mainline code base essentially dies, you're an island and an evolutionary dead end for the code base.
Some OpenSource groups *MIGHT* run there things are meritocracies, or as oligarchies, and some might run the choices as "democracies", but I believe you're either abusing the term democracy, or you don't know what it really means.
It's a market place, the only question is will this bother enough users to get them to move to a different code base? Will this bother enough developers to get them to fork? My hunch is that as long as there exists a theme that moves the buttons back, most people won't care. I use Mac and Linux, and generally I just don't care. My muscle memory is for them to be on the right, but I got over it. Nobody is going to want to setup all of the infrastructure necessary to do a large scale replacement Ubuntu over this. It's too big, and too much work. If it were something like Pidgin vs. Empathy, it might happen.