Tim’s primary  answer, I think, not wrong: good design generally results from having a strong vision of what good design for a particular piece of software should be. “Cult-like” may be overstating it, but good software does need a strong vision, and the holders of the vision need the means to get developers to buy into, execute on, and stick with that vision.

So Tim gets the answer right- but I think his framing of the question is actually a little off, in a way that merits discussion.

The first mistake Tim makes is that when he says “open UIs suck.” This is not false, but it is misleading. The more general rule is that most UIs suck; open UIs are just a subset of that. So implicitly contrasting open and non-open UIs is not necessarily very informative. Plenty of proprietary companies and proprietary design models create and implement lousy designs. Microsoft, of course, was historically the canonical example of this (though Office 2007 and Windows 7 are great strides in the right direction) but Android, which Tim picks a bit on, is perhaps an even better example- nothing about Android’s design and development process is open in any meaningful sense, and… the UI is pretty bad. So Tim’s post would have been much more useful as an analytical tool if he asked “why do most UIs suck?” and then concluded “lack of vision,” instead of asking “why do open UIs suck.”¹

The second mistake Tim makes is the assumption that open projects can’t have strong, coherent vision- that “[t]he decentralized nature of open source development means that there’s always a bias toward feature bloat.” There is a long tradition of the benevolent but strong dictator who is willing to say no in open projects, and typically a strong correlation between that sort of leadership and technical success. (Linux without Linus would be Hurd.) It is true that historically these BDFLs have strong technology and implementation vision, but pretty poor UI design vision.² There are a couple of reasons for this: hackers outnumber designers everywhere by a large number, not just in open source; hackers aren’t taught design principles in school; in the open source meritocracy, people who can implement almost always outrank people who can’t; and finally that many hackers just aren’t good at putting themselves in someone else’s shoes. But the fact that many BDFLs exist suggests that “open” doesn’t have to mean “no vision and leadership”- those can be compatible, just as “proprietary” and “essentially without vision or leadership” can also be compatible.

This isn’t to say that open development communities are going to suddenly become bastions of good design any time soon; they are more likely to be “bottom up” and therefore less vision-centered, for a number of reasons. Besides the problems I’ve already listed, there are also problems on the design side- several of the design texts I’ve read perpetuate an “us v. them” mentality about designers v. developers, and I’ve met several designers who buy deeply into that model. Anyone who is trained to believe that there must be antagonism between designers and developers won’t have the leadership skills to become a healthy BDFL; whereas they’ll be reasonably comfortable in a command-and-control traditional corporation (even if, as is often the case, salespeople and engineering in the end trump design.) There is also a platform competition problem- given that there is a (relatively) limited number of people who care about software design, and that those people exclusively use Macs, the application ecosystem around Macs is going to be better than other platforms (Linux, Android, Windows, etc.) because all the right people are already there. This is a very virtuous cycle for Apple, and a vicious one for most free platforms. But this isn’t really an open v. closed thing- this is a case of “one platform took a huge lead in usability and thereby attracted a critical mass of usability-oriented designers” rather than “open platforms can’t attract a critical mass of usability-oriented designers”. (Microsoft, RIM, and Palm are all proof points here- they had closed platforms whose applications mostly sucked.) Finally, of course, there isn’t just the problem of getting vision- there is the problem of execution. Manpower is always hard, especially when you can’t really fire people, but I think Firefox and GNOME (among other projects) have proven that you can motivate volunteers and companies to contribute to well-thought-out projects once a vision is articulated. It definitely isn’t easy, though!

Tim is not the first or the last person to say “open” when they mean “disorganized,” particularly in the context of UI. It is an easy mistake to make when, well, free software generally feels very rough compared to the alternatives. Free software communities that want to appeal to a broader set of people are going to have to do a better job of  rising to the challenge of this problem, and create circumstances where designers not only feel welcome, but feel empowered to create a vision and feel supported in their implementation.

1. Tim doesn’t help his analytical problem here by not defining what he means by “open UIs”; given that he uses Droid as an example, what he is discussing are “source-available UIs” but given this tweet what he may mean to discuss is “UIs designed from the bottom up”, which are, I believe, a related but analytically distinct thing.
2. The best current example I can think of as a design BDFL is Jon McCann in the context of gnome-shell.

A couple things recently (combined with writing this post the other day) made me think about the difficulties in bringing change to the linux desktop.

