"Proprietary kernel modules are flaky, out of date, and the bane of a Linux professional's existence - right? Maybe not. This three-part (part I | part II | part III) series makes a case for formalizing the uneasy truce between GPL-clean and 'tainted' modules."

The open source community moves too fast compared to our commercial competitors. We are not going to freeze the kernel API because some company doesn't want to update its driver.

The whole idea behind corporate intellectual property in the USA is write it once, then never fix it and patent it. Sue everyone if they make anything similar. Meanwhile, only fix it if you can charge ridiculous support rates per "incident".

The open source model doesn't work that way, because it relies on cooperation from users and the engineers at a fairly low level to fix problems.

The open source model also doesn't have a dividing line between user and engineer. Any customer can become and engineer, after all, they have the source code.

I think the efficiency of such a relationship speaks for itself.

Open Source engineers also have a love of the software we write, so we tend to care about bugs more than our commercial counter parts.

That means, we need open access for our customers to help us with those bugs, if they decide to do so, and we need the ability to debug the software sometimes in the wild.

After all, you can only test so much in the lab and sometimes customers have great labs they run the software in...also known as their organization.

Having a stable driver API would in *NO* way put Linux development at a disadvantage. One could argue that *MORE* drivers might be written for Linux if there were a well documented, stable API.

Some pretty smart people disagree with you; see the "stable_api_nonsense.txt" document in the kernel source tree: http://tinyurl.com/y7lm5c

While you're right that it might be a bit easier to maintain drivers if there was a stable api, that's only one half of the equation. You must also consider how easy it is to change _core_ kernel code to incorporate new features. What ends up happening is that the _drivers_ by virtue of demanding a stable api end up holding the overall system back and making it much harder to change code.

The open source community moves too fast compared to our commercial competitors. We are not going to freeze the kernel API because some company doesn't want to update its driver.

Perhaps if you slowed down you'd stop running around in circles and make some progress out of all that brownian motion.

Open Source engineers also have a love of the software we write, so we tend to care about bugs more than our commercial counter parts.

Nonsense. Most "Open Source engineers" make their living as commercial developers. Are you suggesting that those of us who do that are unethical enough to care less about bugs in the software we're paid to develop than we do about bugs in he software we're not paid to develop?

After more than thirty years developing software, both open and closed, I've found that the reasons for bugs are different in the two worlds, but that neither is particularly more bug free than the other.