Where does open source help end, and consulting begins?

Question

As one of the core contributors for an open-source framework, I'm frequently dazzled by the blurry line between "open source help" and consulting. I'd like to ask for your advice on the matter.

Frequently, people using the framework would post 400+ lines of their code and expect me/others to dig through it to find an error; there are two conflicting forces in my head:

• On one side, I want to foster the community and help everyone
• On the other side, I just physically can't invest 2-3 hours into a forum thread - this feels like "free consulting" to me

Here's an example thread if you want to take a look at an example. I'm curious to hear about where you would draw the line.

Answer 1

Without even looking at the thread, I would draw the line wherever you want. While it's nice to reach a project with support, they should also be supporting your project, not draining it. Just my thoughts.

Answer 2

This is a common problem on any programming related forum. Which is why it is encouraged to post short, compilable programs that demonstrate the problem, if at all it is compilable (or the piece that does not).

I think you are free to say no when it is too much, if this is something you are doing on the side for fun/non-profit purposes. However, if it is your/your employer's software that you want to promote for long term benefits, it is better that you provide as much support as possible.

Answer 3

Managing expectations is key. Open source isn't free or limitless, it is an investment relative to what each contributor can give. Learning to manage what people think they're entitled to for trying out your software by clearly defining how each type of request will, or may be dealt with is fine.

There would be three main types of requests, present in most any project...

• Product related issues relevant to any implementation are a bug and should be dealt with as such (a shared queue, etc)

• Implementation related issues relevant to a specific user trying to do something a certain way and having difficulty is consulting related.

• Feature related issues relating to people asking for functionality, or trying to get functionality should be dealt with either by consulting needs if custom, etc., or included in your roadmap through whatever process you go through to identify valuable features.

  Many people may not even know how to discuss or ask for things in a open source forum..? If I was working on an OS project and someone was demanding my time, I'd be willing and say I have to take a day off of work, will you accept the charges.

Answer 4

If 400+ lines of code trigger an error in the framework, it is not your problem to debug those 400+ lines of code to find out which of them is the issue. After all, your task is to provide a working framework, not to debug all the code on Earth that is using the framework. The person who is reporting the bug must isolate the bug trigger to a trivial example. He wants your help because you know the guts of the framework better than him, you need his help with his code that is using your framework, because that's his code and he knows it better than you. This must be a fair trade between you and the bug reporter.

A good way to filter such attempts of throwing huge piles of code at you is to demand explicitly for failing unit tests as bug reports. This way the eventual bug reporter will have to look at the unit tests first, then write his own unit test that emphasizes the issue.

Answer 5

When somebody says "your code crashes", then he gives you code from a software of his, you can't be sure the code is yours that crashes. First it's common for people to blame others from their faults in the business (an ass covering technique). Second, if the user can't isolate the problem from his code then he hasn't studied the error enough to be sure. Always ask for a minimal program that reproduces the error.

If the minimal program that reproduces the error is >400 lines long then your software must be really broken.

What comes to the question you made up. You own your time and can do anything you want with it. You draw the line, and that line is drawn onto water.

Answer 6

If you are working on a piece of open source software, for free. And are not getting paid for your time. You, as the developer, expect certain freedoms.

A trivial case, is that you are given ultimate control on the features. If a user asks for a feature that is of no interest to you. You have the freedom not to build that feature. This is a luxury that most developers do not have.

One such freedom, is to be given good bug reports. A good bug report means I do not have to read through 400 lines of code to understand whats broken with my program.