Ask HN: What's the greatest lie of open source?
Inviting thoughts based on https://twitter.com/brian_d_vaughn/status/1258792447557038080?s=20
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 :)
Imagine you knew a large corporation uses LibreOffice. I doubt you'd need a million-dollar black market 0day.
Imagine an average user tries to perform a backup reliably ('this looks like time machine only it breaks restoring between versions').
Imagine you buy new blueooth headphones and you can't use high-quality audio codecs out of the box but need to compile something called an audio server.
Hell, in 2020, you don't even know for sure which application draws your browser window on the screen. Is it your browser, or some other process imposing your browser?
These are so many distribution-wide or ecosystem-wide issue that I honestly don't see the progress at any acceptable speed.
Many have been focusing on reproducible builds lately too, so you can verify that a binary is from a particular version of the source code.
That's actually what I do, and it works well for me. I switched back to gentoo when I decided to do that, precisely when I realized that trusting that binaries match their source code was unjustified (I had already a decade of using gentoo, so it was not a problem for me).
I also switched back to chromium, for that reason. Firefox is great, but it won't allow me load an extension from the FS permanently. All the extensions I use nowadays are loaded from sources (unpacked extensions, as chromium is calling them), after an inspection from me.
Of course, I haven't read the code of _all_ the programs I'm running on my system, so it's not perfect security. I'm still confident this is a better level of trust than running binaries.
A side effect of that is that since I actually _do_ read a lot of code from the programs I use, I learn a lot, and it often happens that I change code of programs I'm running to fit my need (the portage system of gentoo make it easy to write your own ebuilds and integrate your changes in your package manager).
Doing so require specific hardware, though, as if you're not careful on what hardware you take, you'll probably need binary blobs to use it.
There is still a security problem I need to solve. Some programs (well, chromium, mainly) easily take 6 to 8 hours to compile. So I usually just lock the version to a stable one and update every month. This may be a problem if a security patch is released.
For both open and closed source you can have security bugs and vulnerabilities, and depending on the attitude of the developers or the community behind it could be or not easier/faster to be solved on open source, but you can't bet on that.
But what is at the very least harder (or at least is in your hand how far you want to go to check about it) in one side is to include unnoticed backdoors, trojans and other gross things against your interests as user.
And yes, backdoors and intentional security problems can be introduced even with a duplicated line (https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-got...). Is not a safe against all protection. But it lowers the bar.
Of course, you can make money using open source software to provide solutions for your clients. If you run a SaaS you most likely built it on open source software, and ironically, exert even more control over your customers.
But what if you simply want to sell your open source product to customers so they can run it themselves? It's a dream for many developers but impossible to achieve. There are some success stories, but they are always the exception not the norm. And they often require selling closed-source extensions that are the bits of the business that actually bring in revenue (think GitLab).
And no, you can't sustain your livelihood by selling support if you are a solo developer. Besides the idea of selling support for open source products is, to most developers, the most unappealing option possible. (Charging for documentation is even worse.)
The GNU Project (supported by the Free Software Foundation) still "encourage people who redistribute free software to charge as much as they wish or can" [1]. This advice might have made sense in a time of software CDs and dial-up internet, but makes no sense in a era of broadband and GitHub.
When you release something as FOSS, you think people will offer contributions to your code. What you get instead is tons of issues on your issue tracker without anyone trying to solve their problems and taking the issue tracker as some sort of commercial support. If you assume the role of maintainer, you will get more work from sharing your code, not less. And most of that work will be to try to figure people problems because they didn't try to solve them themselves as it's easier to just open an issue and wait. Most of them won't even have looked at your code.
This is easily solved, though : just don't provide an issue tracker (or disable it if there's one, like on github). This may sound harsh, but if what you have to offer is useful, better disabling the issue tracker than not releasing it. People can still fork your code and fix their problem, and you can then merge it in your code. Not every developer is a maintainer.
As a matter of fact, one of the guys in that Twitter thread, Olivier Tassinari - a team member for the Material UI react component kit, acted like he was some kind of royalty when he compared his GitHub contribution history with mine after a disagreement about putting ads in NPM logs.
I can't stand arrogant, entitled assholes like that, especially when I'm supporting everybody by regularly donating money to much, much larger open source projects that everybody uses.
Only people that feel that they are morally superior would go to project issue tracker or public forum and tell maintainer what they can do with their own project. If you do not like it, you can stop using material-ui. At least stop naming people assholes just because they disagree with you.
Olivier Tassinari created one of the highest quality react UI toolkit used literally by everybody. My interactions with him on issue tracker were always positive.
[1] https://github.com/npm/policies/blob/master/open-source-term...
See, here you are automatically assuming that I was "telling a maintainer what they can do with their own project" when that wasn't the case at all. As a matter of fact, I wasn't even talking about Material UI when I posted a comment on one of their issues. I was addressing another user about their ads in NPM.
I'm also not calling someone an asshole for disagreeing with me - I'm calling them an asshole for acting like they're better than you and me and that "contributing code to open source is the only way to support open source". (Did you miss the part where I said he acted like not contributing to any large open source projects made me less of person? Because that's exactly what happened. If you don't believe me then that's probably because you have a personal bias. There's absolutely no reason for me to lie and it's not like I go around talking about this all the time - it's precisely on topic and I happened to see Asshole Tassinari's name in the Twitter thread...)
It'a a lie that code-only contributors are better than others and one that is swallowed hook and sinker by many, many open source maintainers. People who believe it are just protecting their fragile egos.
> They can decide what project roadmap is, they can spam your terminal with ads[1] and they can even remove or abandon the project.
Incorrect. I have since blocked all ads in NPM logs (and then NPM subsequently banned them) thank you very much :) I'll never see another one. And you can't take back an open source project once it's been released in the wild. But thanks for all the free work! I'll continue to use it for as long as I wish.
See, I am not naming you asshole.
> I'm also not calling someone an asshole for disagreeing with me - I'm calling them an asshole for acting like they're better than you and me and that "contributing code to open source is the only way to support open source". (Did you miss the part where I said he acted like not contributing to any large open source projects made me less of person? Because that's exactly what happened. If you don't believe me then that's probably because you have a personal bias. There's absolutely no reason for me to lie and it's not like I go around talking about this all the time - it's precisely on topic and I happened to see Asshole Tassinari's name in the Twitter thread...)
Provide citation or it never happened.
> Incorrect. I have since blocked all ads in NPM logs (and then NPM subsequently banned them) thank you very much :) I'll never see another one. And you can't take back an open source project once it's been released in the wild. But thanks for all the free work! I'll continue to use it for as long as I wish.
You are mistaken, read linked policy. There is a number of cases where ads are permitted. You can decide to block ads but many projects can ask for funding in postinstall.
"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.
(Some will. Most who are express it correctly by never contacting you.)
The reality is popularity and budget are more relevant than licensing in that regard.
Say you pay 1M EUR to Microsoft for their suite, 10k users.
You get an asset manager and a IAM (AD), database, web server, OS, user desktop, word, excel,...
All of this integrated.
On the other hand you have all the pieces separately, maintained or not, and they do not talk to each other.
You saved 1M EUR, which will give you a team of 5 or 7 people who are supposed to maintain and integrate these pieces (the part of work MS does, not the administration you need anyway on top).
It may work or not, but this is far from a given.
If I had to start the IT of a company today I would go for full SaaS for services, Win10 on desktop, and O365.
(just in case and to avoid misconceptions: I like my Win10 desktop much more than a Linux one (tried to switch multiple times in 20 years), run all my home services on Linux and develop open source)
The part that's not cheap is running software yourself, regardless of whether it's open or closed source.
Someone is paying the price for open source software. Employers, employers being stolen from, individuals using their spare time, individuals who have been given/made a lot of money or the state.
I worry for younger people who have an over romanticised view of open source and would ask that they consider how their open source heroes created their software. Were they supported by academia, employment or the state? Make sure you can pay the bills before you think you are ARPANET or Linus Torvalds. Make sure the 100/0s of hours invested were a good use of your time.
The more the better. - The contrary is true. The busfactor is only relevant to closed source. Design by committee works nowhere. Not in the arts, not in engineering.
The project is not maintained anymore, the latest issue or commit was years ago. - This defines stability. no problems, no changes needed.
That is the biggest lie I see. It falsely equivocates a project’s security to its popularity. This is the primary adoption consideration for most JavaScript projects.