[tmtvl]

I've only used GNU/Linux since 2012, but I do think we have to face the fact that there is a fair amount of ~~choice~~ fragmentation in the ecosystem. Deb/RPM/Flatpak/Snap/PKGBUILD/Nix, GNOME/KDE/Cosmic/Cinnamon/Xfce/LXQt/MATE/Budgie/Sway/Hyprland, AppArmor/SELinux, GTK/Qt/Electron/Tauri/WxWidgets there's even distributions which use musl libc instead of GNU libc or non-systemd inits. Sure, you can just pick one and focus on it, but if someone else picks something else then they may need to duplicate some effort to get things working on their preferred setup.

[bayindirh]

When you put down your project in a sound and standards compliant way, packaging doesn't matter much. RPM and DEB automatically builds your code and packages it. DEB also has a lot of tools which allows you to make sure that everything is done correctly. I'm sure RPM has similar tools, but I didn't use them a lot.

Desktop environment doesn't matter much, because GTK and Qt works on every Linux Desktop. I'm using KDE, but I don't know which tools I use are GTK, which are Qt, etc. Qt and GTK teams collaborate a ton both in window management and desktop underpinnings side. Also there are tons of standards, and things just work if you follow them. Even the standard libraries of programming languages and Linux userland gives the tools to utilize these standards.

C libraries are mostly interoperable. I operate with GNU's C library, but aside from interesting behavioral differences, the API is not different.

If you're not writing daemons, you have no business with your init system in 99% of the cases, unless you want to utilize a special feature of any of them. You can just ship the service files. daemon() function is part of libc, not your init system.

In total, after your code builds, you can add these layers step by step, one at a time, and have a codebase which works everywhere with minimal effort.