
Ask HN: What's the greatest lie of open source? - niksmac
Inviting thoughts based on https:&#x2F;&#x2F;twitter.com&#x2F;brian_d_vaughn&#x2F;status&#x2F;1258792447557038080?s=20
======
fbhabbed
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.

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

~~~
jka
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
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 :)

~~~
14k12j41j211
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.

------
open-source-ux
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](https://www.gnu.org/philosophy/selling.en.html)

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

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

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

~~~
Chyzwar
They are not morally superior to others. They just have more ownership over
open source projects. They can decide what project roadmap is, they can spam
your terminal with ads[1] and they can even remove or abandon the project.

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...](https://github.com/npm/policies/blob/master/open-source-terms.md)

~~~
wayneftw
Thank you for proving my point.

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.

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

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.

------
ironmagma
If you find a bug or even just a mistake in the documentation, you can fix it.
In actuality, there is such thing as too small a fix, or the process for
merging code can be made arbitrarily large, or the maintainer might just not
want to make the improvement that obviously should be made.

------
eesmith
"The effort[1] of making something open source will be more than made back by
external contributions."

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

~~~
niksmac
The problem I can see is with all those PRs. Nobody ever merge them.

~~~
eesmith
While my OSS projects rarely result in any feedback. Even with packages I know
are used by many.

------
ncmncm
That people will be thankful, and not demand your time and attention.

(Some will. Most who are express it correctly by never contacting you.)

------
CyberFonic
If you write it, they'll use it ... and contribute to it ... and fix your
bugs.

------
krapp
That being OSS guarantees higher quality and safety than proprietary software,
because unlike with proprietary software "with enough eyes all bugs are
shallow, and anyone can fork or contribute."

The reality is popularity and budget are more relevant than licensing in that
regard.

------
BrandoElFollito
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)

~~~
karmakaze
Opensource does make things cheaper at scale. Some of those SaaS services run
software that is or based on opensource. This is especially true when you have
multiple SaaS companies providing services based on the same opensource
software. Even closed source software benefits from using libraries with
permissive licenses.

The part that's not cheap is running software yourself, regardless of whether
it's open or closed source.

------
p0d
That there is no cost in open source software.

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.

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

------
grizzles
I don't know if it's a lie but there sure is a lot of spyware these days. For
example, if you follow the directions to disable telemetry in strapi, it still
stays active in certain configurations (eg. devmode). In other modes it loads
external resources that can be used for tracking.

------
rurban
Many:

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.

------
austincheney
_Vetted by the community._

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.

------
Zooper
That it doesn't cost something. And, that anything that costs something must
be paid for by a false choice between an oligarch and a tyrant.

------
smitty1e
"Web framework X is designed with emphasis on simplicity, performance, and
reliability."

------
uwuwuwu
That it's more secure.

------
kleiba
2020 is the year of the Linux desktop.

~~~
kleiba
Sorry, I forgot that HN is a humor-free zone. Or maybe some kids are too young
to have heard of this joke. Or maybe some running gags have simple reached the
EoL, in which case I understand the downvotes.

