[zanny]

Which is why the campaign for liberated firmware is so important. If motherboard manufacturers were committing work to a common project like libreboot then hundreds of eyes would be upon it and awful code that does this insanity would never enter official repos.

Linksys had this problem a few years back with their new line of "open source" routers - it took them months to clean up their awful internal coding styles to get patches accepted into DDWRT, and even then they were accepted on a compromise where DDWRT developers had to fix a lot of it to make it less of a security portability and readability nightmare.

These hardware vendors at all levels - storage controllers, chipsets, radios, and more all have absolutely no QA on their code and by being so extremely proprietary nobody can do anything about it, and not enough people care to speak with their wallet to changes these terrible habits.

[wsx]

> These hardware vendors at all levels - storage controllers, chipsets, radios, and more all have absolutely no QA on their code

Hardware vendors do have QA, but it's mainly about ensuring that things work, not about trying to break them in every possible way. Safety and security seems to be notoriously hard for people who have been taught how to make things work, but not how to make them fail.

[zanny]

Which is exactly why it would be so valuable to have that code in the open.

I know I'm repeating myself but I still think the interations between OpenWRT and the Chinese firmware vendor that was pushing Linksys firmware upstream is a valuable example of why open source is valuable in this context even if you are not intimately involved in the development, testing, or inspection of such code. Public code by its nature requires more scrutiny and its harder to get people to accept something broken or poorly written when they can see just how bad it is.

If you want to develop awful coding habits, only work with people who never develop free software. If you want to have really good habits, work in a very popular free software community, because when your work is in the open like that and everyone is a volunteer nobody is going to put up with crap.

[rimantas]

  > then hundreds of eyes would be upon it and awful code that
  > does this insanity would never enter official repos.

As the example of OpenSSH clearly shows.

[wsx]

Well, the insanity would rarely enter official releases.

There is no comparison between the bugginess of BIOSes and OpenSSH.

[zanny]

OpenSSH would not fit my definition of a popular project, which is exactly why it has become a security disaster. Though another contributing problem is that C as a language is awful for writing secure or trustworthy code in in the first place, which is the primary cause of most of OpenSSH's problems.

There are degrees of return on code visibility, though. Even a dozen competent developers could miss arcane buffer overflows or bad page execution issues in a large patch because the language is awful and lets you do crazy shit. That is one aspect of development quality that doesn't go away when you move from closed to open source.

But the best practices - consistent code style, documentation, reasonable variable names, reasonable line lengths, and the need to defend your contributions are all products of open collaborative development processes.

I'd argue in many ways that the open nature of OpenSSH is why we have only had three (four?) major security vulnerabilities out of it in the last five years. Its a sixteen year old ANSI C codebase, of course its a security nightmare, but it is a lot less dangerous than it could have been - imagine having heartbleed on a proprietary TLS implementation where developers could not immediately fix it or easily deploy the fix.