I really sympathize and have had similar experiences so I don't feel out of line when I say: it boils down to your own fault. I know about the pressure and the "stone soup" situations and the fear of looking like a jerk or you don't care if you don't sink 5 evenings into helping someone who can't be bothered to read your explanations but the beauty of open source is freedom. Freedom can be messy and even adversarial but we are free to set our rates and if a "thank you" isn't enough payment, don't take the job.

(I sincerely wish I could follow my own advice. And you should remember that the thank yous can add up in the old Karma bank. The person you helped might end up on a hiring committee someday when you're looking for work or be available as a reference, etc, etc. The open source world can be a small one and in my experience your good behavior and attitude in it come back to you.)

it boils down to your own fault

Yes, I know and I fully agree with you! (BTW, I am the OP).

if a "thank you" isn't enough payment, don't take the job

It seems that I have not explained clearly my point of view as all the replies have missed it. Probably because I have mixed a rant and a meditation.

I am not saying that a "Thank you" is not good enough for me as the helper.

What I am saying is that for the help requester, sometimes a "Thank you" is not enough in order to be polite. There is a subtle but big difference.

As a community, it seems that we have forgotten that good old custom of rewarding those that help us, specially when they do it at our request and in a fully altruistic manner.

Anyway, as I said before my real intention was to make other monks aware that when they ask somebody for help they are actually using his time to solve their problems, they should try to not abuse it!

How to be grateful for it later is up to them, their politeness, education and what their mother toll them to do in those cases :-)

Yeah, that is difficult. So we have a couple of different kinds of persons in this equation. I can name a handful of hackers, some high profile, pretty much all monks, who have sunk at least an hour or two on my behalf; mailing lists or bug reports. If I had to hire them or repay them, realistically, I'd be out a couple thousand bucks. This doesn’t even cover some of the help I've received here which in a couple of cases probably equalled $1,000 of my time in a single response.

But I'm not a regular end user, I'm a dev with a CPAN presence, I post tutorials here and there, and I'm a good citizen as far as bug reports and patches go. So, maybe I've saved the Perl community ten times more than I've cost it. When ikegami or creamygoodness or stvn or BrowserUK (update: fixed amusing typo) or any number of other monks and Perl folk spend an hour or two helping me they're helping others indirectly by solving problems I'm not so hot with so I have more time to solve the problems I am good at and spread that around.

Other users… I don't know. Well, now that I think of it, I read a fun article about guessers and askers recently. The gist being some people ask, not worrying about the answer, and don't think anything of it, others guess first and only ask if they think the answer is yes. You and I are guessers. It makes us polite because we don't like to impose. We won't even ask unless we think the answer is yes. This makes askers rub us wrong because when they ask, we're constrained by our attitude to either say yes or we resent being forced to say no because we don't like to be “impolite.” The asker has no concept of the perceived impropriety. He just asks, not having much of an expectation either way.

I'm all for peer pressure to be considerate though. I do think this stuff equals out pretty well already and some of the touchy spots are plain misunderstandings and differences in personality. It would be nice to see a rewards/beer/credits system on some sort of social coding site… It would take the governments of the world a few years to catch on how to tax it. :)

(update: fixed a few typos.)

I know, bug reports and communication without finding out the information you need can be annoying, but then you have to decide if you still take the time to find it out or not.

On the other hand, I have gotten many useful bug reports, even patches, that show that people have spent time to dig into the code, even posted me a script to find out a memory leak for example, and that was saving myself time. If I have a module on CPAN my demand is that it's doing its job correctly, and I'm thankful for people spending time to help me fix bugs.

So some bug reports *cost* myself time, and some *save* time.
If you expect people to give you something additional apart from saying thanks, then you should add a "donate" link somewhere or so.

If there have been several mails, hours of dedication and a real commitment from the person helping you to do your work and solve your problem, just saying “Thank You” is not good enough.

So what would you have them do?

Asking your neighbour to dinner is feasible. They live close--not the other side of the world; you have some level of knowledge of them already--that they don't eat pork, or sea-food or meat at all etc.

What can the guy on the other side of the world do for you?

