February 26, 2003

Support and Open Source

Dan posted a nice micro-rant regarding support in open-source projects. I thought I would try this whole 'trackback' thing and post my thoughts as a response here instead of as comments on his blog.

Supporting open-source projects is hard. It's quite easy to say (and I have many times) "Dude - it's free software. I wrote it for myself. If you like it, great. If not, f*** off." While there is certainly nothing wrong with that statement, there is also the issue of producing successful and high-quality software.

As an open source sotware author myself, I know that while I wrote almost all of my projects to 'scratch an itch', I open-sourced them in the hopes that other people would find them useful as well. There-in lies the problem. In creating a peice of software and making it available for free, you enter into some sort of poorly-defined and purely implicit social contract with the users of that software. The more prominent the project (and PHP is quite a prominent project), the deeper that social contract runs. You've agreed to provide software that more or less does what you say it does. If it doesn't do this, you've broken your part of the bargain (we'll get back to the other side of the deal in a second.) Of course, as an author you can decide that you no longer want to support your software (due to a myriad of reasons that are your own and no one elses). Then it is polite to let users know that the implicit contract no longer exists, and that the project is dead to you.

I purposely described this arrangement as a contract and not a single-sided responsibility because users have an important part to play as well - and one they often forget.

The user is responsible for using the software as it was intended to be used. If you use it in any other way, you're on your own.

The user is responsible for learning to use the software on their own. 'Support' of an active open-source project means making it run as it is supposed to. It doesn't mean teaching you how to use it.

Change requests are performed at the authors whim and on their own schedule. Patches (at least for my projects) are always welcome.

Bug reports need to be helpful. Many projects have detailed instrctions on how to prepare a good bug report. Read them and follow them - it is the users responsbility to generate high-quality bug reports.

Bug fixes will come when they come. The author has other things to do that may take precedence over debugging an issue.

Responses to any inquiry may take some time. The author has other things to do that may take precedence over answering support questions.

And most importantly: be courteous. Regardless of how big a POS you think a piece of software is, the author almost certainly spent much more time writing the software than you did experimenting with it. That time was almost certainly unpaid personal time. They have given a portion of their life to help make your life easier. Show them the courtesy and respect that this deserves.

Courtesy and respect go both ways of course. And the world is sadly lacking in both.

Users: be aware that while the author of the software you use may choose not to live up to their end (making their software work) even if you uphold yours, if you break you part of the contract, they will likely ignore you or worse.

As an aside, I would like to note that if you (the user) really want service and support from an author of some free software you are using, paying them is a great way to get it. It is very amusing to me the number of people who write me saying 'I love your software, it has saved my business [large amount] dollars. I really wish it did X.' or 'I wish you could fast-track the fix of bug Y.' When I told them that I was too busy to handle the task, but that if they wanted to contract me to make the addition, the requests always fall silent. (This is a great method of deterring support requests btw). I've had two people ever pay me to support a product I built (both cases where feature adds/performance tuning). Just as you the user cannot often afford to pay me to help you, I can't always afford to spend the time to help you. It doesn't have to be cash either; if you have something that you feels is equivalent in value to the hundreds of man-hours I have put into making something work, or the couple hours I would have to spend to help you out on your specific problem, I'm all ears.

Posted by George at February 26, 2003 02:15 PM | TrackBack
Comments
Post a comment