Github for science sounds like a great plan? But do we have the underlying stack of equivalent services needed to provide “http for science” and “tcp/ip” for science. I argue that until we do we will struggle to really deliver on the excitement that examples (rightly) inspire.

Cameron Neylon

::: {.wp-caption .alignleft style="width: 310px"}
[![Mapa mental do
TCP/IP](http://cameronneylon.net/wp-content/uploads/2014/10/300px-tcp-ip2.jpg "Mapa mental do TCP/IP"){.zemanta-img-inserted
.zemanta-img-configured decoding="async" loading="lazy" width="300"
height="186"}](http://commons.wikipedia.org/wiki/File:TCP-IP.jpg)

Image via Wikipedia
:::

Itâ€™s one of those throw away lines, â€œBefore we can talk about a
github for science we really need to sort out a TCP/IP for scienceâ€?,
thatâ€™s geeky, sharp, a bit needly and goes down a treat [on
Twitter](https://twitter.com/#!/CameronNeylon/status/171688972710453248).
But there is a serious point behind it. And its not intended to be
dismissive of the
[ideas](http://marciovm.com/i-want-a-github-of-science/index.html) that
are [swirling](http://www.trevorbedford.com/) around about scholarly
communication at the moment either. So it seems worth exploring in a bit
more detail.

The line is stolen almost wholesale from [John
Wilbanks](http://del-fi.org "John Wilbanks"){.zem_slink rel="wikipedia"}
who used it (I think) in [the talk he
gave](http://www.slideshare.net/wilbanks/seattle-sc-symposium-2010) at a
Science Commons meetup in Redmond a few years back. At the time I think
we were awash in â€œFacebooks for Scienceâ€? so that was the target but
the sentiment holds. As once was the case with Facebook and now is for
[Github](http://github.com "GitHub"){.zem_slink rel="homepage"}, or
[Wikipedia](http://www.wikipedia.org "Wikipedia"){.zem_slink
rel="homepage"}, or
[StackOverflow](http://stackoverflow.com/ "Stack Overflow"){.zem_slink
rel="homepage"}, the possibilities opened up by these new services and
technologies to support a much more efficient and effective research
process look amazing. And they are. But youâ€™ve got to be a little
careful about taking the analogy too far.

If you look at what these services provide, particularly those that are
focused on coding, they deliver commentary and documentation, nearly
always in the form of text about code â€" which is also basically text.
The web is very good at transferring text, and code, and data. The stack
that delivers this is built on a set of standards, with each layer
building on the layer beneath it. StackOverflow and Github are built on
a set of services, that in turn sit on top of the web standards of http,
which in turn are built on network standards like TCP/IP that control
the actual transfer of bits and bytes.

The fundamental *stuff* of these coding sites and Wikipedia is text, and
text is really well supported by the stack of web technologies. Open
Source approaches to software development didnâ€™t just develop because
of the web, they *developed* the web so its not surprising that they fit
well together. They grew up together and nurtured each other. But the
bottom line is that the stack is optimized to transfer the grains of
material, text and code, that make up the core of these services.

When we look at research we can see that when we dig down to the
granular level it isnâ€™t just made up of text. Sure most research could
be represented as text but we donâ€™t have the standardized forms to do
this. We donâ€™t have standard *granules* of research that we can
transfer from place to place. This is because its complicated to
transfer the stuff of research. I picked on TCP/IP specifically because
it is the *transfer* protocol that supports moving bits and bytes from
one place to another. What we need are protocols that support moving the
substance of a piece of my research from one place to another.

Work on [Research
Objects](http://wiki.myexperiment.org/index.php/Research_Objects)Â \[see
also [this paper](http://eprints.ecs.soton.ac.uk/18555/)\], intended to
be self-contained but useable pieces of research is a step in this
direction, as are the [developing set of workflow
tools](http://www.wf4ever-project.org/), that will ultimately allow us
to describe and share the process by which weâ€™ve transformed at least
some parts of the research process into others. [Laboratory recording
systems](http://www.mylabnotebook.ac.uk/index.shtml) will help us to
capture and workflow-ify records of the physical parts of the research
process. But until we can agree how to transfer these in a standardized
fashion then I think it is premature to talk about Githubs for research.

Now there is a flip side to this, which is that where there are such
services that do support the transfer of pieces of the research process
we absolutely should beÂ  experimenting with them. But in most cases the
type-case itself will do the job. Github is great for sharing research
code and some people are doing [terrific things with data there as
well](https://github.com/ehec-outbreak-crowdsourced/BGI-data-analysis/wiki).
But if it does the job for those kinds of things why do we need one for
researchers? The scale that the consumer web brings, and the exposure to
a much bigger community, is a powerful counter argument to building
things â€˜just for researchersâ€™. To justify a service focused on a
small community you need to have very strong engagement or very specific
needs. By the time that a mainstream service has mindshare and
researchers are using it, your chances of pulling them away to a new
service just for them are very small.

So yes, we should be inspired by the possibilities that these new
services open up, and we should absolutely build and experiment but
while we are at it can we also focus on the lower levels of the
stack?They arenâ€™t as sexy and they probably wonâ€™t make anyone rich,
but weâ€™ve got to get serious about the underlying mechanisms that will
transfer our research in comprehensible packages from one place to
another.

We have to think carefully about capturing the context of research and
presenting that to the next user. Github works in large part because the
people using it know how to use code, can recognize specific languages,
and know how to drive it. Itâ€™s actually pretty poor for the user who
just wants to do something â€" weâ€™ve had to build up another set of
services at different levels, the [Python Package
Index](http://pypi.python.org/pypi "Python Package Index"){.zem_slink
rel="homepage"}, tools for making and distributing executables, that
help provide the context required for different types of user. This is
going to be much, much harder, for all the different types of use we
might want to put research to.

But if we can get this right â€" if we can standardize transfer
protocols and build in the context of the research into those
â€˜packetsâ€™ that lets people use it then what we have seen on the
wider web will happen naturally. As we build the stack up these services
that seem so hard to build at the moment will become as easy today as
throwing up a blog, downloading a rubygem, or firing up a machine
instance. If we can achieve that then weâ€™ll have much more than a
github for research, weâ€™ll have a whole web for research.

*Thereâ€™s nothing new here that wasnâ€™t written some time ago by John
Wilbanks and others but it seemed worth repeating. In particular I
recommend these posts
\[[1](http://scienceblogs.com/commonknowledge/2009/10/open_source_science_or_distrib.php),
[2](http://scienceblogs.com/commonknowledge/2009/11/distributed_science_part_2.php)\]
from John.*


Image via Wikipedia  Itâ€™s one of those throw away lines, â€œBefore we can talk about a github for science we really need to sort out a TCP/IP for scienceâ€, thatâ€™s geeky, sharp, a bit needly and goes down a treat on Twitter. But there is a serious point behind it. And its not intended to be dismissive of the ideas that are swirling around about scholarly communication at the moment either. So it seems worth exploring in a bit more detail.

Messages de Rogue Scholar

Github for science? Shouldnâ€™t we perhaps build TCP/IP first?