Science Lab’s First Year: prototypes, testing tools and best practices

Since our launch last June we’ve been working to unpack what science on the web and like the web means, and what Mozilla can do to support it. This is the second in a series of posts looking back at Mozilla Science Lab’s first year, and our plans for the future.

(If you missed it, the first post in the series was Software Carpentry: engagement and scaling our efforts.)

Mozilla is perhaps best known for its technical work — disrupting the browser monopoly with the launch of the project in the late 90s, and working to provide users with choice and to drive innovation on the web ever since. Beyond that, the Mozilla community is deeply steeped in openness — from source code to culture, as well as transparency, access, and interoperability. These core values are included our Manifesto, and they apply to all of our work across the organization.

The question Science Lab is faced with is: How can we best translate those strengths and values for the sciences to address the bottlenecks slowing down research? When it comes to technology and tool development in particular, how can we best support the existing work of the community, but also apply the things Mozilla does best to help connect, support and scale this activity?

Our technical work takes on a slightly different form than that done at an end-to-end product shop. It’s rooted in the community and centered around building technical prototypes with multiple touch points, applying open technology or solutions to research problems. In particular, we wanted to test our whether many of the problems slowing down research could be solved by making existing tools and technology work together, rather than starting from scratch. The reason behind that is twofold: (1) most of the technology needed to change behaviors already exists in some form, and (2) the smartest minds are usually outside of your organization.

When assessing new prototyping projects, we look for efforts that:

  • Improve and expand the technical stack available to researchers;
  • Address a significant bottleneck in research practice;
  • Promote best practices for open and web-enabled science by being well-documented, shareable, and designed for re-use;
  • Bring together a diverse set of partners to collaborate, build, and test;
  • Can be applied to other partners, services or situations.

Over the last year we’ve engaged in three major pilots that not only bridge the scientific and technical communities, but provide tools, best practices and resources to enable new ways of doing science on the web. They include exploring the ntion of code review in science with PLOS Computational Biology (currently in phase two, written about here and here); our Code as a Research Object collaboration with GitHub, figshare and Zenodo to explore code citation and discovery; and work on the Open Access Button, which we wrote about recently.

Now we’re looking at how we can extend those prototypes to further adoption, explore new use cases, and continue to test these ideas with stakeholders in the research community. You’ll be hearing more in the coming weeks, from advances to the Open Access Button hack by Victor Ng, to the next steps around interoperability following the “Code as a research object” project.

We’ll also be bringing on a full-time developer to help increase our bandwidth for technical projects and shape that side of the program. Want to come work with us? Check out the job post here and get those applications in soon!

Have an idea for a project that meets the above criteria? Get in touch. We’d love to hear from you.

Serving as a hub for the open research community

The Science Lab was created to serve as a neutral broker and hub for the open science community — a means of bridging the gap between the early adopters and the many scientists who understand the value of open science, but who have not yet (for a number of reasons) mapped that understanding onto their day-to-day workflow. We strive to connect and support the activity of the open research community and its diverse stakeholders (researchers, coders, funders, publishers) to work towards the common goal of making research more like the web: open, collaborative and accessible.

With the push for clearer means for the community to get involved (and stay engaged), we’ll be testing out a few different approaches, from more structured followups after training to an online forum for questions, and even lightweight teaching kits. We’re also looking to explicitly tie these approaches into our educational efforts, so that following a Software Carpentry bootcamp there’s a clearer way to get involved, build on the skills learned and contribute.

Another dimension of this is looking at how to cultivate opportunities for the community to contribute to technically, as well as learn about (and hopefully use and test) open tools and technologies for research.

But we can’t do it alone, and we’d love your input. Our next community call on June 12 will focus on precisely this issue: engagement. Do join us. We’d love to hear your thoughts.

Posted in education, planning and tagged .

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>