I have an idea about improving Linux (and OSes in general) that I would like Mr. Curtis to comment on directly. A lot of posts here have already commented on the problems that my idea seeks to solve, so I wont go too far into why I think it's a central problem. I think the installer and build pipeline problems are just as important as (and directly related to) driver support issues.
I think Linux needs a "Universal Installer" format, similar to the "Universal Installer" that Apple used to help transition Mac OSX from PowerPC to x86 architectures, and later from 32-bit x86 to 64-bit. Linux not only has hardware CPU platform diversity to deal with, just like OSX did, but also kernel detail diversity. If you hear me out, I think the particular "Universal Installer" I have in mind would help with the hardware driver support issues you speak of as well.
I don't think current package management systems are sufficient, in part because they're solving the wrong problem. They are still solving (and sometimes failing) at the "library hell" problem, where conflicting library versions cause unforeseen errors in the software that shares those libraries. Windows has multi-part solutions to their "DLL Hell" counterpart, which are still sometimes insufficient, so many Windows installers end up just putting many versions of the same driver in their own respective Programs folders.
I think a better solution is to have a version controlled shared library database. Instead of forcing all local software to upgrade a shared library when one item does, you keep a "delta" or "snapshot" of the older version(s). Software that doesn't yet support the newest version of the library then just keeps a pointer to the old version, that can be re-pointed to the new version after the next upgrade, or compatibility confirmation message. Older libraries with 0 remaining pointers can be deleted in a "deprecated collection" pass later. Disk space usage can also be minimized by storing old library versions as deltas from the newest matching version. A file system that supports snapshots and symlinks would be sufficient for this solution, and some simple library install and management tools could handle pointer generation and cleanup tasks.
The other problem with any installation, that I personally think is even more important than "library hell", is kernel+CPU diversity. I don't think it's appropriate to distribute kernel+CPU architecture specific binaries, and expect them to "just work," anymore. Where I have high hopes of this changing is via compiler toolchain projects like LLVM. LLVM provides a platform agnostic bytecode format and VM that can be targeted by any language compiler, including for proprietary code. That bytecode format can then be sent to any other platform, and the piece of LLVM that compiles bytecode into local/native machine code can complete that step at install time. Proprietary driver vendors, who sometimes don't have full control over their drivers due to 3rd party license arrangements (nVidia comes to mind), can send proprietary bits as obfuscated bytecode, and open-source-ize the rest. They can also keep their own code proprietary via obfuscating the bytecode, so that OSS community support becomes a separate issue that doesn't hamper timely distribution. This also gives major proprietary software vendors (like Adobe) a much easier distribution method for targeting all Linux releases.
I can foresee some issues that might require install scripting with the use of platform-specific environment variables, but that isn't anything new to installers, such as the Windows MSI installer tool. I see the resulting "Universal Installer" binary as a zipped package of LLVM bytecode files, libary dependencies, and wizards/scripts that define operation order and output paths, using local environment variables and platform-specific conventions. Those scripts could even utilize local environment knowledge to tweak compiler output using platform-specific optimizations and methods.
The same LLVM "Universal Installer" toolchain could even be created/ported for other OSes, like Windows and OSX. Then a developer can use the LLVM tool chain to finally live the dream of all coders: write once, distribute everywhere, and run anywhere.