It’s been just over two months since we announced the start of the Mozilla Science Lab, and I wanted to share with you our thoughts on how to structure our activities moving forward.

Our aim from the beginning has been to see how we could best support and extent the existing work going on in “open science” – in some cases bridging existing technologies to address new problems, in others providing the educational resource to help close the gap in skills and awareness. And on top of that, map some of the core values and areas of expertise of Mozilla to science (e.g., openness, digital literacy, open-source ethos, community), like we did at Creative Commons years ago with the science project.

To ensure sure we were not just operating off of assumption regarding what the community needed (especially one as diverse, dynamic, and with as many stakeholders), we hit the road (literally and somewhat figuratively speaking, thank you Skype). Over the course of the last 2+ months, I’ve spoken to rooms of 20 / 300 / 700 asking for their feedback, and had a series of 1-on-1 calls and meetings with researchers from a diverse sample of disciplines (earth science, biology, ecology, social science, astronomy, physics), policymakers, publishers, tool developers, and educators.

What we learned

1. There’s a *ton* of activity (tool development, community efforts, policy work) pushing things forward, but we’re not nearly there yet.
2. It’s difficult to know what all is out there – what software exists, who’s tried what (and with what successes), how others can get involved. This is keeping many projects from gaining the traction they need. We need a better means of communication (about and among efforts) so we can reduce duplication, foster collaboration and gain broader use.

 (GiveWell’s recent post on the current open research landscape is a great start, but there’s still more we can do.)
3. The system is complex and reliant upon a diverse network of stakeholders and technologies. The vernacular, behavior and idea of what “making the web work for science” among these groups also varies greatly, and needs to be taken into consideration as we craft solutions.
4. We’re facing an ever-widening skills gap. Science is becoming increasingly computationally-dependent, web-enabled and data-driven, yet our training is still based around older methods of doing research rooted in the analog. For there to be a real sea change in the behavior of researchers … for us to make research more open, collaborative and reproducible, we need better training and education tailored towards these aims.


How we can help

It was clear that there is a pressing need for coordination, interoperability, and better communication in this space, whether you’re building digital infrastructure for high performance computing, building open source tools for visualisation, or looking for new (open) means of doing your research in the lab. 

Taking everything we heard into consideration, we distilled that activity down into three core areas, each mutually dependent upon one another. We view each of these areas as key to filling in some of the gaps in this space, as well as providing the infrastructure and support for the breadth of activities already going on.

Let me go into a bit more detail about each of these areas, to help you better understand our programmatic focus moving forward. We’ll be elaborating on each of these areas in a series of subsequent posts, as well.



Code

Through this work, we’ll be engaging with other external groups (scientific startups, publishers, researchers, etc.) to help bridge existing technologies where possible, build our prototypes to explore new problem sets, and supporting existing development in the community. An example of this could be taking an existing tool that may be discipline-specific and working to see if it can be applied to a different field. Or it could be taking existing infrastructure (say, the badges work) and working with external groups to test out different implementations.

Our aim here will be to serve as a means to bring together community around best practice, and also support existing work and extend it through small prototyping bursts of activity, collaborations and internal development.

We currently have one pilot running with the help of PLOS Computational Biology, exploring what code review for science could look like. See our recent post on this for more information.

Code and Data Literacy

Running in parallel to all of our other efforts in building community, communities of practice and open tools is a skills training layer, exploring what “digital literacy” for science means. Research is becoming increasingly digital in nature – data-driven and in many cases computationally-dependent – yet digital skills such as version control, visualization, analysis and online collaboration are not often taught at the university level. There’s an increasing gap between what researchers are expected to know, and what they have access to training wise. And practices fundamental to doing open, reproducible science are still outside of most formal training at the university level, despite increased availability of free, open tools for data sharing, collaboration, electronic lab notebooks and external pressures from funders.

Our work will help bridge that gap – in part by making such training accessible and attainable to all, so that scientists can do better, more digitally-enabled research.

Software Carpentry is our main activity in this space to date, a project founded by Greg Wilson to help teach basic computing skills to researchers. This is done via short two-day bootcamps, taught by a volunteer instructor base all around the world. We hope in the future to be able to build out additional components and work with others in the community exploring different approaches to heightening digital literacy for research.

Community

Last but not least is our focus on building and supporting community around the work mentioned above. We hope to be that connective tissue between various bursts of activity, understanding and practice, providing a focal point for information on developments in this space and a means for others to plug in. Mozilla has a longstanding history in building community, and we want to use that know-how to amplify the work currently going on, build communities of practice around openness, and serve as the glue to bring interested parties together. Engagement is also high on our priority list, exploring how best to use the expertise and enthusiasm of the community to help push these ideas forward.

We will be announcing later this year an international effort that hopes to do just that – so do stay tuned. 🙂

And in the shorter term, we’ll soon be announcing our first community call which will give you a chance to interact directly with us and help us continue to shape the Science Lab, hear about new tools and projects in this space, and learn more about what we’ve got cooking for 2014.

To wrap up

We view these three areas as the support beams for the open research community. You’ll notice arrows showing flow between each of those core areas, as well – that’s intentional. From a technical partnership starting a broader conversation with the community about best practice to a gap raised in our training efforts turning into a technical project, we view these areas as interdependent and mutually reliant upon one another. Moving forward, our hope is to also use model as a means to assess new opportunities, build out new programs and measure our successes.

I’ll be going into more detail about our activity in these three areas over the coming weeks. In the meantime, we’d love to hear your thoughts. Feel free to chime in here in the comments, send to mail or find me on IRC @ kaythaney.