Comments on: The virtuous circle model of support for open source http://osswatch.jiscinvolve.org/wp/2010/02/10/the-virtuous-circle-model-support-for-open-source/ open source software innovation support centre Fri, 03 Feb 2012 15:30:22 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: stevelee http://osswatch.jiscinvolve.org/wp/2010/02/10/the-virtuous-circle-model-support-for-open-source/comment-page-1/#comment-259 stevelee Wed, 10 Feb 2010 14:16:44 +0000 http://osswatch.jiscinvolve.org/2010/02/10/the-virtuous-circle-model-support-for-open-source/#comment-259 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. 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.

]]>