medici@dorm.rutgers.edu (Mark Medici) (11/14/90)
jcmorris@mwunix.mitre.org (Joe Morris) writes: |In an original note Silvia Takahashi writes: | |>>> [...that if Express is installed as the shell, the |>>> "Maximize Automatically" option can cause a UAE.] |To which roper@nwnexus.WA.COM (Michael Roper) of hDC replies: |>>Yes, there appear to be some inconsistencies in the way |>>Windows interacts with shell applications. While none |>>of the systems at hDC exhibit this problem (I have run |>>with the above configuration for months without seeing |>>this behavior), it has been reported by others and will be |>>addressed in the next version of Express (or, even better, |>>Windows). Until then, the workaround is to disable the |>>"Maximize Automatically" option. | |...and to which response medici@dorm.rutgers.edu (Mark Medici) replies: | |>With all due respect and politeness, I strongly suggest that hDC offer |>a fixed version of Express to its registered customers as soon as |>possible and at no charge. I for one, and I am sure the general |>public, are getting sick and tired of being forced to wait and pay for |>bug fixes in the form of upgraded versions. Often, the new or |>improved features of an upgrade are also accompanied by their own |>anomalies, and are of secondary importance to a user who really only |>needs a fully functional version of the existing product. |> [...] |>I believe that upgrades are an important service to the industry. |>However, a registered owner should not be forced to pay for an upgrade |>to correct existing problems with a product. [...etc] | |:soapbox | |I, too, would love to be able to purchase a product and know that every |problem would be fixed at no charge to me for a long time. Economic |reality, however, makes this rather unlikely. | |Clearly there are some types of errors which cannot be tolerated and |which I would expect a vendor to remedy at no cost if for no other reason |than to avoid a "mechantibility and fitness" lawsuit. A compiler, for |example, which fails to emit proper code while appearing to work, or |an operating system which trashes the system disk if a user types 'xyzzy' |fall into this category, as would a multi-user system with known trap doors |in its TCP/IP support. | |Other errors, however, are not so life-threatening to the user and don't |call for extreme measures. Until the day comes when complex systems can |be written with a justified assurance that they will operate properly for |all possible configurations, we should expect that any non-trivial program |has imperfect code. If we want to have the vendor provide fixes for every |error, that's fine; on the other hand if we expect the vendor to do so and |remain in business we should expect to pay for that service, either in a |higher original purchase price, or in a service contract. In a perfect world, all software would be bug free, well documented, vigorously supported by the marketer at no additional charge. The reality is that the opposite is more common. It is unrealistic to expect, given current methods, that any program will be 100% error free. However, once a bug is discovered and confirmed, publisher should make an effort to remedy the anomaly, rather than ask their paying customers to not use the affected feature(s) until sufficient corrections and improvements can be made to justify selling the affected users an upgrade. Forcing users to buy upgrades just to get existing bugs fixed is a subtle form of extortion. The owner of the software is held hostage to the publisher's mistakes, with the price of release being the cost of an upgrade, which otherwise might be unnecessary. I find this attitude unacceptable in the consumer market most vendors project themselves into. |Look at the mainframe world (if you dare): talk to the sysprogs who support |any system bigger than a microcomputer and you'll find that if you want |support it can be had, but you'll pay for it. Usually it's an additional |charge beyond what you pay for a perpetual license for a product, or is |included in the lease charges for a term license; sometimes it's included |in the up-front charges for the product. In either case, you pay. As an |example, like most mainframe vendors DEC prices its software support |according to the power of the platform, and I pay DEC over $500 per month |(at GSA discount rates) for Ultrix software support on a VAX/750. | |To put it another way, TANSTAAFL. ^^^^^^^^^ indecipherable acronym | |If a vendor's product has an error which makes it unusable, or which can |damage the user's system, of if the documentation is so poorly written |that it does not explain how to properly use the product (of course, this |last situation never happens...) then the vendor should be expected to |provide support to the end user as a part of the original purchase price, |and that price should reflect the cost of that service. Support for |relatively minor problems (of course, "minor" is in the eye of the beholder), |especially where there is a workaround *made known to the user community*, |should be at the vendor's discretion. If the vendor wants to provide support |at no charge for minor or RTFM type problems, that is a marketing decision, |not a legal or ethical one. Support is not the issue of this diatribe -- fixing bugs that affect functionality is. These are separate issues in the PC marketplace, where shrink-wrapped software is delivered in executable form without the need to custom port it to each user's environment. On mainframes and mini's, software is often delivered as source code with a field service engineer (or, sometimes team of engineers). These engineers make the necessary modifications to the source for each specific installation and create working executables. As the system is upgraded or changed, the software must also be modified and recompiled. Though it is not a requirement to contract continuing support, it is generally cheaper than maintaining programming expertise in each individual application. In my view, these costs are what drives the market from big iron to PC based solutions. But this is getting off the primary subject. Whether a problem is minor is often subjective. However, when an advertised feature cannot be used, this is usually not a minor problem, at least not in the view of the person that paid for the software. As for a workaround being available, perhaps "workaround" requires better definition. In my view, a workaround is an alternate method of achieving the desired results without triggering the bug. Informing the user community that a feature should not be used because it may crash your system is not a workaround, it is a warning of danger because of the bug. To expound on your compiler example, imagine you purchased a C compiler that advertises the ability to produce executables optimized for a 386. When you start using the compiler, you realize that the programs generated using the 386 specific feature were unreliable, sometimes causing system crashes that could result in lost data. The publisher admits there is a problem with the 386 feature in some environments. The publisher promises that the problem will be fixed in the next release, version 7.0, which will likely cost 1/3 to 1/2 of what you originally paid for the package. Until the upgrade is available, the publisher tells you to not use the 386 specific option, instead compile for generic 80x86's which produces reliable programs. Is this a minor bug? No: the software was selected over competitors because of this feature. Is the offered solution an effective workaround? No: the user cannot use the product in the way advertised and s/he desires. Should the user be expected to pay for an otherwise unneccessary upgrade to get this bug fixed? No: while the user may later buy the upgrade because of its enhancements, s/he should not be extorted into buying an upgrade to receive a fully functional version of the existing software. Admittedly, there are many subjective opinions involved in this discussion. However, I (and I believe most others) feel that the vendor has a responsibility to deliver software with all advertised features working, and without forcing the user to pay for the publisher's mistakes. New features are fine, and usually met with great enthusiasm. However, I personally don't want to be forced to buy a new version, often with its own unique anomalies, just to get the existing problems corrected. The views expressed do not necessarily reflect those of my employer.-- ---------------------------------------------------------------------------- Mark Medici/SysProg3 * Rutgers University/CCIS * medici@elbereth.rutgers.edu ----------------------------------------------------------------------------