March 19, 2010, 11:26 AM — Design and themes have been a key part of the Linux buy-in for as long as I can remember.
In fact, once upon a time, the look and feel of application was actually used as its primary selling point to me. Back in 2000, at the LinuxWorld at Javitts, I made a comment about some app being very buggy (I don't recall which), to which the enthusiastic developer actually replied, "yes, but look at how cool it looks!"
Yes, well, DeLorians looked cool, too.
While I never thought looks should be the main reason you should try something--and thank $Deity my wife subscribes to that view, too--there's no denying that the design of Linux distributions and their component apps play a role in attracting users. We're human beings, with brains wired for visual stimulus-routines. Pretty->acquire is a very base reaction.
The folks at Canonical certainly understand that. I have watched with some interest as Canonical has put a lot of energy into the design and branding of its Ubuntu distribution over the years. I know that that founder Mark Shuttleworth has emphasized it more lately, pointing out the work his design and interface teams have done, Canonical has definitely highlighted the new Light theme coming out for Ubuntu 10.04 Desktop Edition.
Of course, branding with such ferocity can have its drawbacks. True story: a contact at Canonical sent me links to the new branding package, which I followed. I messaged back: "Huh. It's purple now." The reply: "It's eggplant. Actually aubergine."
Seriously? Dude, I'm from Indiana. If I have to Google the name of the color, my brain shuts down. So if I slip and call the new brand purple, blame it on my upbringing.
My lackadaisical attitude notwithstanding, there are users and developers who get very passionate about this sort of thing. A recent kerfuffle within the Ubuntu community serves as a reminder of that, and outlines a broader truth about open source development.
The discussion started innocuously enough, within Bug #532633 in light-themes (Ubuntu) on Launchpad, where the order of the window controls within the Light theme were requested to be re-arranged to be on the upper right side of any given window. Light, it seemed, now placed the buttons on the left side, similar to the Mac OS X interface.
Pretty soon, the tone of the comments turned into a critique of the positioning to an argument regarding the status of the bug itself, as people in the know stated that this wasn't a bug but a deliberate design decision. That statement carried much more weight when Shuttleworth himself made it.
This quickly shifted the thread to more of a "what were they thinking?" tone, with a lot of reasonable and not-so-reasonable comments on why such a strong design change was being made at all, particularly for a Long Term Support (LTS) release of Ubuntu. Question on the motive behind the decision were raised, and were eventually answered five days later, again from Shuttleworth:
"The default position of the window controls will remain the left,
throughout beta1...
"Moving everything to the left opens up the space on the right nicely,
and I would like to experiment in 10.10 with some innovative options
there. It's much easier to do that if we make this change now. I
appreciate that it's an emotive subject, and apologise for the fact that
I haven't been responding in detail to every comment - I'm busy moving
house this week. But the design team is well aware of the controversy,
your (polite) comments and more importantly *data* are very welcome and
will help make the best decision."
Once the statement was made, some developers seemed satisfied in the response. At this point, this tale could serve as a reminder that quick responses are more appreciated by community members, because if you leave them hanging, they might get too worked up. But, some folks weren't going to let it finish there, feeling left out of the important decisions about design specifically and Ubuntu in general. On St. Patrick's Day, Shuttleworth issued his response to this line of argument, which I encourage you to read in it's entirety and culminated in this exchange:
"It's fair comment that this was a big change, and landed without
warning. There aren't any good reasons for that, but it's also true that
no amount of warning would produce consensus about a decision like this.
"> If you want to tell us
> that we are all part of it, we want information, and we want our opinion
> to be decisive.
>
"No. This is not a democracy. Good feedback, good data, are welcome. But
we are not voting on design decisions."
At which point, the conversation predictably ratcheted up the universal screed scale, as developers felt justified in lobbing hurtful responses, feeling betrayed by such cold comments. Righteous indignation ensued, and the conversation continues.
Perhaps the righteous label may not apply because, at the end of the day, Shuttleworth is in the right here. Ubuntu and a vast majority of free and open source software projects, including the Linux kernel, have never been democracies. They are meritocracies, and any member of a community that thinks otherwise is kidding themselves.
Democracies are great, but they are not well-suited for product production and design. There's a reason why "designed by committee" is not a positive label: too many hands on a project with no consensus of direction leads to a pretty crappy project. Even the Debian Project, regarded as one of the most democratic of the Linux distributions, recognizes this: deciding what stays and what goes is what release managers are for.
Sure, it would be nice if Canonical took into account the contingent who clearly does not like this design change. (Note, by the way, they never ruled this option out, stating they'll look at all data before making the decision before final release.) But evidently, Canonical is sailing towards a longer-term design goal by making this change, and at the end of the day, someone needs to have their hand on the rudder steering the ship.
It's critical to recognize that open source does not bring complete democracy to software development. It never did, and it never should. Ultimately, someone in the developer chain will have to make the tough calls.
Of course, community members should take heart in knowing the converse is also true: make too many wrong calls, and community members are very free to pack up and leave. There's lots of other communities out there.
Follow Brian on Google+
