I both agree and disagree with this, and I think the way you framed it leans too heavily on one side of a much older and more nuanced pattern in the Unix and open source world.

First, where you are right. The “write extensions if you want” model in GNOME does push complexity outward. When core functionality lives outside the main codebase, you introduce fragility. Extensions break across releases because they hook into internals that are not guaranteed to be stable. Maintainers disappear, APIs shift, and suddenly a workflow people depended on is gone. That is a real usability cost, not just a philosophical debate. And yes, it can mask gaps in the default experience because power users patch around them.

But the leap from that to “developers are just ignoring users because of vision” is where the argument gets shaky.

This tension is not new. It goes all the way back to Unix philosophy itself. Unix systems were built on small, composable tools rather than one monolithic environment. That philosophy shaped everything from shells to window managers. The idea was never “give users everything by default.” It was “give a stable core and let people build on top.” GNOME is arguably closer to that lineage than people admit, just with a stricter idea of what the “core” should be.

Meanwhile, projects like KDE evolved in a different direction. KDE embraced configurability and feature richness early on, almost as a counterweight to minimalism. That is why you get the “you can customize everything” feel. But that flexibility also comes with trade offs. More surface area means more bugs, more inconsistent UX, and more maintenance overhead. KDE has improved massively over the years, but the complexity cost has never disappeared, it has just been managed better.

So what you are calling “two extremes” is actually two long standing design traditions in tension. Minimal core versus maximal configurability.

Now, about extensions specifically. Saying they “turn users into developers” is overstated. Most users do not write extensions, they install them. The real issue is not that users must code, it is that the extension API is not stable in the way people expect. And that is intentional to some extent. GNOME prioritizes internal refactoring and UX consistency over long term extension compatibility. That frustrates users, but it is not laziness or indifference. It is a prioritization decision.

There is also a technical reason here. GNOME Shell extensions effectively inject JavaScript into the running shell. That is powerful but brittle. If GNOME guaranteed stability at that level, it would freeze a lot of internal evolution. Compare that to something like browser extensions, where APIs are explicitly versioned and sandboxed. GNOME never fully committed to that model, so you get this semi supported ecosystem that sits between “official” and “hack.”

On the “user research is ignored” point, that is also more complicated. Projects like GNOME do conduct research, but they filter it through a design philosophy that values simplicity and reduced cognitive load. A clipboard manager might be widely requested, but if it conflicts with their model of how interaction should work, they will reject or defer it. You can disagree with that, but it is not the same as ignoring data. It is interpreting data through constraints.

Now let us zoom out to open source history, because this pattern repeats everywhere. In the Linux kernel community, there has always been a strong stance that maintainers decide what gets merged based on long term maintainability, not just user demand. Linus Torvalds has been very explicit about this over decades. User requests do not automatically translate into features if they compromise the architecture.

In distributions, you see similar diversity of philosophy. Arch Linux pushes responsibility to the user, giving you a minimal base and expecting you to assemble your system. Ubuntu tries to provide a more opinionated, ready to use experience. Fedora often acts as a testing ground for newer ideas, including GNOME’s direction. None of these are “correct.” They are trade offs encoded as products.

Even within desktop environments, the idea of “just pick the middle ground” sounds simple but is hard in practice. Middle grounds tend to drift. Either they accumulate features over time and become complex, or they cut back and become opinionated. Maintaining a true balance requires constant discipline and often leads to dissatisfaction on both sides.

Your analogy with ovaries misses that point because it assumes a binary outcome where one side dominates. In reality, the Linux ecosystem already solved this by fragmentation. You do not need one desktop to be everything. You have multiple environments, window managers, and workflows coexisting. The “middle ground” exists at the ecosystem level, not necessarily inside a single project.

Finally, the idea that extensions “cover up flaws” can be flipped. They also act as experimentation layers. Features that gain traction in extensions sometimes inform core design later. That is a common open source pattern. Not everything starts in core because committing to core has long term maintenance costs.

So yes, GNOME’s extension model has real downsides, especially around breakage and dependency on maintainers. But framing it as developers ignoring users while hiding behind extensions oversimplifies a deeper design choice rooted in Unix history, maintainability concerns, and differing philosophies about what a desktop environment should be.

If anything, the Linux world is not lacking a middle ground. It is overflowing with different answers to the same problem. The real question is not why GNOME is not KDE or vice versa. It is why users expect one project to satisfy every design philosophy when the ecosystem already provides alternatives.