On the OpenCast Matterhorn developer list the following question was recently posted by Rudiger Rolf:
we have a release of Matterhorn now, and people start to use our system and they need support. I’m sure that many of us are willing to help these adopters, but in which way should they communicate with us?
This prompted a discussion I have seen many times, and so I was prompted to post my response here.
In my opinion there are two main reasons why someone would support a user:
- they are selling services
- they want to improve the quality of the product
Financial transactions should be divorced from community activity and thus, from a community perspective, we are left with those wanting to improve the project (I’ll return to paid support later though). People providing support in the community have two main objectives:
- increase the number of users
- understand the problems users are facing in order to improve the product, to attract more users
Increasing the number of users will ultimately increase the number of contributors (bug reports, feature requests, documentation, user support etc.) and eventually developers (code improvements). Thus attracting users is a key part of creating a successful open source project.
However, not all users will become contributors, and not all contributors will become developers. In fact, the numbers of people progressing along this scale of contribution is very small. Nevertheless, just one contributor is a reduction in the centralised cost of development and thus a step towards sustainability for the project.
For some people the idea of free support for a growing number of users appears to lack scalability. They ask “if we are attracting users at a faster rate than contributors/developers how does the project continue to provide support? Surely there is a danger of too many resources being devoted to support and not enough on development.”
These are common concerns in a growing project. However, these assumptions ignore the fact that some people are willing to pay for support. The ideal solution is to provide a user support mailing list along with supporting documentation. There is a need to encourage everyone to assist with these community support channels. This channel should become the place where the not only users get support, but also where those providing paid for support seek support themselves. However, support provided from the project community is provided on a voluntary basis and therefore no guarantees of service are provided. The message is clear, if you want guarantees of service then you need to pay for it.
Of course “paying for it” may not mean in cash. For example, if an organisation is known to provided paid for support but they also provide resources for project management, documentation, code or some other contribution they are earning “credits” to get support themselves.
Over time, the number of “first level user support requests”grows. However, the number of people able to answer these questions is also growing, lets not forget that some of those users are still around and are now indebted to the support community. Furthermore, since a healthy project encourages people to contribute early by documenting their experience in FAQs and getting started documentation there is an increasing amount of support documentation for newcomers.
This self-help culture enables core community members to focus on bug reports and feature requests rather than first level support requests.For those users who need a fast turnaround on support requests, they will have to pay. They may contract a third party or they may use local resources to set up a local support infrastructure.
If these paid support providers are smart they will reduce their own costs by interfacing with the wider support community via the project support lists. They will both consume and produce commons support materials in the project. They will also recognise that visibility in the community support channels is a form of marketing for their paid-for services. And this is where the virtuous circle finally closes.
