> ditch binary blobs entirely

I agree there is not much of a clear call to action. As a firmware engineer who has worked with bluetooth amd wifi, this is a key phrase. It’s also a big fantasy. FCC compliance is a big headache, and part of why people buy a given chip is the FCC certification comes with it. For instance, if I throw an ESP32 into a product and use wifi, I don’t need further certification. That can only happen if “there is no way” you can make the radio do what the FCC doesn’t allow. A general stategy for this is for the company to give a binary blob for radio related functions that limits the radio capabilities that you need to link to in your final build.

So that means there is almost zero chance the chip makers will ever publicly move away from binary blobs. At best they might quietly support reverse engineering efforts by open source driver projects.

That said, I would love it if all the chips I worked with had a battle hardened non vendor alternative. One major downside to these binary blobs is that they can be buggy. We were recently able ro rewrite our Bluetooth firmware to use an opensource version which greatly sped up the data throughput since it didn’t have a bug that killed byte transfer. But we don’t use this code lightly. FCC violations are crazy expensive and not something you take lightly.