• talking with someone about distributor innovation brought up this post by Vincent. Solid post that I mostly agree with (bottom line: distributor changes done without upstream input are doomed to failure) but the comments raise a challenging and difficult-to-rebut counterpoint: distributor changes done with lots of upstream input have a history of being watered down, shouted down, and hence failing to make revolutionary change. Incremental or additive change, fine; revolutionary change, not so much.
• discussion of javascript in the desktop reminded me of Pyro. Obviously Pyro wasn’t perfect, but the speed with which it was shouted down, despite the advantages it might have brought (easy web integration, someone else doing optimization and a11y for us, etc.) was very troubling. To paraphrase what a friend said at the time, ‘developing an online desktop in GTK seems like flying a private jet to an environmental rally- it might be justifiable, but it suggests you aren’t really that serious about the benefits of the new system you’re claiming to embrace. If you really think the web is that great, you have to take Pyro seriously.’ What can we learn from the differences in their receptions?
• discussion in this bug about the Sugar filesystem is fairly typical of what happens when you try to implement radical change- people used to the old system focus intensely on the transition costs (it doesn’t work RIGHT NOW and my old system WORKS RIGHT NOW DAMMIT) and give varying levels of thought (usually little) to the potential upside of the change- maybe tagging and search really have vastly more potential than hierarchies now that our computers have more capabilities than they did in the time of Aristotle. Kudos to the Sugar folks for persisting despite that resistance.

This isn’t to say that resistance to change is always a bad thing. Plenty of people have brought fairly cracked out ideas to the GNOME table that deserve to be shouted down; Sugar would certainly have been helped by better communication about their vision, a strong dash of pragmatism and a better sense of how to pick your battles; and Pyro might have been better received if the presentation at GUADEC hadn’t been frequently described as ‘condescending.’ But there is a theme here- lots of shouting down of new ideas is being done. Sadly, you can even make a fairly good argument that this is the default reaction to new ideas.

For a long time, this problem didn’t matter that much to the linux desktop. There were plenty of problems to solve just to get usable at all, competitors put out shoddy products, innovation by others happened very slowly if it happened at all, and there was no disruptive change in the basic model for delivery of apps. This basic state of affairs lasted for nearly 20 years. But now things have changed- the linux desktop has matured to the point where the answer to ‘what next?’ can at least sometimes be something other than ‘fix bugs’, Apple is doing real user experience innovation, Windows is feeling price and quality competition (say what you will, but XP and Office 2007 are miles better than Windows/Office 98), and the web is simultaneously revolutionizing how people collaborate and how almost all modern end-user software is developed and delivered.

It seems like a critical question for the linux desktop, then, to figure out how to make radical change happen, since our competitors are eating away at our traditional advantages while making radical change themselves. It can’t be just incremental change (gradually improved usability) or additive change (bolt on a11y on top), because competitors are delivering all those things and then some. Freedom helps here, especially in the very, very long term, since end-user modification and individual control are not features that Apple and Microsoft can ever offer, and which web services can offer only with great difficulty. But that is a very long term solution. In the mean time, if you don’t want to just imperfectly clone everything they do and then wait for freedom to work its magic, merely being as easy to use as OS X or as accessible as Windows won’t help- something bigger and more substantive has to change.

The question is how to do this change, given the resistance I’ve already suggested is rampant? I’m afraid I have no magical bullet to resolving this resistance to change, but I have some suggestions:

