We are shutting down Ondsel

Sometimes I envy that although I am not a SWE. I work in a field that is so close with the open source and tech scene that we don't have to rely on commercial products like some other fields. It is hard to compete or gain enough interest in some fields of engineering to any open or free solutions.

Perhaps you mean proprietary. Ondsel is after all a commercial project.

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.

>with the ability to print money is the ability to entrench said software, such as heavy investment in software development.

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.

GNOME, several reboots of the audio stack, XWindows versus Wayland,...

FOSS only does well when it isn't the main source of income for contributors.

Wayland has its issues to be sure, but the X Window System was no longer suitable for modern systems; the justification for replacing it was quite sound.

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.

> this proliferation of competitors also shows just how much disagreement there is in the community on this particular matter

It is to be expected that there is a proliferation of different UIs if there is the possibility of making different UIs run on the same OS. The reason is that everybody has a different workflow, different aesthetic preferences, different ways of doing things (e.g.: leaning more toward keyboard, mouse, touchpad, touchscreen). The best thing I remember in this space were the dozen or so X11 windows managers of the 90s. The worst one is the single UIs for Windows and Macs. There are some ways to customize them but not as heavily as it is possible with Linux.

Wayland seems to restrict what's possible to customize but I might be wrong because I have no direct experience. I'm still of X11 because of an old NVIDIA card and frankly I could stay on X11 forever. I know that I'll have to switch sooner or later because of software compatibility. I'd hate to have to buy a new laptop only to be able to run Wayland. It's still good enough to work with me for my customers.

> The worst one is the single UIs for Windows and Macs. There are some ways to customize them but not as heavily as it is possible with Linux.

Which is why Windows and Mac still get native UIs for many desktop products, while Linux if a product actually targets it, gets Electron.

Do they? There's no lack of Electron UIs on Mac and Windows. What's even a native widget library on Mac and Windows today? Do Swift-UI and WinUI (v3 nowadays) count? It's not as clear cut as it was in 2000s.

Yes they do, that is why I clearly mentioned "still".

Native widget libraries is whatever the OS vendor puts on the SDK, and ships on the installers for their compilers.

The large majority of Electron apps that happen to land on Mac and Windows land, usually come from GNU/Linux shops, that also feel like targeting other operating systems, and since that is the solution for GNU/Linux, they dump it into everyone else.

In the process they help Google take over the browser ecosystem, and then talk about how M$ used to be all over the place with IE.

Native widgets libraries were historically those, who were only one that knew, how to talk to the display server. So if you wanted to write another widget library, you had to link to them anyway, to use them as a proxy. That's how Qt, for example, runs on Windows or Mac, using the old win32 api or Cocoa.

But meanwhile, the OS vendors got creative and pumped out a bunch of new, _more modern_ libraries, which have abilities that the old, "system" ones do not have. You want Acrylic design on Windows? Better be satisfied with WinUI -- which, in v3 is the recommended way to write native applications by the platform owner, and which is decoupled from system releases and from Windows SDK.

Electron apps are coming from any shop, that want to throw together some installable, locally running app and figured out, that paying HTML+CSS devs is cheaper, than paying C++ (or ObjC) ones. Having shorter development time is also something positive. It has nothing to do with Linux shops; there are Electron apps, that could be running on Linux if there was a will, but aren't (Whatsapp), or almost-electron-but-edge_webview-instead (Teams).

In 2024, the recomend ways to write GUIs in Windows are Win32 (your native widgets library), exposed by WinForms. WPF has parity with WinUI 3, in recomended way by the platform owner, officially communicated at BUILD 2024.

Doubled down at .NET Conf 2024 during the last week.

Regardless of the GUI framework from Apple, and Microsoft, those are managed bindings to the underlying native APIS (Win32 and Cocoa), which is why they also expose handles to do lowlevel stuff if one so desires, coding like 2000.

Webviews are a different matter, as they don't require shipping Chrome with the application.

It definelty has a lot to do with Linux shops, as they can't be bothered to support GNOME, KDE, Sway, XFCE, or whatever everyone else uses, so Electron it is.

And then they want Mac OS and Windows customers as well.