In the commercial software world, user interfaces are generally designed by one group. Like Microsoft for Windows or Apple for Mac OS. Those desktop environments were designed by one company who did things like user testing and statistical analysis to try and make the desktop they thought would work best. Linux is different. Large groups definitely DO perform user testing and statistical analysis, but one group can also say "Here's what we want" and, if they have the ability to code it, their idea comes into being. It's pretty amazing, when you think about it. Linux lets people create what they want. If you don't like what's out there, fork it! Or start from scratch! You're in control!

The biggest problem I have with that is that every added option is added complexity. For the user, for an admin, and for the developer. Every small option requires lots of testing in any non-trivial application. I actually prefer the theory of super simple, to the point of elegant, by default, with a basic (or even advanced) plugin API. That seems to be the best way to get around all of the little things everyone finds issue with in anything a developer does.

The biggest problem I have with that is that every added option is added complexity. For the user, for an admin, and for the developer. Every small option requires lots of testing in any non-trivial application. I actually prefer the theory of super simple, to the point of elegant, by default, with a basic (or even advanced) plugin API. That seems to be the best way to get around all of the little things everyone finds issue with in anything a developer does.

The problem with 'elegant' is that there really is no such thing, because your idea of elegant is somebody else's idea of ass-backwards thinking. The best you can hope for is a set of defaults that will piss off the least amount of people.

As for built-in features vs plugins, I'm not really sure how offering plugin support makes things any easier, for either the developer OR the user. For the developer, instead of having to do a bunch of testing on built-in features every time you change something, now you've got to test a bunch of plugin APIs. And it's even worse for users, because now instead of having to bring up a dialog box or a config file to change option, they must go searching for a plugin to do their bidding, who's code may or may not be thoroughly tested, and the plugin may or may not work when a new version of the app comes out.

The choice between "customizable" and "not customizable" is not a binary one, though. Even Gnome 3 and iOS have a settings panel, and even e17 and fvwm put limits on the amount of tweaking that they allow.

IMO, the solution is that when developers want to introduce options in their software, like for any other feature, they must answer the question : "Will a significant portion of my user base use this ?". Then they should perform telemetry on installed software to see if users actually use the feature after all.

It is sometimes straightforward to answer the question. Everything which is highly dependent on taste, like theming and notification sounds, should be customizable. At other times, it's more difficult to find an answer. But I think it's part of the software design homework.

It is sometimes straightforward to answer the question. Everything which is highly dependent on taste, like theming and notification sounds, should be customizable.

Even that is not always straightforward. For example, Is it really necessary to add theme support for every single app on the system, instead of leaving themes at the OS level where they belong, so that all apps have a consistent look and feel?