I don't think the problem is the Unix philosophy, which has to do with building focused components ("do one thing only and do it well") that are interoperable w

I don't think the problem is the Unix philosophy, which has to do with building focused components ("do one thing only and do it well") that are interoperable with each other (e.g., Unix pipes). While it's hard to apply Unix pipes to GUIs, component-based GUIs have been explored (e.g., Smalltalk environments where everything is an object and thus composability is built-in, Plan 9 [the acme editor is a great example of how an IDE can be composed from smaller programs], OpenDoc, Microsoft's OLE, COM, and ActiveX technologies, and even KParts and Bonobo in KDE and GNOME, respectively). I think the problems with the Linux desktop are as follows: 1. Think of the sheer size of modern desktops. Think of the large amounts of code that are in the Xorg, GNOME, and KDE code bases. Building a large desktop system that is as feature complete as Windows or macOS will take millions of lines of code when developed using conventional programming languages and tools. This is not a single programmer's weekend project. Even a small team of programmers will need a considerable amount of time building something usable. A counterargument to this, though, is the STEPS project by Alan Kay's Viewpoints Research Institute (http://worrydream.com/refs/Kay%20-%20STEPS%202012%20Progress%20and%20Final%20NSF%20Report.pdf http://worrydream.com/refs/Kay%20-%20STEPS%202012%20Progress...). The researchers were able to implement an entire desktop operating system in just 20,000 lines of code. Perhaps by using the lessons drawn from STEPS it may be possible for one programmer or a small team of programmers to build a high-quality Linux desktop in a short amount of time. In fact, reducing the size and complexity of Linux desktops may lead to a better situation for Linux desktop users. 2. It is difficult to impose a singular vision on something as large and complex as a desktop using bazaar-style development patterns. It's one thing to build a clone of Unix this way; Unix's userland is a collection of disparate tools anyway, and Unix was already a well-studied design by the time the GNU project started. It's another thing, however, to build a brand new environment in this manner. It's no wonder that the best desktop ever to be built on top of Unix, NeXTSTEP and its descendants, was a commercial project led by Steve Jobs. 3. Big software projects require large amounts of resources. Windows and macOS has these resources. The server-side open source ecosystem has many well-funded projects, including the Linux kernel itself. But GNOME and KDE never had this level of investment. This is true of application software as well. Consider the resources devoted to the development of Microsoft Office and the Adobe Creative Suite, and compare that to LibreOffice, the GIMP, and Inkscape. On the flipside, consider how GNU/Linux (the Linux kernel + GNU utilities) successfully competed against proprietary Unices, to the point that some users of proprietary Unix systems downloaded GNU tools because they liked them better than the tools that came with the system. I believe this is one of the key benefits of small, composable tools. 4. Fragmentation may hurt adoption. On one hand more choice theoretically means that it's easier for users to choose a desktop that best fits their needs. On the other hand, fragmentation in an environment where resources are already scarce means sifting through an ecosystem of half-baked, incomplete desktops instead of having fewer but complete desktops. In addition, developers have to decide which technologies to target. If I'm using an existing toolkit, do I pick Qt, GTK, or something else like Electron? Do I target Wayland or X11? 5. In my opinion, churn has also hurt adoption. Sometimes churn is necessary, but this doesn't minimize the disruption for both users and programmers. I still remember the KDE 3 -> KDE 4 and the GNOME 2 -> GNOME 3 transitions and how disruptive they were. I also felt they harmed adoption at a critical time for the Linux desktop. By comparison, Microsoft has bent over backwards to preserve backwards compatibility. Apple is more willing to make disruptive changes, but these disruptive changes usually have a clear benefit (for example, the transition from Mac OS 9 to Mac OS X with all of the modern features the latter had), and Apple tries hard to minimize the impact of these disruptions for both users and programmers. I think the solution to this problem is for the community to adapt to the realities of open source software development with its constrained resources compared to commercial development, and build small, composable software tools that don't require large armies of developers to maintain, preferably in high-level programming languages or even (taking a page from STEPS) domain-specific languages. No one desktop is going to satisfy all users, but smaller, more modular tools are easier to deal with than large monoliths. "If you don't like it, change the code; it's open source" isn't much of a solution when you're staring down hundreds of thousands of lines of C++, but if the desktop were something more akin to Squeak Smalltalk, it would be easier to change it to fit one's liking, even without express support for customization.