Can you give an example of bad Linux advocacy thinking?

Idealists care too much about ideas
and not much at all about people.

Some of them are discussed in my first and second papers. It's not limited to ESR. For example here is a stance by Evan Leibovitch in his essay In the middle lies sanity:

The GNU Project was around long before Linux. But it's not a stretch to suggest that GNU was a relatively obscure phenomenon before Linux brought its benefits front and center to the computing mainstream. Stallman's belief that it is better to have poor-quality free software than high-quality proprietary stuff might have forever kept the GNU world view as a niche had Torvalds' pragmatism not brought it out.

Here both facts ("But it's not a stretch to suggest that GNU was a relatively obscure phenomenon before Linux" -- IMHO it's a stretch and FSF was pretty well known long before Linux) and Stallman's views were deliberately twisted (I fully support the FSF idea that in many cases even poor written program with the source is more useful than much more polished closed source program; moreover FSF products were mostly first class software products). There is also a clear attempt to diminish the importance of FSF. Essentially he is saying that FSF were being narrow-minded and Linus Torvalds was a kind of "true pragmatist" (i.e. "liberator of oppressed masses"). But the fact that companies release software using GPL implies that they see business rational behind GPL. Now please tell me who in this case is a real pragmatist ;-)

Actually almost any Eric Raymond major paper can serve as a good example because each contains a lot of  oversimplifications, overgeneralizations, explicit and implicit attacks of FSF, attempts to contribute to Linus Torvalds'  "personality cult" and/or plain-vanilla fairy tales (that's why I called this phenomenon Raymondism in my first paper), but any his interview or commentaries about Microsoft is especially good starting point. Here is one recent sample called "Microsoft -- Designed for Insecurity" that clearly demonstrate that ESR did not research the problem, checked facts or understand the issue he is writing about.  It's just plain-vanilla pontification about merits of open source and I especially like the final phase "Cockcroaches breed in the dark. Crackers thrive on code secrecy. It's time to let the sunlight in." :-). Here is the story: 

News services all over the world reported today (14 April 2000) that Microsoft programmers had inserted a security-compromising back door in their FrontPage web server software. Thousands of websites worldwide may be affected. Representative coverage of this story can be found at CNET.

Amidst all the nervousness about yet another Windows security hole, and not a little amusement at the passphrase the Microsoft programmers chose to activate the back door ("Netscape engineers are weenies!") there is one major implication of this story that is going unreported.

This back door seems to have been present since at least 1996. That's four years -- *four years* -- that nobody but the pranksters who wrote it has known about that back door. Except, of course, for any of the unknown crackers and vandals who might have found it out years ago. All the world's crackers certainly know about it now after the worldwide media coverage.

Webmasters all over the world are going to be pulling all-nighters and tearing their hair out over this one. That is, webmasters who are unlucky enough to work for bosses who bought Microsoft. At the over 60% of sites running the open-source Apache webserver, webmasters will be kicking back and smiling -- because they know that Apache will *never* have a back door like this one.

Never may sound like a pretty strong claim. But it's true. Because back doors (unlike some other kinds of security bugs) tend to stand out like a sore thumb in source code. They're hard to conceal, easy to spot and disable -- *if you have access to the source code*.

It's the fact that the compromised Microsoft DLL was distributed in opaque binary form that made it possible for the good guys to miss this back door for four long years. In the Apache world, every every one of the tens of thousands of webmasters who uses it has access to the Apache source code. Many of them actually look at code difference reports when a new release comes out, as a routine precaution against bugs of all kinds.

Under all that scrutiny, a back door would be unlikely to escape detection for even four *days*. Anybody competent enough to try inserting a back door in Apache knows this in their bones. So it would be pointless to try, and won't be tried.

What's the wider lesson here?

It's pretty clear. Anybody who trusts their security to closed-source software is begging to have a back door slipped on to their system -- with or without the knowledge of the people who shipped the code and theoretically stand behind it. Microsoft HQ is doubtless sincere when it says this back door wasn't authorized. Not that that sincerity will be any help at all to the people who will have to clean up the mess. Nor will it compensate their bosses for what could be millions of dollars in expenses and business losses.

If you don't have any way to know what's in the bits of your software, you're at its mercy. You can't know its vulnerabilities. You can't know what *other people might know about it that you don't*. You're disarmed against your enemies.

Does this mean every single webmaster, every single software consumer, has to know the source code of the programs they use to feel secure? Of course not. But open source nevertheless changes the power equilibrium of security in ways that favor the defense -- it means back doors and bugs have a short, inglorious lifetime, because it means the guys in white hats can *see* them. And even if not every white hat is looking, potential black hats know that plenty of them will be. That changes and restricts the black hats' options.

Apache has never had an exploit like this, and never will. Nor will Linux, or the BIND library, or Perl, or any of the other open-source core software of the global Internet. Open-source software, subject to constant peer review, evolves and gets more secure over time. But as more crackers seek and find the better-hidden flaws in opaque binaries, closed-source software gets *less* secure over time.

Who knows what back doors may be lurking right now in other Windows software, only to be publicly acknowledged four years in the future? Who *can* know? And who in their right mind would be willing to risk their personal privacy or the operation of their business on the gamble that this is the *last* back door in Windows?

The truth is this: in an environment of escalating computer-security threats, closed source software is not just expensive and failure-prone -- it's *irresponsible*. Anyone relying on it is just asking, *begging* to be cracked. If theory didn't tell us that, the steadily rising rate of Windows cracks and exploits over the last eighteen months would.

Cockcroaches breed in the dark. Crackers thrive on code secrecy. It's time to let the sunlight in.
--
Eric S. Raymond

He retracted this article later but still insists  "The bottom line is very simple: Closed source can't be trusted, because you can't see what it's doing.". I used to work in this area and things are much less simple for me than for Eric Raymond. Anyway, here is his retraction:

The status of the "back door" I discussed in "Microsoft: Designed For Insecurity" is now uncertain. Since the problem was reported on 14 April by BugTraq and the Wall Street Journal, one of the people involved in discovering it has retracted his report. There is now dispute over whether this problem was due to a genuine back door or a server misconfiguration.

The general point of "Designed For Insecurity", though, is independent of this particular incident. As if to illustrate this, there is yet another back door report from 13 April that may affect hundreds of e-commerce sites. See

http://www.internetnews.com/ec-news/article/0,2171,4_340591,00.html

The key quote in this story is this one from Kasey Johns, webmaster of one of the affected sites:

"I want the right to look at the code, make modifications, and not be locked into whatever ghosts the author has hiding in there," said Johns.

The security and trust problems that come with that kind of lock-in are the real point here, not the details of any particular exploit or the name of the vendor attached to it.

The bottom line is very simple: Closed source can't be trusted, because you can't see what it's doing.