[zozbot234]

> 25x duplicated effort

People keep saying this, like too much effort is a bad thing. But OP makes it clear that there's very little duplication of effort in the Linux-on-phone/mobile/SBC community - most developments are shared community-wide. There are some technical divergences (Alpine/musl vs. glibc- and init-based systems for example) that can impact direct compatibility, but they're very minor.

[asdfasdf23r23r]

Correct. This is non-sense speak by non-developers. Greedy non-developers.

they "sell" it as "25x duplicated effort" but in reality, there's 25x little tweaks to a build system, that give thousands of people zero effort to port their known platform right away. Now those thousands of people will have REAL effort to adapt their knowledge and existing ways to fit that one holy way enforced by the device true owners.

In reality it is "25x places where i will have to hide my plan for monetize this". Just like most other projects, greed always destroy everything the community help build in good will.

[nexthash]

I would like to disagree with your characterization. I use Linux distros regularly at work (Amazon Linux), in school (Rocky Linux, currently studying), and at home (Ubuntu) when hacking together various projects. I've seen firsthand the issues that come with trying to get a distro to interop with Bluetooth, sound, and software not quite designed for it.

This is not a zero sum game: I believe we can have both an OSS approach to Linux while at the same time having a channel of commercial development that brings more adoption (and fun, hackable devices!). This "one holy way" and the multitude of community-based distros can coexist, in the same way that commercial software companies and OSS communities have already learned to.

[zozbot234]

> I've seen firsthand the issues that come with trying to get a distro to interop with Bluetooth, sound, and software not quite designed for it.

These issues crop up on bleeding-edge hardware due to different distros running differently-timed versions of the same underlying components. They fade away over time as software versions start supporting the formerly-bleeding-edge hardware across the board, and the issues invariably shift to the next bleeding-edge hardware release. This is not an immutable fact about the ecosystem, it's a consequence of wanting something to function before it's fully ready for serious use.

[panny]

Right, this boils down to "Oh no! 25x many people are interested in our project. What can we do to reduce that to 1x people interested in our project?" If I can't easily boot my preferred distro, I don't buy your boards. That simple.

[3np]

There's also a middle ground somewhere between 1 and 25.