Broadcom isn't really against anyone making their own firmware (and people have tried, but haven't gotten much further than booting). As for the parts that can never be open-source:

1. The decoder blocks, H.264 and H.265, Broadcom/RPT can never release the source code to this without violating potentially thousands of patents worldwide.

2. The GPU of the Pi runs a ThreadX RTOS, which is licensed, runs on "billions" of devices worldwide, and can never be open-source without being sued for, well, huge amounts of damages. (The GPU blobs will never be open for this reason, but perhaps a mostly-complete GPU firmware NOT based on ThreadX will be released someday by the community, but I wouldn't hold my breath).

Also, you know the Pi's new OpenGL driver? All it does is convert the OpenGL commands and stuff into commands for this proprietary ThreadX GPU software.

3. If you think this isn't great, it's still better than the Pi's competitor boards, which have missing gaps in functionality, proprietary blobs which don't work well or even at all, and open-source implementations that currently just suck. (Read Hackaday's Pine64 Un-Review to see what I mean. It's improved a bit since then, but this is why "Pi-killers" haven't caught on.)

Interesting. Thank you so much for the reply! Would it be feasible to engineer an open source firmware that doesn’t support any of the things you listed?

I use Pis as a stateless platform for an application that doesn’t use any graphics, GPU, or codecs. I imagine several other people do too.

> Also, you know the Pi's new OpenGL driver? All it does is convert the OpenGL commands and stuff into commands for this proprietary ThreadX GPU software.

You mean the old driver? The new one is based on Mesa.