As a user of software, what bothers me a lot is that some software packages don't have clear contact details and instructions for reporting bugs.

Dear developers, if you release any software package, please include at least the following information in the documentation.

1. The address of the official website of that package, from where you can download the newest version of the package and anything related. (This is less of a problem with CPAN modules, because it's easier to guess, but it can be surprisingly hard to find for some other packages, especially when installed through an OS distribution package or other third party source.)
2. Address of where to send bug reports and where to review previous bug reports. (This is a problem for CPAN modules too. Eg. until someone told me, it wasn't clear to me that Mark Lehmann does not like the CPAN bug tracker.)
3. Some hints for what information to include in bug reports. (I have sometimes forgotten important pieces of information like the version of the module. Yes, it's my fault when I do that, but such a checklist can still help.)

These can help a lot to users like me, and it's not much work for you, just a few paragraphs (of mostly cut-and-paste text), so please include them. (To Anon OP: you might already know this, so don't take this personally. I'm asking developers in general.)

Also, when you get such bad reports, instead of trying to reproduce the problem from very few information, have you tried just replying the submitters asking for more information? I don't really know if that works, just wondering.

I'm not a famous CPAN author but I have spent hours trying to help answer questions here. I'm always pleased to see feedback indicating that my efforts helped. Thankyous don't go amiss either.

If you want to do it then do so. I can't see how playing the martyr takes open source land one step further forward.

If the bug report doesn't contain enough info, ask for more info. If they can't provide the info, close the report. If it's a real bug, someone else with more skills/experience will report it sooner or later.

If they can't provide the info, close the report. If it's a real bug, someone else with more skills/experience will report it sooner or later.

Or give the bug reporter a program which will record/report enough information to reveal bug/fix

Good joke! Let me know when you write a program that can read the person's mind. And start itself automatically as the person is about to start mailing for help.

Jenda
Enoch was right!
Enjoy the last years of Rome.

completely understand ... I am on several open source projects and have attuned my senses when a 'asker' is straying across boundaries; I make it clear that I am willing to help but wont do their work for them and I give myself a time limit (sometimes this is # of emails, duration ... whatever fits) and pop it into my emacs journal so I can get some perspective. This seems to work for me.

I try to remind myself that many times people can be at their wits end and really desperate (esp where data loss and other vagaries strike) but there are the rare 1% of people who for example make feature requests and demand time estimates ... or are not willing to invest a single minute in researching using that great big thing called the 'internet' the basics ... I dont waste any cycles thinking about it and just send their mail to /dev/null.

Anon monk here, but not the OP.

Note to developers: if I ask you a question, I've read the docs and am not able to find the answer. Maybe it's in there or maybe it isn't, but I can't find it (which means others may also have trouble finding it). If

1. you answer my question, and
2. you have your code repo publicly available such that it's easy for me to fork and send you a pull request (or patch or whatever)

then I'm apt to fix that one little piece of the docs myself and nudge you to accept the changes.

My advice: please make your repo available, and when you answer a question (please do!), if you don't think you can make the time to update the docs yourself, encourage the askee to improve your docs themselves.

Aside: if you don't know the answer to a well-researched and courteous question, please say so! An, "I've got no idea, never tried it" or "tried that once in a previous version and it was an awful idea" or "please ask on the mailing list" is far better than no reply at all. No reply at all makes me think maybe you're either rude, or don't maintain the code anymore, or maybe the email I sent is stuck in limbo somewhere.

I think, many of the more famous CPAN (or other OSS) modules must make this experience. It's not nice and it leads me to add a paragraph to all my maintained modules under which circumstances I will provide free support and that any kind of support can be got via hiring me - looks like other authors had the same idea, see a comment of David Golden: http://www.dagolden.com/index.php/804/expectations-of-volunteers-in-open-source/.

Yes, "Thank you" is sometimes not enough - but you should create the rules (and tell the prices) before you take a job (or before you investigate more effort).

In case of CPAN you can always ask the RT Admins for help if a user is misusing RT (e.g. reopen rejected tickets).

And you might take a look into DBI - there is a good paragraph about "Getting help" - it guides the users perfectly. The users who ignore this will be ignored, too - it's easy.