If you pay for beach accommodation instead of a dwelling in some higher-priced metropolitan area, sure. As an add-on though, still more expensive.
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.
Apparently it's possible to download a whole load of books illegally, but still train AI models on them without those getting pulled after you get found out.
That's not even the most recent iteration, there's also Deskflow now which is maintained by the main Synergy developer and a very active independent dev. Works fine on Wayland afaik. Also has a wiki page with the history of all the forks!
> To put a positive conspiratorial spin on the recent Wayland push: maybe they think that taking away the option to fall back to X11 will finally get enough eyes on Wayland to fix its remaining issues.
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 :)
Free books for you as an individual, not free for the library and the city backing it. What's in your library still ends up paying authors (and their publishers).
A not-so-insignificant number of FOSS developers are well able to make quality UIs, but decide to charge for their more polished creations.
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.
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.
The Steam client has to restart in order to pick up the newly added external titles, at least last time I tried. In gaming mode, restarting the client means restarting the system, which is ever so slightly annoying.
Apart from that though, it works just fine on the Steam Deck.
It's a little more nuanced than that. Software and gained freedoms survive not because they exist, but because they are being actively maintained. If your original, never-taken-away software does not get continually maintained, then:
* 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.
No. Jonathan was co-maintaining KDE neon, which now has one developer left and is about to be joined by KDE Linux, another take on a Plasma-based distro. He also handled release manager duties, which have been transferred and running smoothly for a few months now.
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.
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.
Phabricator had its task tracker open to everyone, but the company behind it would charge for prioritization of tasks being tackled. If you want your bug fixed or feature implemented before whatever else is on the maintainer's inherent priority list, pay up. IIRC, they also did all development in-house without accepting merge requests from the outside, but I may misremember.
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.
Until monopoly, or until 15-20% when companies start offering widespread Linux support for applications and peripheral management, and retail stores start selling some devices with a Linux desktop preloaded?
I'd do the math, but it really depends on whether the recent growth holds, accelerates, or slows down again. So, hard to tell.
About 4-6% in US and other Western countries, depending on analytics source. Increases in the past year or so by a full percentage point or so. More in India, less in South America, barely any in China.
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.
Bookworm stayed on Plasma 5.27.5 when Plasma shipped bugfix releases up to 5.27.12. Debian may have cherry-picked a handful of patches from there, but that's a lot of bugfixes missed on a release that was already super old.
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.
All of the cloud providers are already in on BSD-licensed Valkey, so which community is realistically going to take over AGPL Redis next time around? The much smaller group of Redict proponents?
There's only so much manpower to go around and much of it is otherwise preoccupied now.
There is no end goal. It's just a bunch of independent actors who are all trying to get ahead of their competitors a step at a time. Two steps if they're lucky.
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.
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.