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.
One thing to consider is that the term ’support’ may imply a largely one way interaction (OK perhaps with cash going the reverse direction). In reality, and especially in an open development model, interactions are much richer. Some close source support interactions are also rich, in fact I once got employed by rapidly moving from being supported to providing ideas and testing out experiments. However given that open development’s key aim should be building a diverse and sustainable community, every interaction should be mined for maximum value to the project.
At it’s simplest the act of supporting someone is likely to uncover bugs, possible enhancements or document errors. All of these can be viewed as simple contributions from the user. My contention is this 2 way interaction is of great value to all parties. In fact users may contribute more directly by raising a ticket or suggesting a work around or solution. Ross already mentions the opportunity to provide community support.
In addition ’support’ touches on many operational areas of the project including QA, release procedures, governance, sustainability. All these processes are likely come into play as part of, or in direct consequence of, a ’support’ transaction.
I was just discussing testing with the Southampton Accessibility team. Here the question asked was how do we involve users who will be testing? However it soon became clear that this is not just an issue of getting test results, but a much broader issue. Testers will need to know what they should be testing and what to expect(e.g docs or training) they will need to discuss their findings with others testers and with developers (or at least someone close to the development). They will need ’support’ with their problems, as well as software updates.
In this case we discussed the ideal of users interacting directly with developers on a single channel and raising tickets directly. However with very non techy users it’s more common to give have separate channels (often a forum for uses). A mediator may then create and monitors tickets on their behalf, as part of a QA process. As users are unlikely to use developer code setups for checking the fixes they also need to be notified of releases that fix the issues they found (so the release process comes into play).
However the project should aim to encourage such users to quickly learn to work more directly with the project team, perhaps starting with with tickets Thus they start having ever deepening and richer interactions. Thus supported users can become contributors, or even committers. Joanni Marie of GNOME’s Orca screen reader project is a wonderful example of someone who in a short time progressed from being a user’s representative to a core developer (in fact Joanni still has both roles). This helps the projects sustainability, and the sustainability of the users own experience with the project. That probably closes a circle too.