In the past few months, the debate concerning which software purchasing/licensing protocol is better, open source or proprietary, continues to percolate in the TechRepublic discussion boards. On one side of the debate, we have the camp that distrusts the motivations of the open source community and dismisses the viability of an economic model that does not revolve around the exchange of wealth. On the other side, we have the camp who distrusts the multinational conglomerate software giants and their preoccupation with earnings and control. Stuck in the middle are people like me, who have no technological agenda to champion, but instead just want to get some work done using the best software they can get their hands on.
While the debate will probably never completely die, perhaps we can help turn the heat down enough to reach a slow simmer by analyzing the current debate with an eye toward establishing common ground and a rational perspective.
Foot in the door
The one significant change in this ongoing debate has been the increasing acceptance of open-source software as a viable alternative to traditional proprietary applications by the decision makers who control the enterprise purse strings. As I suggested in a recent discussion thread:
The question is no longer whether open source is viable, but whether IT professionals will install such applications in their respective organizations. This subtle change means that open source software is now competing on the basis of effectiveness, cost, reliability, security, and features rather than merely trying to get a foot in the enterprise door.
However, when it comes to Linux, not everyone is convinced it is ready for the end-user desktop. For example TomSal argues that:
Linux won't be on the desktops soon — maybe a mondo huge companies OR companies that the nature of their industry means all their users are engineer types; but the average Joe small business shop with users who need their helpdesk to figure out how to change a default printer or change a font in Word, EXTREMELY unlikely that Linux will find a home there anytime soon.
Linux needs to be friendly to the "AOL" crowd first..then we as IT folks can bring serious arguments to our CIO/CFO and CEO's to why Linux is a good switch for the corporate desktop.
I used to think along similar lines myself. I believed that Linux required the use of long command line strings with weird syntaxes and cryptic parameters. Point & Click Linux, which was recently featured on TechRepublic, changed my mind. The MEPIS Linux distribution version included on the CD accompanying the book is about as simple to install as it gets. The "Linux is too difficult to install" mantra just doesn't hold water anymore. As apotheon observed:
I find that end users are even less likely to be able to install a Windows OS properly without help than certain very user-friendly Linux distributions. SuSE comes immediately to mind. Fedora and Progeny Debian both use the Anaconda graphical installer, which is more friendly and easier to use than the Windows installer. MEPIS is so incredibly easy to install on the hard drive that it beggars the imagination.
Even Debian (my personal favorite distro for a great many reasons), once used as the poster child for how difficult Linux is to install, has had its installation process revamped to the point where installing the base operating system consists of little more than accepting default options.
Anyone trying to make a case for sticking with Windows based on how easy the OS is to install has not been paying attention.
Summing it all up
But even if you accept the idea that Linux and open source software is ready for end-user desktops in many enterprises, you may still have to overcome other barriers to more widespread acceptance. Security concerns revolving around the implementation of software are a major concern for any organization, especially if regulatory and legislative compliance is a part of the equation. Enterprise decision makers need assurances that the software deployed within the organization is secure. This is the concern expressed in a TechRepublic discussion thread started by KaceyR:
In keeping up with the Open Source software movement, I've come across a single, basic flaw.
The only way to ensure that your executable is as it should be, is to perform a comprehensive review the source code and to recompile it yourself.
I can, very easily, set up a distribution web site that contains both the source code and compiled executables, complete with my own hooks in the executables that will do whatever I want them to. The typical user will download the executables, maybe even the source, but will never perform a compile, and I certainly won't have my hooks in the source that they can review.
Without a complete review of the source code and an independent compile yourself, you have absolutely no assurance that the code you are running matches the source code that it's supposed to. Should that code damage or otherwise compromise your system, what's your recourse? Rebuild your system.
In addition, if you have the time and intellect to review and completely understand the source code, why are you wasting your time downloading someone else's product when you can make your own with the same level of effort?
By example, let's say you download a copy of Firefox, and it's been tweaked with a hack that allows an external user into your system. You're browsing around the internet and everything is great, then one you realize that you've lost all of your data. During a post-mortem, you discover that Firefox was the culprit, so you go after the developers at Mozilla. Oops! The signature of the executable doesn't match ANYTHING the original developers have ever released. They're not responsible. Time to rebuild your system.
Now let's say that you're running proprietary software and the same thing happens. During the post mortem you discover the culprit is the ABC product from XYZ company. The file signatures are compared and, sure enough, they match. XYZ company is clearly responsible, so they will be inclined to assist you in determing the exact cause and fixing the problem, as well as you (possibly) having a legal recourse against XYZ company.
This is both a level of protection and a level of assurance that the program will perform as expected.
Companies today are very paranoid (and rightly so) about system intruders and industrial espionage. With this in mind, why would you turn to Open Source software?
In a nutshell, this argument is probably the main reason more companies have not implemented open source software solutions en masse. Whether it is deserved or not, the perception has been that open source is not as robust as proprietary software—that, when it comes to support and accountability, there is no single entity whose proverbial feet you can hold to the fire. Backers of open source software have their work cut out for them when it comes to overcoming this lingering stigma.
Perhaps the best answer to the "is open source software secure" question posed by KaceyR was expressed by bhoule:
Several years ago, a long time commercial database product (Borland InterBase) was turned over to the Open Source community. Only after its public release was it discovered that an unpublished "back door" previously existed to bypass the security of both the DB and the OS it ran on.
How can you be sure that the same situation does not exist in other commercial products? Without access to the code, how will you ever know? With open source, at least the possibility exists that nothing similar will sneak by. But does this mean that everyone should eschew commercial software? Certainly not.
Open Source is not a cure-all, nor will commercial vendors ever drive the open code model away. The decision to implement one vs the other is a function of economics and trust. Do you trust the open source community more than you trust your vendor? Is the long-term TCO of open source greater or lesser than that of commercial programs? There is no right answer. Neither camp is 100% correct. It boils down to an individual's decision in specific situations.
But this concept of individual choice and responsibility brings to mind another trap that KaceyR falls into. The claim is that the only way to know if an open source product is safe is to personally perform a code review. While speciously correct, the argument neglects the power of community and the monitoring and reporting that the collaborative open source environment provides. If living in a vacuum, open source exploits — theoretical or otherwise — would have a field day. But the reality is that with millions of eyes in the open source community, such an exploit would not exist for long. One could be paranoid and demand a self-performed code review on every single open source app, but then I would expect such an individual to be testing their gasoline before filling their car's tank just to be sure it wasn't ethanol or diesel!
Lastly, KaceyR's legal liability hypothetical was a bit of apples/oranges. A checksum-validated commercial product was compared to a checksum-failed open source project. Let's turn that around and compare like items: a commercial vendor is no more likely to support a checksum-failed product than an open source provider is. As for the checksum-validated converse, while it may be technically true that legal recourse would be possible in the commercial situation, reality dictates that no-fault EULAs and the long legal process would render the point moot. Legal indemnification of commercial software serves mainly to bolster the trust-in-your-vendor argument.
Trust in whom you feel appropriate. It seems clear from the comments that KaceyR will live happily in the commercial world. Zealots, meanwhile, will run with Linux on their desk, Opie on their PDA, and Freevo on their DVR. The rest of us will continue to strike that balance of economics and trust.
The question of secure software is very compelling at first blush. Fear, uncertainty, and doubt are difficult obstacles to overcome, especially in organizations not culturally attuned to change. Tried and true may cost more over time, but they are a known quantity, bringing with them the comfort of predictability. But when you get to the core of the matter, what makes software secure; how much assurance and trust can you have in anything software related? Bugs, bad installs, and broken features are all just part of the experience for any IT professional in an enterprise setting. Things happen.
In the final analysis, it comes down to service and confidence. As an IT professional, when making any software purchasing decision, you must consider the quality of the service agreement (if there is one) and use it to assess your confidence in the overall viability of the software in question. This applies whether the software is proprietary, open source, or developed in-house.
As t_mehta put it in a discussion post:
- Trusting any software is a question of faith and testing—Can we trust any/ all proprietary software to be absolutely perfect—nope, same is true for OSS front—no difference here.
- Will finding whose responsible for a coding problem in OSS or in MS or Borland etc. solve the problem in my plate now - nope, you've got to wait for someone to fix it, who pays that guy is irrelevant - no difference here.
- If you are a corporate with service support—commercial OSS support and proprietary support is equally good—no difference here.
- If you chose to download & install software with no support identified in advance—e.g. freeware on MS or Linux—your support options are the same—NIL, if things go wrong its your funeral—no difference here.
- Legal recourses are the same if you have the same support agreements in place—no difference based on platforms (OSS/ Proprietary).
Overall, the argument put forth is axiomatic since in simple words it says proper service agreements are useful to customers irrespective of the source/ ownership of the software installed - that's like saying 2 + 2 = 4, we all know it, so what's the big deal—I don't get KaceyR's issue—lets compare unsupported Proprietary software with supported OSS software—give me the supported software any day, who cares about its origins.
I say, based on the lifespan you are looking for use whatever is functionally appropriate and cost-effective (over the lifecycle) IRRESPECTIVE of it belonging to the OSS world or proprietary—period.
I think this is really what it comes down to: The amount of code and sophistication of features incorporated into application software means that no program can ever be truly perfect. Due diligence will be required no matter how the software is acquired. The real debate between proprietary software and open source software lies not with the often politicized method of delivery, but with the features offered by the software itself. The really fruitful debate should be focused on the merits of the software, not what was paid for it and to whom.
Mark W. Kaelin has been writing and editing stories about the IT industry, gadgets, finance, accounting, and tech-life for more than 25 years. Most recently, he has been a regular contributor to BreakingModern.com, aNewDomain.net, and TechRepublic.