publishing software

During the session on collaboration between Digital Humanities centers at Digital Humanities 2007, Julia Flanders made some remarks that got me thinking about software tools and publication. Her remarks revolved in part around the possibility of such a collaboration providing peer review services, and also around the way in which our community tends to be good at building prototypes, but less good at producing finished software. One of the motivating forces behind this habit is the academic culture of publication. It’s a regrettable fact that tool-building in the humanities does not get the same credit as publishing. In the EpiDoc project, we’ve made an effort to be sure to cite software tools we’ve built as publications, which is what they are. The new Digital Humanities Quarterly is in a position to publish peer-reviewed articles that do not fit the traditional definition of article (e.g. multimedia presentations). What obstacle would there be to publishing peer-reviewed, Open Source software source code in a journal like DHQ? Obviously software doesn’t follow the same rhythms as print publishing, but why couldn’t a 1.0 release be termed a publication? Is a good software tool not the moral equivalent of an article or even a book? Or am I just a heretic?

This entry was posted in General. Bookmark the permalink.

4 Responses to publishing software

  1. I think that you are probably preaching to the choir here. I know that in our work we are constantly fighting the powers-that-be, trying to convince them of just these very notions. Software and digital presentations should count as published items, although a peer review must be carried out in order for this to handle any kind of academic questions. The peer review step is the crucial one in our environment.

    Then again, convincing the academic bureaucracy that a particular publication is acceptable peer review is another thing all together. It looks like DHQ might be just the ticket.

  2. Sean Gillies says:

    Hugh, it’s not just the humanities. I heard through the applied math grapevine that the author of Python’s NumPy ( was having trouble getting his tenure committee to appreciate the enormous significance of that work. I think a culture of software citation (like EpiDoc’s) could really help the guy out.

  3. Amit says:

    Of course not. There’s no research in software pertaining to the field. Its a tool, just like developing the slide rule or the card file wouldn’t get you tenure 30 years ago.

  4. Hugh Cayless says:

    This might be stoa’s first troll, so in celebration, I’ll break my own rules and feed it.

    First, your argument is a straw man: you wouldn’t get points toward tenure 30 years ago for building a slide rule, but you certainly would for building a lexicon or creating a new method for analyzing texts. In our day, these kinds of work are as likely to be manifest in software as not. We’re not talking about purely technical tasks like building web pages.

    Second, this kind of attitude is poisonous toward any sort of Digital Humanities. Developing the tools to work in innovative ways with our sources takes time and intellectual effort. If that time and effort were counted as worthless, then nobody would ever get tenure for working on DH projects. But they do.

    Third, and finally, beyond a certain level of sophistication, the creation of software to process source materials is an editorial act, in that the software will make decisions programmed into it by its creators. Understanding and being able to evaluate those decisions is vital if the outputs themselves are to be correctly evaluated. Unless the software is published and peer reviewed, how can this happen? I fear the answer is that it won’t, and the biases and assumptions of the software builders will be accepted without question.

Leave a Reply

Your email address will not be published. Required fields are marked *