Communicating freely

Thoughts on how we can all talk a little easier, and how that can make life better.

Be nice to developers

Adriaan from KDE – the man I personally blame for all bugs ever encountered in programs written in the C++ language [1] – has written a blog post suggesting that it’s a good idea not to send abusive emails to Free Software developers who don’t offer professional support services at zero cost for their code.

He has got a point. While the low barriers of access and hierarchy in Free Software often provide easy access to the developer in question, the developer’s personal provision of support is likely to receive a far lower priority than development work. This is hardly surprising.

Few people expect to speak directly with the developer of a proprietary application when the application misbehaves. Support is instead provided by a department inside the production company or an accredited partner. Free Software takes this abstraction a little further. One of the key innovations in this paradigm is that third parties can provide professional top tier support regardless of their relationship with the original developer of the application.

It is important to remember that the word "Free" in Free Software does not refer to the software having zero cost either in production or in adoption. It refers solely to the freedoms the software offers everyone who receives a copy.

There is a cost of production, delivery and support with Free Software. This cost may include personnel hours, hardware and electricity on the production side and it may include training, integration and maintenance on the support side. Such cost calculations do not disappear because Free Software offers more freedom than proprietary software.

Free Software is often developed by people and organisations who offset their cost of production because they get something else in return. What they receive may be kudos, the ability to play with other people’s innovations or a solution delivered to users. The situation and cost benefit analysis differs for each individual or organisation.

In the post delivery of a solution different dynamics are at play. A developer who creates a technology with a cost offset might not wish to also offer service level agreements to users. It might just not fit into their reason for making the software or it might have too high a cost.

Everyone can get the code, everyone can distribute it, everyone can offer support for it. It’s more flexible and encourages more competition over delivery of solutions. Those solutions can be technical, integrative or support based.

Many developers are happy to answer some questions and even respond to requests for features, but it’s not reasonable to expect that they are obliged to do so. We should be nice and bear in mind that we have no entitlement when it comes to obtaining support unless the creator has promised such support explicitly.

[1] KDE is written in C++. There is a connection.

One Response to “Be nice to developers”

  1. rca Says:

    How to give and receive support

    I think this is actually a much more complicated issue than it might seem on the surface.

    If you look at the large Ubuntus upport network (not entirely free software, but close), it’s mostly based on volunteer experts. They sit in forums IRC channels and try to solve people’s problems. Often they help with software for which they aren’t themselves developers — they are simply users. So if the software is popular enough and if the right support channels exist, users can find support for it from people other than the developer.

    This also works commercially of course, where guaranteed support services can be bought. Free software gives us a broad choice here, with software support again not coming from the main developers, but from independent companies all over the world.

    The problem more often arises when a piece of software is “small” enough for users to talk to developers directly. At this stage, the developers are often coders, first- to third-level supporters and QA rolled into one. Here it becomes hard for users to make any distinction between the roles of a developer, and for many users, “the software doesn’t work” is the most important issue when they visit a developer’s website.

    They might not consider that supplying the developers with bug reports might be required, and that fixing an issue might take several weeks after that. They are *talking* to the developer, but they are *expecting* to be talking to a support person. The developer is talking to an end user, but expecting to be talking to a beta tester.

    I think this gap between expectations is what creates a lot of friction at that point. The same users that are happy to be completely ignored by proprietary software makers when venting on a support hotline are not happy anymore when talking to developers and being told that their issue might have to wait, or that they should supply more detailed issue reports.

    In some way, many users are not ready to interact with developers directly (yet) :)