"We all make Ubuntu," Shuttleworth comments, "but we do not all make all of it. In other words, we delegate well. . . . We have processes to help make sure we're doing a good job of delegation, but being an open community is not the same as saying everybody has a say in everything."
In other words, just as not everybody has equal input into decisions about the Linux kernel or security, so not everybody has equal input into design. "It may feel less democratic, but it's more meritocratic," Shuttleworth says, evoking the FOSS community's vision of itself as a place where competence is rewarded. "It means (a) we should have the best people making any given decision, and (b) it's worth investing your time to become the best person to make certain decisions, because you should have that competence recognized and rewarded with the freedom to make hard decisions and not get second-guessed all the time."
Shuttleworth admits that the unexpectedness of the design change can be criticized, but, in the end, he firmly insists, "This is not a democracy. Good feedback, good data, are welcome. But we are not voting on design decisions."
This declaration has met with some approval, notably by journalist Brian Proffitt, who argues that "Democracies are great, but they are not well-suited for product production and design. There's a reason why 'designed by a committee' is into a positive label: too many hands on a project with no consensus of direction leads to a pretty crappy project."
By contrast, a user called TuxChix comments on LXer that "This idea is demonstrably false by the fact that we have a thriving open movement to begin with. Where decisions have been made cooperatively, rather than handed down from above. If the 'best' way was subservients reporting to bosses who call the shots, Linux would be a complete failure, and it isn't."
Similarly, the InaTux blog argues that "Democracy is more than just the final decision, it's also about the open discussion of an idea, good or bad. Government legislation is discussed before it's voted on. So is Free Software; even if the people who end up voting on it are Ubuntu's design team, it should be discussed with the community beforehand. Just as legislation is discussed amongst the public and media before it's voted on by the U.S. Senate or Congress."
Shuttleworth has indicated that he is willing to hear further discussion. In addition, by stating that the button position will remain at least for the current beta, he may be implying the possibility of change.
However, by this point, the resolution of the particular issue may have become less important than the larger issues it has raised. The FOSS community certainly expects input into decision-making, but how realistic is that expectation in a project the size of Ubuntu? Moreover, how do they balance that expectation against commercial expectations, or the wish to push change as rapidly as possible?
Similarly, while decision-making by experts may be efficient, the Design Team's authority is the result of top-down decisions, not the meritocratic demonstration of competence to make those decisions. Furthermore, its ability to make decisions is undermined by the apparent lack of usability testing that has gone into its efforts.
Yet, even if the Design Team's expertise is accepted, Shuttleworth's insistence on its right to make decisions is certainly undiplomatic. While community expectations may be partly unrealistic, they still need to be managed. To deny them as bluntly as Shuttleworth does can only excite discontent.
Judging from past performance, Shuttleworth will probably be able to push through the changes he champions. However, no matter how the war of the buttons ends, it highlights the tension between democracy and meritocracy that is central to the workings of not only Ubuntu, but the greater FOSS community as well. Perhaps what matters is not that one tendency should prevail, but that both democracy and meritocracy should co-exist, each compensating for the weaknesses of the other.
One of the ways around the issues of security and control that make some businesses wary of cloud computing is to build a private cloud -- one that remains within the corporate firewall and is wholly controlled internally. Private clouds also increase the agility of IT an organization's IT infrastructure and make it easier to roll out new technology projects. Download this eBook to get the facts behind the private cloud and learn how your organization can get started.