Lessons learned in starting a national software institute


#1

Someone recently asked me to reflect on my experience of setting up the UK’s Software Sustainability Institute, which started in 2010.

Here’s my thoughts - hopefully others find them useful:

  • Make sure you have enough effort on board from people who are good community builders. If there’s one thing I would have done differently with the SSI, it’s that I would have doubled the community engagement and dissemination and outreach effort at every stage.
  • I think a lot depends on the landscape. When we started in the UK, we were coming out a period of huge investment in software development (from the e-Science programme) and continued investment into the traditional HPC-led computational sciences. Although we initially focussed on these groups, we quickly realised that the sweet spot for us was working with the large group of researchers who had been inspired but not always been involved by the e-Science programme and were not already being catered for by the high-end computing initiatives. This allowed us to achieve quick wins with this sector of the community whilst selling upwards the idea of “on-ramps” that would enable researchers to use larger and larger resources. We did this primarily through training, and through supporting a wave of enthusiastic people (our Fellowship programme), many of whom were advocates of the open science / open source movements. Getting a feeling for who are the groups who are raring to change things is important here (hence the need for good community engagement).
  • We bent our funders rules considerably to support the communities with the most need that could be helped with the least resources, which were often not ones which we were directly funded to support. In particular, at one stage about three years in to our first phase, 60% of our work was in research areas outside the normal scope of our funder. However the upshot of this is that we got more funders to come on board – we’re very lucky that our original funder (EPSRC) were lenient in the early days!
  • It’s all about community amplification and understanding what approach you’re taking. We used a very hands-on, grassroots approach that worked well to get a number of key champions involved – in general our policy was to help others make a change and act as an arbitrator / facilitator to support them. Most of our work now is in giving community champions resources to make things happen, so that we can do much more than we could trying to keep it all in-house. As a result, we’ve helped create self-supporting communities of practice such as the Carpentries community in the UK and the Research Software Engineers.
  • Get evidence. The thing that got us the second phase of funding, and will hopefully get us the third phase is some solid data about the research software landscape that funders can use to argue their case. For us, it was about showing the reliance on software, and also identifying how we could help show our funders in a good light – a specific thing in the UK is the idea of “place”: ensuring everything isn’t concentrated in a few elite institutions and making use of the specific expertise that has grown in a particular area. For the SSI we’ve serendipitously tapped into that.
  • Evolve as your knowledge of your community’s needs evolves. When we started, we didn’t do training, we didn’t do policy research and our ideas for our website were very different. We ended up doing all these things because we gained a better understanding of what was required to fulfil our mission and vision, rather than narrowly focussing on completing plans of work which would have ephemeral impact without doing the other things.

Anyone got tips of their own they’d like to share?


#2

Thanks Neil - this is really helpful in thinking about what URSSI could/should do.