Linux, OpenBSD, Windows Server Comparison: Total Cost of Ownership

• Microsoft Licenses and Non Responsibility

In a rational world, Total Cost of Ownership, TCO, would be the primary method of determining what systems were purchased. All the factors that contribute to the actual costs of a system from initial licensing costs, to formal training costs to time spent by IT staff troubleshooting problems and even estimates of the time staff spend figuring things out and training themselves and each others would be included.

Platform choices are rarely made on TCO estimates. There are simply too many factors to account for and many are too difficult to calculate with any useful degree of accuracy. Sometimes platform choices are not explicitly made but are simply the result of following the path of least resistance. This means staying with what you have, where you can, and buying servers to support specific systems without regard for the overall infrastructure. When platform choices are made explicitly, they are not likely to be made on careful TCO calculations, but rather on gut feelings about the relative importance of the various factors discussed previously, and how a platform lives up to expectations of those factors regarded as most important.

One factor may be more important than any of those discussed so far or subsequently. This is simply that Microsoft is perceived to be the dominant player in major sections of the computer industry and that there is no need to justify any decision to go with a Microsoft selection. Any other choice needs to be justified but not Microsoft.

When examining servers, one wonders by what possible combination of costs could Windows servers offer a lower TCO than Linux or OpenBSD servers. The absolute minimum starting license cost for any Windows 2000 server is about $700 and it climbs rather quickly for almost anything other than development use, depending on how many client connections are allowed and what server applications are used. Then there are license management costs, which are not trivial. License management is a nuisance for anyone who must deal with it, and cannot be ignored given Microsoft's recent history of forcing license audits on its customers. If you haven't kept adequate records, it may even be necessary to repurchase products that have already been purchased before. Corresponding Linux and OpenBSD costs are zero though you may purchase media to simplify installs or obtain supplementary products not part of the base OS.

Moving to security, Linux is more secure and OpenBSD much more secure in a default install than any Windows system. Windows can be made more secure than its defaults but it is a labor intensive process, and while it's relatively easy to make Linux and OpenBSD much more secure than the defaults, the more secure you try to make Windows, the more labor intensive the process becomes, and the less Window's like the result is. TCO begins to stack up against Windows.

Regarding reliability, there is no contest. Given normal installs by typically trained administrators not working for large organizations, with the facilities to thoroughly test and standardize installs for reliability, Windows systems are much less stable than Linux or OpenBSD installs. The more Windows systems are asked to do, the less stable they will be compared to UNIX counterparts, performing a similar diversity of tasks. Troubleshooting unstable Windows systems may be the most labor intensive task, for small to medium size IT staffs. TCO stacks up further against Windows.

When we get to ease of learning, we do find an area where Windows servers have an advantage. If you must get some new service running in a minimum of time and are willing to do this without really understanding what you are doing, then Windows has an advantage. If you know of a suitable Windows product, you can buy it, possibly even downloading it from the Internet, and if things go typically, it may be installed and working in minutes, with no real knowledge of how the product works or what the install may have done. As an infrequent, emergency expedient, this may be acceptable, but as a general method of operating servers, it's not professional and can't be called managing them. Following whatever emergency required such a hasty install, the installation should be examined, especially for security implications. It may be appropriate to remove and reinstall the product with different settings.

I don't believe there is a significant Windows advantage in this regard. The advantage may be mostly a matter of perception, i.e., installing Windows products without understanding them is almost taken for granted. If you know that a particular Linux or OpenBSD package contains a service or required function, there is no reason the appropriate "rpm -i" or "pkg_add" command could not be issued as easily as a Windows install. Likewise, it should be possible to focus efforts on the absolute minimum necessary to get the new product to run, without really understanding it. Still, once one is forced to resort to using documentation, it's always seemed normal to me, to use that documentation and follow pointers to related documentation to understand what a product does, how it works and the range of available options, rather than limiting oneself to the barest of mechanics necessary to make the product work.

Generally though, it's clear that UNIX systems require more up-front learning effort than Windows systems. In the long run, this is more than paid back, as the experienced UNIX administrator can do so much more than a Windows administrator.

The only environment where there would be significant UNIX learning costs, is one that has no UNIX system or experienced administrators, and new UNIX systems are brought in and existing staff learn on the job. Otherwise there will be UNIX machines in place that perform functions, and staff that manage them and presumably (hopefully) know what they are doing. If there is staff turnover or new staff are added who are expected to work with the UNIX machines, they will presumably posses appropriate UNIX skills. Highly skilled UNIX staff might be hired to supplement UNIX skill sets that are perceived to be weak, but otherwise new hires would be expected to posses necessary skills to allow them to take over machines that were already operational. In other words, at least the more routine functions should already be automated and new staff would be required to maintain and extend existing installations, not set up entirely new machines with no experience or existing standards for guidance.

