Ask HN: What's the greatest lie of open source?

"Well, if not contributions, at least it will help with your career, with consulting work or job offers."

[1] Yes, even slapping the BSD license and doing nothing is effort. And odds are good you'll not get anything out of it.

This is better than not having the code at all, however this is a false sense of security.

First of all, you should be compiling your own binary from the sources, otherwise you are blindly trusting that those binaries you download are built from the original source code, which may not be the case.

Second, open source security relies on enough eyeballs reading the code independently and spotting the security holes or anything malicious but you can't know how many people actually did. Some software isn't popular enough, some other software contains millions of lines of code.

The same process would have to happen for each patch and software update.

The same thing happens with closed source projects, however. Less popular software will have smaller staff and it's more likely to contain errors and security holes, especially if it's an one man project. More popular software will have more staff working on it but if the software is big and complex, most people working on the project have never read the entire code and there's more lines of code that may contain issues.

Software is a giant mess

Building from source is a tricky one and actually I'm not sure that everyone should compile from source (although it is definitely good to retain that ability, and to have, for example, entire Linux distributons that do so during package installation.

Signing keys and binary signatures should achieve most of the result without requiring energy and CPU expenditure on recompiling every time. Especially in the presence of continuous integration, those resource costs can spiral, and that's energy that could be spent on other needy human endeavours.

Regarding enough eyeballs - yep, it's hard to tell at the moment. When version bumping a single dependency by a minor release versiom, often it's possible to do this manually by checking commit and change logs. But it's hard to scale.

The longer-term solution there is likely automation: we should encode as much of that manual diff-and-review process as we can into automated security scanners. With good enough static analysis, and languages that can unambiguously express code as syntax trees, we should be able to generate 'tree diffs' and look within those for resolved, unchanged, and introduced issues.

Lots to do and better times ahead :)