Home

A Software User's Bill of Rights - Draft 1
  The idea for this document comes out of a growing trend in the software industry to fail to provide adequate service to customers. The particular incident which sparked me to draft this document is the way in which the Macromedia Corporation has handled customers of their Drumbeat Product. To me, this type of corporate callousness towards consumers is only likely to increase unless we take a stand against it. I think it is time for us to take a step forward to create a set of standards that protects us as consumers. 

This is a work in progress to be expanded by the software users' community. I welcome all serious suggestions for additions or modifications to the Bill of Rights. Email me only to send real ideas rather than 'I agree' messages. The subject line of your email should read 'Bill of Rights.' I will do my best to incorporate your suggestions into the document keeping in mind that some suggestions might be in direct conflict to other suggestions.

Thank you

Rick Curtis

We, as software users, are the backbone of the software industry. Our dollars keep companies large and small going and have made the software industry into the trillions-of-dollars per year success that it is. Each year we click 'I agree' to countless End User License Agreements (EULA) filled with pages of legal jargon in which software companies explain the myriad ways in which they have no responsibility for their own product. We as consumers are often set adrift and provided with little or no support, sometimes shoddy products, and careful crafted misinformation. It is time for users to demand greater accountability and integrity from software companies. It is with this in mind that we propose these Rights of Software Users. 

We encourage software companies to voluntarily adopt these guidelines. Commitment to this standard demonstrates to us as consumers that we have invested wisely in a company that values us as customers and that we will be treated fairly.  Companies who ignore such a relationship with their customers demonstrate that they do not value our business and are not worthy of our investment. We believe that supporting customers should be a core value of a software company not just a goal. When customer support is merely a goal, it is much more likely to be subjugated or even ignored in the pursuit of other goals like increasing profits.

Contract between Company and Customer

  1. The purchase of a software product is a mutual contract between the software company and the buyer. The purchase of a product requires the software company to provide a reasonable level of support for the buyer. Such support can come in many forms including: accurately written manuals or online materials, upgrades and patches to address bugs and incompatibilities, discussion groups and forums where users can ask questions and seek advice, Web-based FAQ and knowledge-bases, and telephone-based support. We do not expect something for nothing. Cost for these types of support should be built into the cost of the product.

Honest Disclosure of Information

  1. The withholding of crucial information about a product that would affect a buyer's decision is considered a breach of contract as well as a breach of trust with the consumer. This means that decisions to discontinue product lines, decisions to not support new operating systems, etc. all must be made clear to the customer in advance so that software purchasing decisions are made with a true understanding of the product and its future. The specific timelines for the required release of such information are detailed below.

Upgrading Products

  1. When upgrading a product every reasonable effort shall be made to ensure that Version upgrades fully support all features in the existing version.
  2. Customers are too often "caught" on the wrong end of a purchase date. A company announces a new version and customer X who bought it within 60 days on April 2 gets a free upgrade. Customer Y who purchased it on April 1 has to pay the upgrade price. It's just not fair. Upgrade pricing for products must be based on a sliding scale from date of purchase. A suggested scale would be:
    3.  
    Product Purchased Upgrade Cost
    Less than 6 months from upgrade release Free
    Less than 9 months from upgrade release 50% off upgrade price
    Less than 12 months from upgrade release 25% off upgrade price

     

  3. All upgrades provide the users with the ability to open and transfer from previous versions under the following guidelines
    • The upgrade must be able to open or convert the previous version files and save the files in the previous version format. Any new features implemented show "degrade gracefully" when saving in the previous version. 
    • If the upgrade (e.g. 3.0) is released within 12 months of a previous release (e.g. 2.0) it must also be able to open files from the previous version to that (e.g. 1.0) or a two-way conversion utility must be provided (again with graceful degradation).
  4. All new features in an upgrade must be documented for users including any changes in technique required to accomplish something done different in the previous version. If an feature is removed, it must be documented with clear instructions on either
    • How to covert to a replacement function,
    • How to accomplish the task in another way, or
    • How to remove the feature from a customer built solution without breaking the rest of the solution.
  5. When introducing an upgrade to a product or a new piece of software that replaces an existing product, software companies must provide a fair upgrade path for current users to the new product. This upgrade path must include both reasonable upgrade pricing and timely release of information about the product. Companies should either: 
    • Announce the new product in a timely fashion before its release so that users can make informed decisions about purchasing the current version. A timely fashion would be a minimum of 6 months ahead of release. If such an announcement would negatively impact the company's position through early release of information to competitors then instead… 
    • The company should maintain confidentiality in regard to the release of the new or upgraded product, continuing to sell the current product and provide a free upgrade for all customers who purchased the product during the 6 months prior to the release of the new or upgraded product.

