I am currently finishing my PhD thesis and, as a great deal of the job was to create tools and protocoles, I am considering putting the different scripts I wrote on open source directories (such as SourceForge or GitHub).

The advantage I see for opening them is:

  1. They will be available for everyone and can be reused by the scientific community
  2. They could be improved (and corrected) by others
  3. It ensure my authorship for the different scripts (I can prove I put them there)

However, I was wondering if there is any drawback of doing so (for future publication, version maintenance, and so on).

I have to precise that not all the work was published yet. My field is biological science.


4 Answers 4


The issues I have personally encountered working on this - my source code is a mixture of open source and closed source projects, depending on many factors:

  1. You have to maintain your code. This might not be something some people care about, but for me, I dislike the idea of putting out code that doesn't run at least relatively smoothly. Which means while the custom workflow where data bounces between a Python script, a C++ program and then an R script for analysis might work for me, produce good and reproducible results and generally carry science forward, it sure as hell isn't going to see the light of day. Things need to be put into functions in case people end up using your code like a library, general messiness cleaned up, etc. That's...well...it's work.
  2. Documentation. As with the above, I really dislike the idea of releasing something without documentation.
  3. Lack of feedback mechanism/opportunity cost. This one is a big one for me because they are what make 1 & 2 so difficult - it's really hard to tell if someone is using my code. It feels a bit like shouting into an empty room, it has little to no impact on my career, and certainly people aren't using it to the extent that it would appear as a line-item on my CV. So I put in a lot of work that could have gone to another paper etc. purely for ideological reasons.
  4. Sanitizing code. Releasing code into the open and not putting in things that might get you scooped means going over your code to not put in a glowing neon sign that says "Future Directions Here". You can't really have a code base that is the combination of three projects, one being written, one being tinkered with and one really only in the musing stage and open source that code without taking a risk.

    Beyond that, for me, is the potential presence of private health data. So my "released" code needs to be scrubbed of any reference to anything that might be confidential, and along those same lines, now needs dummy data that will work and is validated to go along with the code because the data the code was actually written for cannot just get dumped on GitHub or whatever.

All of this is because you asked for cons. Despite this, I try to put up as much of my stuff as is possible.

  • 1
    Surely 1 and 2 are desirable even you are not releasing the code. Otherwise you will come back to the code a few months later with no idea how to run it. Oct 20, 2013 at 16:45
  • @FaheemMitha It's a matter of degree. What's necessary for me to know what I was thinking, and for someone else to is pretty different. Similarly, I don't so much care about pretty, platform agnostic code when it's just me.
    – Fomite
    Oct 21, 2013 at 4:22
  • Maybe you could use C.R.A.P.L. when releasing your code @Fomite Nov 22, 2019 at 14:02

Some disadvantages could be:

  • People may expect you to maintain the code. If you don't maintain it, the code may be rendered useless at some point.
  • You might feel forced to document the code. This is actually an advantage, but many people would not realise that ;)
  • You might have to work on cleaning up the code. Exactly the same point as above applies, if you ever want to re-use your code this is actually an advantage.
  • If people start using your code (this is not impossible), they could e-mail you and start asking questions. This takes your time. On the other hand, it also provides you the opportunity to be co-author (so hey! don't document, so people are forced to ask your help ;-)

More points are raised in the very similar question that was asked at Programmers.SE less than a month ago:

Why don't research papers that mention custom software release the source code?

  • 1
    to point 1: don't base your decisions or work on possible, unspoken expectations of others, never. thats my opinion. point 2-4: comments, good coding and testing should be a basic quality principle for scientific work. And documenting things is even for yourself during the research necessary. few weeks after I wrote a script I barely know the computing and variables anymore. and at least: arguing that questions to your scientific work are a disadvantage but maybe leads to a co-authorship just states the perverted situation of science nowadays.
    – user4039
    Nov 8, 2012 at 19:09
  • I agree with cheeseman for the point 2-4. For me that points might fall into the benefit of opening the code.
    – Wiliam
    Nov 9, 2012 at 8:01
  • I agree with both cheeseman and William. I just meant they might be perceived as disadvantages, whereas in reality, being forced to write proper code is actually an advantage (as I said in the answer)
    – gerrit
    Nov 9, 2012 at 9:57
  • My experience is that you do have to maintain the software, and people do ask support questions. But hey, that means: my software is successful (and if the support questions are too complex, I point them to the fact that I run a consulting business so they could buy my professional help ;-) ) Oct 18, 2013 at 11:14

