The Software Sustainability Institute (SSI) ran a workshop for research software engineers (RSEs) in Oxford on 12 September 2013. Here are some thoughts that came to mind during the workshop.
Often working alone in institutions, feeling isolated and undervalued research software engineers (software developers in research institutions) have felt the need to get together in a community. Perhaps not considered as important as those doing the research, career progression is unclear as there is not the same recognition for software outputs as there is for academic papers.
With this in mind SSI organised the workshop to bring RSEs together, discuss topics of interest and decide on a way forward for a fledgling community. They used the "un-conference" format with a couple of invited speakers (Figshare and the recomputation manifesto) to begin followed by group discussions on topics chosen by those at the workshop. The day ended with a final discussion on what an RSE community would look like and do
All the details are on line here The discussion groups reported back and I expect SSI will collated them into a report soon.
A Brief Summary
SESC has RSEs as a target community and it was great to see so many get together for such an informal meeting at relatively short notice. The major concerns aired at the meeting were
Recognition for software developed - Getting it cited/published. How can people find it?
Journals exist that peer review software so if you want some formal review and publication take a look at: * Journal of Open Research Software * Journal of Machine Learning Research: Machine Learning Open Source Software
People can find them in code repositories:
- CCPForge A repository primarily for computational science software run by SESC. Offers revision control, file releases, choice of licences, bug and feature tracking, wiki.
- Google Code
Download count or the number of repository forks is some measure of the discoverability of your code but not necessarily of its quality. Perhaps a rating system could be devised to score software and a community score be built up.
Sharing of code - How? Am I allowed to? Who owns the IP?
Share code in repositories listed above using revision control. Youll also be able to use them to release the software to users if you dont have an open RCS repository. Which one you choose will depend on factors such as the license you want to use, whether you need bug tracking or project management tools or access to other bundled tools.
Exactly what you can share is a little more tricky. Many institutions own the code you produce at work so you better check! Sharing code within an institution doesnt have this restriction of course. If the whole code cant be shared then perhaps small components can. A module that reads and writes a particular file format for example, or one that calculates physical properties, or a script to produce some amazing graphics.
Training - What should I know? How can I learn more?
Apart from Where is the nearest decent coffee? there is plenty to know but the good thing is that its a pretty standard list.
- Revision control - git, subversion, mercurial etc
- Build tools - make, ant (autotools if youre feeling brave)
- Compiler options for code checking (rather than performance)
- Documentation tools - doxygen, Robodoc
- Testing - units, coverage, validation
- Basic Linux commands
- Scripting - bash, perl, python
SESC can provide training on the first 5 and we also go further looking at areas such as:
- Software metrics - measuring the complexity of source code and finding ways to reduce it
- Pretty printing - having a consistent layout for code
- Software transformation - e.g. from FORTRAN 77 to Fortran 95.
Its time for a community of research software engineers. Together they can address the issues mentioned above and express their views to employers and funding bodies about how things could be improved.
SESC is keen to play a role which can start with training but we are also happy to discuss issues and give support in other ways. Let us know what you are thinking.