The unstable API provides far worse problems than (clearly) indicated in the article. One solution proposed was to include drivers in the tree earlier - that *DOES NOT* fix the problem!
Imagine this _common_ situation. I install Linux Foo 1.2. It has kernel 2.6.5. Some new hardware is invented, a driver becomes available in-tree, and is released for 2.6.7. Guess what? That hardware does not work with Linux Foo 1.2. Vendors do not distribute all new kernels for their distributions, because due to all the other changes in kernel revisions (far more than just driver bug fixes) and their kernel patching, it would be dangerous to try to push a new kernel out. Instead, Linux Foor 1.2 will only ever have small security and bug fix patches applied. There will never be a 2.6.7 kernel package for Linux Foo 1.2.
However, the kernel API has, of course, changed between 2.6.5 and 2.6.7. There is no way to just go grab a copy of the driver for 2.6.5 and install it. No, you must use 2.6.7. And not "2.6.7 or higher," because higher might break the API again. Just 2.6.7. Since Linux Foo 1.2 will only ever have kernel 2.6.5, the user cannot simply install the driver for his new hardware.
The user, in order to use this new hardware, must upgrade his entire OS. But wait, Linux Foo 1.3 won't be out for another 3 months. The user must instead manually install a new kernel. Assuming that you actually had a user who's willing to upgrade their OS at all, you've now alienated and lost the vast majority of remaining users, because the number of people who even know how to, much less are willing to, manually download and install a kernel (possibly adding various patches for compatibility with their distro's special features) is very, very small in relation to the total number of computer users.
The end result really is that the hardware is useless on Linux in general until 3+ years down the road when everyone is using a kernel newer than 2.6.5. Of course, the users who got burned previously may not be using Linux anymore. And there will be new hardware out that won't work with Linux then, either.
The in-tree drivers do absolutely nothing of usefulness *now*. They only make hardware work for any appreciate fraction of the user population a *long* time after the driver is added to the tree.
The solution requires it to be possible for a user to install a driver for whatever OS they currently have installed. This does *NOT* require ABI stability; it is acceptable to require drivers to be distributed as source and require compilation, so long as there is an easy to use method for doing so. It does require a stable API so that a driver can actually be able to compile without needing to match it to the specific kernel running.
(I imagine a special kind of "Linux Driver Package" with tools that compile and install the packages for the user. Users just click on the driver on the CD that came with the hardware, or from a driver web site, and the GUI tool pops up and does the work, prompting for verification and authorization. This will work even if drivers are distributed as source, so long as all user systems have the basic compiler/development tools installed.)