Here are some objections I've heard. It's up to you to decide how relevant it is to you. This post isn't to say that I endorse all or any of them: it's just to list some of the potential disadvantages.

You might be giving away your most promising source of future funding: the exploiting and extending of those tools and protocols.

The tools and protocols are potentially your future career. You've put an awful lot of work into them. Only now, can you start getting value out of them. Giving them away, means giving away all your hard work, for others to leap ahead of you, and free-load off your development work.

You will get the aggro of users demanding more documentation, and the constant nagging of questions. And because they got the tools and protocols for free, their expectations may be even higher, and they'll feel even more entitled to more of your time, than if they'd paid for it.

Weird, I know, but from experience, many users have lower expectations of paid tools than of free tools, because with paid tools, there are well-defined boundaries of what the user gets for their money. As learnt from experience, and from behavioural economics experiments, people tend to value something more, if they've paid for it.

  • 9
    On the other hand, if there are papers describing those tools, you might get more citations if people use and/or extend your tools. Nov 9, 2012 at 7:33
  • 6
    I can add that in practice, usually nobody is interested in my code ;)
    – gerrit
    Nov 9, 2012 at 9:58
  • 2
    As I commented here, it is hard to imagine someone else taking the hairball that is typical scientific research code and extending it, or even using it, without authorial assistance Jan 25, 2013 at 16:29
  • (+-0) I completely agree that code and protocols are important for the future career (+1). But I beg to disagree strongly with the conclusion that you are giving away a source of future funding (-1). This can only happen if the PhD student is the owner of all the code in question, which is very often not the case. Please see my detailed answer. Oct 17, 2013 at 17:37

Too long for a comment:

@EnergyNumbers wrote:

You might be giving away your most promising source of future funding: the exploiting and extending of those tools and protocols.

Assuming that opening the source is accompanied by a corresponding license, making the code publicly available under a FOSS license may actually do the exact opposite:

It might ensure that you can exploit and extend those tools even after you leave your current institution, thus securing a promising advantage for future funding/employment negotiations.

  • As a PhD student employed for doing the corresponding research by some university or research institute, you usually do not own the code you wrote. Instead, your employer has the copyright (depending on your legislation, you still may have the authorship rights, but the economic rights are your employer's).
  • Other people may have been involved in the development, so they have intellectual rights to the code as well.

In this situation, a FOSS license can give legal certainty that you can go on using and developing the code after you leave your current university (which is not unlikely to happen after a PhD is finished).

Of course, the license must be granted by the holders of the copyright (university, co-authors' universities, etc.). This will not happen unless you

a) bring the matter to the attention of your university (supervisor, IP office, etc.) b) you convince them that the FOSS license is good for them as well*

However going for such a FOSS license is IMHO advantageous for both you and your university:

  • for you, because you can throw this piece of software into negotiations for your next job and go on using it.
  • for your current university, as they have a much better chance that the code is maintained so they can go on using it. It is a huge difference between e.g. people in your current group using your code and your group finding someone else to take over the maintenance of the code.

I wrote might: because you'd have this advantage without FOSS license if you are the actual copyright holder of the code. That would be the case, if you were not paid for doing the research (but e.g. only for being teaching assistant), or you were paid by a scholarship and didn't sign a contract that transfers the copyright of the work you do during you PhD to your university, you actually own your code. So you already have all rights to deal with your code in future as you like, and granting a FOSS license to the public doesn't change this.

* In my experience, IP offices tend to see $$ as soon as you start telling them that you developed a software, but have no idea about the costs of selling the software (infrastucture and ensuring maintenance) that you can in practice avoid with FOSS licenses.

  • 1
    How can you grant a licence over the university's software? If you were able to grant any licence, you could just grant yourself perpetual irrevocable rights.
    – 410 gone
    Oct 17, 2013 at 18:06
  • @EnergyNumbers: good point. I clarified that of course the university has to grant the license, but in practice the PhD student is the one who makes them do this. Oct 18, 2013 at 11:12
  • "In this situation, a FOSS license can give legal certainty that you can go on using and developing the code after you leave your current university (which is not unlikely to happen after a PhD is finished)." The "not unlikely to happen" refers to leaving the university, I presume? Oct 19, 2013 at 15:25
  • @FaheemMitha: yes Oct 20, 2013 at 9:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .