GitHub repository ownership as a PhD student in a lab

Question

I'm a PhD student and use GitHub to track and share code for nearly all of my research projects, most of which are largely coding-based work in the field of remote sensing.

Our lab is discussing how to best keep track of all the software related projects we do. I generally start and manage projects where I'm first author under my own GitHub account. I recently started a organization account for our lab and I have a repository in there that is basically just a README listing everyone's projects and links to them. We also have this information on our lab website.

I'm considering the pros and cons of having projects owned by the lab account, but I am leaning somewhat away from this, because most of these projects are individually maintained by students or lab technicians and it seems fairer to have them get credit on their own accounts. But we all want the lab to get credit and for people to know certain tools were developed within and supported by our lab.

Anyway, I'm just curious what other labs do and to get a feel for best practices here.

Answer 1

It's fairly common for labs to have GitHub organizations. There are multiple reasons for this.

1. First of all, it doesn't prevent the authors from getting credit. The commits will be shown as commits of the individual, not as commits of the organization.
2. Labs often have a scientific "brand" in terms of what they research. If the GitHub repository is completely personal, then your work does not fully contribute towards this brand. But contributing towards the joint scientific output of the groups is a major reason why you may get funding from the group's third party funding.
3. Perhaps most importantly, PhD students eventually leave the lab. They can continue maintaining their projects if they want to - there is no necessity to be an administrator of a GitHub organization to continue maintaining existing repositories. But what if the leaving PhD students choose not to maintain the code? If the repository is personal, then other people in the lab then cannot commit bugfixes to the repository. They could fork it, but once the repository link is in a scientific paper, the original repository is the official one. And this is problematic if the group's brand depends on the repository because it's a central part of their overall story.

Answer 2

For me it boils down to the question: Does the individual student take the software with him after the PhD and build his career on it? Or does the lab base a large share of its work on this code and multiple students will contribute and maintain the code.

An example for single person is Tim Davis' UMFPack / Suitesparse. He wrote multiple articles about the algorithms and further improvements. When he moved from Florida to Texas, he took all software with him.

If your concern is about the future of the software, it depends on the people. If the single developer leaves academia, the project is at danger. If the group maintaining the software cannot motivate new PhD students to pick the task up and continue maintaining, the project will break.

Answer 3

If your audience is non-programmers or infrequent programmers:

Most people will not look at Github accounts or care which account is associated with your code. They will look at the manual. They will look at journal articles about your code. It's possible they might look at a copyright notice.

Write a useful manual, and state at the beginning of it who should get credit for writing the software.

Answer 4

You don't have to answer these questions, but what country and what institution? In my country (USA) there are intellectual property laws for federally funded research (a lot if not most STEM research) and institutional rules resulting from those laws that make it expedient for the institution to have the ability to own the repo and whatever it contains. When the students/postdocs/other researchers leave, they'll need to have guaranteed that the GitHub ownership or access stayed with the lab or institution. At my institution, that incentivizes many projects to go open source (which is fine with the federal law (Bayh-Dole Act) and my institution (UT Austin)) which requires explicit paperwork at UT (the feds don't seem to care too much but they do like commercial products and OSS products simultaneously).

Seeing commits as credit/blame is one thing (which I guess you could show off on a CV), but that's not the real point. Bayh-Dole gives the institution the opportunity, practically the mandate, to commercialize the software, which they sometimes try to do. But, as you can find on the internet, it's weird when it comes to commercializing software. Nevertheless, your institution may have policies in effect that demand that you declare software products that were created under government-funded work so that the law can be followed. We are consulted about whether we think the software is commercializable, and the law requires the "inventor" to get a cut of any sales or licenses (which I've seen happen to the substantial benefit of the author), but it's not pushed very hard if you say "there's no market for selling this as a product, and we ought to open source it on GitHub." UT trusts the author/inventor to make that call, and many NSF grants are starting to come with a mandate that any software developed under the grant be opened (don't know how this is made to mesh up with Bayh-Dole's desire to commercialize everything!).

All that makes me think that you ought to have a GitHub owner account for the lab that is controlled by the most expert git/GitHub user in the lab with the password information being shared via a good shared mechanism (i.e. a password safe that supports sharing). There also ought to be a process in place for what happens to change both the GitHub owner account and any other shared passwords when they leave.