When I played a major role in selecting a new association management system that ran on AIX, I'd never seen a UNIX prompt prior to this acquisition, no staff had any professional UNIX experience, and no new staff were hired to support the machine. There were of course learning and training issues. The application vendor provided some support including a two day training session for all IT staff. We chose 7 x 24 technical support from IBM as our primary support method. My primary responsibility was oversight and testing installation of the new management system, but the AIX machine was also my responsibility, and I set policies and directed operations on it. There is no question that my knowledge of UNIX system administration was not systematic, because there were many things that UNIX administrators would typically know, that I never had to deal with. Some things were set up adequately when we got the machine, and I simply never dealt with these. I did make security changes and was able to automate all routine functions which has been discussed elsewhere. Except for web related data exchange that came later, these were all done in approximately a two years.

My initial exposure to Windows NT and NT servers was no more systematic than AIX. I started with NT workstation in early 1996 because I needed a stable desktop system. I went from Windows 3.1 to NT 3.51 minimizing interface adjustments. We got an NT server in mid 1996, but I didn't do significant work on it until early 1997, when I upgraded to NT 4 on both systems. I had to move a web site from a remote Sun system with Netscape, to NT with IIS. The old site was mostly static but had a moderate amount of CGI content. One of the main reasons for moving was to achieve a high degree of integration between our member database and the web site. The new site thus had much more CGI content. Different member types were to have selective access to various parts of the system based on member codes. Members could register for private parts of the site using Perl scripts which called the Windows API to create users and add them to groups. In some ways my involvement with NT was much closer than AIX. In both cases, whatever I did was driven by needs to get an application system working and keep operational the server on which the application depended.

It two years on AIX, I had most routine functions automated. Whenever a problem was encountered, it was dealt with and disposed of. In contrast, after two years of experience with NT server (3 years NT total) I was starting to feel the first real frustrations with NT's limitations and troubleshooting problems that seemed to have no solution. AIX involved a form of culture shock, which NT never had because of the interface similarities to what I'd known before. Both systems required significant amounts of learning. With AIX, the only obstacles were my own limitations. With Windows, after a level of knowledge was achieved, there didn't seem any where to go. Large parts of what I have accomplished on Windows systems, has been a result of bringing tools and techniques I learned in the UNIX world (Perl, the MKS Toolkit, and latter the Cgywin tools) to Windows.

Based on significant personal experiences with both, the real usability costs of Windows servers are much higher than UNIX servers. Windows has an ease of learning advantage for the novice but that is quickly lost as experience is gained and ease of use becomes more important.

Window's greatest strength is none of it's technical features but the fact that there are more applications available for Windows than all competing operating systems. It's worth noting though that Windows is not a unitary market and that there are many Windows products from the 95 / 98 / ME family that are not ready for 2000 let alone XP.

Application availability can be figured into TCO. If a system doesn't have the applications you need, then you figure TCO by comparing the cost, including time lag, of custom built applications on the system without the applications, to the cost of commercial or open source solutions on the systems that have them. Custom building will normally be much more expensive. It's likely to be so much more expensive, that it will be more than all other costs combined. Typically then, if one system under consideration has the applications you need and another does not, the latter needs to be eliminated from consideration.

Thus if I'm right about costs, if Linux has the necessary applications, then it will be much cheaper than Windows server systems because it wins all the other cost comparisons. If the necessary applications are also open source, then Linux's cost advantage is likely to be compounded. If Linux does not have the necessary applications, the choice would normally go to Windows or another commercial system.

By nearly every technical measure, OpenBSD is superior to Linux but it's hampered by limited application availability. Because less is installed by default, adding products to OpenBSD may require more work because necessary infrastructure products may also need to be found and installed. For those environments with modest application needs, if OpenBSD does meet your server application needs, it should be considered.

Microsoft Licenses and Non Responsibility

One of the reasons sometimes given for going with commercial solutions is so that there is someone on the other side, the supplier, who can be held accountable. While some custom software development or installations may result in contracts that actually give the buyer some leverage over the supplier, this is not generally true of shrink wrap software and you can be sure that Microsoft licensing agreements assure that you have no meaningful recourse if you have problems with their software. Their "warrantees" amount to saying that you as the customer are solely responsible for determining the appropriateness of the software to your environment and all consequences of its use. Microsoft is not responsible for anything, even clear defects in the software. Good luck holding Microsoft accountable for anything.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in https://geodsoft.com/terms.htm (or https://geodsoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of https://geodsoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.