Cem Kaner has written a Software Customer Bill of Rights. His general approach is to require that customers have roughly the same rights when they buy software as when they buy other products.
Much of what Kaner says makes sense. But at least one of his principles seems awfully hard to implement in practice:
2. Disclose known defects. The software company or service provider must disclose the defects that it knows about to potential customers, in a way that is likely to be understood by a typical member of the market for that product or service.
This is hard to implement because software products have so many defects – big mass-market software products typically have thousands of known defects. And this is not just the practice of one or two companies; it’s standard in the industry. If a vendors waited until all the defects were removed from a product, that product would never be finished and would never ship.
Some of the defects in software products are serious, but most are relatively minor. There is simply no way to explain them all to consumers. And sometimes it can be hard to tell in advance which defects will prove to be critical to customers.
Still, Kaner seems to be on the right track. It would be helpful if vendors disclosed the most serious known defects to their customers, so that customers could weight their impact in deciding which product to buy.
[Link credit: Dan Gillmor.]
“If a vendors waited until all the defects were removed from a product, that product would never be finished and would never ship.”
I didn’t see a requirement in the “Bill of Rights” that the defects be REMOVED, only that they be disclosed.
“Some of the defects in software products are serious, but most are relatively minor. There is simply no way to explain them all to consumers. And sometimes it can be hard to tell in advance which defects will prove to be critical to customers.”
I agree that it would be difficult to impossible to explain all bugs in language non-technical users could understand. I’d be happy if they were only required to not overly obscure the explanation. Too often, bug explanations are written in such a way that only an expert working in the company that wrote the software could possibly understand it.
But I absolutely believe all known bugs should be disclosed, with special attention paid to the ones that most often cause tech support issues. And one of the key reasons is because, as you said, it can be difficult to know which will be a critical issue.
And while I agree it isn’t possible or even desirable to remove all bugs, I do believe some are far too complacent about the number of severe bugs that keep showing up in major software products, and that there wouldn’t be nearly as many IF vendors were required to disclose them. It would be very interesting to compare the bug lists on revisions of long used software packages: The same bugs should not keep reappearing in products like Microsoft Office, IE, Intuit Quicken or other staple software packages.
As it is, I can’t count how many time I tried to find information through Microsoft on a problem I was having with Microsoft software without success – then turn to Google Groups or Web search and find more than I want to on the issue.
And Microsoft isn’t alone. I’ve had far too many incompatibilities or glitches with software AND hardware drivers with the manufacturer insisting it was new to them, or acknowledging it privately, but not EVER publicizing it … even though it turns out to be a common issue, discussed for months or years on Usenet. It has reached the point that I can assume that almost anything I install will need a patch, tweaked configuration, won’t work quite the way it is supposed to, or will cause problems on the system.
I agree that it would be virtually impossible to publish a list of known defects in a way that is understandable by typical users. How many Microsoft customers would understand that a defect in URLMON.DLL’s use by the Explorer Shell would result in auto-executing viruses within Outlook? If Microsoft would have recognized this when they found the bug originally, they probably would have fixed it.
I would rather see more posting about the geo-political influences which have led to the laws against reverse engineering. I’m very interested in that.
> [a purchaser] does have the ability to read the
> terms before opening the shrink-wrap envelope.
This is incorrect in many cases. For perhaps the
most egregious example I have seen recently check
out the horror story with Dell’s software license policy.
> Beyond this, though, most of the suggestions
> are attempts to interfere with the rights of
> the customer and vendor to come to a free
> agreement about terms.
This assumes that customers are able to bargain
with vendors. This is plainly not true, except
in cases of multi-hundred-thousand dollar cases
which are well outside the normal for a consumer.
The purpose of consumer law is to provide a
baseline of behavior. Based on current behavior
and prior experience in other fields, there is
a critical need for such legislation.
> Don’t most software companies have a list of
> known bugs that need to be worked on?
> It wouldn’t be hard to make portions of that
> information public when the product is first
> shipped.
The problem is that the proposed bill of rights
says “known bugs” must be disclosed, not that
“severe bugs” or “some bugs” need to be disclosed.
How can the consumer know that a feature they
think is important, but that the vendor thinks
is unimportant is broken, if all bugs are not
disclosed? Portions of that information is not
sufficient.
> For one thing, what counts as “his own data”?
> For another, what counts as “accessing”?
Data that the owner has entered. Data that was
not shipped by the manufacturer.
Access means to block access – either by removal
or obfuscation.
If the license expires, the program should not
remove the consumer entered data. For example:
a CAD program should not remove the drawings
that the user has created.
If the software encrypts the data using a
proprietary technique, but provides a means
to extract the data when the license is valid
should not disable this functionality when
the license expires.
Point 5 is the only point with no explanation, yet
it’s very important. It’s unfortunate that there isn’t
more explanatory material for this point. For one thing,
what counts as “his own data”? For another, what counts
as “accessing”?
I think this point should be bifurcated into a
point about interoperability and a point about
enforcing policies against the user. But the content
of the interoperability point is very unclear;
presumably the idea is something like “the software
should not contain any features which can only be
justified on the ground of preventing interoperability
with other hardware or software”. And even this would
be very controversial, because sometimes preventing
interoperability is part of a means to some other end
(trying to collect license fees from other software
developers, trying to impose license obligations on
them, trying to enforce a policy against the software
user).
I’m not sure the goals of this section can be expressed
really clearly.
Don’t most software companies have a list of known bugs that need to be worked on? It wouldn’t be hard to make portions of that information public when the product is first shipped.
SecurityFocus already maintains the Bugtraq database of known security bugs for various products, including a description of the problem and fixes where known. It would not be all that difficult for a software publisher to create a similar database for products made by that publisher. The publisher of a software package already has most of the data that would go into the database, and it could be made even more complete by accepting user bug reports.
One could even argue that a bug database would be a good thing for the manufacturers as it could help improve both software quality and customer trust. A bug list containing fixed bugs would show a commitment to ongoing support and improvement of the product, especially if there was a link to downloads of patches or updated versions of the software.
I agree with the general idea of making the contract terms available to the user before sale. OTOH, he does have the ability to read the terms before opening the shrink-wrap envelope. At that point, if he does not agree, he should be able to return the software to the point of purchase for a full refund. But this is a cumbersome process at best and it might be a good idea to streamline it.
Beyond this, though, most of the suggestions are attempts to interfere with the rights of the customer and vendor to come to a free agreement about terms. Reverse engineering, publishing benchmarks and other information, access to customer data, use of encryption, resale terms, all these should be subject to market competition just like other product features. If few customers care about these features, why should vendors be forced to provide them?
Let some vendors allow these forms of usage, and others refuse them. Let customers vote with their pocketbooks to reveal how important these features are to them. Only in this way can the market strike a balance between the value of the features and the cost to implement them. Heavy-handed attempts to settle these issues via the proposed regulations will only lead to an economically inefficient outcome.
I really dig that reverse engineering clause… I wonder how that will square with the ubiquity of “no reverse engineering” clauses in EULAs…