A recent forum post by a new poster raised an ember of inspiration in me regarding the issue of a new user communicating with an open source project.

Keen eyed readers will notice how I phrased that - a user communicating with an open source project...not the other way around, we're not going to be focusing on how a project 'should' communicate with users but what users can do to make their experience communicating with open source projects a little smoother.

I'm not in the habit of telling people what to write or say and I'm not going to set out a series of commandments that a user or project must follow, that's not the point of this blog post.

What I do want to do is offer users a few tips to help 'manage expectations' because communicating with an open source project can be very different to communicating with a paid or for profit entity.

1. Help yourself!

If you haven't googled your particular issue, read the documentation, scoured the forums, tracked down the address and driven to the house of that user back in 1998 who had the same issue but only saw fit to post a 'Problem resolved' message, and then subsequently beaten the answer out of them (I jest)...well then you're in for a bad time.

Nothing infuriates an open source project more than asking a question that has already been answered, sometimes many many times over, but you simply haven't taken the time to look it up. It's lazy, makes you look like an idiot and people will delight in telling you where to go.

Also remember, starting off by making yourself look like an idiot will shape future communication with you - see point one above.

Now, let me caveat that last sentence.

The fact people will think you're an idiot is one thing, actually being an idiot is another. For instance, how would you know to look up 'hyperdyne metafold generator failure is causing recursive extoplasmic segmentation faults'?

You wouldn't, and not knowing that doesn't make you an idiot.

But to people who do know that and have answered the same question 30 billion times you will look like one.

This is what is known as a 'no win situation'. Enjoy it! (The moral of the story being, try to relax let this wash over you like water off a ducks back, as there is nothing you can do about it.)

The second half to helping yourself is, after reading the documentation and confirming there is a real genuine problem, providing ALL the information necessary to replicate the issue. Actually, I'm going to stop right there. This point could fill a book in itself so let me instead defer to the excellent words of Simon Tatham and his How to Report Bugs Effectively essay.

That essay should be required reading. If there was a license all of us had to sit to even be allowed behind the keyboard of a computer I'd use my single vote for this being in the curriculum, if only for the hope that there might be a few less Mongooses in the world.

2. You are a user, not a customer

This is an absolutely fundamental difference that goes right to the heart of the matter. Many of us live in a world dominated by the US customer service model, where the customer is always right and their views are at least made to feel extremely important, even if they are silently ignored in practice!

This tends to carry over into the software world but here the practice becomes a little blurred.

The past 15 years has seen the rise of online services that offer their product for free to users, but then monetise those users in various way (such as directed advertising).

Because their customers are their revenue stream these services follow a similar customer service model of 'the customer is right, keep the customer sweet'. It's obviously not the sole reason but it's contributed to a generation of users who have grown to expect 'free' to equate to a similar pandering to their opinions and complaints they might see in the physical consumer world.

Now, for goodness sake don't go thinking this is a blanket statement that applies to everyone or every service, things are not black and white. And don't go thinking I'm conflating free and open source in that last paragraph, I know the difference - I'm just using common terminology.

Anyway, as I said I'm not setting out commandments here and if the above doesn't apply to you or your service, great.

What in caveat in mind, nearly all open source projects also highly value their users and wish to provide as high a level of 'service' as they can. They dearly want you on board, to use their tools and to hopefully inculcate a similar sense of passion and fulfilment that they themselves get out of the project.

But, and this is the big one, for many projects you aren't a customer, you won't always be right, your opinion can sometimes count for nothing, your request can and sometimes will be ignored and you almost certainly won't be pandered to.

There, I've said it.

It feels like blasphemy in this modern world but it's essential you realise that to (many) open source projects you're not the centre of the universe. Whilst people will be willing to help you, don't expect to be king of the castle and have people fall at your feet or fan you in the hot midday sun with the tomes of expansive documentation you failed to read.

3. Waffle is irrelevant. Information is king. Terse != dismissive

Everyone loves praise for their work and loves to know you find their work useful but do not be under the illusion that by wrapping your bug report in stanza after stanza of obsequious love poetry aimed at the maintainers/developers it will be given any more attention or preference than the rest.

In fact, with many open source projects being a labour of love slotted around the daily grind and full time jobs that put food on the table, your voluminous sonnets will just lead to frustrated shoulder slumping resignation as the relevant information is painstakingly parsed from under the roses and perfume.

So what do you do? DO expect communication with developers and maintainers to be short, sharp, to the point and devoid of pleasantries. DON'T cry yourself to sleep over it or feel insulted, the key is information exchange and not small talk - see point one above and Simon's essay again.

Also, don't ascribe tone or intent to text on a screen.

Don't do it, just don't do it.

Doing so inevitably causes you to append your own prejudices and perceptions as to tone and some arbitrary level of respect those words somehow convey. There is no metadata available for plain text so the the application of these prejudices are entirely your own doing.

Instead, try to simply take the words at face value and with the understanding that the other person has the best of intentions.

Sometimes, some people will write to elicit a negative emotional response, they're called trolls and are easy to spot. You can safely ignore such trolls!

Thankfully developers often have no emotional ability that they're aware of and are thus incapable of intentionally eliciting responses in others (I jest again...?). Their text should instead be read in your favourite monotone robot voice. A speech to text programme should suffice here.

I exaggerate of course, but the point remains, support interactions on mailing lists and support forums are (at least in the initial exchanges) primarily about getting information transferred quickly and clearly.

Somewhat the opposite of the style of this post in fact.

There are all manner of other types of communication through these channels, some of which are very emotional in nature and can be fun to read or write, particularly when talking to friends. But as a new user please don't go getting your knickers in a twist if the initial responses you get aren't cheery and effervescent.

As a test, I'm now going to ask you to make sure you include the word banana in any comment you make on this article. Just to see if you actually read the whole thing.

Warnock's dilema

I'll sign off on one thing that's also key to learn, but doesn't necessarily fit in this particular post. It's essential you know of it, lest you go mad in digital isolation...

http://en.wikipedia.org/wiki/Warnock%27s_dilemma

Enjoy!