Response to Mr. Brown's critique of Open Source Software.

[Note: this response was written on June 10th, from a paper that Mr. Brown
apparently found fit to withdraw after initial publication. The URL that
the paper had previously been found at
(http://www.adti.net/html_files/defense/opensource_whitepaper.pdf)
stated, "The White Paper will be available by the close of business, June
10, 2002." Being as it is now after 8:00 p.m. EST, and the paper is still
not in evidence, I will not wait any longer to see if Mr. Brown has
changed his initial paper.]
 
Every now and then, you hear about or read something that forces you to
look at things in a new light, to marvel at the goings-on of the Universe.
 
The paper, "Opening the Open Source Debate," written by Kenneth Brown,
president of the Alexis de Tocqueville Institute, fails utterly and
entirely to accomplish this.
 
Regardless of the stance that one takes on a given issue, it is always
enjoyable to find a well-reasoned, objective treatment of said issue,
allowing the reader to consider previously un-thought-of venues and
realize new insights. However, this "paper," with a clear, very
subjective stance, does nothing except embarrass anyone who takes it
seriously. From the quirky use of English, to the figures cut out of
whole cloth, one has to wonder what possessed Mr. Brown to sit down and
put pen to paper.
 
An example of the questionable figures that Mr. Brown uses is this: "In
the U.S., the software sector accounted for approximately 319 million jobs
in 2001." Software has clearly taken off when it employs more people than
live in the country. If it were merely a typo, it might be forgiven, but
he then refers to his appendix, where the same figure resides, with
further reference to www.bls.gov/ces/home.htm#data, where the most I can
find is some 2.2 million, or slightly under 1% of the country's gross
population. While I admit I'm not certain of my figure in relevance to
whatever Mr. Brown thought he was quoting, at least I'm not presenting
something that is clearly incorrect.
 
If this were the only mistake, I would be tempted to let Mr. Brown off
fairly lightly. However, that is only the beginning. While he may term
his paper a "debate," one usually has to prop up premises with facts in a
debate; Mr. Brown showed no reluctance in avoiding this restriction.
I will start from the beginning, so that the interested reader may follow
along:
 
Brown: "Executable software accompanies binary code..."
Truth: Executable software -is- binary code; the two are one
       and the same, at least withing the bounds of the arguments
       that are being put forth.
 
Brown: "Open Software is not necessarily free software."
Truth: This is akin to saying "Water is free, usually." It's
       such an open-ended statement that it begs further
       qualification, not free-ranging pot-shots.
 
Brown: The entire section labelled, "GPL Open Source -- The
       Gift that Keeps Taking".
Truth: Aside from the fact that the heading, itself, proves that
       Mr. Brown has no interest in objectivity, the section is
       so full of mis-representations and accusations, with nary
       a shred of supporting evidence, as to make one cringe.
       First, he attempts to show that the Gnu Public License
       (the "GPL") is overly restrictive... and proves it by showing
       how open it is. Then, having failed in this endeavor, he
       decides that character assassination is not below him, and
       takes aim at Richard M. Stallman. "The controversial nature
       of Stallman's position began to turn away his supporters.
       [...] The rise in the popularity of Linus Torvalds and the
       Linux open source operating system began to create new
       supporters. Ironically, Linux supporters became the biggest
       proponents of the GPL." Clearly, Mr. Brown uses a different
       definition for the word "ironically" than do most. Linux
       supporters became proponents of the GPL not because they
       like Linux, but because the like the GPL. If anything, one
       could argue that they like Linux because of the GPL, and
       not the other way around.
 
Brown: Another section, entitled "The Myth of a 'Public Software'
       Community".
Truth: First and foremost, the heading implies a thesis to follow,
       and then supporting argument. This is entirely untrue. I
       don't know what point Mr. Brown tries to make in the argument
       (perhaps that federal dollars can act as a catalyst in the
       private sector? I'm really unsure.), but he fails across the
       board to address anything, much less prove anything.
 
Brown: In the single attempt Mr. Brown makes to find an alternative
       viewpoint, he quotes Rossz Vamos-Wentworth, "Security holes
       are eventually found, with or without open source code."
Truth: The security world holds to two viewpoints, neither of which
       is entirely conclusive. The truth lies somewhare in the
       middle. The viewpoint that the paper puts forth is that, if
       you can read the source code, it makes it all the easier to find
       security holes. Ironically, this is also the opposing camp's
       viewpoint; they, however, would append "and then fix them" to
       the sentence. The problem with closed-source software is that
       you generally find out it's insecure in one of two different
       ways: when the manufacturer decides to let you know, or when you
       get cracked.
 
Brown: A whole paragraph with a slew of questions. I will reproduce
       them here in their entirety: "Issues include: Who should have
       the right to alter software manuals? Who is the final editor
       or is there one? How should changes be regulated? Are manuals
       copyright protected documents? What is the process for making
       changes? What body regulates these changes? How can organizations
       guarantee that information in manuals is always accurate?"
Truth: WITHOUT EXCEPTION, every single one of the above questions can
       be applied -- in some cases, moreso -- to the private sector.
       The mere fact that Mr. Brown bothers to ask these seemingly
       rhetorical questions to bolster his position speaks plainly of
       how little he knows about the basic functioning of a real-world
       software or hardware company. I know one very competent end-user
       who spent TWO DAYS attempting to get a router to work properly.
       Why was he unable to? Because the manual, from one of the largest
       network equipment manufacturers, left out a two-word command.
       In other words, the entire paragraph should apply, in my
       considered opinion, to the software community at large. The
       only documents that I consider to have good editorship and
       version control, for the most part, are those by large,
       non-proprietary organizations such as the IEEE and the RFCs,
       describing open protocols, that are the white papers upon which
       the Internet is based.
 
Brown: "It becomes unrealistic for a firm to depend too much on the
       'trust'of an anonymous community..."
Truth: When an electrical engineer designs a "widget," one thing he
       tries very hard to avoid is "single sourcing" a component.
       In other words, the engineer goes to great lengths to make
       sure that no given component can only be obtained from a
       single vendor. The reason for this is that, were the vendor
       to go under, or change its structure, or simply cease to
       produce the component, suddenly the engineer's company would,
       at a minimum, have to spend time and resources to redesign
       their widget, and in a worst-case scenario, would be forced
       to halt its production entirely. This is -exactly- the case
       with closed-source software. Far better to have a loose-knit
       community that is, and always will be, able to assist you
       than one commercial entity that could fail tomorrow. Just
       ask users of Wang word processors how much trouble they had
       getting their information onto a more... well, "open" platform.
       Furthermore, on top of the community, itself, there are also
       a wide range of Open Source vendors (eg. Red Hat,
       http://www.redhat.com) that offer service and support contracts,
       and have under their employ some of the stars of the Open Source
       community. Ask yourself: when you have competing vendors offering
       support, do you get better service than when you're locked in? I
       clearly don't need to bother answering that rhetorical question.
 
Brown: "While each of these firms would insist that they are not against
       copyright protection, invoking the protections argues that they
       are against people copying their marketing documents and symbols."
Truth: While I'm sure the preceding sentence is supposed to prove some
       purported point, the fact that it's an oxymoron makes it difficult.
       Okay, apologies: it's not an oxymoron, it's an "identity:" he just
       restated the same thing, when he was attempting to contrast
       something. Mr. Brown should clearly leave abstract thinking for
       others.
 
Brown: "The purchase price of computer software is only a fraction of the
       total cost of ownership ["TCO"]. So even if the price tag reads
       "free", it can end up being more expensive than software you buy.
       This is especially true for the typical consumer. If it requires
       technical know-how to operate, doesn't offer built-in support, and
       demands constant attention, it won't feel free for very long."
Truth: All this is very well and good... but it leaves out the fact that
       the "average consumer" doesn't know how to fix a broken Windows
       box, either. Once something goes wrong with proprietary software,
       more likely than not, the answer is "re-install." This doesn't
       strike me as a cost-beneficent solution, especially when time to
       re-configure the system is involved. On the other hand, most
       computers with Linux installed on them only have to get re-booted
       when the machine has to be powered off to install new hardware.
       Contrast this with re-booting to install, say, a USB driver for
       a camera. And, if support is needed, it's actually -easier-
       for people to remote-administer an Open Software machine than
       a closed one; so long as you trust the remote operator, they
       can likely fix you without having to lug your machine to Comp USA.
 
Brown: "If a software application representing 5000 hours uses GPL code
       that reflects only 100 hours, is the GPL fair in its argument that
       the entire product is GPL?"
Truth: This may be the least insightful argument Mr. Brown has used thus
       far. Clearly, if only 100 hours' additional work would be required,
       and the author wished for the software to remain proprietary, then
       he would put in the 2% extra work himself. NOBODY forces ANYONE
       to use GPL code; rather, it is there as a resource. If you choose
       to use it, knowing full-well the ramifications, then, yes, the
       license is applicable. Otherwise, you don't. As opposed to
       closed source, at least you have a choice.
 
The rest of the paper meanders on; there are some other issues regarding
legal precedence in which Mr. Brown, to be blunt, makes me wonder whether
he is ignorant, or intentionally deceitful. ("There are unlimited
scenarios for accidents to occur, the license could be lost in the source
code's distribution, or maybe unreadable due to a glitch in its electronic
distribution." Do you eat candy you find, unwrapped, lying in the street?
No. And neither should a software firm; instead, any firm worth its charter
practices due diligence and is very careful of licensing, regardless of
whether it's open or closed. Common sense is clearly not one of Mr. Brown's
strong points.)
 
In his conclusion, I find it ironic that he names IBM as spending billions
on development, and wondering if Open Source would put their development
at risk. The reason I find this ironic is that IBM has put around a
billion dollars into Linux, itself, only to find it reaping great rewards
as it is able to make use of Linux's synergy, letting them minimize
in-house development costs, and allowing the lowering of their systems'
TCO, and, therefore, raising their margins and allowing them to compete
more proactively in the marketplace.
 
Or perhaps Mr. Brown is against competition, period.
 
Sincerely,
 
Ken D'Ambrosio
Merrimack, NH