Dear Mr. Nimmer:

I am writing to express concern about the direction and impact Uniform Commercial Code Article 2B on the use of software by end-users, both privately and under the auspices of their employers. I have had considerable experience in these matters working as technical support at an Internet Service Provider and as a process engineer at Motorola (AIEG), Inc. My experience with the intercompatibality and stability of software has consistently been negative, a result which I attribute directly to software developers.

My predominate concern resides around the push of major vendors to combine the advantage of shareware/freeware while maintaining the commercial benefits of purchased software. With shareware, for example, a prospective customer tries the product without fees for a stated amount of time (or in a cripled version). The underlying agreement is that the consumer uses the product "as is". Risk is spread out more equitably because if the product fails to perform adequately or to the advertised claims, the user has the option of discontinuing its use. Risk to the user is lost time and productivity. The vendor incurs costs in time and development invested in a product which did not provide a financial return. Ideally, a satisfied customer purchases the full license. Freeware, on the other hand, provides a full working version with no restrictions and relies on the honesty of the consumer to send in a fee if satisfied. Freeware, then, represents a consumer-biased business model. The vendor-biased model, under which most commercial software is sold, requires the license to be purchased up front before use of the product. The consumer has little opportunity under which to evaluate the product ahead of time or under their system constraints. The current direction of Uniform Commercial Code Article 2B would allow vendors, however, to exploit their own leverage in this model at the expense of the consumer.

For example, consider the development of a software product whose team/corporation is operating under the stress of a competitive market. The temptation to push the product "out the door" with functionality less than advertised, or particularly, code that is not properly optimized, is great. As is currently becoming the standard in this industry, the decision is then made to sell an "upgrade" about six months later after the original product is released. It has been my experience that these "upgrades" are marketed with additional features which do not enhance the overall functionality of the product but rather mask optimized code that should have been available upon initial release. Consumers which purchased the original version are actually completing the final beta testing phase which was the responsibility of the vendor. The real rub is that some of the work going into the "upgrade" may actually be the result of concentrated consumer effort, the product which, is turned around and sold back to the consumer. Risk, then, is shifted to the consumer who paid for the product up front and is forced to use the product "as is" with limited recourse. The consumer will invest time to resolve hardware/software differences, program compatibility, and feature difficulties JUST TO MAKE THE SOFTWARE PRODUCTIVE. In other words, the consumer is forced to spend needless effort attempting to recover his initial financial investment. The risk of the vendor has been eliminated since the product has already provided a financial return. Hence the developer has combined the advantage of shareware while maintaining the leverage provided in the vender-baised model, all at the expense of the consumer. Article 2B would enable vendors to legally push development of a product onto consumers essentially for free, allowing the vendor to realize reduced costs. The consumer, on the other hand, would have no recourse.

One might think that competitive pressure would force such products out of the market but this is not so. If the initial release were the final version of the product this might be true. Often, however, the upgrade comes within a reasonable amount of time so that the company can exploit a window of opportunity without giving up market share to competitors. In addition, users may not have the option of switching to another software product if it is not compatible with their source files. Users may also wish to avoid the learning curve associated with a different vendor's product. A notorious case of this can be found in the beta testing of Windows 95. This was Microsoft's next flagship operating system. Microsoft, however, was actually CHARGING some of its testers for beta-code. They had to pay for the right to help Microsoft solve compatibility and stability problems. Upon release, some of the features were partitioned off and sold as an "upgrade" called Windows 95 Plus. Others were given to original equipment manufacturers to incorporate on new PC's only (called OEM Service Packs 1 and 2). Users which had upgraded from Windows 3.1 and 3.11 could not get these packs. However, they will be able to in July. They are renamed "Windows 97" and will cost around $90. Unfortunately, users wishing to maintain compatibility with their previous files had no choice but to switch to Windows 95.

The result of poor project management with little attention being given to details has resulted in the morass of sloppy and incompatible software. Businesses must force their IS departments to spend unusual amounts of time to system support because of problems resulting from this. When I worked for Internet Oklahoma I spent hours in direct communication with consumers trying to get their software up and running. Most of the calls I fielded were not "learning-curve" problems but instead resulted from incompatibility issues between the operating system, application package, and the hardware. Calling the software vendors usually resulted in finger-pointing - unless another consumer had independently discovered the solution to the problem and made the vendor aware of it. My employment at Motorola (AIEG), Inc. resulted in 40% of my time being dedicated to maintaining the department's computers even though I was a process engineer. Why was I doing this? The IS group was so back-logged fixing other PC's in the plant that our department redefined part of my responsibilities (specifically because of my experience working at Internet Oklahoma). This is certainly not restricted to Motorola alone, hence, the current industry focus on the "cost of PC ownership". Passing Article 2B would allow the software industry carte blanche to interpet the extent of its responsiblities to its client base. I do not support a strengthening of the current vendor-biased model and therefore do not support Article 2B as written. Its passage would result in a further degradation of code quality and functionality while pushing the liability to the consumer. The software industry can complain as much as it wants about the increasing length and complexity of code but as a mechanical engineer I urge you to look into the complexity of automobiles. Tell the excutives at Ford, Chrysler, and GM about the software industry's counter-argument (and its ultra-high profit margins) and they will laugh.
Brent Clothier
bclothie@uiuc.edu