When should you publish code on GitHub? Work-in-progress or after publication? [duplicate]

Question

What is policy are you following about publishing data analysis code on GitHub? Do you do it after publishing or as a work-in-progress?

I developed a number of Python algorithms to analyse a large dataset, and I would like to make my work visible.

Answer 1

There is a movement gathering strength lately to encourage publishing the code:

Nature-Publish your computer code: it is good enough

Or, more vehement: If there is no code, there is no paper

The reasons outlied on the article are very reasonable. If you are expected to publish detailed derivations, experimental methods, and proofs of theorems, why would you be allowed to keep the code? No one will accept a theorem if you claim: "the proof is too messy to show, but hey, here are three cases where it works".

I think the best way is to publish the code used as supplementary material, and include a link to the repository, so people can get the improved versions. If you are concerned about people using too bleeding edge versions, make releases, but leave the development public. This will also help you get bugfixes and contributions.

Thank you for wanting to release your code. I really believe this attitude will help make research better.

Edit:

After some time, I have something to add. Most of the code in an application is there for "administrative purposes": load and write data, massage, check conditions... For publishing, that part can be as hackish as one needs it to be. The real "research" is usually in a small part. That is where one should dedicate one or two hours of adding a few comments and clearing the code.

For the rest, a docstring in the functions or a paragraph explaining the aim, should be fine.

Answer 2

Styles and technologies come and go. Git and Github are the flavor of the moment. Tomorrow it will be something else.

What is more fundamental is that scientific results are normally expected to be reproducible. If the code has secret details in it that are crucial for producing the result, then the result is not reproducible. If the code is simply the embodiment of the methods described in the paper, then there is no problem with not publishing the code.

As an example, there is a device called the Bodybugg that people buy and strap onto their arms in order to measure (or attempt to measure) how many calories they're burning each day. There is publicly available information on what sensors the device has built into it, but the algorithms used for putting the sensor readings together to get an estimate of energy consumption are proprietary. That means that any scientific research that uses a Bodybugg is basically worthless.

On the other hand, there can be perfectly legitimate reasons for not wanting to release one's code. For example, there could be a concern that people who lack the relevant expertise will play with it and use it to publish their own half-baked "gee-whiz" papers that turn out to be wrong. That then harms the reputation of the original author. The author may also not want to be in the business of answering questions from lots of people using their code, or they may want the freedom to make major changes that would upset users who were counting on the code to remain stable and backward-compatible. Science is not software development. Scientists want to focus on doing science, not on software distribution, licensing, making regular releases, and supporting a user community.

It may not even be legally possible to release a working version of the code. E.g., it may have some old FORTRAN routines in it that calculate Clebsch–Gordan coefficients, and if the author of those routines is dead, then it may not be legally possible to publish them.

I'm also skeptical about the long-term value of releasing code in most cases. Github will be gone in five or ten years, and the vast majority of the software it hosts will then cease to exist, since the vast majority of coders will not bother to migrate their code.