The company/organization/government capable of making the robot wouldn't hand it out to random people, and would instead reap the paycheck by themselves.
There are a handful of these companies out there. Collabora, KDAB, D. Richard Hipp's SQLite company, and if you're lenient enough you could also include companies that productize their open source package such as NextCloud or The Qt Company. Heck, Red Hat (sorry, IBM) regularly gets pulled in to improve software across their stack, kernel or otherwise.
You could also include non-profits like the Linux Foundation, Blender Foundation or (new!) Godot Foundation, which do the same thing but without having to disguise as consulting, because development of the software itself is important enough to the industry that can pool its resources by donating to the respective foundation.
Still only works for important enough packages. I don't think there's a way around that. An open source project generally has to provide massively outsized value so that a handful of developers can capture a fraction of that value for paid maintenance.
Speaking for KDAB, only a relatively small fraction of our overall revenue is paid work on open source codebases. We mostly get paid to work _with_ Free Software and to teach it to people. Living off of maintaining or improving Free Software is only sustainable for freelancers or small boutique companies. Even the big foundations don't fund all that much development, they mostly focus on governance, infrastructure and promotion. The Linux kernel is possibly an exception, in terms of feeding an appreciable number of people working on it professionally outside of a company directly selling it.
It's not just practicing leetcode though. It's also putting your considerable skills to work for an entity that will funnel the world's attention into advertising (Google), create platform lock-in and undermine repairability (Apple, Nvidia), successfully lobby governments against use of open standards (Microsoft), etc.
All companies pay you to put its interest before your own interest, but some companies are much worse and much more effective at working against the greater good than others. I'm not selling out to those just to add another few years to my already very achievable retirement.
The problem is that there is also a steady supply of people coming in who don't give much of a damn about any of this, and just want to do what their friend group does. They might get more aware later, but by then there's already a new generation out there making the same mistakes.
Unless we can push ethical (and FOSS) software over the point of critical mass, it's a never-ending losing battle. And even if we get there, the battle for daily attention is much fiercer than, say, Blender or Godot permanently winning mindshare among professionals. Trends are fickle and even just by not being the next best thing, we can lose the masses to the next best Skinner box.
Meanwhile, my 500-person company switches from MS Office to Google Docs like it's no big deal. Because it isn't. Excel isn't the main skill, using spreadsheets is. Formulas, tabs, references, filters, sorting, pivot tables, scripting, blah blah blah.
Apart from Excel specialists with highly specialized workflows when the rest of your finance department is also using the same, nobody cares whether you're good at Excel. They just want something to easily tabulate rows and columns of data and get some insight of out if. LibreOffice does that as much as Google and MS.
Don't put "LibreOffice" on your resume, put "spreadsheets" and 95% of the time it won't make an actual difference anyway. You can learn the location/naming of most relevant functions of your employer's preferred spreadsheet app in a matter of hours and then you know several tools, which is always better than just knowing a single one and puts you ahead in other ways.
> Is that why they're so unresponsive to user needs?
It's because Wayland is a set of protocols, rather than a single dominant implementation.
In order to do it right, cross-compositor and flexible, you have to get different actors with different interests and bandwidth agree on a standard. This takes time.
In order to get it working fast, developers need to make a compositor-specific implementation first and then put in the extra work of getting it through the standards discussion as well as switching their compositor ecosystem to the new standard.
Until this happens with all parts that you care about, you're going to be annoyed either about interoperability or functionality. Pick your poison, and cue Moxie's "The Ecosystem is Moving" blog post. Also, keep using X11 until Wayland has the features you want. Most DEs/WMs haven't ripped out X11 support yet, and hopefully won't until their support of Wayland protocols is solid enough.
I acknowledge that the Wayland team is not responsible for the implementation decisions of the GNOME team.
However, the Wayland team is responsible for the set of protocols that they've developed and that they've asked others to implement. The Wayland team has failed to define protocols that are flexible enough to provide basic functionality that users expect, even if they were implemented perfectly.
This should not be a process that depends on individual developers building compositor-specific remote-desktop tools first, then praying that someone likes them enough to put it in the standard. Wayland built the standard, they just built an insufficient one.
>If the Linux kernel had worked the same way, we'd never have gotten Linux.
Yes we would. In fact it's exactly how Linux works and has worked for decades. New features get added in drivers and then get rolled up into driver subsystems when enough hardware supports them.
With Coreboot and the ChromeOS Linux kernel running well on the device, how much would it take to release a Framework Laptop Linux Edition based on the Chromebook mainboard, but with a standard keyboard and somewhat optimized for a pre-installed Linux distribution?
I would imagine that regular Linux won't do as well as ChromeOS in terms of battery life, but perhaps still considerably better than the Windows mainboard+firmware.
I've recently purchased a monitor with poor HDR that I knew was not worth any cost premium, and I'm using it with an operating system that still has to get basic HDR infrastructure in place. I do not feel like I'm missing out. Other stuff is way more important in comparison, and no matter what you pick, there will always be tradeoffs to make.
On an opposing note, updating my Arch system (pikaur -Syu) recently wanted to install Electron 20 and remove Electron 19, which the element-desktop package was still depending on. I wasn't using it so that's an easy uninstall. But there's nothing inherent about Arch that prevents these issues from popping up every now and then.
> On an opposing note, updating my Arch system (pikaur -Syu) recently wanted to install Electron 20 and remove Electron 19,
hm that's weird, with yay it only ever adds new electron versions, never removes the old ones. e.g. there's electron12 to 20 in the repos and they can be installed side by side