1. The first one is a non-suggestion. The solution is not to do innovation in-house and closed off from the public. Do it that way, and you have all the difficulties that stem from being proprietary (lack of resources, lack of feedback, etc.) and you’ll never get any of the benefits of being open (free assistance in maintenance, free integration in other products, etc.), since odds of it being integrated upstream are extremely low (for good reasons). ‘I want the PR value’ is also not a good reason; the positive PR value you get from that sort of thing lasts only one release cycle, while the damage to your community reputation is permanent. Obviously some balances must be struck so that we can get ideas from as many sources (corporate and community) as possible, but too often pleas for balance are really ‘I don’t know how to do innovation any other way, so I’m doing it this way, sorry’ in disguise.
2. actively encourage incubation of new technologies. Anyone willing to work on changes in a branch should be encouraged with all the resources we have, and with a serious no-stop-energy policy. Constructive, non-bikeshedding feedback only- those running an incubator should feel completely empowered to ban or mute people who aren’t contributing constructively. There is a time for non-constructive feedback, but that time is at the last possible moment. Think of premature stop energy as premature optimization- the costs are almost always higher than the payoffs. To do it right, you have to understand the problem first, and the best way to do that is to encourage someone to do the design and prototyping and write the code.
3. Move development to git or bzr ASAP. Part of incubation of new ideas is to fork early and often, with tools that lower the barrier to creating and testing changes, and which make it as easy as possible to merge those changes back once it makes sense. (Great to see that Behdad is working on that.)
4. Make testing changes easy. Greg seems to be pushing hard for this in the Sugar space, which will be terrific for them in the long term. Some of the push for jscript in GNOME seems to be driven by the same concern- quicker cycles of iteration mean more small changes, quickly, which helps development of new ideas.
5. Encourage a JFDI culture. Part of the problem with bikeshedding is caused by developers who think they are required to talk about things at great length before doing them. A great developer should be transparent, by publishing as much information as they can while they work, but if you’re well trained and well prepared you need not wait to get public feedback on that information before going forward. The best feedback will still be there for you when you’re done- and likely it’ll be even better in reaction to your work. (Note that transparent JFDI implementation after some early internal design thinking is probably a solid feasible halfway point between ‘do it all in-house’ and ‘do it all in the open.’)
6. Encourage a serious innovation culture. We need to be able to tell the difference between serious innovation (what the web is doing to collaboration and development; changing how users experience games) and ‘innovation’ (ooh! shiny!) It would be great if development as a whole (and linux in particular) started to be consciously aware of the difference- that would go a long way towards resolving the imbalance between the two categories. (We did some of the same sort of thing in creating a GNOME culture around ease of use, so it isn’t impossible, though it has been less conscious of late- which is a definite problem, easily visible in some of the newest UI bits.)
7. develop sustainable design best practices: the practices used by designers tend to be optimized for small, tight-knit groups, and many designers strongly believe that too many cooks spoil the broth. Learning how to do iterative, long-term, expert-driven-but-not-dominated design that can respect and incorporate community-driven feedback would be huge. As best as I can tell, no one really knows what such a process would look like yet. Figuring that out should be an explicit goal for someone- perhaps Mozilla (now that they’ve purchased Humanized) or perhaps a university program in design.

It would be great if this post started some serious discussions of the problem and solutions; I certainly don’t pretend that I’m an expert in innovation or that I’d have all the answers even if I were such an expert. And at the end of the day, the #1 reason there isn’t much ‘serious’ innovation- anywhere- is that innovation is really damn hard. That I can’t solve either… but some of the other issues should be resolvable as well.

[Ed. later: I removed some childishly snide KDE links, and apologize for the snarky tone therein. I do think that KDE 4's 'innovations' are a prime example of confusing 'shiny' with 'innovative', but I should have said that flat out rather than doing it the way I did. Note that that may well be a better way of failing to innovate than complaining about- and killing- new ideas before they ever get to the user; either way I think both GNOME and KDE have a real problem here, which is why I said 'linux desktop' and not GNOME in the title.]

• lazyweb: as previously mentioned, I’ve got a remote control which, to the computer, looks like a keyboard. For an upcoming project I’d like to remap the keys (make the current pgup button ‘n’, pgdown ‘p’, etc.), ideally from a script (so that I can easily turn it off and on) or perhaps from a hotplug event. Still need to figure out how to do that; any pointers welcome.
• firefox: for a while I’ve been using Kiwi Cloak to modify my web-surfing habits (Greg, you might want to check it out) I’ve spent a tiny bit of time modifying it; it is now an XPI (so I can activate/deactivate it separately from the rest of greasemonkey) and forwards to my tasklist when I try to enter a verboten site.
• Tracks: I installed Tracks trunk on my server. I’ve been using the last stable release since some time before law school, and like it a lot. Trunk is more of the same goodness, now with a tickler, which is spectacularly awesome. (Reminder: if you’re working on an alternative file manager, you should really read Getting Things Done and build something that works like that.)
• opensearch: spent a couple hours (during the Clemson-UNC game) yesterday figuring out how to add opensearch to altlaw.org. Still not very discoverable, even in FFox 3, but hopefully will be a nice touch for altlaw when it goes live.
• apple: I went to apple store yesterday to buy a new computer for my mom. The store was packed. It is mindblowing how good their industrial hardware design is- the new keyboard will probably end up following other Ives work into MOMA’s design collection. How is it that no other PC manufacturer has figured out that people want good design and are willing to pay a premium for it? Are they really all that margin obssessed that they can’t figure out that there is a luxury business out there waiting to be seized? (Leopard was unimpressive, other than Time Machine; have already had to hard reboot once in less than a day’s use.)

Back to law a week from today, after (with?) a one-day stop at the Princeton Cloud Computing Workshop. Schedule for the semester looks to be Corporations, E-Commerce, Privacy, Advanced Copyrights, and Telecommunications, but I may tweak it.

“Some may say iPhone [is the most advanced smartphone] but there is no more than great usability … on it.” –Avi

Ah, yes, no more than great usability. Apple will have to content themselves with the $100+ million they made that first weekend, because I’m sure that as soon as the world figures out iphone has only great usability the world will beat a path to a more fully featured competitor’s door.

[Later: Avi counters very well. I shouldn't have called him out specifically; it was just that the quote screamed 'usability is just useless shininess' rather than 'usability is a critical feature which I weighed against other critical features, and which was not enough to make up for the lack of those features.' The first attitude is all too common (not just in open source, but proprietary software has other mechanisms in place to control the tendency which we don't have yet) and drives me up the wall.]

