> surely you jest?
No, I don't.
> 1. It is possible to provide source code so incredibly awful it is effectively
> opaque and unmaintainable
It is. However, "effectively opaque" does not stop anyone extracting the necessary info to write the driver cleanly - and because the kernel is GPLv2, you have a right to the sources built for the kernel you're using. So your point is a red herring; given sufficient interest in having a clean driver, one will appear.
> and offers little that purely black box reverse engineering could give you.
Disagree. It's quite difficult to do source-level debug access in a black-box environment.
> 2. Binary blobs can be loaded and run by otherwise 'open' drivers.
These are very rare these days; Linux has such a wide range of Free drivers available, it's only really the graphics acceleration stuff that gets shipped in this way. And that's getting better by the day.
And if you want to reverse- engineer the driver - the kernel is wide-open for instrumentation, so even that's possible.
> they can have additional restrictions put upon them by vendors who can use
> copyright restrictions to limit the distribution of those blobs.
Perhaps. But if you've already got the blob on your device - put there by the manufacturer - it's not a breach of copyright to continue to use that code.
> Drivers have been, are, and will continue to be a serious problem.
No, they're not. I use a large number of Linux installations of varying types on vastly different hardware. Drivers haven't been a problem for a long time, except for niche hardware where the manufacturer will not engage.
Many moons ago, the kernel team made a promise to write a Free driver for any piece of hardware where the manufacturer would supply sufficient information to make that task possible, Some manufacturers still wouldn't play that game, but many did. Linux driver support is excellent these days - I frequently get much better response from some random piece of kit by using a Linux distro than by using the "official" driver under Windows.