||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.
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.
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
- 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
- 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.
- When upgrading a product every reasonable effort shall be made to ensure
that Version upgrades fully support all features in the existing version.
- 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:
|Less than 6 months from upgrade release
|Less than 9 months from upgrade release
||50% off upgrade price
|Less than 12 months from upgrade release
||25% off upgrade price
- All upgrades provide the users with the ability to open and transfer
from previous versions under the following guidelines
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
- 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).
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:
- 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
- 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.
- 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
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.
- 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.
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.
- 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.
Shipping Software with Unfixed Bugs
- 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.
- 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
Keeping Software Current
- 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
software shall fully support the latest hardware and software which evolves from the hardware and software minimum or
- 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
- 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