Digital History and Continuous Deployment

The other night on Proggit I came across a blog post praising continuous deployment. Continuous deployment is the process of code written for applications are immediately deployed which lowers cycle time and opens up individual initiative. As I was reading the post and doing a bit of my own Googling I began to wonder if continuous deployment worked as a metaphor for digital scholarship. These are my quick thoughts.

I don’t mean continuous deployment in the sense that developers mean continuous deployment. After all, digital history projects are not necessarily in the business of testing and debugging for consumers.[1. Though there is certainly a place for that in terms of user interfaces and visualizations.] Rather, I mean continuous deployment in digital history to be the continual refinement of narrative and analysis, the ongoing growth of digital archives, and the implementation of current and future visualizations.

At conferences and in discussions with people unfamiliar with digital history, I often talk about the iterative process of digital history – that the finality of a journal article, dissertation, or book could seemingly never exist for digital projects given the nearly unlimited space for data, information, and space that our modern servers and hard drives provide (unlike the analog limitations of ink, paper, and costs). More than one conversation has wandered into whether this sort of scholarship was good for history. After all, if the content of a digital project is continually changing, can a project be reliable for its posterity? The skeptics raise an important point. Indeed, if continual research leads a scholar to draw new or different conclusions than originally posited on a project, should there be some way to archive "old" narratives and analysis for posterity’s sake? I’m sympathetic to this view, especially since one of our goals with digital scholarship should be citable material. We need some sort of stability, though I don’t know exactly what version-controlled digital scholarship looks like yet.

However, I think there is a larger point to be made about continuous deployment in DH. The iterative process allows us to react to new data or interpretations, easily update material, and also unlocks data and knowledge for broad audiences.

Scholarship More Agile

Programmers talk of their projects being agile, meaning that software can adapt quickly to changes or add functionality with little risk. The same could be said for digital history. There is a tremendous amount of risk in publishing a book or journal article – the sale and marketing of the product, the costs of physical media, the time of editing and revision. In digital history, these items can simultaneously occur or could be eliminated entirely. The nearly limitless space that modern hard drives allow us means we can create digital projects that encompass a very wide array of subjects and material without the physical limitations of ink and paper. Digital publication doesn’t require a reprinting or new edition: we can adapt to changes very quickly (new scholarly interpretations, new visualizations, etc.) or expand digital archives with relative ease.

Easy Revision and Updating

Agile development allows for ease in revising and updating material in digital projects. Revising narrative or archive items is a simple matter compared to the amount of work and investment it takes to update print publications. Changes to my own projects involve no more than connecting to my server or editing local files for upload. In a matter of moments, my changes are "live" for users to begin using or interpreting.

No Gatekeepers

Digital history should be open. While I respect and am thankful for the material that services like JSTOR and ProQuest offer, unfortunately this material is locked behind costly gates. The sum of the world’s knowledge should be open for broad consumption. Perhaps the Google Books model is one way journal publishers can begin thinking about ways of sharing the contents of their journals.

March 02, 2011 @jaheppler