How do you cite a Github repository?
I am working on a honours thesis and have developed a Fortran library that I would like to cite in it.
In some places they suggest to quote the documentation of the project but this is something I plan to do in the future and isn't done yet. The only documentation I have right now is the README file and the code itself.
What would be an acceptable way of directing a reader to my work on Github?
(bonus) Is there a BibTeX way to do it?
I think energynumbers answer is correct in terms of what is "correct" in academic literature. However, if the immediate issue is "I need to let a reader of the thesis/dissertation that I'm working on right now see the software", then (low-tech as it seems) you could consider including the source code in an appendix. How practical this is may depend on its length... Or ask your supervisor whether they're happy for you to provide a github link and what the format should be. Also, welcome to Stackexchange :-)
@charlespwd Welcome to Academia.SE! :) I edited the question a bit to make it working well with StackExchange way of asking question (so you can get the best answers). I hope that you don't mind. If you do, just revert my changes.
@SimonWaldman: 7K lines of code spread over multiple modules is definitively not something I can include in an appendix. My colleague did include his MATLAB code in his thesis but I found it to be a terrible way to share code as you cannot reuse it easily (copying it in matlab would ignore the tabbing, etc.).
@charlespwd ha, fair enough. And I agree that it's a terrible way to share code. But if this is for an examinable thesis rather than a published paper, I think the correct answer is "whatever your supervisor is happy with" ;-)
^ There are so many great points I think they are worth compiling into an answer, much better than all current ones!
Take a look at this: [https://github.com/blog/1840-improving-github-for-science]. This might answer at least a part of your question.
- 7 years ago
I was asked to provide my comment as an answer, so here it is. It is yet another way to cite software. However, it requires some effort from the software authors.
I developed an Open Source Web tool for modeling and gathering data when following a certain theory/methodology in software engineering. Here is how you would cite it:
Graziotin, D and Abrahamsson, P 2013. A Web-based modeling tool for the SEMAT Essence theory of software engineering. Journal of Open Research Software 1(1):e4, DOI: http://dx.doi.org/10.5334/jors.ad
This is possible because I opted to publish a software paper in the Journal of Open Research Software. It is a fully Open Access journal. This journal only accepts software papers on open source software for research.
A software paper is a special kind of paper, which describes the software-e.g., what is it about, implementation and architecture, its availability, and its reuse potential. The editorial process works as in any other research venue, and articles are peer-reviewed.
The article processing charges are 25GBP. However, they can be fully waived if you cannot afford them.
What it is nice with this approach is that researchers have an extra motivation to open their software for research: they get a publication for that, plus citations. Additionally, writing a software paper is far easier than writing a methodology paper.
I wrote a review of the journal on my blog. TL;DR; Great experience, go for it.
Nice review of the Journal of Open Research Software. I've never heard of this journal before, and I'm impressed by your description of its review process. I'm particularly impressed that they critiqued the code. If anyone else has submitted there, can you comment?
Just to clarify, for future visitors of this question. I have just joined the Editorial board of the journal. However, this answer was written when there was no "competing interest".
@FaheemMitha I've reviewed for the JORS and agree completely with this answer. Yes, I reviewed the code as per the JORS reviewer guidelines. I've reviewed 'Software Papers' in traditional domain journals, and occasionally gotten editorial pushback for my reviewing the code as well as the paper: see carlboettiger.info/2013/06/13/what-I-look-for-in-software-papers.html
@cboettig Thanks for the link. I read your blog article. It was good, though a little too R specific. Do you have any idea of the current turnaround time between submission and a decision for JORS? Personally, I think a good thing to do is create a Debian package for your software. If done properly, it automatically addresses a bunch of issues.
@FaheemMitha Yes, I was mostly referring to the comment string on that post, which reflects varied opinions of reviewing the software, rather than the contents of my post; sorry. Yes, Debian packages assure at least basic metadata are provided, but clearly are not ideal for a Windows audience, for example. Other package systems provide other +'s and -'s. JORS makes the authors speak to each of these issues.
@cboettig Well, clearly one would only make a Debian package for fairly Unixy software. Most scientific software would work only on one of Windows and Linux anyway.
Thank you so much for this. I have been looking for some time for an alternative to *Computer Physics Communications* which is Cost-Of-Knowledge compatible. This seems to fit the bill very nicely.