What pleases users, both programmers and non-programmers, is goal oriented documentation. Documentation that allows them to use the software to achieve specific goals, without really bothering to learn how the software works. If you are writing commercial software, free or not, pleasing the users is likely to be a priority, and writing goal oriented documentation is therefore a must. The same is true for some motivations behind non-commercial free software, e.g. to promote free software over non-free solutions, or to experience the nice feeling of knowing your software gets used.
However, if your goal is to get qualified feedback, preferably in the form of patches or at least useful bug reports, ordinary users aren't going to be what you are after. As Kevin points out, they are unlikely to even report bugs. What you want is not users, but the much rarer power users. That is, users who actually have taken the time to understand the tool they are using. These users will use the tool in unexpected ways, producing interesting ideas for enhancements, give detailed bug reports, and if they are programmers, give the best kind of feedback, patches.
The goal directed documentation may lure some users to the tool who will later turn into power users, so it should not be totally ignored, even in this case. But the kind of documentation that helps create power users is not goal oriented, but tool oriented. Such documentation describes how the tool work, and the concepts it is build on, and should be supplemented by a (possible integrated) reference manual.