What are the disadvantages of opening the source of your own science tools

Question

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.

Answer 1

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.

Answer 2

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?

Answer 3

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.

Answer 4

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.