CCL: Where can you publish articles on software?
- From: Cory Pye <cpye=crux.smu.ca>
- Subject: CCL: Where can you publish articles on software?
- Date: Sat, 15 Oct 2005 13:59:00 -0300 (ADT)
Sent to CCL by: Cory Pye [cpye[-]crux.smu.ca]
On Fri, 14 Oct 2005, Warren DeLano warren],[delsci.com wrote:
> No -- let me clarify -- I do not imply that closed-source is tantamount
> to deception. It is simply non-disclosure -- a willful holding back of
> pertinent helpful information. It is tantamount to saying "trust
> I have correctly applied chemistry, physics, math, and computer science
> to create a working solution to your problem.
Every time somebody publishes a paper, there is a matter of trust inherent
between the readers, journal, and author. This trust entails, for example,
the author declaring "I did not fabricate my data", "I have not
published this work elsewhere", and the editor declaring "This
undergone a rigorous peer-review process", "I did not let any personal
connection with the author influence my views", etc. There is a certain
of trust inherent in scientific publishing. A (complicated) program is the
author's "baby", and it is up to the author as to whether he or she
make it publically available. I don't think that the trust argument is
applicable here, as it is an inevitable fact.
One difficulty with making a program publically available is it can mutate into
a non-viable form by an inexperienced programmer, and if the mutant happens to
be widely circulated, then a lot of the blame ends up on the original
programmer, who has essentially given up his "baby" for adoption,
the modifier. One can easily waste weeks of time addressing irate
because of someone else's goof-up.
> Thorough testing of closed-source code can of course lay an empirical
> foundation for extending such trust, and testing is equally necessary
> with open-source code. But testing alone is not the same as disclosing
> an implementation that can itself be subjected to direct intellectual
> While there are valid personal, economic, political, legal, practical,
> and insitutional reasons for not disclosing source code, I challenge
> anyone to come up with a compelling scientific reason for why source
> code should not be disclosed -- when possible -- to enable
> understanding, reproduction, verification, and extension of
> computational advances.
Suppose a junior faculty member publishes a paper and publicly releases some
code with his first graduate student. The idea becomes so popular that a senior
researcher or company takes that open-source code, with acknowledgements, and
incorporates it into a popular commercial program, with some modifications and
writes 2 or 3 papers describing the advances. Science is advanced. Lots of
people use it, but only quote the paper in the manual of the senior researcher.
Now suppose that the advances were supposed to be the rest of the graduate
student's Ph. D. work. This student cannot re-publish this work because the
other ideas have been published already by the borrower. The junior faculty,
for lack of sufficient publications, loses his grant, and is denied tenure.
The student's thesis, being mostly unpublishable, is not accepted.
Has science advanced at the expense of the careers of the two individuals?
Are computational chemists a species known for eating their young? :-)
Had the junior faculty member not disclosed his source, it would have been
more difficult for this hypothetical travesty to happen.
The sad reality is that things like this can and do happen and a little
paranoia goes a long way. It would have been far better if the company had
approached the junior faculty and come to an agreement.
In order to be able to do your own science, pragmatics such as having tenure,
a grant, etc. have to be looked at first. It is a lot less stressful (and the
temptation to cut corners less i.e. thorough testing) to implement a new code,
building on some older code, when you don't have someone breathing down your
neck trying to outdo you. Writing and debugging code is a lot of effort, and
you want to be rewarded for your efforts, either through publications,
citations, or financial remuneration.
I would like to say for the record that my experience coding the COSMO routine
within the ADF package (97-99) has been absolutely wonderful, as I have found
SCM to be very cooperative in pointing out my errors and vice versa. I am also
grateful to the many users who have been patient when they hit the occasional
snag, esp. Heiko Jacobsen and Michael Atanasov. Through
dialogue the resulting code was much better. I will certainly celebrate with
a bottle of good scotch when I hit 100 citations on the TCA paper describing
our implementation either late his year or early next year.
> Is there ever a legitimate *purely scientific* reason for settling with
> empirical evidence alone (just test results) when mathematical proof is
> itself attainable (via inspection of source code)? I cannot think of
Source code is "not" mathematical proof, just ask anyone who had to
use a buggy
Fortran compiler, say when the runtime "check array bounds" debugging
didn't work with a character array.
> Or are we all agreed that making source code available is the
> *scientific* ideal to which we should all aspire?
> If so, then when we do not make source available, we should certainly
> have some compelling non-scientific reason for holding it back, and as
> honest scientists, we must realize that doing so will have the effect of
> limiting the value and impact of our work -- at least from a scientific
> standpoint. Intellectual advances are either shared or lost, and
> software implementations are no exception to this.
> [stuff deleted]
************* ! Dr. Cory C. Pye
***************** ! Associate Professor
*** ** ** ** ! Theoretical and Computational Chemistry
** * **** ! Department of Chemistry, Saint Mary's University
** * * ! 923 Robie Street, Halifax, NS B3H 3C3
** * * ! cpye]![crux.stmarys.ca http://apwww.stmarys.ca/~cpye
*** * * ** ! Ph: (902)-420-5654 FAX:(902)-496-8104
************* ! Les Hartree-Focks (Apologies to Montreal Canadien Fans)