The fact remains that proprietary software seem to be a license to print money, and with the ability to print money is the ability to entrench said software, such as heavy investment in software development.
This is a uphill battle for open source software, but it seems that open source software tend to keep improving in the long run.
It seems like proprietary software has a big advantage when there's still lots of room for improvement, so that investment in further development pays off.
However, in some cases, there's little room for real improvement, and the thing becomes a "solved problem" for the most part. At this point, the proprietary companies then start enshittifying the software (look at Photoshop, now a cloud-based program) to try to extract more money from users, and to keep users on the upgrade treadmill. Part of this is probably from the way corporate politics work: when you're a manager with a team in place, you need something to keep that team busy, to justify your team's continued employment to upper management, so when you run out of useful improvements to make, you invent less-than-useful "improvements" (e.g., ugly new UIs).
This is where FOSS seems to be able to do well: it doesn't need to waste resources on useless improvements (we'll ignore GNOME for a moment as an exception), and can just focus on delivering the necessary functionality. Once that's done, it can just go into maintenance mode and people can move on to other projects. Until then, it can continue to improve and attract users to switch from the enshittifying proprietary stuff.
FOSS only does well when it isn't the main source of income for contributors.
GNOME I'll heartily agree on. But I've never liked GNOME myself (v1 seemed OK though) and have always criticized that project. I've always been a KDE fan, though admittedly they've had some similar problems and have handled some major changes rather poorly (esp. 4.0). Really, the desktop environments are one place where FOSS hasn't really done that well, frequently re-inventing the wheel for questionable reasons, or adopting questionable new design philosophies. At least there's a fair amount of competition in the space, so if one project rubs you the wrong way, you can try another; this proliferation of competitors also shows just how much disagreement there is in the community on this particular matter.
I really don't know enough about the audio stack changes; I can only guess that they found big problems with older solutions there which required major architectural changes, esp. for certain high-performance applications.
Why when I have my file manager view of a directory open do I need to open it again inside the application to save a file there?
This works fine on macOS in anything that supports it. For example I can drag assets in and layers out of Pixelmator without any issue, drag emails to the desktop or a Finder to save them, etc.
> mostly you can't use overlapping windows because of raise on click
Which can be disabled if it makes sense for that app. What use case are you thinking of here?
> Why when I have my file manager view of a directory open do I need to open it again inside the application to save a file there?
You can drag a directory into the save dialog to jump to it (Windows gets this wrong), and the title heading of an open Finder window is itself draggable, you don't have to exit the directory if you already have it open.
Alternatively Opt-Cmd-C to copy current directory and then paste it into the save location dialog, or Cmd-Shift-G and paste in the location.
My use case is I have 2 applications that I want to drag something between, and the windows overlap
Can you create a new document and then drag a proxy icon to the Finder on MacOS?
This should work for most use cases. If you can see the window for the target app even if you can’t see the drop destination, holding on that window briefly while dragging should raise it to the front (my testing says about 2 seconds). Alternatively (or if you can’t see the target window), the various expose gestures and buttons work during a drag operation. For example on a MacBook you can start dragging from one window, swipe up with your other fingers to reveal all applications or swipe down to reveal just the windows from the current app, and you can drag to the window for your target. From there you can hover on the target and expose will switch to the chosen window after a moment, or you can perform the opposite swipe action while hovering over your target window to raise it to the front.
As for the new document thing if you mean to save a document for the first time by dragging it to a finder window, as far as I can tell you can’t do that. You can drag the finder window to the save dialog but not the other way around.