Comment 22 for bug 882274

> > Customization comes at a cost for those who don't want it. Every option
> > adds a cost. Adding all the options everyone wants results in software
> > nobody will like. The balance is not going to be liked by everyone too.
> > Accept that.
> I can't! :) I can't understand the costs of adding an option in these
> cases. Could you (or someone else) tell me how the users that don't use
> this feature would be affected?
> > This is not an option I want to carry in the codebase.
> Again, it's a no without a why. :) "I don't want this" doesn't look
> reasonable to me. But as you said, you carry the day in these cases.

Actually it's not a "I don't want this," it's a "We don't have the time and resources to deal with problems that happen with this option when we make updates later on." The problem with making an interface that is infinitely customizable is that any time you make an update you have to check *every* one of those combinations to make sure something doesn't break or become unusable for the group of people who choose that particular combination of options. This takes valuable resources away from dealing with other problems which may be just as high priority and slows down the process of innovation, unless you drop support for these options in which case you have a minefield of options which randomly make the interface useless.

At least that's what I think Shuttleworth is saying here. And it makes sense, to a degree, that limiting options makes supporting the few options you do have much easier and more efficient. I'm not sure it necessarily applies in all the cases that we've seen the heavy-handed, "We won't fix this, so buzz off," response we've seen on many bug reports, but it does explain one of those tricky bits of Unity design philosophy that hasn't come through to most users.

I think many of us really want to see a document that outlines the reasoning behind these "design decisions" that are being made without community input. Obviously I think a lot more of us would like to have some input on changing those philosophies and goals, but many would at least settle for knowing what they are. I'm a little surprised such a document is not available already; surely the design team itself has agreed to the basic principles under which they are designing Unity? Or does everything have to go through Shuttleworth's Mother-May-I before being implemented?