[defrex]

Multiple configurations are a maintenance burden. So, all else being equal, it's better not to have them. That said, not all else is equal, and configurability can indeed increase the user experience. But if your defaults are so good that very few people take advantage of the settings, you're better off dropping them.

[bityard]

At what point does user experience trump the ability to use the software at all in the first place?

UX designers are often seduced by reductionism because it makes their lives easier and combined with various hand-wavy aesthetical rationalizations, proceed to ignore several immutable aspects of reality:

Developers of an open source project usually have little insight into how their project is actually being used out in the real world. They only know about their use cases and (if they're lucky) that of their co-maintainers and bug reporters.

If at some point in time, an option was added to make some piece of the project do "x" instead of "y", it is overwhelmingly likely that the option _was put there for a very good reason_. Just because you don't know the reason doesn't mean one doesn't exist.

If the project has more than a few dozen users worldwide, then it is extremely likely that for every UI widget, command-line option, or configuration setting, there is a non-trivial subset of users who rely on that thing being there for their workflow. Remove it, and at best you lose those users. But more often you make them angry as well.

When looking at others' code and designs, it is a very human trait to assume that the person who created it didn't know what they were doing and that the way _you_ would do it is better. I get this and I fall into this trap more often than I would like to admit. _But it is almost always wrong_. We often look at the code in a vacuum and don't see the context under which is was written and why it is still there.

I've watched this happen time and time again with various open source projects: Person (or team) creates a successful project, maintenance of the project shifts to a new person or group who decide that the old project was "unmaintainable" and decides to a ground-up rewrite into what they _think_ is going to be a better version of the same thing. When in reality, all they have done is written a new, far less useful version of a somewhat similar thing.

Citation: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

[eitland]

Yep. We mostly agree it seems.

Problem is, as the author notes: developers loves to work on these features.

I also don't have a problem with devs cutting down unmaintainable mess.

My problem is with this general idea that a designer should come in - especially in open source projects - and decide what is and isn't useful.

I also guess that some of the problems one see when designers try to join open source projects might be related to this.