A century or so ago, enterprises faced a key decision about their mission critical infrastructures: develop and deploy their electric-powered applications over direct current (DC) or alternating
current (AC)? Thomas Edison backed DC, while Nikola Tesla and George Westinghouse put their money on AC. Edison had the first-mover advantage in the electricity business, and, at least at first, DC
was a winner, technically. Eventually, though, Westinghouse and Tesla worked the bugs out of AC and offered an even better solution for electricity distribution. Never one to give up easily, Edison
went so far as to promote the use of AC, which he considered dangerous, to electrocute large animals, including an elephant, as well as back development of the electric chair (see “War of Currents”).
We all know how things turned out, and even Edison eventually acknowledged AC's superiority – but some of the enterprises that chose DC over a century ago were still stuck with it as
recently as last year (see “Off Goes the Power Current Started by
Thomas Edison”).
For some, Edison and DC represented the job-preserving choice, as in the old adage, “Nobody ever lost his job buying IBM.” Part of that decision was undoubtedly due to Edison's early
dominant position in the industry (the New York City electric utility is still called Con Edison, after all), but part was surely due to preconceptions and “common knowledge” about
electricity that Edison encouraged. The same goes today for the many enterprises facing a choice between open source and proprietary software.
Open source software may be free of charge (usually), but it comes with plenty of its own preconceptions and “common knowledge.” What are some of these preconceived notions, and why are
there so many? I'll introduce some of the most common ones – without either debunking or proving them. At the moment, my objective is simply to point out how people make assumptions about
software they purchase that may or may not be warranted, and prompt some discussion about how to talk about software.
You needn't be inclined to see conspiracies to assume that some anti-open source memes might originate in Redmond. For ammunition in the debate over Windows Server versus Linux, one needs to look
no further than Microsoft's “Compare Windows vs. Linux” page; this site was originally called
“Get the Facts. But it would be simplistic to believe that Microsoft and the rest of the proprietary
software industry was responsible for all negative press about open source software.
While many preconceptions are offered as “facts” by proprietary software vendors, many more come from all around us, whether in the form of water-cooler gossip or reported as fact by
the media and trade press. Consider:
Given the degree to which proprietary software dominates the market, it's easy to see that the kind of things that “everyone knows” about software would tend to favor proprietary software.
It would be easy start a discussion of open source software preconceptions by looking to Microsoft's famous “Get the Facts” campaign and taking the opposite positions. These are the
current takeaway bullet points from the Windows vs. Linux page:
Microsoft wants to convince you that for the same application, a Windows server will work better than a Linux server. So, the corresponding preconception that you can derive from the first bullet
point might be, “Despite being available for no charge, open source software actually costs more than proprietary software.” Likewise, the preconception derived from item 3 might be,
“Open source software is less secure than proprietary software,” and so on.
While easy, this is also an easy way to be led down the garden path, by allowing Microsoft to frame the overall discussion. Consider the question of cost: surely, no organization can afford to
spend more than absolutely necessary on software. Yet most of the TCO studies I've seen are sketchy at best about methods, usually relying on telephone or email surveys to generate data from
corporate IT staff who are asked to estimate their costs, rather than any more rigorous audits of actual costs. Even if I'm willing to accept that a Linux server requires 20 more hours per year to
administer, I'm not quite ready to believe that means an added cost of $1,000 per year if my system manager is salaried.
Rather than allowing Microsoft to guide the discussion, I'd rather look at some of the more fundamental questions raised by any discussion of any kind of software. I won't offer any answers (at
least, not in this article), nor will I even attempt to rebut any of the preconceptions. I'm just going to put these ideas out as starting points for discussing how to talk about open source and
proprietary software.
In the interest of full disclosure, I should note my personal bias strongly in favor of open source software – and yet I am willing to consider the possibility that proprietary software can
be just as good, or even better, than the software I prefer to use.
I need quality code, and I can only get that from a proprietary vendor. If “you get what you pay for,” shouldn't proprietary software offer higher
“quality?” Proprietary software, developed by a corporation with an organization specifically put together to design software and assure quality, should be “better” than
open source software.
Open source developers just don't have the kind of customer/user orientation that proprietary vendors have. Proprietary software vendors are in business to sell software, and if
they don't respond to the needs of their users, they will lose market share and eventually go out of business. So, obviously, proprietary software vendors will produce software that is better for
their customers.
Open source vendors don't do innovation. Only big companies can afford to do blue-sky R&D and come up with innovative new products and features. If you look at most open
source projects, they're just copying the functionality of existing successful proprietary software.
Without proprietary protection for code, there's no profit motive for open source software. How could open source software, like MySQL, possibly compete with a proprietary outfit
like Oracle? All the MySQL code is out in the open, so if they did anything really new or innovative, Oracle could just use that in their own products. It's the competition inherent in the
commercial software market that produces software that is so much better than open source.
Cost, or “total cost of ownership,” is lower for proprietary software. Open source software, when I buy it from an open source vendor like Red Hat, is expensive. I can choose from a bigger pool of qualified people with skills certified by proprietary software vendors, so my personnel costs will be lower. Since the cost for high-end support, the kind I need for my enterprise, is about the same for open source and proprietary software, my overall costs are going to be higher with open source.
Proprietary software is better for security and privacy issues. Obviously, open source software has to be less secure: anyone can look at the actual source code! How much easier
could it be to write a virus that could subvert an open source program? And commercial software vendors have to be careful about security and privacy, since they stand behind their code. They're
accountable for their software. And, unlike open source projects, proprietary software vendors have the staff and resources to handle security issues the right way.
I raise these issues in order to examine them critically. You might assume that my bias in favor of open source software means I believe all these statements to be false – but that is not
correct. Nor should I assume that proprietary software proponents would believe them all to be true. The proprietary software industry would like their customers to believe they are all true,
though, and software vendors have not been shy about presenting evidence in favor of their position. In upcoming articles, I'll bring evidence to counter these preconceptions.
Recent articles by Pete Loshin
Pete is Founder of Internet-Standard.com, an open source and open standard computing consultancy providing technology assessment, needs analysis and transition planning services for organizations seeking alternatives to commercial software. Pete has written 20 books, including “TCP/IP Clearly Explained” 4th Edition, Morgan Kaufmann, 2003) and “IPv6 : Theory, Protocol, and Practice,” 2nd Edition (Morgan Kaufmann, 2004).
Pete can be reached at pete@loshin.com or at 781. 859.9175.