RTFA. The patches are a mess,
Yeah, not seeing this one as a problem; Open Source projects have no problem supporting hardware that the manufacturer would rather they didn't support, often over the manufacturers objections, but when it comes to hardware specifically built on behalf of the Open Source project, all of the sudden it's now the companies job, rather than the Open Source project's job, to pee on the patches until they smell like the projects leaders peed on them, so that there are no changes required to be able to use them.
This seems really similar to Samsung releasing code with "board" support for some hardware, and then some maintainer getting all pissy that they didn't write the code the same the maintainer would have, had the maintainer had the time, but the maintainer doesn't have the time, but won't integrate the patches anyway because they aren't done the same way they would have been done, had the maintainer done them, but the maintainer won't do them.
Either bitch when they don't obey the GPL and provide their code, or take their code when it's provided and say "thank you", but don't bitch when they hand you code, and you don't want to do the work to integrate it into your moving target of a project. Thanks.
don't compile cleanly and the wireless driver is missing. Rendering it an expensive paperweight.
It's not entirely a paperweight, but they've acknowledged that the code, as supplied, lacks wireless driver support, and that they need to sanitize the code and break it along interface boundaries so that it can be a binary driver module.
Again, I think the "problem" isn't so much that the module wasn't supplied immediately, instead of just being promised, but that it means they aren't going to get the source code for the module itself. A lot of Open Source projects like to try to force hardware vendors to give up what the hardware vendors consider their "keys to the kingdom", and will go so far as to design system interfaces which aren't usable unless you have GPL'ed code in your driver, making your driver GPL'ed, meaning that they can demand source code.
As far as SDR - Software Defined Radio - such as that used in WiFi and cellular radio parts firmware is concerned, those guys can piss up a rope. Specifically, if the source were made available in a way that could be utilized the way the Open Source people want it to be able to be utilized, which would mean:
(1) Other vendors could just copy the register interfaces and use the same driver, without having to do hardware design work
(2) Other vendors could thus undercut the prices by the amortized R&D costs (i.e. the hardware would be commoditized)
(3) The driver work would effectively not be a recoverable cost at the commodity price point
(4) They lose their FCC certification for the part
(5) They can't sell in the U.S., France, the U.K., Japan, and other countries that license hardware/firmware as a single lump
So... piss up a rope; be happy with the forthcoming binary-only driver blob, and be happy it's been promised at all so that you can dick around with the way the rest of the system works to your hearts content. That's all you're going to get for economic reasons, unless you get together as a group and buy out their R&D costs, and buy out their first mover advantage.
Otherwise, if you can live with the limitations, hold your damn horses, and wait to buy the router, which is generally not hardware available anyway.