I'd wager that most people are working towards a home base in the lands they're used to, then go on trips every now and then. Selling your metropolitan home base gets you the permanent beach lifestyle for sure, but permanently removing oneself from more densely populated areas is not for everyone.

The same reasoning may apply here :P

https://github.com/deskflow/deskflow

Yes, and I also think it's important to focus on that part in particular: X11 is not a feature, it's not a user story, it's an implementation detail of the desktop environment / window manager.

There are certainly historical architectural choices that imply many aspects of what X11 can or can't do for the user, likewise with desktops' implementation of the Wayland protocol. The differences between these approaches is real, and substantial.

But in the end, X11 is not a cause unto its own. It's a component in service of the user experience at large. People criticize the removal of X11 support either because their use cases have been affected in some inconvenient way, or because they're afraid of future consequences one way or another.

It's important that desktop environments work on providing the features/UX/quality that users need and expect. It's also important that users tell their DE developers what their needs are, in terms of what problems they are trying to solve, not in terms of which components to use underneath. Choice of component stack is a developer issue and should remain this way.

In the end, the DEs/WMs that solve their users' problems to a high degree of satisfaction are the ones who will retain and gain the most users. Approaches will differ across the Linux desktop space regarding what problems to solve specifically, which problems to prioritize, and how best to implement solutions for them. Dependencies like X11 shape the ultimate user experience one way or another, in terms of features, constraints, development effort, and continuity.

And so do many other implementation choices that need to be made or revised along the way. Ideally most users will end up with DEs/WMs whose development philosophy is aligned with their personal priorities. Friendly bug reporters can help out with the awareness part at least :)

An overwhelmingly large number of people keep saying that socialism is bad, individualism is where it's at. I trust they're right.

Between having to make a living somehow, and not reaping a whole lot of other personal benefits from open source audio development, it takes a very special kind of person to publish these contributions in the first place. Once they're published, generally with its UI defined in code by a developer person, they're not necessarily easy for a designer to edit.

Nor is there much of a steady community around most of the plugins. So many are "publish, feature-complete enough, move on" kind of projects.

As always, be the change you want to see in the world.

Its install recipes directory may yield a less fancy, but probably more comprehensive list: https://github.com/zynthian/zynthian-sys/tree/oram/scripts/r...

With Zynthian OS up and running, the full list of plugins shows in its webconf page, it's so long that they have to hide basically most of the plugins from the main on-device UI.

Roughly speaking, if it's open source, most likely it will work. If it's proprietary, assume that only Pianoteq and a small number of u-he plugins will work. Most commercial products with binary-only distribution don't feel like RPi devices are a large enough market for them to build binaries for it. Even if they otherwise offer ARM builds for Apple Silicon and Linux builds for x86.

Apart from that though, it works just fine on the Steam Deck.

* It will slowly go stale, for example, it may not get ported to newer, increasingly expected desktop APIs. * It will lose users to competing software (such as your proprietary fork) which are better maintained.

As a result, it loses its relevance and utility over time. People that never update their systems can continue using it as they always have, assuming no online-only restrictions or time-limited licenses. But to new use cases and new users, the open software is now less desirable and the proprietary fork accumulates ever more power to screw over people with anti-consumer moves. Regulators ignore the open variant due to its niche marketshare, increasing the likelihood of things going south.

Harm can be done to people who don't have alternatives. In order to have alternatives, you need either a functioning free market or a working, relevant, sufficiently usable product that can be forked if worse comes to worst. Free software can of course help in establishing a free market, it isn't one or the other.

If a proprietary product takes over from one controlled by the community, much of the time it's not a problem. It can be replaced or done without.

If a proprietary platform takes over from one controlled by the community, something that determines not only how you go about your business but what other people expect from you, everyone gets harmed. The problem with a lot of proprietary software is that every company and their dog wants their product to become a platform and reshape the market to discourage alternatives.

MIT by itself does no harm. If it works like LLVM and everyone contributes because it makes more sense than developing a closed-off platform, then great! If it helps to bootstrap a proprietary market leader while the originally useful open original shrivels away into irrelevance, not as great.

He may have contributed in other ways that I'm not aware of, but overall KDE is in a very good spot with many more developers working on stuff.

That said, a few entities are advocating for something like this, e.g. Bruce Perens with Post Open (https://postopen.org) or FUTO with "source first" (https://www.futo.org/about/futo-statement-on-opensource/).

A big hangup with all of this is, who is "us"? Whom do you owe money to?

The original author? What if I end up forking the software without the original authors involved, am I going to do it for free with all the proceeds going to people who aren't working on it anymore?

Or all future contributors? Using which formula to divvy up that money? Lines of code, useful bug reports written, number of tasks triaged, number of tasks resolved, documentation authored, users supported - what determines the relative amount of your contribution? Who receives the payment(s) from $megacorp, can they be trusted to redistribute it among contributors? What happens when the original maintainer / payment receiver steps back or scales back their contributions? How to avoid the divvy-up metric being gamed by people who care more about the money than the quality of the software?

Yes, it's possible; no, "just add to the license" doesn't cut it. This is a much bigger question. How you answer these questions determines whether your project even preserves open source's main (user-side) benefit of forkability.

It's unclear how successful they were with this. Phabricator lasted for about a decade before announcing the end of its development, not all of which was as a stand-alone company. The announcement didn't say why they stopped.

I'd do the math, but it really depends on whether the recent growth holds, accelerates, or slows down again. So, hard to tell.

The increased visibility due to SteamOS/Proton, coverage by various prominent TechTubers, end of Windows 10 support, availability of image-based OS upgrades and Flatpak/Snap to supercede package dependencies, all seem to combine into an actual breakout year comparatively. We'll see if the trend holds or was just a one-off.

Even at this point, Plasma 6.4 has been out for almost two months and 6.3 will not get any more updates ever. While everyone else is upgrading, Debian is going to be stuck on an already unsupported version for another two years or however much.

Debian is great for what it is, but you better hope you don't run into issues with your desktop environment because they will not be addressed.

There's only so much manpower to go around and much of it is otherwise preoccupied now.

The collective system steers into whichever direction was determined by the previous set of steps, with very little potential for any individual actor to turn it around.