One of the more difficult questions behind some of the discussion here over the last week or so involves the extent to which we should try to educate our users so they can make informed choices.
The most basic problem, of course, is that it's easy to support education in the abstract and extremely difficult, particularly when you're involved with real world decision making, to separate education from advocacy.
I've got an unusually nasty version of that problem with a project I'm working on because I'm on both sides of the fence: user and techi. As a user I'm quite sure I know better than anyone else what needs to be done, and as a techi I'm quite sure I know better than anyone else how to get it done - the problem being, of course, that's there's no actual evidence to support either belief.
In this particular case, and I suspect often enough in other contexts, what's going on is that I've spent a lot more time on this then they have, and as I help them catch up, both their views and mine are going to get modified. We are, in other words, most likely to educate each other about the specifics of the one and only right way of doing this - i.e. the one that evolves for us over time.
However, if I peer deeply enough into my navel, I think I can clearly group the issues or things about which there's consensual uncertainty into three categories - and maybe learn something from doing that:
For example, I expect to use open source software, on Unix, for this - and maintain that for the particular class of application we need, Domino is the only proprietary option that makes the slightest sense, but that would be too expensive. (In fact, it would cost about $250K more upfront than using an open source mix, but in the long run the most likely IT related risk to be realized by this organization is that they hire an idiot to run the system - and using Domino could reduce both the risk of that happening and the rate of IT collapse if it does.)
On these kinds of issues, therefore, I see no distinction between preaching the obvious to my user colleagues and educating them.
For example, I'm convinced that the risks of using cloud anything vastly exceed the cost of owning and operating almost everything (except the net) ourselves. At the same time, however, bandwidth costs (especially in Canada where they're more than three times comparable U.S. numbers) make a powerful argument for using other people's bandwidth, and thus other people's servers. Notice, however, this this isn't as simple as it seems: a good compromise may be to do everything in house, but rent space on servers maintained by the three network carriers as store and forward points for bandwidth intensive material like videos.
On these kinds of issues, therefore, I try to very carefully separate advocacy from education - explaining costs and risks in as nearly objective terms as possible, while stressing that decisions made to minimize risk (as opposed to decisions made to reduce immediate dollar costs) are almost always highly subjective. Thus showing them what the cost choices are is mostly education, but valuing risks avoided is mostly advocacy.
I'm comfortable, for example, with limesurvey and think it can do a particular part of the job very well. Is it really the only choice? No, but it's the only choice I'm immediately comfortable with and therefore the one I'd like to educate my users to choose - except, of course, that's it's pure advocacy for me to do so.
So where can we sensibly draw the line between advocacy and education? Logically it's education if it helps them make their own choices, and advocacy otherwise - but, in practice education is often so slanted as to be indistinguishable from advocacy (even by those involved) unless you already know enough about the subject not to need to education. As a result my bottom line is a cop out: the idea that just making sure that both you and your users are aware of the issue and the impact it has on your working relationship is half the battle - while the other half is both so situation specific and touchy-feebly in nature that it's like walking through a minefield: every step an adventure, and your first mistake also your last.