Silicon Motion Has Open-Source Driver, But Fails

[FourDMusic]

I think Michael was going for the humor of the situation but the article was quite condescending from a reader's point of view, especially since Michael is making the mistakes of these devs more public than it ever should be (I can't believe you included his name, poor guy).

I've been on many different mailings lists and new comers almost always ask what seems to be trivial questions (I've done this, I'm sure). But we need to be welcoming if we want to foster a friendly, open environment that everyone enjoys working with. Or everyone will leave and no work will ever get done.

In regards to the Silicon Motions developers, REALLY? There are hundreds of git tutorials and while I do appreciate your open-source work A LOT, please submit meticulously written code - most everyone else does, you are no exception. Then we can avoid these situations. Hopefully, we will be able to laugh about this situation over a beer someday.

Good luck to you!

[allquixotic]

Uh, well. Mailinglists on kernel are sometimes harsh, yes.
But then, the attempt was really bound to fail with such a lot of coding errors and lack of experience with the tools Kernel devs use. Maybe they should gift him a book explaining git and writing drivers for the Kernel.
Anyway, what makes me cringe somewhat is the thought that here we see the mistakes openly in the source. But what if companies (and they probably do) release such drivers as blobs? Or other software - not just drivers. [emphasis mine] Ouch.

This isn't a hypothetical "what-if" scenario. This is reality. Most of the proprietary software systems of the world consist of absolutely horrendous code quality, with tons of undefined behavior, legacy compatibility hacks to re-create bugs that were fixed 10 years ago, cargo cult coding, and lots of other horrid things. That's why proprietary software is usually extraordinarily brittle, meaning that it only works in a certain specific set of circumstances that were anticipated by the developer, and falls down easily when straying from the happy path.

It's no secret that open source code -- especially on large projects with a strong commitment to code quality -- tends to be more adaptable, more tolerant of user error and hardware bugs, and easier to maintain. This is in fact the main argument given by many proponents of the open source movement, in favor of open source software -- they argue that the development process itself is inherently inclined to produce better software. And of course they make a good argument that often reflects reality, or else we wouldn't be here on Phoronix talking about Linux code quality.

This is also why most wireless (802.11) devices simply refuse to work with one another. It's not that the hardware is electrically or physically incapable of behaving in a compatible way; it's just that the imbeciles who wrote the proprietary drivers tested their adapter with an extremely limited set of other devices (usually the company's own devices only) for compatibility and smooth, trouble-free operation. When companies interpret wireless standards differently and don't communicate their interpretations to one another in the form of open source drivers, this kind of problem is inevitable.

I have seen some pretty bad open source code, but none of it comes close to the unbearably low bar for proprietary software that's set within corporations that we rely upon for our daily activities, like Nvidia, AMD, Marvell, Atmel, Ralink, Intel, Cisco, VMware, and so on.

It's the Bazaar and the Cathedral. It's the Democracy and the Tyrant. When your work product is just a driver "that works", it is completely irrelevant how compatible your code is; how portable it is; how well it avoids undefined behavior; or how well-documented it is. As long as you can bandaid over any outwardly-showing flaws and hide or gloss over any remaining flaws, you get to keep your job and your hardware and its drivers get to launch on time. Everybody's happy.

Except the customer who tries your crap driver with a configuration you didn't anticipate, and has no way to fix your junior programming mistake because your company chose a 20th century business model / licensing model.

Steve Ballmer said once that Linux is a cancer. No, Steve; look yourself in the mirror. You are the very icon of the most cancerous ideology within the entire high technology industry: proprietary software / ideas.

[DaemonFC]

I don't think this article was too harsh.

Chucking shit over a wall with the intention to abandon it, and not releasing it under a license compatible with the kernel's is such a stupid thing to do that Silicon Motion deserves to be mocked for it.

If you want to mainline a hardware driver, you have to maintain it, the license can't be any more restrictive than the GPL 2, and it can't e utter crap with thousands of bugs that you have no plan to do anything aout. Where is that unfair exactly?

[AnonymousCoward]

Chucking shit over a wall with the intention to abandon it, and not releasing it under a license compatible with the kernel's is such a stupid thing to do that Silicon Motion deserves to be mocked for it.

If you want to mainline a hardware driver, you have to maintain it, the license can't be any more restrictive than the GPL 2, and it can't e utter crap with thousands of bugs that you have no plan to do anything aout. Where is that unfair exactly?

Do they want to abandon it? Do they want to keep the incompatible license? To me it kinda looks like "hey, you, I heard we should put our drivers into the official kernel, do that" "how?" "how should I know, that's your job, go and find out!" Maybe they do just want to dump their code somewhere, but if that's the case, this article doesn't support it (and neither do the mailing list posts I found).

[elanthis]

I see no problem with the treatment here.

Let's go over the facts:

1) The developer did absolutely zero research prior to his submission. He did not so much as Google "writing Linux drivers." There is naive and there is willfully ignorant. He was of the later.

