After reading it a few times I presume the author is happier than 'somebody who writes code', in the same way that I'm happier to have my car stolen than somebody who needs their car every day.

No, it's simple - if I don't know what I'm looking at, I don't want anybody who DOES know to get to look at it, either. The person who does know how to program in whatever language has an inherent advantage in that situation. Frankly, they also have no real ethical or legal imperative to prevent using whatever possible weakness they can exploit against me; doubly so if they can profit by it.

Rather than the idea of "happier to have my car stolen, etc.", it's more, I'm happier to be the guy who rides the train rather than the bus. I don't know exactly how the train is operated (even if I know the concepts that make it work) - my knowledge extends only so far that I know that it does what it's supposed to. I'd go so far as to suggest that relatively few rail transit riders do know how to properly operate a train - and add to that, trains can only run on rails; i.e. they do one thing well (generally speaking - let's not discuss the number of issues NJTransit's had recently). The potential for hijacking is significantly reduced by inherent limitation and obscurity of control.

So too do I want software along that same thought process. Relatively few users know how to do more than what they need to know; and even so those that would hijack it are locked into a specific set of operations.

Consider this:

Most humans want trains to be safe (A). Some humans are lazy fucks and will risk hurting people or deliberately hurt them to save time and make money (B). Some humans know a lot about how trains work (C). Most humans don't know much about how trains work (D). Some humans don't know anything about how trains work (E).

A train is an object that operates at normal scales, in multiple senses. It is very natural for the state of the safety of a train to be observable to its users. They would know if its rusty and unkempt, if the doors weren't put on properly, if the engine is making unusual sounds, if the conductor looks shady and may be there to scam them. Group D may not know exactly how the train is going to kill them, but you don't need to be in Group C to recognise most design failures. The safety of trains is ensured in part by the size of Group D, operators (Some C, Some B) won't make enough money if Group D refuse to ride the train so they keep standards high.

Now software isn't quite the same as trains. Software has nearly everyone, like yourself, nearest to Group E. Group D is not insignificant - these are those who work with software at a design level, and can spot design faults. Group C are minuscule.

Closed source software means that the only ones checking Group B are the members of Group C who have, for whatever reason, gone the extra mile. Group D are as oblivious as E.

Open source software allows Group D to get involved in checking that the operators are more of Group C than Group B.

---

Your busses vs trains scenario is interesting. Trains are controlled by widely available and auditable schedules, making them more open than the untracked antics of the completely closed source reasoning of bus and car drivers.

You are describing security through obscurity, which was considered a non-starter even before the advent of widely available software. It presumes that everyone who knows something is to be trusted, and everyone who doesn't is not competent enough to bridge that knowledge gap.

See, I see it rather that, no one is to be trusted - whether they happen to know something or not. Like I said elsewhere, it's the Prisoner's Dilemma writ large. My automatic assumption is that all other prisoners are out for their own good, and therefore I want to limit their access to that which they can use to disadvantage or harm me.

Ah thanks, that makes a lot more sense.

I generally don't trust open-source. Too many people have access; and therefore I assume anything open-source has zero security. It's a related to the Prisoner's Dilemma - it's most advantageous to those who find exploits to use them for their own good rather than report them and reduce them.

>Too many people have access; and therefore I assume anything open-source has zero security.

I don't think it's fair that you were downvoted, but this is an idea that developers and IS professionals tend to disagree with [1]. Even detractors don't feel that higher code availability correlates with lower levels of application security.

1 - https://www.schneier.com/essays/archives/2004/10/the_non-sec...

I consider it a given that developers and IS professionals would (at least) publicly disagree with that statement. After all, if they agreed that closed-source was better, there would be fewer open-source projects, which gives them a smaller resource set. In the end, whether or not it's more secure isn't really the issue, it's what keeps the paychecks coming more effectively.

Being able to use code blocks from FOSS projects makes a developer's life easier, rather than consistently reinventing the wheel. It also allows for more code to get out the door, faster. So whether they're paid on salary so they can just browse GitHub (or SourceForge, etc) for the code they're looking for, or paid by project so they want to get things out quick, it's beneficial to have many open source projects across the entire ecosystem of computing.

Being able to review source makes an IS professional's life easier, because rather than testing the I/O of a black box (which is often time-consuming), they can look over "important sections" of the (often human-readable) code. With something like Notepad++, they have code indentation and highlighting, and can search for key phrases to identify those "important sections" which often show some kind of major security hazard. This means that they get more projects done, in turn being able to make more money.

So when you look at the situation from a "cui bono?" ("who benefits?") perspective as a relative outsider, those two groups of people who are most strongly in favor of open source are the two groups which are most likely to benefit from it. As such, I consider their statements subject to bias, whether conscious or not!

There are similar arguments that have been made by tech professionals in favour of closed source software. I'm not clear as to why you disregard the potential bias here, and why you think that subject matter expertise should disqualify an arguer. Frankly, this reads as ad hominem and conspiratorial thinking to me.