“I can't get no, I can't get no,
I can't get no satisfaction,
no satisfaction, no satisfaction, no satisfaction.”
— Rolling Stones, (I Can't Get No) Satisfaction
In today's world, there is a large number of free software applications. The free software development model has a potential of producing high quality software with high quality documentation that would make the user able to fully exploit in a straightforward manner it's all promised features. Such a software would be a very powerful tool for the user that would bring him a great level of satisfaction.
However, sadly, the real situation is far from the theoretical potential.
Everyone wants to be satisfied by the things he is using. Who wouldn't. But only some projects have a goal of satisfying it's user. Other projects just pretend it. It's natural that the user wants to select those products that will satisfy him, but if he goes only according to what these projects say, it will not work, because all projects say they are the good ones. If he goes by what his friends say, this will not work either, because what works properly in one situation, may completely fail in another.
Therefore we propose a simple formal system how to discriminate projects, whose true goal is to satisfy the user, from the rest. We will supply an easily verifiable definition of a "satisfying project". Then the only thing that is need to be known publicly about a project is, whether it is satisfying or not. Such information is much easier for the user to check than large amount of often conflicting users' testimonials. It's also easy to comply with our definition for the projects whose true goal is to satisfy the user.
A satisfying product has the following information (typically documents) available for the user:
It must be clear to everyone what exactly are the requirements, what exactly are the features and what exactly are the usage instructions.
Note: this specially means that it's not possible to have more versions of any of these documents published without being apparent which one is the official one. It's also not allowed to have any of these documents missing. It also means that it must be clear what is part of each of the document and what is an external information that is not.
If the user meets conditions that he reasonably believes are meant by the requirements published, and if for each step in the instructions he performs actions that he reasonably believes are meant by that step in the instructions, then, independently on other circumstances, he must always perceive the behaviour of the product to satisfy what he reasonably believes is meant by the published features.
Note: the word "believes" is used to guard the user against ambiguities in requirements, features, or usage instructions. It can happen that the developer meant something else than the user understands. It's the developer's responsibility to ensure that such confusing situation doesn't happen.
Note: the word "reasonably" is to guard against user's unreasonable belief. Reasonably means that according to common consensus, it's not generally obvious that his belief is wrong. A reasonable belief is for example that if a program says it supports HTML, that it will support CSS. Unreasonable belief is that if a program says it supports JPEG, that it will support PNG.
If a product is not satisfying, we call it dissatisfying product.
Note: it specially means: for a product to be dissatisfying, a single incident showing that the product is not satisfying is enough.
Bug is a particular thing that causes the product to be dissatisfying. This term is only for practical purposes of developer communication and doesn't have any actual importance in this theory
Bugreport is a report that proves beyond reasonable doubt that the product is dissatisfying.
It's a project whose goal is to produce a satisfying product. If the project leadership consistently demonstrates intention to produce satisfying product, then we call this project to be satisfying.
It's a project that is not satisfying.
Note: this particularly means that if unwillingness to fix bugs is publicly proven by anyone (typically someone whose bugreport was not taken into account), the project is not satisfying.
Satisfying projects are very important for the users. First, the probability of troubles is minimized for the user, because the goal of the project is a satisfying product, whose very definition is based on delivering the promised satisfaction to the user. Second, it's not possible that a bug causes the user a trouble and then fixing the bug is arbitrarily delayed. Therefore if the users gets a trouble, he always gets satisfaction by the fact that by having this trouble he contributed to the effort towards a satisfying product, and therefore towards eliminating other people's trouble.
Clarity which document is the official - if this is not met, the user can pick up obsolete document and get resulting troubles and waste potentially long time because of this confusion.
It's not difficult to have the goal of meeting these requirements. First the developer writes these documents in a good faith. Then he publishes them and if a users send bugreports then, he fills in the a missing information or changes ambiguous wording.
It's not difficult to have the goal of keeping the technical design itself in a good state either. It basically means slowing down, relaxing and keeping a database of bugs with priorities. Taking one bug after other and resolving them. Not being afraid of ripping parts of the design out and redoing them again because of a bug caused by their bad initial design. And working on new features only when the bug database is empty.
Choosing one's project to be developed in a dissatisfying way is a decision that means consciously allowing a frustration of the users that is potentially unlimited. This should be realized by the users when choosing between a dissatisfying and satisfying project. And this should be realized by developers whose true (not only proclaimed) goal is to help other people with their development.
We suggest here for projects who strive to truly satisfy their users, to comply with the definition of satisfying project, because then users will be able to easily indentify them as a project that has user's happiness as a true goal. We believe this simple formal system has a potential of ending frustration of users who would like to enjoy the high quality software available, but are unable to, because they are cannot determine which one it is. We also believe this can make developers whose just vaguely felt what their true goal is, to realize their true goal in its full importance, and subsequently make the user experience more pleasing.
Contact, support: Clock
on the Internet Relay Chat.© 1998-2016 Karel ‘Clock’ Kulhavý et al..