Of course… it turns out OOo doesn’t actually support this yet. What a tease to find that out after 15-20 minutes of mucking with X (which would have been 2 minutes if I hadn’t typo’d xorg.conf.) Blah.

[Ed. later: as Jimmac points out in comments, the latest version of S5 supports this quite well. HFSNW. Now if only theming S5 slides was something mere mortals could do.] 

(You can spit on me or suggest a missing link in the comments.)

[Ed.: I realized later this might have been taken as a commentary on my new job; I actually wrote this post some months ago without posting it and isn't RH-related at all. My summer resolution is to either post or delete all my old drafts, and this is one of the lower-hanging fruit.] 

“You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.”

– R. Buckminster Fuller

Kudos to those who are doing that. (I was going to make a list, but it was longer than I expected- which is great.)

This is the most depressing thing I’ve read all morning.

(It of course could explain something in a way that would be useful to users, but then it would offend one camp or the other, and that would require the aforementioned balls, so it won’t actually be useful.)

(Not that Fedora will be unique in this problem; this may be the most maddeningly stupid screen in all of YaST, and I seem to recall that older Fedora installers had something similar. But at least SuSE has basically admitted there is no way to provide useful information on this choice without pissing someone off and didn’t bother to waste time documenting it.)

(Wow, took me all of one week to have to say ‘this post is purely my personal opinion and does not represent the opinions or policies of Red Hat, Inc., particularly the legal department, who would surely think I’m off my rocker for even knowing what this particularly controversy means.’ :)

(ed. after a shower and some head-clearing: it is of course possible that KDE apps may be best of breed (though I can’t think of any and the first person who says k3b gets their posting privileges revoked), and those should be documented. But if your example is konqueror, you have already lost the game for many reasons.)

(ed. even later: that first link was broken for a while; now fixed, sorry for any confusion.)

(ed. last: the comments are even stupider than I thought they would be (except for joe’s) so I’ve turned them off. If you don’t get it by now, you never will.)

(I shared Kathy’s palpable disappointment at GUADEC when so few people had read the books she cited in her talk; I think it behooves lots of GNOMErs to read something on usability and design other than websites and blogs before GNOME launches into the Next Great Rethink. Research like this that is actually targeted at The Desktop and not just individual applications is icing on the cake.)

• Sr. O’Grady (who it was a pleasure to finally meet last week) has a long post on why the Solaris default shell is silly. It is a good post, and worth reading if for nothing other than his anecdote about who is having problems with the shell. I would summarize it in two sentences: Mom told me that first impressions are important. Did the Solaris people not listen to their moms? (This of course holds true for legal writing too…)
• Librarything has an awesome post on when tags work and don’t work.
• Someone has proposed and bountied a free replacement for .mac. Interesting to keep an eye on- given the requirement that it be free beer, I hope it will also be gpl-free and that it can be integrated with Linux clients as well.
• RecordMyDesktop looks pretty sweet. First person to replace the 2.18 release notes with a good screencast gets a cookie. :) (Thanks for the pointer, Ted.)
• The new WordPress seems to have finally fixed my whitespace problems, and when I did that upgrade, I did lots of other little plugin upgrades, and as a result lots of little things seem to work better now. $DEITY be praised. Now if only gallery (or something similar) were so easy to set up, upgrade, and use- I’d kill for a self-hosted image tool as easy and yet as extensible as WordPress.