Software that is custom-developed as part of novel methods is as important for the method's implementation as reagents and protocols. Such software, or the underlying algorithms, must be made available to readers upon publication.
“An inherent principle of publication is that others should be able to replicate and build upon the authors' published claims. Therefore, a condition of publication in a Nature journal is that authors are required to make materials, data and associated protocols available to readers promptly on request.” This excerpt from our guide to authors may seem obvious, but judging from the number of discussions we have had with authors and referees, we would like to clarify one specific point: at Nature Methods, the definition of “materials, data and associated protocols” includes custom-designed software necessary for the method's implementation. Yet there are several ways of making software available, with various degrees of disclosure and in a choice of formats.
The minimum level of disclosure that Nature Methods requires depends on how central the software is to the paper. If a software program is the focus of the report, we expect the programming code to be made available. Without the code, the software—and thus the paper—would become a black box of little use to the scientific community. In many papers, however, the software is only an ancillary part of the method, and the focus is on the methodological approach or an insight gained from it.
In these cases, releasing the code may not be a requirement for publication, but such custom-developed software will often be as important for the replication of the procedure as plasmids or mutant cell lines. We therefore insist that software or algorithms be made available to readers in a usable form. The guiding principle is that enough information must be provided so that users can reproduce the procedure and use the method in their own research at reasonable cost—both monetary and in terms of labor.
Some authors who favor the highest degree of transparency and sharing for their software elect to develop their programs in an open-source environment. By doing so, the authors not only provide accessibility and transparency, they also allow the community to build upon their own developments and make continuous improvements to the tool. Open-source software has become extremely popular in various fields. In microscopy, for example, image analysis software tends to be modular, and users benefit from the flexibility of being able to replace some modules with others in an open-source framework. Despite the tremendous added value of open source, other authors prefer to release a compiled version of their program, so as to protect commercial interests tied to sophisticated custom-designed software. This option is not optimal because it turns the program into a black box, but it may be acceptable if the operations performed by the software are sufficiently clear.
Any restrictions to a program's accessibility must be specified at the time of submission, and editors will consider the amount of information made available, case by case, in consultation with the reviewers. If some restrictions are deemed acceptable, they must be clearly explained in the methods section. This condition—it may be useful to reiterate—applies for reagents as well. Also, the possibility to reach an agreement on restricted distribution does not obviate the need to provide, during confidential peer review, all programming details deemed necessary by the reviewers to evaluate the method.
Beyond the question of code disclosure, the optimal format and degree of necessary detail in which software must ultimately be presented varies widely. The best format of a method-related program depends on the complexity of the program, how central it is to the method and the average level of programing skills among the intended method users.
In some fields, any interested laboratory often will have basic programming skills on board; thus if the software is simple enough, a small set of equations that can then be put in code in each lab's favorite programming environment may be the most efficient and clear presentation. In other fields, a majority of intended users may not be computer-savvy and may require an executable version of the software with a user-friendly interface. In all cases, however, we encourage the inclusion of a description, in a narrative style, of the key operations performed by the software to promote transparency and for the benefit of users whose favorite activity is not the decryption of programing code.
In sum, the goal of publishing a methods paper should be to see this method adopted by the widest possible relevant community of researchers. Therefore, like other materials, the algorithmic components that constitute integral parts of new methods must be made available and in a format that will facilitate the method's adoption.
We strive to continuously update our policies with readers and authors in mind. Let us know how this one could affect you at http://blogs.nature.com/nmeth/methagora/.