Scholarly papers in scientific computing (and many other fields, nowadays) typically involve some amount of code or even whole software packages that were written specifically for that paper or were used to obtain results in the paper. What is the best way to help readers of the paper access the code? My current approach is to put a link to a Github repository (along with a particular version tag) in the paper or in a citation.
|
|
Well, I think you have a few options.
In any or all of these cases, however, you should indicate the sourcing clearly in the article, and indicate what kind of licensing it is (GPL, Creative Commons, etc.), so that there's no IP-related issues down the line. |
|||||||||||||||||
|
|
Great question and great replies, but I think none addresses the question of persistence adequately, if the goal is to achieve the same standard accorded to the publication itself. (Which may be silly given the chances the code still runs, but may still be at least as useful as the publication all the same). University websites journal supplements aren't persistentUniversity websites are unlikely to provide the stability or the redundancy to preserve hosted content. Content is more difficult to cite and typically lacks machine readable metadata. Unfortunately it appears that journals are not doing much better in maintaining their supplemental materials (see Anderson et al. 2006), and may not accept the necessary formats, or even accept supplemental material at all (see one notable example). For these reasons, folks concerned with long term archiving of data have unanimously turned towards advocating for the use of dedicated repositories rather than websites or supplemental materials, and many journals now mandate this practice. It seems only fair that code be held to this standard. The solution of many copies?Github and related sites have yet to prove longevity over the 100s of years scale achieved by university libraries and established publishers. By facilitating widespread distribution it may provide a solution others have echoed in the comments, including one fellow who couldn't comment on stackexchange,
Figshare & the CLOCKSS standardThe only archival standard I am aware of is figshare, which can accept full code repositories (as "filesets" for the moment, but I believe will soon have the option to be listed as type "code"). The key piece to figshare is not only the citable DOI with programmatic metadata, but the backing of CLOCKSS archival service, which maintains copies of all its content at 12 geographically and geo-politically distributed nodes around the world. Should figshare go out of business or cease to exist, this will trigger all its content to be freely available from CLOCKSS. Consequently, I'd suggest using Github for distribution of code, but also providing an archival copy to figshare at the time of publication. |
|||||||||||||
|
|
You may use some fancy pdf-techniques to simply attach the code to the pdf (that is, the code-files are embedded into the pdf and can be "downloaded" with a click on some button in the pdf). This can be accomplished with the attachfile package, for example. Of course, this work with preprints (although I don't know if it already works with the arxiv) but you probably get problems with journal-files... |
|||
|
|
|
For small scripts that are specific to a specific research project, the best place for publication is the journal's Web site, as "supplementary information" to the paper. That's where it is easiest to find for someone who reads the article. More substantial packages that are of interest for other projects as well should better be published separately. Unfortunately there is no really good solution at this time. Ideally, a code publication would be permanently accessible through a DOI, just like a paper, but I am not aware of any hosting site that hands out DOIs and guarantees their permanence. Public repositories like Github or Bitbucket are perhaps the best bet for now. The best solution would be to publish the paper packaged with the code and the data that go with it, but that is not yet technically feasible. I am working on a research prototype exploring this idea, see this site for details. |
|||||||
|
|
I've taken two tactics, born of the fact that I anticipate changing institutions soon, so my university URL isn't stable in the slightest. When the code is relatively short, I've tried including it as a supplemental appendix in the journal itself, under the assumption that they'll probably do a decent job keeping the paper and the code in roughly the same place. This is especially useful for code where there isn't a wide amount of general interest - code that's somewhat useless without the paper in question to provide context. But for source-code, actual software, and more complicated projects or ones of general interest, I've been following your tactic of linking to a GitHub repository, which should at least be stable for the average productive lifespan of my papers. |
|||
|
|
|
Take a look at http://www.runmycode.org. They host companion sites for code associated with research papers. If the code is R, Matlab, or a few others, it will actually run the code for you. I haven't tried it yet, but I intend to. I think David Donoho and his collaborators use it. |
|||||
|
|
University libraries could be a place for this or the hosting center of the university. |
|||
|
|
|
As a reader, a statement in the paper to the effect that code can be obtained by contacting the author directly would be effective. As an author, this could help foster collaboration, and give me an opportunity to remind people to cite my article if they use the code in their work. |
|||||||||||||||||
|