Discontinuing Products

  1. We encourage and expect companies to innovate to create new and improved products. The is the nature of the fast paced software development business. As companies introduce new products, they must also provide continued support for discontinued products for a reasonable amount of time. Customer support for the product should be phased out over a reasonable length of time:
    • Software patches and updates to the product must remain available for at least 24 months from the date of discontinuation of the product. These patches and updates must be available for free or solely for the cost of media and shipping. Information about what the patches and updates are for and how to obtain them must be easily accessible on the Web.
    • Technical support articles, knowledge-bases, and other on-line documentation must remain readily available for at least 24 months from the date of discontinuation of the product. 
  2. Software users commit significant time, money, and other resources in learning a particular product and building solutions that may depend on a product. When a company is discontinuing a product or replacing it with a different product consumers deserve adequate notice to be able to plan and shift their business strategy to accommodate a new product.
    • If the company is discontinuing a product with no plans for an alternate product an announcement must be made to customers at least 9 months in advance of the discontinuation date.
    • If the company plans to replace the product with a new product the company must provide a free upgrade for all customers who purchased the product during the 6 months prior to the release of the new product.
  3. Companies discontinuing technical support, maintenance patches, or feature upgrades for a software package shall, as an active and integral part of that discontinuance, provide users with a reasonable and affordable migration path to other comparable software products.

Shipping Software with Unfixed Bugs

  1. On more than one occasion companies, in the rush to beat competitors to market, have released a product prematurely. In such cases, the product has essentially been bug-ridden Alpha code packaged as a full release product which has then been "shorn up" with patch releases over many months. This is unprofessional and unacceptable. Companies are not permitted to release Alpha software products to consumers and market them at full retail value as if they were full-developed final code. If a company wishes to sell a pre-release evaluation version, it must do so at a reduced cost and with clear statements that the software is pre-release only. To use the software, customers must accept the EULA and all statements that indicate that code could be disruptive and damaging. The company would not be held liable for any damages caused by using pre-release code.
  2. Companies shipping software with known bugs shall document all known bugs and have this information available to the purchaser prior to software purchase and included with the delivery of the software product. Workaround solutions shall be actively investigated and distributed. Thereafter, the company shall periodically offer maintenance patches to customers at no charge to fix known bugs.

Keeping Software Current

  1. As an act of offering software for sale, companies shall agree to maintain the software to the standards of the current computing environment (including hardware and operating systems) as it evolves for a disclosed period of time not less than 18 months from the initial distribution date. The software shall fully support the latest hardware and software which evolves from the hardware and software minimum or recommended specifications. 
  2. Operating Systems:
    • Software products are advertised as running under a particular operating system. Operating system compatibility means that the program should function properly under the operating system and that its operation and installable files should not disrupt the operation of other software or of the operating system itself. 
    • Whenever new versions of a current operating system that the software product supports are made available in Beta form, the software manufacturer is required to either test their product under the new operating system to determine compatibility or to announce not more than 6 months from that release of the beta that the company does not intend to test their software product for compatibility with the new operating system. If there are compatibility problems the software manufacturer is required to
      • Either work with the operating system manufacturer to resolve the conflict,
      • Develop their own patch to allow the software to operate properly under the new operating system, or
      • Publicly announce that within not more than 6 months from the release the the operating system Beta that the software manufacturer's product will not operate under the new operating system and/or that no patches to provide computability to the new operating system are planned.