I think if they had the following done right, it would be pretty much on par with open source hardware/software expectations:
1. Hardware datasheets for all components
2. Bootloader available to view the source for, if not completely open source. I understand bootloader can be proprietary tech and they can use non-commercial compete license but allow people to hack them and at the very least view it.
3. All PCB and gerber files available. Clean schematic documentation.
4. HAL/Middleware - this is by far the most crucial portion. The user should be able to write drivers for anything. Right now, if I want to connect a VR 2048x2048 LCD (3.5" square) with a DSI/MIPI interface, I cannot write a driver for this with RPi. It's not entirely their problem either - the DSI org gatekeeps the datasheet and development for it unless you fork out a generate multi thousand dollar membership.
That's all. Obviously they cannot compel each component manufacturer to open source their silicon... at some point the expectation fades.
Bootloader available to view the source for, if not completely open source.
...also known as the original IBM PC/XT/AT, which had the BIOS source code available, although still copyrighted to IBM. However, documentation for everything was in general very well done, and the IBM PC Technical Reference manuals had schematics too.
An older (preferably pre-ME, pre-EFI, pre-secure-boot) standard x86 PC, which you might be able to get for free (although "retrocomputing" enthusiasts have driven demand and cost up), I would consider more open than the RPi ecosystem. More relevantly to the article, they have also been able to boot from USB since the mid 2000s. ;-)
> 2. Bootloader available to view the source for, if not completely open source. I understand bootloader can be proprietary tech and they can use non-commercial compete license but allow people to hack them and at the very least view it.
This is a bit of a nitpick, but assuming point one of your post, tbh as an embedded developer there’s nothing magical or worth protecting in a bootloader. It’s such boring and, in the case of embedded systems on a chip, specialized code that really has no commercial value if the hardware documentation is available except in letting you gatekeep what runs on your chip. As in, anyone with the datasheets can write a bootloader and the bootloader provides no value to someone that has their own (proprietary or knockoff) SoC.
All that is to say, the Broadcom bootloader is closed for the same reason the datasheets and documentation are: it’s to prevent revealing the internals of the chip for fear of making it easier to reverse engineer or clone.
In a world increasingly more virtualized, multilayered, and interconnected, how would you ensure "purity" in that regard? And can you?