Imo, the key difference between these two worlds (which you hint at in your analysis of the ascription of fault at the very beginning) is that when most or all elements of an operating system's stack of essential software is fixed, that leaves the capacity (and responsibility) of deciding the nature and quality of users' experiences with a piece of software in the developer's hands alone. But when an operating system is flexible and its components are somewhat interchangeable with alternatives, or the target platform is actually a whole family of operating systems, developers can't and don't have such sole responsibility or capacity. Distro and package maintainers especially do crucial work in sharing that burden and making sure those end-user experiences are coherent and pleasant, and in general they do a great job of it.
When there are problems, I think it's equally useful to consider them as logistical and social problems among community members (developers, distro maintainers, package maintainers, and end users) in managing that shared control and responsibility. Some examples:
• End users who are used to navigating the alternative world of mostly-uniform platforms may not understand that not everything is up to the developer, which can misdirect their frustrations (and their bug reports).
• By the same token, advanced users and smalltime contributors form a crucial layer of these ecosystems wherever they are healthy, by not only running up against integration issues themselves so that they can be identified, but by figuring out how and where to report them and how to mediate information between the authors of applications and people who work to integrate them into their operating systems (distros). Developers who want wide support are faced with the task of seeking or building those relationships somehow (or just rolling the dice).
• Developers of new pieces of software may find themselves faced with a social bootstrapping problem: they need people using their software, or at least excited about it, in order to generate the interest in their software required to get someone working on integrating it with a particular distro.
• Users who change out major system components in a distro (like the init system or the display server) take on (or create a need for) a new role in doing so: they become integrators of the system just like that advanced layer of users I mentioned, or distro maintainers. A clearer understanding of that might ease a lot of frustration for users and developers about things ‘not working’. (This is reflected in Gentoo's self-description as a ‘meta-distribution’.)
I'd like to see more of this acknowledged explicitly, maybe by two official standards of support: original development target and explicitly co-supported. A lot of F/OSS projects sort of already do this by pointing to the program's inclusion in various distro repositories on their official pages, sometimes with a word of warning about especially experimental cases (i.e., packaged but not co-supported).
Supporting more distros will always require more work from developers, but such work doesn't always have to be intensive development work. It can just be a working relationship between a developer and a motivated user of some distro who the developer agrees is more or less competent to figure out the technical boundaries of integration problems and work with them in a reasonable way to solve them equitably. I know it _can_ happen because I see it play out all the time when it comes to packaging software for my favorite Linux distro¹, which because of the distro's weirdness can require some hints or even minor source code changes from application developers. When the motivations are communicated clearly, application developers are often willing to incorporate minor compatibility changes for the sake of some boutique distro's compatibility, with very little fuss.
Idk what really can be done to communicate this to users, or how to better manage the sort of clusters of related configurations that exist on meta-distros like Arch or Gentoo, but both seem in principle doable to me.
When there are problems, I think it's equally useful to consider them as logistical and social problems among community members (developers, distro maintainers, package maintainers, and end users) in managing that shared control and responsibility. Some examples:
• End users who are used to navigating the alternative world of mostly-uniform platforms may not understand that not everything is up to the developer, which can misdirect their frustrations (and their bug reports).
• By the same token, advanced users and smalltime contributors form a crucial layer of these ecosystems wherever they are healthy, by not only running up against integration issues themselves so that they can be identified, but by figuring out how and where to report them and how to mediate information between the authors of applications and people who work to integrate them into their operating systems (distros). Developers who want wide support are faced with the task of seeking or building those relationships somehow (or just rolling the dice).
• Developers of new pieces of software may find themselves faced with a social bootstrapping problem: they need people using their software, or at least excited about it, in order to generate the interest in their software required to get someone working on integrating it with a particular distro.
• Users who change out major system components in a distro (like the init system or the display server) take on (or create a need for) a new role in doing so: they become integrators of the system just like that advanced layer of users I mentioned, or distro maintainers. A clearer understanding of that might ease a lot of frustration for users and developers about things ‘not working’. (This is reflected in Gentoo's self-description as a ‘meta-distribution’.)
I'd like to see more of this acknowledged explicitly, maybe by two official standards of support: original development target and explicitly co-supported. A lot of F/OSS projects sort of already do this by pointing to the program's inclusion in various distro repositories on their official pages, sometimes with a word of warning about especially experimental cases (i.e., packaged but not co-supported).
Supporting more distros will always require more work from developers, but such work doesn't always have to be intensive development work. It can just be a working relationship between a developer and a motivated user of some distro who the developer agrees is more or less competent to figure out the technical boundaries of integration problems and work with them in a reasonable way to solve them equitably. I know it _can_ happen because I see it play out all the time when it comes to packaging software for my favorite Linux distro¹, which because of the distro's weirdness can require some hints or even minor source code changes from application developers. When the motivations are communicated clearly, application developers are often willing to incorporate minor compatibility changes for the sake of some boutique distro's compatibility, with very little fuss.
Idk what really can be done to communicate this to users, or how to better manage the sort of clusters of related configurations that exist on meta-distros like Arch or Gentoo, but both seem in principle doable to me.
—
¹: https://nixos.org/