Pirating: An accepted "profession"?
I have recently read two short entries on Nature.com published in 2010 that discuss on the relevance of publishing computer codes for the development of life sciences. The former is a comment written by Anthony Fejes (link on blogs.nature.com) on the post of Nick Barnes entitled "Publish your computer code: it is good enough", and I agree with both and with most of the comments posted by several readers on reference to the main article.
The question is: should your computer code be published? Next are summarized some reasons that are commonly given for not publishing a code. Those reasons were cited by Barnes, Fejes, and the comments that followed Barne´s article. Please analyze them, since they may be useful when discussing with your students on matters of research productivity, and even in matters of ethics.
1. The code is not well elaborated (but it is good enough for doing the task); it is too much work to polish the code. It may be a matter of a lack of a good programming background, which in some cases may be solved in collaboration with an specialist. A major issue will be when the code is not well documented, as pointed out by the blog entry written by Fejes, because such would mean that the code is useful for a single and very specific purpose which from my perspective may not occur. An improperly documented code would also mean that nobody but the code writer would be able to manage it, i.e., a waste of all the resources invested in the responsible of the code writer, i.e., low productivity.About the work demanded to publish the code, it is the same issue I faced when I asked my fellow graduates to publish their works on the web. Fortunately, some accepted and we demonstrated that with some imagination, almost no time investment is needed. In summary: if you want, you can do it.
2. Publishing the code is not common practice. But should be, further considering the East Anglia case mentioned by Barnes in his article. In an extreme case (remember the IPCC error on the Himalayan glacier melt case?), this would even be considered as bad praxis.
3. People will pick holes and demand support and bug fixes. Nobody is in position for demanding such. On the contrary, opening the code should demand for mutual cooperation. Hence, development of the code.
4. Because of the intellectual property. Barnes strongly disagree with it, but I may discuss it. Intellectual property is a big issue in places where there are no clear laws about it. The situation is even more complex within circles were knowledge is power (or a matter of surviving, as it may occur in some developing countries). However, this does not mean that new generations can not be educated on ethics.
4.1 Intellectual property: Acknowledgements. How far should should acknowledgements be extended? It is a matter of ethics. This may be a good indicator on how far our work has contributed to the current knowledge.
4.2 Intellectual property: Welcome others to join the development team. This an issue difficult to take into action, because few labs are willing to collaborate with others fellows. The reasons: limited funds, and even some "professional jealousy", which happens everywhere. The illustration in Fejes comment shows an anecdote on this matter. We may not be able to change the world, but we should are entitled to change the minds of those under our guidance.
In summary, designing and adopting a manual of good practices would be the difference between unproductive and productive outcomes. As one of the readers (A. Horseman) commenting on Barnes´s article said, good practices would ease the process of finding and solving errors.
