Live data from Hacker News

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

news.ycombinator.com

11–20 of 37 posts

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

#11
post #8

The greatest lie of open source? Assuming that an open source program is safe just because the source code is public. 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. Sec…

Many of those things are solved by outsourcing it to a distro. Sure it's not perfect but having a maintainer layer between the developers and the users has proven much safer than blindly trusting the developers like npm. It also scales much better than doing it yourself.

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.

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

#12
post #10
post #8

The greatest lie of open source? Assuming that an open source program is safe just because the source code is public. 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. Sec…

Sigh. You're not wrong, but I do believe that we can change the dynamics over time :) 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 requi…

There's still both motivation and workforce missing to overhaul the desktop. It's not usable and in fact harmful for any average user.

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.

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

#13

That people/organisations (who benefit from a project) will contribute. Some do.. however many organisations take and don't give back. They are quick to move on when the open source project falters (or original maintainers burn out) rather than rally toward a solution.

That's the one I would have mentioned as well.

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.

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

#14
post #8

The greatest lie of open source? Assuming that an open source program is safe just because the source code is public. 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. Sec…

[deleted]

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

#15
post #8

The greatest lie of open source? Assuming that an open source program is safe just because the source code is public. 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. Sec…

> 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.

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.

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

#16
The following is not a lie of the open source ethos, but I would describe it has one of it's biggest failures: That you can sell your open source product to users and make a living from it.

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.

[1] https://www.gnu.org/philosophy/selling.en.html

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

#17
Not exactly a lie, but I guess a drawback: while having a source code is nice in a way people could know that the program is safe, in the same way open source is also more prone to getting hacked. The reason is because potential hackers could study the source code in-depth to figure out potential security loopholes/corner-cases, something that's a lot harder to do on proprietary software whom hackers don't have access to the source code.

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

#18
That it is cheaper at scale.

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)

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

#19
post #8

The greatest lie of open source? Assuming that an open source program is safe just because the source code is public. 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. Sec…

Safety is a big bag that includes a lot of things, with a lot of players. In 2013 we learned about one of those players, laws made to support them, and having faith that that player won't act instead of having a non illegal way to verify that it is happening.

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.

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

#20
The greatest lie of open source is that open source contributors are morally superior to testers, donators and people who take their time to submit detailed issue reports.

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.

Post reply on HN