> Saying "no" is the easiest job in the world

It depends on your motivation. Probably a lot (many, most?) committees can just sit pretty and try to do as little as possible. But a lot of software projects exist by getting attention, and they tend to do that by adding features. A lot of FOSS maintainers find it super hard to say no. For some anecdata: I have a small/medium project and I've found that just the energy requirements of really thinking about everything everybody proposes are pretty high. I could just say "yes", but then I'm on the hook. I could also just say "no", but then I'm discouraging people and not really giving them any information about how to contribute productively--this would be something like, "sure we could add a flag to turn video upside down, but I'm concerned that putting this kind of functionality in flags means we'll have a UX of 1000 flags that no one can remember or use; should we start considering building another place to put this kind of functionality?

Your anecdata supports the no part:

> just the energy requirements of really thinking about everything everybody proposes are pretty high

Indeed, that's why it most often results in a no (your ending quote is just a polite way of saying no), and you're right about the discouragement part, and that's one of the reasons forks like neovim appear. (and unfortunately often you can't "motivate" your way into creating enough time for all that extra work either, so with the best intentions... no it is )

> committees are pretty good at it.

I don't know it seems to me that committees are famously bad at it, so that we use "design by committee" for something that refuses to take a single direction and either makes bad compromises or says "yes" to all options.

There are two types of comittees:

Those that are paralyzed by fear of change and say no to everything, and those that are afraid of offending people and say yes to everything. Both are counterproductive.

Reality is not binary, so this extreme simplification is counterproductive when describing one

In your first comment you seem to think that the BFDL for life is not so good. Now you are saying negative things about committees. So what do you think would actually be a good way to run an open source project?

> Saying "no" is the easiest job in the world

On the contrary, saying No to an otherwise great contribution that doesn't fit into the longterm vision of a project for one or another reason is the hardest thing in the world.

I agree, committees are good at saying no. They tend to say no to two not perfect ideas and then force a consensus containing most often the worst aspects of both original approaches. The good news is that the result is so bloated that can‘t be changed and so provides a stable foundation for years of misery.

There are counter examples of course but the power dynamic of committees is not conductive to results that have properties desirable in software.

When I think about the two models, I have Linux as the dictator type and XML as committee designed. Both are functional enough, but the while so few data points are hardly conclusive, I think it's generally indicative.

I'm not a particular fan of XML, even if it's functional enough to get the job done.

Of course you have to find a dictator that is ready to invest all the time and energy to care for a project over a prolonged time and is actually capable of doing so while avoiding to alienate the user base. That's a pretty tall order.

> I'm not a particular fan of XML, even if it's functional enough to get the job done.

XML by itself is okay-ish. The true design by comittee disasters are the specs surrounding it. XMLSignature, SOAP, etc