But the RPi is broadcom and arguably the best supported. Obviously this is special.

From experience I agree with you, the chipmakers suck because they utterly fail to be open source when they're one of the groups that needs it the most. It is to the extent that I would advocate for laws in the theme of right-to-repair to force chip vendors to provide source for necessary code to use their products to consumers. (in this case open source in the narrowest definition, they can keep their copyrights but would be required to distribute source to end users in a form and with a license that makes them usable)

If the question is "are any of the SBCs worth the trouble?" and the default answer is no unless I have a really good reason and want to dedicate the time to building the janky software stack (I don't), or they're from a small list of vendors I'd trust won't be a mess (RPi, nvidia, beagle, ... that's it off the top of my head)

Were the kernel and BSP improvements and ongoing support for RPi produced by Broadcom, or by the user community?

There is some sort of close relationship between Broadcom and the raspberry pi foundation which is not entirely clear, they are a bit more than just customers although companies use the “partnership” label to mean just about anything.

The relationship is very clear: Upton was a Broadcom FAE that started the RPi Foundation. The secondary story was that he found a use for an orphaned SoC and embarked on an 'educational' quest to make small computers for classrooms.

The real question is if Broadcom is devoting internal software resources to improving the ecosystem, or if it's coming from the devoted users. I don't track commits on kernel.org enough to know what's what.

Please excuse my ignorance here, but are you saying that the board makers have no say on what chip they want to incorporate into their board? And those chips firmware are not open or at least accessible to the board makers?

Board support packages very rarely get updated and usually target a very specific kernel version.

You move off that kernel version, no BSP, no boot. sad times.

This is one reason why you don't get android phones supported past the android release shipped.

You're completely at the mercy of the SoC provider. Promises of 'n' years support are quite often quietly dropped after 18 months, when they realise all the engineers have moved to working madly to get the latest SoC's BSP out of the door.

Rinse and repeat.

This problem wouldn’t exist if linux had a stable ABI.

Hopefully Fuchsia’s stable ABI promises pan out and companies start releasing drivers for it.

Haiku is already working on the board, although you need to build your own, as there's no public builds for it.

Haiku remarkably does have proper driver APIs and stable ABIs.

Linux is and will remain painful, on all platforms, until it is finally deprecated, and for a while longer after that.

What I'm saying is treat the board as a development harness to get your project going. If you have issues with the processor don't take it up with the board maker because they're usually just as clueless. The exception would be boards like RPi or Beagle where the designers are tight with or owned by the chipmakers themselves.

Right, which is what GP was saying: stick to those that are able to support longer than zero time horizon.

But the fundamental difference here is that most people buying SBCs are treating them as self-contained COTS compute modules.

As someone that has worked with these EVKs for decades, you never treated them as part of your final product. But with the advent of Beagle and RPI, that's where we are now.

But when you buy an RPi or Beaglebone as the core of your industrial smelter and expect support for that module comparable to, say, a module from Kontron? You're going to be disappointed.

Support is the S in IOT.

I thought that.... oh, Security is the other S. Got it!

Identity is the Id in IdIoT.

Are these vendor kernels good enough to run some sort of hypervisor and pass through devices at the lowest possible level to (updatable) guest kernel(s)?

The idea here would be to run things like the TCP stack, USB from the lowest proxy-able level the in USB stack, etc in the guest kernel(s), as well as the entire application level, so as to reduce exposure to vendor kernel bugs and feature freeze leaving it only with minimal SOC-specific nitty gritty. For GPIO the vendor kernel could be used as a PRU of sort, passing messages to the guest kernel for actual processing.

Then the vendor kernel is just treated as a BIOS/blob getting in the way as little as practicable, it's very ugly but would allow using all these boards, also same method could possibly be used to recycle obsolete android phones.