The metaphor "dead in the water" is ubiquitous but useful. It is an elegant way to express the notion that a massive entity can appear to be moving but also have a plain endpoint in the not-too-distant future.
This strikes me as a simple but remarkably insightful indictment. There are a few positives of paper that this quote leaves out, but many of them are being addressed in
, and the rise of eBooks is finally quashing the last remnants of real-paper nostalgia.
So what's next? Obviously direct publishing to the web can rectify the key issues raised in the quote above — we can update and refine at will as much content as we please (more or less). But the other issue that follows from publishing on the web with particular application to technology research is multimedia. Publishing on paper, while perhaps a fine method for presenting scientific results, fails miserably when communicating how a system functions — you can communicate more in a brief video than in a lengthy academic-style paper. (Even better for pure software systems, just let "readers" run the app themselves.) Still, video is not the best medium to convey everything, in particular deep technical detail or theoretical motivation. Also, sometimes a static image or audio clip can make a more focused point better than playing a video.
Thus, my guess is that the future of system papers will be some sort of multimedia document, perhaps regularly modified or expanded. My colleague,
John Doherty, has been saying this for a very long time. He and I put together
a rich multimedia document describing our past work on viewing documents on mobile devices. The document does not include much in the way of real science, but that's not really the point. We're trying to convey why a system is important and how it works, not prove a hypothesis.
Of course it is easy to correct mistakes on this page (and I'm sure there are plenty — let me know!). But what I'm more interested in is whether it could evolve into something that is continuously updated with meaningful content. I remember my graduate advisor telling me to iterate papers I write just like I iterate the systems I build, trying out new "designs" with a couple of colleagues and slowly converging on a final form that I would submit. Except, of course, that's not really how systems work, is it? They are never really done — you just keep iterating. Papers should probably be the same. But to structure your work (and give you useful deadlines) it is also probably useful to have some goalposts. Again the software metaphor comes in handy. Why not have research document releases? So you "publish" a multimedia document as an initial, alpha release that only a few people will look at but whose feedback could radically alter the "product," then you come back with a more sophisticated "beta" release and so on. Toward the end you would have a robust system complimented with a magazine-quality rich media document. (In some cases, but of course in most cases the system, and therefore the document, would halt abruptly somewhere in the beta stage. It is research afterall.)