Downwards compatibility during long time development

Tux
Microsoft’s Larry Osterman described in a recent blog entry that there will be no totally reworked Windows kernel after Vista due to the need of downwards compatibility. The argument however raises the question if Linux could be faced by a similar problem.

Larry Osterman’s post explains that there will be no new kernel since it would break downwards compatibility. He mentions an example where Microsoft dropped support for NT 4 audio drivers in Vista and immediately was called by customers who complained about not-anymore working audio software – although the support officially was dropped 1998 anyway:

People reported that some call center applications had stopped working. We started digging and discovered that these call centers were using software that depended on the NT4 style audio drivers. These call centers didn’t have the ability to upgrade their software (the vendor had gone out of business, and the application worked just fine for their needs). So we put the support for NT4 drivers back, because that was what our customers needed to have happen.

First of all this example shows pretty well why it makes sense to use Free Software for your core applications: in the worst case (the vendor goes out of business) you can still pay someone else to make changes you really need. In this case the call center could just pay a developer to alter the audio core of the application to use the new ones.

Nevertheless the question remains if something similar could happen with Linux.

In case the software just uses a specific sound architecture Linux already showed that it can handle such things: Linux’ sound architecture ALSA replaced the older Open Sound System some years ago but still provides a compatibility layer. So even if you have an application which only works with OSS it still works on a new kernel. Since the above described problem seems to be such a case the question is why Microsoft didn’t add a compatibility layer.

However, if the sound application came along with it’s own drivers and needed NT 4’s driver API Linux wouldn’t be faced by such a problem anyway: in Linux the drivers have to be Open Source. As a result, if the driver API changes, the drivers are ported to the new API. This shows how important it is to open up all drivers and not introduce a general stable API: the API would have to change sometime in the future which would in return drop support for all old drivers.

Still, there is one thought which I can’t get rid off: Windows has a stable base of customers and well established ways of speaking to them (the important ones at least). This is worth money since these customers – equipped with Beta software – are a large computer test lab. I doubt that Linux has something similar. There are hardly any Linux hardware/software test labs I would now off and I never heard of anyone running mass regression tests on standard hardware pieces on a daily base for the newest Linux kernel. Not even from one of the big vendors. But that should be the usual way!
But running regression tests against for example one hundred different network cards costs a lot of money, and maybe the community is just not there yet.