Next week sees the release of our new functionality to sync GitHub releases to your figshare account to improve academic credit of code, software and scripts.
As academic domains become more data rich, an increasing fraction of research activity is captured in the tools used to analyse and process these data which raises an important question:
In order to truly exploit the research budgets and outputs they generate, technology needs to continue to evolve in order to make dissemination of research outputs as easy as possible.
As the largest host of open source software on the planet, GitHub is a natural place for researchers to store and version their scripts and tools. We worked with GitHub Scientist Arfon Smith (co-founder of citizen science juggernaut ‘Zooniverse’) to make sure that our integration with the GitHub API was following best practices using the new webhooks and only asking for the necessary permissions. This however, is only half of the story.
When forging new ground in academia, it is very important to get as much information from the community with regards to best practice and community need, particularly when it comes to reuse and functionality. We also wanted to explore possibilities around using open APIs to bridge two existing services (in a way that’d also be replicable for other repositories). This is where the third and perhaps most important partner came into play. Mozilla Science Lab is a new branch of the open source giant’s community, headed up by Kaitlin Thaney, working to help make research more efficient through use of open tools, community building and educational programs like Software Carpentry. They serve as a connection point and support for the research community, bringing together technologists, researchers, librarians, publishers and funders to discuss how we can make the web work for science. The Science Lab’s work is focussed around 3 tiers:
In order to handle matters like licensing and documentation to enable maximum reuse of the code responsibly, we reached out to the community for their input through the Science Lab’s community call, in open discussion threads, and with other researchers, publishers and repository leads to explore how we could use open APIs to move content from one repository to another, so information could move easily between offerings. Whilst we’ve moved to building out that functionality internally at figshare, we also wanted to test a means of bridging code and data repositories to demonstrate how others could also utilise similar functionality to serve the research community.
Perhaps the most encouraging aspect of this collaboration is the involvement of various communities in both the technical and research space through Mozilla and GitHub. Even more so, the fact that these two companies have brought in scientific based initiatives this past year alone demonstrates their understanding of the problem.
Those employed to develop software and scripts within a research department rarely get the credit they deserve. Often their work is included as a middle name author and the code remains undiscoverable to the academic world, dramatically reducing the potential for reuse. As funders changes their policies with regards to research outputs, these academics should finally get the credit they deserve in order to progress their career at an appropriate rate. An example of such policy is the National Science Foundation’s (NSF) move to measure academics based on their research ‘products’ and not ‘publications’.
The project has been garnering feedback and heightening awarenessthrough the work of the Science Lab since we announced we were working on this back in December. You can catch up on the project’s evolution in these posts (1, 2) and discussion threads. There is also some more information with regards to the conversations around licensing and workflows here.
The project is an open and iterative one. We are all big believers in the idea that there should be multiple options for researchers to carry make their code citable and reusable, as long as they follow some basic best practice repository guidelines - such as persistent identifiers and long term preservation plans. We’ll be making available an open roadmap for the project soon as well as continuing the discussion around best practice for code reuse. We hope you’ll continue to help us test and shape this work as we move forward.