OSS Watch is an independent, non-advocacy service. We are experts on free and open source software, but we do not insist on it as the solution to every problem, nor are we tied to any particular solutions or providers.
For organisations using, or wanting to use, free or open source software we can provide consultancy, training and support on selection and evaluation of software, engaging with open source communities, licensing and intellectual property issues.
For organisations creating free or open source software we can provide consultancy, training and support in software licensing and intellectual property, sustainability, commercialisation and business models, and building communities
For the public sector we offer consultancy services through the G-Cloud iii procurement framework for specialist advice related to procurement of solutions relating to cloud services. For more information, see OSS Watch on G-Cloud.
For the University of Oxford, we offer advice and support to researchers, projects and services across the University on all aspects of free and open source software. For more information, view our service information page for the University of Oxford.
For project consortia we support building new open source communities or supporting engagement with existing communities, and to work on areas including IP management, exploitation and sustainability. We are able to join project consortia as a partner via the University of Oxford, or to contribute to the development of project proposals on a consultancy basis.
Not sure if we can help? Then please just mail us!
Authored Comments
Hi Mark,
You're right that what I've described above is written in a way that applies mainly to developers, and that it's important for a project to attract a variety of roles, so thank you for bringing it up. However, I think the principles I've descibed are relevant to enabling all forms of contribution, they may just need to be applied differently.
For example, with documentation, you still have the steps of being able to raise issues with existing documentation and submitting improved documentation, for which you need simple, well-documented processes and support from other members of the community.
For more community-oriented roles like event organisation, having an open forum for suggesting ideas and improvements could help lower the gradient at the 4th stage, while a culture of mentorship, as with code contributions, helps lower it at the 5th. In this case, rather than coding styles you need to consider things like the culture of the community, perhaps ensuring that codes of conduct are well documented and so can be ahered to. Documentation can help too, keeping records of what worked well and what didn't in the past can help inform future organisers.
Many Thanks
Mark