4 ms·
There was some speculation yesterday on why Canonical keeps picking and losing these fights: https://old.reddit.com/r/linux/comments/18yvefc/why_does_the_commu
by bsimpson 3y ago
There was some speculation yesterday on why Canonical keeps picking and losing these fights:
https://old.reddit.com/r/linux/comments/18yvefc/why_does_the_community_always_seem_to_choose_red/ https://old.reddit.com/r/linux/comments/18yvefc/why_does_the...
The top reasons given were:
- Not Invented Here: Canonical wanting to design its own everything and not being welcoming of contributions or feedback from outsiders.
- Inventing for itself first: Canonical builds what's best for Ubuntu and lets other people import the source if they want to. Other providers build in the relevant communities, which makes it easier for other distributions to import the next-gen stuff (e.g. X11 and its replacement Wayland both came from Xorg).
---
While I was writing that, I was really tempted to use lowercase "canonical" to describe Xorg's relationship with the graphics stack, and then changed to "relevant" when I realized that the company being discussed is uppercase "Canonical." I wonder if how much of their self image is reflected in their name: do they they they're the canonical stewards of the Linux desktop?
- saidinesh5 3y ago> Other providers build in the relevant communities, which makes it easier for other distributions to import the next-gen stuff (e.g. X11 and its replacement Wayland both came from Xorg). It seems more like Redhat just employes more GNOME devs and thus Redhat's work seems like "default upstream work" while Canonical's seems like "rewrite because of NIH". It is not as if GNOME is super inviting to random outside contributions either. I haven't used GNOME/Ubuntu in a long time but I remember when Canonical wanted to go Wayland first before rolling out their own display server for their phone use case. At that time, Wayland was mostly just in Meego and related devices. I just wish these distro wars happened in the final UI layer of the software stack instead of duplicating enormous amounts of the useless/boring/core work over trivial differences. (rpm vs. deb, snaps vs. flatpaks, etc..)