2) The code quality is low. This deserves ridicule all on its own. Low quality developers need to be fired, not coddled. The world has enough incompetent people making everyone else's life hard.

3) The license shows that the company itself has done absolutely zero legal or professional research or effort to handle this driver. The entire effort might even be illegal due to use of some third-party code that can't be relicensed under the GPL.

Again, he's not just a new developer, he's someone who intentionally avoided putting any effort into doing things the right way, but yet managed to spend time writing (or repurposing, more likely) around 20,000 lines of code. Unacceptable.

[yogi_berra]

1) The developer did absolutely zero research prior to his submission. He did not so much as Google "writing Linux drivers." There is naive and there is willfully ignorant. He was of the later.

That is someone else's job, Developers write code.

2) The code quality is low. This deserves ridicule all on its own. Low quality developers need to be fired, not coddled. The world has enough incompetent people making everyone else's life hard.

Style errors do not equate to low quality code.

3) The license shows that the company itself has done absolutely zero legal or professional research or effort to handle this driver. The entire effort might even be illegal due to use of some third-party code that can't be relicensed under the GPL.

Based on what evidence? He may have had all of the legal permission he needed to release the code under the GPL, from Michael's blog post and the thread on kernel.org you have no idea what happened beyond the wrong boilerplate license block.

[DaemonFC]

Do they want to abandon it? Do they want to keep the incompatible license? To me it kinda looks like "hey, you, I heard we should put our drivers into the official kernel, do that" "how?" "how should I know, that's your job, go and find out!" Maybe they do just want to dump their code somewhere, but if that's the case, this article doesn't support it (and neither do the mailing list posts I found).

There's this thing called Google. I guess Silicon Motion hasn't bothered reading the abundance of "How to get your driver in the kernel and not look like an idiot" posts. Greg Kroah Hartman has written quite a few of them.

[DaemonFC]

I see no problem with the treatment here.

Let's go over the facts:

1) The developer did absolutely zero research prior to his submission. He did not so much as Google "writing Linux drivers." There is naive and there is willfully ignorant. He was of the later.

2) The code quality is low. This deserves ridicule all on its own. Low quality developers need to be fired, not coddled. The world has enough incompetent people making everyone else's life hard.

3) The license shows that the company itself has done absolutely zero legal or professional research or effort to handle this driver. The entire effort might even be illegal due to use of some third-party code that can't be relicensed under the GPL.

Again, he's not just a new developer, he's someone who intentionally avoided putting any effort into doing things the right way, but yet managed to spend time writing (or repurposing, more likely) around 20,000 lines of code. Unacceptable.

Regarding item 2, poor quality code is typical of proprietary drivers. You can get a whiff of it just by how many deficiencies become apparent when you load the module. Nvidia's blob and AMD's Catalyst are good examples of that. I have a feeling that if either of those ever got their source code released, it would be an absolute laugh riot as well. (Other than the "OMG, I was running THAT!? On a production system!?!?!?")

[DaemonFC]

Based on what evidence? He may have had all of the legal permission he needed to release the code under the GPL, from Michael's blog post and the thread on kernel.org you have no idea what happened beyond the wrong boilerplate license block.

Actually, releasing nonfree source code is worse than not releasing anything at all. If a person so much as looks at it, then it can legally taint anything they write as a free software replacement for the offending proprietary code.

[crazycheese]

*text*

Great write up!