NWA-PCUG 07/99 NewsLetter Article 18861 N. Hwy 112, Springdale, AR 72762-9303 Who Should Pay for Year 2000 Upgrades? by Robert E. Simanski, CPCUG From 5/99 CPCUG Monitor There is a heated debate today on who should absorb the cost for fixing Year 2000 (Y2K) problems, the developer or the end user. It's certainly a major issue when it comes to enterprise-wide software and proprietary line-of-business applications, although it applies to virtually all hardware and software for personal computers. Here is my opinion. First of all, let me say that no normal information technology (IT) professional wants to see any of his or her suppliers go out of business over this issue -- or, for that matter, suppliers' competitors. If good software developers are driven out of business because they cannot absorb the costs of Y2K fixes, everyone will lose. it's in the common best interest to develop a compromise that is fair to all parties. Although I am not an attorney, I would imagine that the legal profession will have a field day next year. In my opinion, the argument comes down to a handful of issues, each of which may have legal implications. Reasonable Expectations of a Normal End User Although the Y2K problem may have been well known in the academic community of computer scientists as early as 1990 or 1991, it was not common knowledge among IT administrators and other computer professionals until about 1995. I maintain that a reasonable person would expect that any computer product released after 1995 would be substantially Y2K compliant. I use the term "substantially" because software developers are only human, and even the most diligent developers continue to discover minor issues in software that I'm sure they believed, in good faith, to be compliant. Windows 98, released only last year, has required at least one Y2K bug fix. Therefore, as a general statement, I believe that both software developers and hardware manufacturers should provide fixes at no charge for products released after 1995. In specific cases, however, this statement could be modified in light of other two issues that I will discuss. Practical Useful Life of the Product I originally labeled this topic "normal useful life," but I'm not sure that accurately expresses my meaning. When you buy a household appliance, you can expect it to last a certain number of years based on the cumulative experience we have gained by using that type of product. For example, you would reasonably expect a new stove or refrigerator to last about 20 years, and you might very well use it every day for that length of time. When it comes to computer hardware and software, things are not that simple. My wife is still using the Kaypro PC that I bought in 1986, but only because it continues to meet her very limited needs. For that matter, I'm sure there are some businesses still using 286- or 386-class computers. Those that are, however, are probably losing much more money through low productivity than the cost to replace these systems with up to date systems, so they don't count in my book. In the personal computer arena, the current pace of technological improvement is so great that the practical useful life of computer hardware and software is 3 to 4 years, at least where for profit businesses are concerned. That's the point where potential productivity gains justify upgrading a system. When it comes to enterprise level or line-of-business software, however, the cost of upgrading can be substantial, so I would imagine that the practical useful life of a software release would be longer. Still, a given software developer should be able to establish the practical useful life of a product by determining how often his or her customers upgrade to a newer release. IT professionals could pool their experiences and share this information with each other, perhaps through a trade or professional association. let's say that the median length of time between upgrades of a particular product, or perhaps class of product, is 5 years. That would be the practical useful life of the product. If a customer bought its current version of a product in 1994, then the developer should not be expected to provide anything that would extend the practical useful life of the product beyond 1999. The customer should be willing to pay for a fix or upgrade to extend the practical useful life. However, if the customer bought the product in 1997, reasonably expecting to use it until 2002, then the developer should provide whatever fixes are necessary to enable the customer to do that, at no charge. Suitability for the Intended Purpose This issue is related to the first two and is often implied or expressed in product warranties. When you buy a kitchen stove, for example, you assume that it is suitable for your intended purpose; that is, the cooking of food by normal means. If, during the warranty period, you find it is not suitable for its intended purpose, you have every right to expect the manufacturer to either replace it or refund your money. So, too, with software. Let's say that it's 1996 and I am a membership director for a new trade association. I need a database program that will enable me to track membership data well into the 21st century, so I invest in a membership database application designed for trade associations. I specified my requirements in writing to the developer and have every reason to expect that the application sold to me is suited for my intended purpose. Now it's 1999. The developer informs me that the version that I bought in 1996 has serious Y2K problems, and I will need to upgrade to the current version to get the bug fix. I could make a strong case that the developer should provide the upgrade at no charge. My reason would be that when I bought the software, the developer knew that I intended to use it beyond January 1, 2000, and that I bought the program believing, in good faith, that I would be able to do so. However, as of January 1, 2000, the software would no longer be suitable for its intended purpose. Therefore, under the terms of my warranty, it should be considered defective. Conclusion By 1996, the Y2K problem had become general knowledge, at least among computer professionals. Therefore, developers should have known whether the programs they were selling were compliant. If they knew of problems and did not disclose them, then they were acting in bad faith. On the other hand, if they were not aware of any problems because they had not yet begun to check their software, then they were negligent. In either case, the developers, not the end users, should absorb the cost of Y2K fixes. Robert E. Simanski, ABC, of Herndon, Virginia, has been a member of the Capital PC User Group since I987 and a projbssional writer and editor for more than 30 years. He is the owner of Your Publications Pro!, a business that offers publications, Web site; and computer consulting and troubleshooting services. Bob may be reached by phone at (703) 481-6776 or by e-mail at rsimanski@mindspring.com