Have Strict Public Support Rules for Your Free Software
I think most developers of free /open source software sooner or later find themselves in the dilemma how much support they are ready to provide for free. Well, I certainly found myself in it that dilemma. Here’s what I did about it…
How Come?
When an open source project starts, it is a totally anonymous entity. Nobody asks you, the developer, anything about it, nobody wants any help with anything… A clear sign you have no users (yet). This can be quite frustrating, putting hours and hours (or weeks and weeks) of work into a project that obviously no one cares about…
Then, wonder of wonders, there is that first comment, that first issue report, that first request for help… Wow! You’ve finally got noticed. At least this one person, perhaps on the opposite side of the world, has found your code useful. What a relieve…
You eagerly respond. You make your best effort to give a truly substantiated response, to be the most helpful person you can, for YOUR user (note the singular ;-)) …
Months later, your good code, (but also your supportive attitude) have led you to a point when you have many more users, and many more support requests. But your available time is still the same, and you still have to do those bothersome things that help you pay your bills…
If you are in the lucky position to have found ways to make money proportional to the number of your users (read: visitors), good for you. (Tell us how then ;-)) But if not, you are in a dilemma: You don’t want to piss your users off but neglecting their inquiries, but you also don’t want to piss your employer/clients or your family off by not devoting to them the time they deserve.
What to do?
Reality is, you can’t create more time. Nobody can. All you can do is concisely and deliberately select which matters you will spend time on, and which you will drop or defer. Applied to support requests, it means you need constraints and priority rules that you consistently apply to select the requests to process.
In this, it is utterly helpful to have these rules written down – right on your website! That way, they are not only clearly outlined for yourself, but for your users, too. It will help them write better support requests by making it clear and explicit what you expect, while making things easier for you to handle.
Here is my list of support rules: Hackadelic Rules Of Support.
Your list should contain both inclusion and exclusion criteria. I have personally found it easier to define strict exclusion criteria. Inclusion criteria cannot be definitive anyway, because your time is still limited, and even if all inclusion criteria were satisfied, there will be still some items that you will have to drop (if nothing else than for becoming obsolete over time).
Remember that this is your list, and you need to be happy with it in the first place. If there have been inqueries, or attitude that you found disturbing, put it in your exclusion criteria. If you feel some things are important to you, no matter how exotic, put them in your inclusion criteria. (For example, I included “fun” into my criteria, though fun is a very subjective and volatile concept.)
Note that, at the beginning, your support rules list will be quite “vivid”. They are likely to go through some (many) changes, iterations and refinements before they get the shape that you are satisfied with. Especially if it is not exactly your 2nd nature to do things like this.
My advice is nonetheless: Make it public from the beginning. Don’t refuse yourself the chance for public feedback.
