It seems to me to be important in this context to draw the distinction
between _software_ which is about the most ephemeral thing I can think
of (OK maybe butterflies are more so) - e.g. try compiling code
published > 5 years ago - and _algorithms_ which if well constructed are
potentially everlasting (how many programmers still use Knuth's data
structure & sorting algorithms?). One assumes that the only lasting
commitment of the author is to supply the version of the code
_as_it_was_ when the paper was published (for the purpose of replicating
the results in the paper), he's not committed to maintaining the program
so that it's still guaranteed to work _now_ (but may well not replicate
the results), i.e. he's not committed to supplying updates for ever! So
unless of course the code was designated Open Source and kept maintained
by the community, the old code may not be much use to anyone for very
long without the programming expertise needed to adapt it to new
versions of OS's etc. But note that Nature Methods doesn't stipulate
that the code must be Open Source, only that the code or executable is
made "available to readers promptly on request".
The problem is that the important features of an algorithm tend to get
obscured by the nitty-gritty details of its implementation in code. On
the other hand, even a programmer who knows nothing about the underlying
science should be able to code a well-written algorithm using whatever
is the language flavour-of-the-day. So it seems to me that it's just as
important to establish good algorithmic standards in order to ensure
that the methodology is completely and correctly expressed in the
published algorithm, as it is to enforce software availability.
Cheers
-- Ian
> -----Original Message-----
> From: CCP4 bulletin board [mailto:[log in to unmask]] On
> Behalf Of Nat Echols
> Sent: 26 March 2007 00:12
> To: [log in to unmask]
> Subject: Re: [ccp4bb] Nature policy update regarding source code
>
> > I thought that some of you might be interested that the
> journal Nature
> > has clarified the publication requirements regarding source code
> > accessibility. It is likely that some of you deserve congrats
> > for this. Cheers!
> >
> > http://www.nature.com/nmeth/journal/v4/n3/full/nmeth0307-189.html
> >
> > Although there are still some small problems, I think that this is a
> > big step forward, and certainly an interesting read, if you are
> > interested in FOSS and science.
>
> Any chance of getting the IUCR to implement some policy like
> this? (Or
> the public funding agencies?)
>
>
Disclaimer
This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient you must not review, use, disclose, copy, distribute or take any action in reliance upon it. If you have received this communication in error, please notify Astex Therapeutics Ltd by emailing [log in to unmask] and destroy all copies of the message and any attached documents.
Astex Therapeutics Ltd monitors, controls and protects all its messaging traffic in compliance with its corporate email policy. The Company accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Astex Therapeutics domain. Unless expressly stated, opinions in this message are those of the individual sender and not of Astex Therapeutics Ltd. The recipient should check this email and any attachments for the presence of computer viruses. Astex Therapeutics Ltd accepts no liability for damage caused by any virus transmitted by this email. E-mail is susceptible to data corruption, interception, unauthorized amendment, and tampering, Astex Therapeutics Ltd only send and receive e-mails on the basis that the Company is not liable for any such alteration or any consequences thereof.
Astex Therapeutics Ltd., Registered in England at 436 Cambridge Science Park, Cambridge CB4 0QA under number 3751674
|