Supporting your free software? Don't burn out

Not long ago I watched a free software developer totally lose his cool with a user who (admittedly very frustratingly) posted a "bug report" in Spanish on an English-language project that amounted to "it doesn't work". He posted a very sarcastic reply in a couple of random languages (one of them through a machine translator). It was an understandable reaction, and in a way, kind of funny if you could understand all of the languages involved, but it wasn't exactly good public relations. It was a sure sign of burnout. He had forgotten one important point: you are not obligated to help just because you wrote the thing.

What follows is what I wrote to him (the names have been excised to "protect the innocent"—or guilty as the case may be). I thought it might be of some use to others as well, so I decided to repeat it here:

An open letter to a volunteer free software developer: 'Don't burn out!'

My recommendation is to put a FAQ up somewhere that says you only provide support in English (and probably some other rules too), and then just don't reply to stuff like this. Or if the person comes back, post a link to the FAQ.

That's a reasonable policy—it just means you're too busy to deal with it. People should understand that, and if they can't, it's not your problem.

But you know, in this case, you actually spent a bunch of extra time with no real purpose except to make this guy feel bad. So, you lost time; he lost time; heck, even I lost time. Nobody wins.

Not that I can't identify: I don't know how much time I've wasted coming up with "clever retorts" that I really shouldn't send.

I don't know how much time I've wasted coming up with "clever retorts" that I really shouldn't send

It's just like any other kind of service profession. You have to establish some kind of limits on how far you'll go to help people, or they will eat you alive! This is the main reason I don't like service professions—I worked as a telephone support tech for a Hewlett Packard contractor, and lasted about four months before I had to bail.

Ironically, in that time I had no more than three or four "irate" calls. Other people seemed to do much worse—I think I just had a very calming voice. One guy in my section got so angry he broke his phone when he hung it up (I'm not sure why he wasn't wearing a headset, since most of us did).

Don't let it all get to you (Photo credit: Mike Fernwood/CC By-SA 2.0)

The ones that are really infuriating, though, are the "babies" who want you to go through everything in painstaking detail: I once had to explain how to use a mouse to close and open windows on the screen. Or rather I once explained it—the truth is, I was well "outside my support parameters" at that point. Management wasn't too happy when I spent that kind of extra time with people—I was constantly over budget on time-per-call.

What finally got me down was just having my head full of other people's problems all day long, and then not being able to get all this trivial stuff out of my head in the evening. Also, I've never been really comfortable on phones. I'd much rather write an email or meet someone in person: to me the phone is the worst of both worlds—immediate time pressure on every reply and no visual contact.

Support forums exist for users to help each other, not for "babies" to get you to "mother" them

What you need to do is to quit thinking of your project as this service (unpaid!) that you are obligated to perform. It's a tool that you created so that you could do your own work. That's what you get out of it, and that's why you're working with it. The support forums exist for users to help each other, not for "babies" to get you to "mother" them. If other people happen to benefit, then that's "gravy", but it isn't your responsibility.

As a maintainer, your responsibility (in as much as you have one at all on a volunteer project) is to fix actual bugs when actual bug reports are filed (and filed properly).

Help other people when helping them is fun or at least engaging. Let some threads go unanswered longer. Eventually, one of two things will happen:

1) People will decide that your project is important enough for them to help support it, and users will start helping each other

2) People will decide not to use your project

Either way, your workload declines. As for the popularity contest of your project versus "the competition", just let that take care of itself. It really doesn't matter!

Unlike a commercial developer, you don't get a penny extra from "market share". So it's not your problem. And if you keep trying to "take the world to raise" and provide all of the support, then it just means more work. And people will let you do all the work if you're willing—you've got to back off and create a vacuum before people will fill it.

And then, either they will or they won't. If they won't, then your program will probably remain a niche application which you use. If they will, then it will take off and become a big player—but with other people taking on the workload (which is as it should be).

Well, I hope this letter is encouraging to other volunteers, or at least will keep them from tearing their hair out. It's all okay. You're doing a wonderful job just being there at all. You have to remember to keep telling yourself that, because the world can be cruelly insensitive about such things. You will be taken for granted, but the way to deal with that is to reserve some space for yourself and your sanity.

[Editor's note: Thanks Terry, I will keep my cool next time, I promise :-D (Tony Mobily)]

Licensing Notice

This work may be distributed under the terms of the Creative Commons Attribution-ShareAlike License, version 3.0, with attribution to "Terry Hancock, first published in Free Software Magazine". Illustrations and modifications to illustrations are under the same license and attribution, except as noted in their captions (all images in this article are CC By-SA 3.0 compatible).

License

Verbatim copying and distribution of this entire article are permitted worldwide, without royalty, in any medium, provided this notice is preserved.