Getting into Digital Humanities: A top-ten list

Today I’ll be joining a roundtable discussion hosted by the New York Council for the Humanities for its incoming class of public humanities fellows. I was asked to prepare a “top-ten list” for public humanists looking to get started in digtial humanities, and with the help of friends on Twitter, I came up with the following:

10) Enter the circle (read, tweet, blog)
9) Start with partners
8) Attend THATCamp
7) Write grants, not papers
6) Release early and often
5) Stop worrying about the definition of DH
4) Digital is always public
3) Must. Try. New. Things.
2) Break something
1) Lather, rinse, repeat

Instead of explaining this advice in prose, I decided to put together a video. Here it is.

N.B. As my mother always told me, “do as I say, not as I do.”

The Dividends of Difference: Recognizing Digital Humanities' Diverse Family Tree/s

Textile, Countryside Mural, 1975In her excellent statement of digital humanities values, Lisa Spiro identifies “collegiality and connectedness” and “diversity” as two of the core values of digital humanities. I agree with Lisa that digital humanists value both things—I certainly do—but it can be hard to *do* both things at the same time. The first value stresses the things have in common. The second stresses the ways we are different. When we focus on the first, we sometimes neglect the second.

This is something that has been driven home to me in recent months through the efforts of #dhpoco (post colonial digital humanities). Adeline and Roopika have shown us that sometimes our striving for and celebration of a collegial and connected (or as I have called it, a “nice”) digital humanities can, however unintentionally, serve to elide important differences for the sake of consensus and solidarity. #dhpoco has made us aware that a collegiality and connectedness that papers over differences can be problematic, especially for underrepresented groups such as women and minorities, especially in a discipline that is still dominated by white men. A “big tent” that hides difference is no big tent at all.

As these critiques have soaked in, they have led me to wonder whether the eliding of differences to advance a more collegial and connected digital humanities may be problematic in other ways. Here I’m thinking particularly of disciplinary differences. Certainly, the sublimation of our individual disciplines for a broader digital humanities has led to definitional problems: the difficulty the field has faced in defining “digital humanities” stems in the first place from people’s confusion about the term “humanities.” Folks seem to get what history, philosophy, and literary criticism are, but humanities is harder to pin down. Just as certainly, calling our work “digital humanities” has made it more difficult for us to make it understandable and creditable in disciplinary context: the unified interdisciplinary message may be useful with funding agencies or the Dean of Arts and Sciences, but it may be less so with one’s departmental colleagues.

But what else is lost when we iron out our disciplinary differences? Our histories, for one.

Most of us working in digital humanities know well the dominant narrative of the pre-2000s history of digital humanities. It is a narrative that begins with the work of Father Busa in the 1950s and 1960s, proceeds through the foundation of the Association for Computers in the Humanities (ACH) in the 1970s and the establishment of the Humanist listserv in the 1980s, and culminates with foundation of the Text Encoding Initiative in the 1990s. Indeed, it is in the very context of the telling of this story that the term itself was born. “Digital Humanities” first came to widespread usage with the publication of A Companion to Digital Humanities, which proposed the term as a replacement for “humanities computing” in large part to broaden the tent beyond the literary disciplines that had grown up under that earlier term. The Companion contains important essays about digital work in history, anthropology, geography, and other disciplines. But it is Father Busa who provides the Foreword, and the introductory history told by Susan Hockey is told as the history of digital textual analysis. Indeed, even Will Thomas’s chapter on digital history is presented against the backdrop of this dominant narrative, depicting history in large part as having failed in its first attempts at digital work, as a discipline that was, in digital terms, passed by in the controversies over “cliometrics” in the 1960s and 1970s.

Let me be clear: I’m not slagging Susan, Will, or the other authors and editors of A Companion to Digital Humanities. Their volume went a long way toward consolidating the community of practice in which I’m now such a grateful participant. If it aimed to broaden the tent, it succeeded, and brought me with it. Nevertheless, as an historian, the story of Father Busa, of Humanist, and even of cliometrics is not my story. It is an important story. It is a story I do not refute. It is a story that should be told. But as a digital historian who isn’t much involved in textual analysis, it isn’t a story I can much identify with. Nor is it the only story we can tell.

tee-rMy story, one I expect will resonate with many of my digital history colleagues, is a story that considers today’s rich landscape of digital history as a natural outgrowth of longstanding public and cultural historical activities rather than a belated inheritance of the quantitative history experiments of the 1960s and 1970s. It is a story that begins with people like Allan Nevins of the Columbia Oral History Office and Alan Lomax of the Library of Congress’s Archive of American Folk-Song, especially with the man on the street interviews Lomax coordinated in the aftermath of the Pearl Harbor attacks. From these oral history and folklife collecting movements of the 1940s and 1950s we can draw a relatively straight line to the public, social, cultural, and radical history movements of the 1960s and 1970s. These later movements directly spawned organizations like the American Social History Project / Center for Media and Learning at the CUNY Grad Center, which was founded in the 1980s—not coincidentally, I might add, by Herb Gutman who was the historical profession’s foremost critic of cliometrics—and the Roy Rosenzweig Center for History & New Media (my former institution), which was founded in the 1990s.

Importantly, these roots in oral history and folklife collecting are not simply institutional and personal. They are deeply methodological. Like today’s digital history, both the oral history and folklife collecting of the 1940s and 1950s and the public and radical history of the 1960s and 1970s were highly:

  1. technological;
  2. archival;
  3. public;
  4. collaborative;
  5. political; and
  6. networked.

Digital humanists often say that particular tools and languages are less important than mindset and method. Our tools are different, but digital historians learned their mindset and methods from the likes of Alan Lomax.

lomax

Thus, from my perspective, the digital humanities family tree has two main trunks, one literary and one historical, that developed largely independently into the 1990s and then came together in the late-1990s and early-2000s with the emergence of the World Wide Web. That said, I recognize and welcome the likely possibility that this is not the whole story. I would love to see this family tree expanded to describe three or more trunks (I’m looking at you anthropology and geography). We should continue to bring our different disciplinary histories out and then tie the various strains together.

In my view, it’s time for a reorientation, for another swing of the pendulum. Having made so much progress together in recent years, having explored so much of what we have in common, I believe the time has come to re-engage with what make us different. One potentially profitable step in this direction would be a continued exploration of our very different genealogies, both for the practical purposes of working within our departments and for the scholarly purposes of making the most of our methodological and intellectual inheritances. In the end, I believe an examination of our different disciplinary histories will advance even our interdisciplinary purposes: understanding what makes us distinctive will help us better see what in our practices may be of use to our colleagues in other disciplines and to see more clearly what they have to offer us.

[Image credits: Smithsonian Institution’s Cooper-Hewitt Museum, Library of Congress, Radical History Review]

Looks Like the Internet: Digital Humanities and Cultural Heritage Projects Succeed When They Look Like the Network

A rough transcript of my talk at the 2013 ACRL/NY Symposium last week. The symposium’s theme was “The Library as Knowledge Laboratory.” Many thanks to Anice Mills and the entire program committee for inviting me to such an engaging event.

cat When Bill Gates and Paul Allen set out in 1975 to put “a computer on every desk and in every home, all running Microsoft software” it was absurdly audacious. Not only were the two practically teenagers. Practically no one owned a computer. When Tim Berners-Lee called the protocols he proposed primarily for internal sharing of research documents among his laboratory colleagues at CERN “the World Wide Web,” it was equally audacious. Berners-Lee was just one of hundreds of physicists working in relative anonymity in the laboratory. His supervisor approved his proposal, allowing him six months to work on the idea with the brief handwritten comment, “vague, but exciting.”

In hindsight, we now know that both projects proved their audacious claims. More or less every desk and every home now has a computer, more or less all of them running some kind of Microsoft software. The World Wide Web is indeed a world-wide web. But what is it that these visionaries saw that their contemporaries didn’t? Both Gates and Allen and Berners-Lee saw the potential of distributed systems.

In stark contrast to the model of mainframe computing dominant at the time, Gates and Allen (and a few peers such as Steve Jobs and Steve Wozniak and other members of the Homebrew Computing Club) saw that computing would achieve its greatest reach if computing power were placed in the hands of users. They saw that the personal computer, by moving computing power from the center (the mainframe) to the nodes (the end user terminal) of the system, would kick-start a virtuous cycle of experimentation and innovation that would ultimately lead to everyone owning a computer.

Tim Berners-Lee saw (as indeed did his predecessors who built the Internet atop which the Web sits) that placing content creation, linking, indexing, and other application-specific functions at the fringes of the network and allowing the network simply to handle data transfers, would enable greater ease of information sharing, a flourishing of connections between and among users and their documents, and thus a free-flowing of creativity. This distributed system of Internet+Web was in stark contrast to the centralized, managed computer networks that dominated the 1980s and early 1990s, networks like Compuserve and Prodigy, which managed all content and functional applications from their central servers.

This design principle, called the “end-to-end principle,” states that most features of a network should be left to users to invent and implement, that the network should be as simple as possible, and that complexity should be developed at its end points not at its core. That the network should be dumb and the terminals should be smart. This is precisely how the Internet works. The Internet itself doesn’t care whether the data being transmitted is a sophisticated Flash interactive or a plain text document. The complexity of Flash is handled at the end points and the Internet just transmits the data.

480px-Internet_map_1024 In my experience digital cultural heritage and digital humanities projects function best when they adhere to this design principle, technically, structurally, and administratively. Digital cultural heritage and digital humanities projects work best when content is created and functional applications are designed, that is, when the real work is performed at the nodes and when the management functions of the system are limited to establishing communication protocols and keeping open the pathways along which work can take place, along which ideas, content, collections, and code can flow. That is, digital cultural heritage and digital humanities projects work best when they are structured like the Internet itself, the very network upon which they operate and thrive. The success of THATCamp in recent years demonstrates the truth of this proposition.

Begun in 2008 by my colleagues and I at the Roy Rosenzweig Center for History and New Media as an unfunded gathering of digitally-minded humanities scholars, students, librarians, museum professionals, and others, THATCamp has in five years grown to more than 100 events in 20 countries around the globe.

How did we do this? Well, we didn’t really do it at all. Shortly after the second THATCamp event in 2009, one of the attendees, Ben Brumfield, asked if he could reproduce the gathering and use the name with colleagues attending the Society of American Archivists meeting in Austin. Shortly after that, other attendees organized THATCamp Pacific Northwest and THATCamp Southern California. By early-2010 THATCamp seemed to be “going viral” and we worked with the Mellon Foundation to secure funding to help coordinate what was now something of a movement.

But that money wasn’t directed at funding individual THATCamps or organizing them from CHNM. Mellon funding for THATCamp paid for information, documentation, and a “coordinator,” Amanda French, who would be available to answer questions and make connections between THATCamp organizers. To this day, each THATCamp remains independently organized, planned, funded, and carried out. The functional application of THATCamp takes place completely at the nodes. All that’s provided centrally at CHNM are the protocols—the branding, the groundrules, the architecture, the governance, and some advice—by which these local applications can perform smoothly and connect to one another to form a broader THATCamp community.

As I see it, looking and acting like the Internet—adopting and adapting its network architecture to structure our own work—gives us the best chance of succeeding as digital humanists and librarians. What does this mean for the future? Well, I’m at once hopeful and fearful for the future.

On the side of fear, I see much of the thrust of new technology today to be pointing in the opposite direction, towards a re-aggregation of innovation from the nodes to the center, centers dominated by proprietary interests. This is best represented by the App Store, which answers first and foremost to the priorities of Apple, but also by “apps” themselves, which centralize users’ interactions within wall-gardens not dissimilar to those built by Compuserve and Prodigy in the pre-aeb era. The Facebook App is designed to keep you in Facebook. Cloud computing is a more complicated case, but it too removes much of the computing power that in the PC era used to be located at the nodes to a central “cloud.”

On the other hand, on the side of hope, are developments coming out of this very community, developments like the the Digital Public Library of America, which is structured very much according to the end-to-end principle. DPLA executive director, Dan Cohen, has described DPLA’s content aggregation model as ponds feeding lakes feeding an ocean.

As cultural heritage professionals, it is our duty to empower end users—or as I like to call them, “people.” Doing this means keeping our efforts, regardless of which direction the latest trends in mobile and cloud computing seem to point, looking like the Internet.

[Image credits: Flickr user didbygraham and Wikipedia.]

Game Change: Digital Technology and Performative Humanities

“Game changing” is a term we hear a lot in digital humanities. I have used it myself. But try, as I was asked to do for a recent talk at Brown University’s Ancient Religion, Modern Technology workshop, to name a list of truly game-changing developments wrought by digital humanities. I come up short.

Struggling with this problem, I found it useful in preparing my talk to examine the origins or at least the evolution of the term. I’m sure it’s not the earliest use, but the first reference I could find to “game changing” (as an adjective) in Google Books was from a 1953 Newsweek article, not surprisingly about baseball, specifically in reference to how Babe Ruth and his mastery of the home run changed the game of baseball. This is a telling, if serendipitous, example, because baseball fans will know that Babe Ruth really did change baseball, in that the game was played one way before he joined the Red Sox in 1914 and another way really ever since. Babe Ruth’s veritable invention of the home run changed baseball forever, from the “small ball” game of infield singles, sacrifice bunts, and strategic base running of the late-19th and early-20th centuries to the modern game dominated by power and strength. As Baseball Magazine put it none-too-flatteringly in 1921: “Babe has not only smashed all records, he has smashed the long-accepted system of things in the batting world and on the ruins of the system has erected another system or rather lack of system whose dominant quality is brute force.” From what I could gather from my quick survey of Google Books, for the better part of the next thirty years, the term is mainly used in just this way, in the context of sports, literally to talk about how games have been changed.

In the 1980s, however, the term seems to take on a new meaning, a new frequency and a new currency. Interestingly, the term’s new relevance seems to be tied to a boom in business and self-help books. This probably comes as no surprise: I think most of us will associate the term today with the kind of management-speak taught in business schools and professional development workshops. In this context, it’s used metaphorically to recommend new strategies for success in sales, finance, or one’s own career. It’s still used in the context of sports, but most of what I found throughout the 80s and 90s relates to business and career. Going back to our graph, however, we see that it’s not until the turn of this century that term gets its big boost. Here we see another shift in its usage, from referring to business in general to the technology business in particular. This also comes as no surprise, considering the digital communications revolution that tooks shape during the five years on either side of the new millenium. Here we see a new word appended to the phrase: game-changing technology. And even more specifically, the phrase seems to become bound up with a fourth word: innovation. Today use of the term has been extended even further to be used in all manner of cultural discourse from politics to university-press-published humanities texts.

But when we use the term in these other arenas—i.e. in ways other than in the literal sense of changing the way a sport or game is played—in order for it to be meaningful, in order for it to be more than jargon and hyperbole, in order for the “game-changing” developments we’re describing to live up to the description, it seems to me that they have to effect a transformation akin to the one Babe Ruth effected in baseball. After Ruth, baseball games were won and lost by new means, and the skills required to be successful at baseball were completely different. A skilled baserunner was useless if most runs were driven in off homeruns. The change Ruth made wasn’t engendered by him being able to bunt or steal more effectively than, say, Ty Cobb (widely acknowledged as the best player of the “small ball” era) it was engendered by making bunting and stealing irrelevant, by doing something completely new.

In the same way, I don’t think technologies that simply help us do what we’ve always done, but better and more efficiently, should be counted as game-changing. Innovation isn’t enough. Something that helps us write a traditional journal article more expertly or answer an existing question more satisfactorily isn’t to me a game-changing development. When you use Zotero to organize your research, or even when you use sophisticated text mining techniques to answer a question that you could have answered (though possibly less compellingly) using other methods, or even when you use those techniques to answer questions that you couldn’t have answered but would like to have answered, that’s not to me game-changing. And when you write that research up and publish it in a print journal, or even online as an open access .pdf, or even as a rich multimedia visualization or Omeka exhibit, that to me looks like playing the existing game more expertly, not fundamentally changing the game itself.

These things may make excellent use of new technologies. But they do so to more or less the same ends: to critique or interpret a certain text or artifact or set of text or artifacts. Indeed, it is this act of criticism and interpretation that is central to our current vision of humanistic pursuit. It is what we mean when we talk about humanities. A journal article by other means isn’t a game changer. It is the very essence of the game we play.

If those things, so much of what we consider to be the work of digital humanities, don’t count as game changers, then what does count? In his new book, Reading Machines, Steve Ramsay argues that the promise of digital technologies for humanities scholarship is not so much to help us establish a new interpretation of a given text but to make and remake that text to produce meaning after meaning. Here Steve looks to the Oulipo or “workshop of potential literature” movement, which sought to use artificial constraints of time or meter or mathematics—such as replacing all the nouns in an existing text with other nouns according to a predefined constraint—to create “story-making machines,” as a model. He draws on Jerry McGann and Lisa Samuels’ notion of cultural criticism as “deformance,” a word that for Steve “usefully combines a number of terms, including ‘form,’ ‘deform,’ and ‘performance.'” For Ramsay digital humanists “neither worry that criticism is being naively mechanized, nor that algorithms are being pressed beyond their inability” but rather imagine “the artifacts of human culture as being radically transformed, reordered, disassembled, and reassembled” to produce new artifacts.

This rings true to me. Increasingly, our digital work is crossing the boundary that separates secondary source from primary source, that separates second-hand criticism from original creation. In this our work looks increasingly like art.

The notion of digital humanities as deformance or performance extends beyond what Steve calls “algorithmic criticism,” beyond the work of bringing computational processes to bear on humanities texts. Increasingly digital humanities work is being conceived as much as event as product or project. With the rise of social media and with its ethic of transparency, digital humanities is increasingly being done in public and experienced by its audiences in real time. Two recent CHNM projects, One Week | One Tool and Hacking the Academy, point in this direction.

An NEH-funded summer institute, One Week | One Tool set out to build a digital tool for humanities scholarship, from inception to launch, in one week. For one week in July 2010, CHNM brought together a group of twelve digital humanists of diverse disciplinary backgrounds and practical experience (Steve Ramsay among them) to build a new software application or service. The tool the group created, Anthologize, a WordPress plugin which allows bloggers to remix, rework, and publish their blog posts as an e-book, is currently in use by thousands of WordPress users.

At the outset, One Week | One Tool set out to prove three claims: 1) that learning by doing is an important and effective part of digital humanities training; 2) that the NEH summer institute can be adapted to accommodate practical digital humanities pedagogy; and 3) that digital humanities tools can be built more quickly and affordably than conventional wisdom would suggest. I think we succeeded in proving these claims. But as a project, I think One Week | One Tool showed something else, something unexpected.

One of the teams working on Anthologize during One Week | One Tool was an outreach team. We have found that outreach—or more crudely, marketing—is absolutely crucial to making open source tools successful. The One Week | One Tool outreach team made heavy use of Twitter, blogs, and other social media during the week Anthologize was built, and one of the strategies we employed was the Apple-style “unveil”—letting a user community know something is coming but not letting on as to what it will be. All twelve members of the One Week | One Tool crew—not only the outreach team, but the developers, designers, and project managers as well—joined in on this, live-Tweeting and live-blogging their work, but not letting on as to what they were building. This created a tremendous buzz around the work of the team in the digital humanities community and even among a broader audience (articles about One Week | One Tool turned up in The Atlantic, ReadWriteWeb, and the Chronicle of Higher Education). More interestingly, these broader communities joined in the discussion, inspired the team at CHNM to work harder to produce a tool (actually put the fear of God in them), and ultimately influenced the design and distribution of the tool. It was, as Tim Carmody, now of Wired Magazine put it, representative of a new kind of “generative web event.”

Quoting his colleague, Robin Sloan, Tim lists the essential features of the generative web event:

Live. It’s an event that hap­pens at a spe­cific time and place in the real world. It’s some­thing you can buy a ticket for—or fol­low on Twitter.

Gen­er­a­tive. Some­thing new gets cre­ated. The event doesn’t have to pro­duce a series of lumi­nous photo essays; the point is sim­ply that con­trib­u­tors aren’t oper­at­ing in play­back mode. They’re think­ing on their feet, col­lab­o­rat­ing on their feet, creat­ing on their feet. There’s risk involved! And that’s one of the most com­pelling rea­sons to fol­low along.

Pub­lish­able. The result of all that gen­er­a­tion ought, ide­ally, to be some­thing you can pub­lish on the web, some­thing that peo­ple can hap­pily dis­cover two weeks or two years after the event is over.

Per­for­ma­tive. The event has an audience—either live or online, and ide­ally both. The event’s struc­ture and prod­ucts are carefully con­sid­ered and well-crafted. I love the Bar­Camp model; this is not a BarCamp.

Ser­ial. It doesn’t just hap­pen once, and it doesn’t just hap­pen once a year. Ide­ally it hap­penn… what? Once a month? It’s a pat­tern: you focus sharply on the event, but then the media that you pro­duce flares out onto the web to grow your audi­ence and pull them in—to focus on the next event. Focus, flare.

To this list I would add a sixth item, which follows from all of the above, and is perhaps obvious, but which I think we should make explicit. Generative web events are collaborative.

CHNM’s Hacking the Academy project is another example from digital humanities of this kind of generative web event. On May 21, 2010, Dan Cohen and I put out a call for “papers” for a collectively produced volume that would explore how the academy might be reformed using digital media and technology. We gave potential contributors only seven days to respond, and during this time we received more than 300 submissions from nearly 200 authors.

Turning this into the “book” that eventually became Hacking the Academy would take considerably longer than a week. The huge response presented us with a problem, one that required us to rethink our assumptions about the nature of authorship and editing and the relationship between the two. Reading through the submissions, some as long as 10,000 words, others as short as 140 characters, we struggled with how to accommodate such a diversity of forms and voices. Our key breakthrough came when we realized we had to let the writing dictate the form of the book rather than the opposite. We established three formal buckets (“feature essays,” “coversations,” and “voices”) and three topical buckets (“scholarship,” “teaching,” and “institutions”) into which we would fit the very best submissions. Some of the good longer pieces could stand on their own, relatively unedited, as features. But in most cases, we had to give ourselves permission to be almost ruthless in the editing (at least when compared to long accepted notions of authorial versus editorial prerogative in academic writing) so that submissions would fit into the formal and intellectual spaces we created. Long or short, formal or informal, we let the best writing rise to the top, selecting contributions (either entire pieces or very often just a particularly compelling paragraph) that could be juxtaposed or contraposed or placed in conversation with one another to best effect.

In the end, the “book” exists in several forms. There is the “raw” index of every submission. There is our 150-odd-page remix of this material, containing more approximately 40 articles from more than 60 authors, which is being published online and in print by the University of Michigan’s MPublishing division and Digital Culture Books imprint. Then, and I think most interestingly, there are third-party remixes, including one by Mark Sample re-titled Hacking the Accident.

Appropriately, Hacking the Accident is itself a performance of sorts. Using the classic Oulipo technique of N+7, in which the author replaces every noun in a text with the noun seven dictionary entries ahead of it, Mark has created a new work, not of humanities scholarship, but of literature, or poetry, or theater, or something else altogether.

These are just two examples, two with which I am particularly familar, of what we might call “performative humanities.” There are others: most significantly, the lively performative exchanges that play out in the digital humanities Twittersphere every day. I wouldn’t go so far to say performance is the future of humanities in general or even digital humanities in particular. But I do think the generative web event is one example of a game-changing development. Performance is a different ball game than publication. The things required to make a successful performance are very different from the things required to make a successful text. It requires different skills, different labor arrangements, way more collaboration, and different economies than traditional humanities research.

We can look to new tools and new research findings, but I think we will only know for sure that digital humanities has changed the game when what it takes to succeed in the humanities has changed. We will know the game has change when bunting and base-running aren’t working any more, and a new kind of player with a new set of skills comes to dominate the field of play.

[Image credit: Wikipedia]

[This post is based on a talk I gave on February 13, 2012 at Brown University in Providence, Rhode Island. Many thanks to Michael Satlow for the kind invitation, generous hospitality, and an excellent two-day workshop.]

Stuff Digital Humanists Like: Defining Digital Humanities by its Values

[A very rough transcript of my talk at the CUNY Digital Humanities Initiative on December 1, 2010. The DHI’s theme for this semester’s program was “What is Digital Humanities?” This is my attempt to answer—or dodge—that question. Many thanks to Matt Gold and all my friends at CUNY for a great event and a thought-provoking discussion.]

Our colleague Bethany Nowviskie might scold me if I didn’t preface this conversation by saying there are different strains of digital humanities. Bethany might define those strains as “old” and “new.” I’d probably divide things along more disciplinary lines, looking to a tradition of digital humanities that comes out of literature and one that comes out of public history. If I had to place myself along these axes I’d probably land where the “new” and “history” strains meet. There are, of course, lots of other ways to slice the pie.

But instead of exploring the genealogies of digital humanities any further, I’d like to switch gears and instead talk about digital humanities as community, or more precisely, as a set of overlapping personal communities, each one centered around individual, self-identified digital humanists. Thought of this way, digital humanities starts to look a lot like a social network. Indeed, in some ways digital humanities increasingly is a social network built, for better or worse, on Twitter’s platform. What follows is a description of digital humanities as seen from my vantage point as a node in that social network.

In as much as digital humanities is an Internet-based social network, it should come as no surprise that digital humanities looks a lot like the Internet itself. Digital humanities takes more than tools from the Internet. It works like the Internet. It takes its values from the Internet.

Jonathan Zittrain does a good job of describing these values in his excellent book, The Future of the Internet and How to Stop It. Among the values Zittrain says are hard coded into the very architecture of the Internet are something he calls the “procrastination principle” and something he calls the “trust your neighbor approach.”

The procrastination principle (or “end-to-end argument”) is a design principle that states that most features of a network should be left to users to invent and implement, that the network should should be as simple as possible and that complexity should be developed at its end points not at its core, that the network should be dumb and the terminals should be smart. This is precisely how the Internet works. The Internet itself doesn’t care whether the data being transmitted is a sophisticated Flash interactive or a plain text document. The complexity of Flash is handled at the end points and the Internet just transmits the data.

There is an analogous value in digital humanities. Innovation in digital humanities frequently comes from the edges of the scholarly community rather than from its center—small institutions and even individual actors with few resources are able to make important innovations. Institutions like George Mason, the University of Mary Washington, and CUNY and their staff members play totally out-sized roles in digital humanities when compared to their roles in higher ed more generally, and the community of digital humanities makes room for and values these contributions from the nodes.

Zittrain points out that the procrastination principle necessarily implies a second principle he dubs the “trust your neighbor approach.” In order to permit innovation from the nodes, the network has to trust that those innovations are benign. Moreover, the network requires one server to pass along another’s packets: when I send an email to a colleague in Australia, I have to trust that my data packets will be passed along by other machines on the network in the several hops they will have to take to get to their destination. The Internet assumes assumes people will be good citizens.

Digital humanities makes some similar assumptions in its commitments to open access, open source, and collaboration. As Bethany has said elsewhere, “how many other academic disciplines or interdisciplines work so hard to manifest as ‘a community of practice that is solidary, open, welcoming and freely accessible’ — a ‘collective experience,’ a ‘common good?'” We allow allow all comers, we assume that their contributions will be positive, and we expect that they will share their work for the benefit of the community at large.

Thus in some important respects, the values of digital humanities proceed directly from the design decisions made by the original architects of the Internet. Surely we don’t always live up to these ideals, but we value them just the same.

Or at least this is the direction my theorizing of the question “What is Digital Humanities?” increasingly takes me. But in the end, I’m not sure that theorizing this question is particularly useful. Fortunately, thinking of digital humanities as a social network provides another vector along which to define it: the stuff around which it coalesces.

Most of you will already have groked the not-so-hidden reference to the Stuff White People Like blog in my title today. For those of you who aren’t familiar with this blog, it was started in 2008 by a blogger named Christian Lander and later turned into a bestselling book by the same title. Along the way, it was imitated by hundreds of other “stuff * like” blogs.

As you can see from this list, the “stuff * like” concept is by now pretty cliched. But the fact that it has been so successful as an Internet meme points to its utility: it is often easier, more comprehensible, and more productive to define diverse and diffuse communities—especially Internet communities—in terms of the things to which they gravitate rather than the abstract conceptual boundaries that separate them from other communities.

Indeed, this insight is not unique to “stuff * like” bloggers. In its current sorry state we forget how successful MySpace once was, but it became for a time the dominant social network largely on the strength of this insight, by identifying music as one of most important things around which social groups congregate. In many respects, MySpace was community or set of overlapping communities built around bands and shared music tastes. IMDB does something similar with movies. Digg does it with web links. Yelp does it with restaurants. Even Apple is directly trying to capitalize on MySpace’s original insight with its dubiously successful new music centered social network, Ping.

It follows, therefore, that if digital humanities is a social network, then one of the things that will help us understand it better is looking at the things around which the network coalesces, the stuff digital humanists like. In this I’d also make one possibly more controversial claim: not only do we like these things better than their alternatives, we like them better than their alternatives because they work better than their alternatives in the real world.

Here are five to start us off:

  • Like: Twitter / Don’t like: Facebook. The first thing we have to mention, which we have mentioned a few times already, is Twitter. The reasons we like Twitter are complex and I won’t pretend to understand them all, but I’ll throw out a few suggestions. First, its “follow” rather than “friend” model is more open, allows for the collaboration and non-hierarchy that the Internet and digital humanities values. Second, and related to this, Twitter is the place where content-creators—journalists, writers, artists, web developers, etc.—tend to hang out. We overlap with those communities, or at least seek to overlap with them, in productive ways. They are the distant nodes from which we hope new innovations will come. Third, Twitter, in the way we use it, is mostly about sharing ideas whereas Facebook is about sharing relationships. Scholars are good at ideas, maybe less so at relationships.
  • Like: Agile development / Dislike: long planning cycles. The second thing I’ll mention is agile development, the philosophy of “releasing early and often,” which we do not only with software/code but also with our ideas and writing when we Tweet, blog, and chat. We do this as good neighbors but also in the hope that releasing our code and ideas will improve with contributions from end points of our networks.
  • Like: DIY / Dislike: Outsourcing. Most of the most successful digital humanities projects are those done by scholar/technologists not those imagined by scholars and implemented by technologists. Likewise, the most successful digital humanists are scholars who know the technology, often those who are self-taught, not ones who seek a client-vendor relationship with technologists. We take this insight to heart in our hiring at CHNM, looking for people with formal training in the humanities and self-taught tech skills.
  • Like: PHP / Dislike: C++. Fourth, and following from the last point, we like PHP not C++. This is another way of saying we like the transparent, easy-to-learn, and simple (if sometimes ham-handed) technologies of the Web more than the more powerful, more sophisticated, more elegant, but less approachable compiled code of the desktop. A focus on getting the most out of simple, transparent, vernacular technologies allows us to keep the door to the field open to new entrants.
  • Like: Extramural funding / Dislike: Intramural funding. In one respect, this may seem obvious: everybody likes grants. In another respect it’s probably going a little too far to say we don’t like intramural funding: it is essential to building and maintaining capacity for our centers and staff. But it seems to me the most successful digital humanities projects are those that result from competitive grant making processes, especially the federal grant making process. Why is this? I can point to at least three reasons: 1) Attracting grant money keeps us innovating, which, like it or not, is a premium in our business. Grants are given for new work, not for more of the same. 2) Writing grants and serving on panels keep us in conversation with the field. We have to keep current and keep in touch with one another to justify our projects to grantmakers and to recommend others’ projects for funding. Increasingly, funding guidelines themselves require collaboration. 3) Unlike much traditional scholarship, which often requires one big deliverable (a book) after years of close-kept study, research, and writing, grant work requires defining and meeting a set of closely timed, concrete deliverables, a mode of work which encourages the kind of agile development so valued by the Internet and digital humanities community.

These things represent a set of shared interests, map onto a set of shared values, and in doing so they identify and define a community. We could identify lots of other things that digital humanists like and dislike. In fact your list may be very different than mine—please let me know in comments. As I said at the outset, this is just the view from my node in the network.

I haven’t “defined” digital humanities beyond defining my community and its values today and I don’t think I need to go any further than that at this point. Elsewhere I have suggested that perhaps digital humanities doesn’t have to answer questions, at least not yet. Likewise I’m not sure we have to define digital humanities yet beyond describing a community and a set of shared values. Our job for now is to continue to work together, and the rest will take care of itself.

Omeka and Its Peers

As an open source, not-for-profit, warm-and-fuzzy, community service oriented project, we don’t normally like to talk about market rivals or competitive products when we talk about Omeka. Nevertheless, we are often asked to compare Omeka with other products. "Who’s Omeka’s competition?" is a fairly frequent question. Like many FAQs, there is an easy answer and a more complicated one.

The easy answer is there is no competition. 😉 Omeka’s mix of ease of use, focus on presentation and narrative exhibition, adherence to standards, accommodation for library, museum, and academic users, open source license, open code flexibility, and low ($0) price tag really make it one of a kind. If you are a librarian, archivist, museum professional, or scholar who wants a free, open, relatively simple platform for building a compelling online exhibition, there really isn’t any alternative.

digital_amherst

[Figure 1. Digital Amherst, an award-winning Omeka powered project of the Jones Library in Amherst, MA.]

The more complicated answer is that there are lots of products on the market that do one or some of the things Omeka does. The emergence of the web has brought scholars and librarians, archivists, and museum professionals into increasingly closer contact and conversation as humanists are required to think differently and more deeply about the nature of information and librarians are required to play an ever more public role online. Yet these groups’ respective tool sets have remained largely separate. Library and archives professionals operate in a world of institutional repositories (Fedora, DSpace), integrated library systems (Evergreen, Ex Libris), and digital collections systems (CONTENTdm, Greenstone). Museum professionals operate in a world of collections management systems (TMS, KE Emu, PastPerfect) and online exhibition packages (Pachyderm, eMuseum). The humanist or interpretive professional’s online tool set is usually based around an off-the-rack web content management system such as WordPress (for blogs), MediaWiki (for wikis), or Drupal (for community sites). Alas, even today too much of this front facing work is still being done in Microsoft Publisher.

The collections professional’s tools are excellent for preserving digital collections, maintaining standardized metadata, and providing discovery services. They are less effective when it comes to exhibiting collections or providing the rich visual and interpretive context today’s web users expect. They are also often difficult to deploy and expensive to maintain. The blogs, wikis, and off-the-rack content management systems of the humanist (and, indeed, of the public programs staff within collecting institutions, especially museums) are the opposite: bad at handling collections and standardized metadata, good at building engaging experiences, and relatively simple and inexpensive to deploy and maintain.

Omeka aims to fill this gap by providing a collections-focused web publishing platform that offers both rigorous adherence to standards and interoperability with the collections professional’s toolkit and the design flexibility, interpretive opportunities, and ease of use of popular web authoring tools.

omeka_tech_ecosystem

[Figure 2. Omeka Technology Ecosystem]

By combining these functions, Omeka helps advance collaboration of many sorts: between collections professionals and interpretive professionals, between collecting institutions and scholars, between a "back of the house" and "front of the house" staff, and so on.

omeka_user_ecosystem

[Figure 3. Omeka User Ecosystem]

In doing so, Omeka also helps advance the convergence and communication between librarians, archivists, museum professionals, and scholars that the digital age has sparked, allowing LAM professionals to participate more fully in the scholarship of the humanities and humanists to bring sophisticated information management techniques to their scholarship.

Which brings us back to the short answer. There really is no competition.

Lessons from One Week | One Tool – Part 3, Serendipity

Over the past few months, several people—including several participants themselves—have asked me how we chose the One Week | One Tool crew. We had about 50 applicants. Nearly all of them were perfectly qualified to attend. This made the selection process exceedingly difficult. I have no doubt we could have ended up with another group of twelve and been equally successful. Indeed, I have often joked that with the applicant pool we got we could easily have done "Three Weeks | Three Tools."

In the end, the uniformly high quality of our applicant pool meant we had to make our choices on largely subjective criteria. Who showed the most enthusiasm? Who showed the most willingness to collaborate? Who seemed open minded? Whose writing style showed clarity of thought and energy? Who seemed like the hardest workers? Who seemed eager to learn? Whose seemed like a quick study?

One important thing to note is that we didn’t pick for particular technical skills. Of course we wanted a good mix: a team full of UI specialists or outreach experts wouldn’t have worked. But we didn’t select for PHP, Ruby, Java, TEI, or any other technology. We assumed that if we picked good people with a range of skills, even if those skills were all over the map, we’d end up with something interesting. I think we have.

As it turns out, we have ended up with something even more interesting because of that diversity of skills. Boone said something very telling at the bar on Thursday night: Anthologize probably couldn’t have been built without One Week | One Tool. A single shop wouldn’t have had the necessary range of skills to do it. I know CHNM couldn’t have done it alone. Sure, we have the PHP and JavaScript chops (although not the intimate knowledge of WordPress Boone brought to the table). But we certainly don’t have deep knowledge of TEI and XSLT the team needed to produce Anthologize’s rich, clean outputs. Nor, I suspect, would we even have hit upon TEI as a solution to that particular problem.

There are lessons here for hiring. Pick the smartest people. The best writers. The hardest workers. Pick people with proven track records of working well in teams. People with lots of energy. People who approach heavy workloads with clear thinking and good humor. People who’ve shown aptitude for picking up new technical skills on their own.

These people may not know what you need them to know on Day 1. But they will work hard to learn it. They’ll also bring a host of additional skills you didn’t think you needed, but will be happy to have once they’re there. Having these additional skills on tap may even let you take your work in directions you couldn’t have otherwise imagined.

#oneweek #buildsomething

Lessons from One Week | One Tool – Part 2, Use

For all the emphasis on the tool itself, the primary aim of One Week | One Tool is not tool building, it’s education. One Week | One Tool is funded by NEH under the the Institutes for Advanced Topics in Digital Humanities (IATDH) program. IATDH grants “support national or regional (multistate) training programs for scholars and advanced graduate students to broaden and extend their knowledge of digital humanities.” Thus training is the criteria by which One Week | One Tool will ultimately be judged.

A key argument of One Week | One Tool is that learning digital humanities consists primarily in doing digital humanities, that digital humanities is a hands-on kind of thing, that to learn tool building you have to do some tool building. At the same time, we recognize that there’s a place for instruction of the hands-off sort. To that end, the first 18 hours or so of One Week | One Tool (essentially from Sunday night until mid-afternoon on Monday) were reserved for presentations by CHNM staff. Jeremy offered a practical introduction to software development best practices and tools. Trevor described the range of outreach strategies we have employed on projects like Zotero, Omeka, and the National History Education Clearinghouse. Dan provided the view from 30,000 feet with thoughts on the state of the art and near future of digital humanities software development. I kicked things off on Sunday with a brief introduction to CHNM and our tool building philosophy. Several strains of thought and practice inform our work at CHNM—public history, cultural history, radical democracy, dot.com atmospherics, and more—but to keep things simple I summed up our tool building philosophy in one word: use.

Here is more or less what I told the crew.

At CHNM we judge our tools by one key metric above all others: use. Successful tools are tools that are used. The databases of Sourceforge and Google Code are littered with interesting, even useful, but unused open source tools. Academic software projects are no exception. Every year NSF, NIH, and now NEH and IMLS award grants for scholarly software development. In recent years, the funding guidelines have stipulated that this software be made freely available under open source licenses. Much of the software produced by these programs is good and useful code. But little of it is actually used.

There are several reasons for this. Many efforts are focused narrowly on the problems of a particular researcher or lab. While the code produced by these researchers proves useful for solving their particular problems, even when released, it hasn’t been designed to be generally applicable to the needs of other researchers in the field. It is, in effect, a one-off tool released as open source. But open source code alone does not constitute an open source project.

Other projects build generalized tools that may be of potential use to other researchers. But few make the necessary investment in outreach and, yes, marketing to make potential users aware of the tool. It is for this reason, among others, that we see so much duplication of effort and functionality in scholarly software projects.

Building a user community is the first prerequisite to building a successful open source software project. The success of software is judged by its use. The universal assessment that iTunes is a hit and Zune is a flop is not based on the quality of the code or even the elegance or potential usefulness of the experience. It’s based on the fact that everybody uses iTunes and nobody uses Zune. This is not to say that software has to have millions of users to be successful. But it is to say that successful software is used by large swath of its potential users. To be sure, the total population of potential users of cultural heritage mapping tools is much smaller than the total population of potential users of digital media playback software. But any open source software project’s goal should be use by as many of its potential users as possible. In any case, we should aim to have our software used by as many cultural heritage institutions and digital humanists as possible.

Moreover, a large and enthusiastic user base is key to a successful open source software project’s continued success. If people use a product, they will invest in that product. They will provide valuable user testing. They will support the project in its efforts to secure financial support. They will help market the product, creating a virtuous circle. Sustainability, even for free software, is grounded in a committed customer base.

Related to building a user community is building an open source developer community. Some number of users will have the inclination, the skills, and the commitment to the project to help on the level of code. This percentage will be very small, of course, less than one percent, which is another reason to build a large user base. But this small group of code contributors and volunteer developers forms the core of most successful open source projects. They find and fix bugs. They provide end user support. They write documentation. They add new features and functionality. They provide vision and critical assessment. They constitute a ready-made pool of job candidates if a core paid developer leaves a project.

This developer community is a project’s best chance at sustainability, and collaboration at the developer level, rather than collaboration at the institution or administrator level, is usually key to a scholarly open source project’s lasting success. Getting provosts, deans, and directors from partner institutions to commit FTE’s and other resources to a project is very welcome—we’d love some commitments of this sort for the tool we built last week. But it’s not where the strength of a collaboration will be located. Individual developers, who commit their time, effort, ideas, code, heart and soul to a project, are the ones who will keep something going when money and institutional interest runs out.

A developer community does not develop on its own, of course. It requires support. First and foremost, a developer community needs open communication channels—an active IRC channel and listserv, for example—something which, in the case of a university of library-based project, means a group of responsive staff developers on other end. Community developers need profitable access to the project’s development roadmap so they know where best to contribute their efforts. They need well-documented and thoughtfully-designed APIs. They need technical entry points, things such as a plugin architecture where they can hone their chops on small bits of functionality before digging into the core code base. Most importantly, community developers need a sense of community, a sense of shared purpose, and a sense that their volunteer contributions are valued. All of this has to be planned, managed, and built into the software architecture.

This philosophy of use is core to CHNM’s vision of open source software for scholarship and cultural heritage. The tool the crew of One Week | One Tool developed—like Omeka and Zotero before it—should be case in point. It was chosen with clear audiences in mind. It was built on approachable technologies and engineered to be extensible. It’s outreach plan and feedback channels are designed to encourage broad participation. When it’s released tomorrow, I think you’ll see it is a tool to be used.

#oneweek #buildsomething

Lessons from One Week | One Tool – Part 1, Project Management

Three days into One Week | One Tool, I’m beginning to see that one of the nice things about running an NEH Summer Institute as a practicum rather than a classroom is that the organizers learn as much as the participants. For me, this week has reinforced and clarified an important set of related lessons about decision making, leadership, and team building in digital humanities. (I’ve learned some other lessons as well, and I’ll talk about those in subsequent posts over the course of the week.) As you can imagine, things are a little busy around here, so here they are in short.

  1. Snap decisions are good. When faced with a choice between A and B, it often pays simply to pick one and move on. It’s tempting to think that hours of study and deliberation will yield the “right” answer. But the truth is most project management questions don’t have right answers. Furthermore, no amount of research will insure that everyone will be happy with your decision. At the end of the day, some of your stakeholders or team members are going to be disappointed with your decision, and time spent purely in hopes that you can satisfy everyone is time wasted. Finally, no matter how much prior study and deliberation, decisions are always and inevitably made in the moment. Put another way, the moment of decision always involves a snap judgment. You’ll never know if the decision you’ve made is a good one until after you’ve made it. Bottom line: when faced with tight deadlines, do just enough research to understand the consequences of A or B, pick one, and then deal with those consequences.
  2. Leadership is momentum-making. It may seem obvious, but the job of a leader is to move people forward. To keep people with you have to be constantly in motion. This is the importance of snap decisions. People will forgive a leader a bad decision. They can’t forgive indecision. Like a ship, leaders create a wake that pulls people along. If you stop, they will drift away.
  3. Collaboration is shared doing. We tend to think of collaboration as shared decision making. But more important is shared accomplishment. Consensus on a project is certainly important, but strong collaborations aren’t forged in talking, they’re forged in working. As noted above, one or more team members will always be unhappy with every decision that’s made on a project . Trying to understand and accommodate their concerns will help mend any hurt feelings or disappointments, but what’s really going to bring them back into the fold is getting down to work on the task they had previously opposed. Getting people to invest some time in a decision they opposed initially is the quickest way to help them see its merits and reengage their coworkers. Helping them contribute to the team is the best way to make them feel valuable and valued again.

More to come. #oneweek #buildsomething

New Wine in Old Skins: Why the CV needs hacking

Likewise, no one pours new wine into old wineskins. Otherwise, the wine will burst the skins, and both the wine and the skins are ruined. Rather, new wine is poured into fresh wineskins. – Mark 2:22

Since the time of my first foray into digital humanities as a newly minted graduate working on a project to catalog history museum websites (yes, in 1996 you could actually make a list of every history museum with a website, about 150 at the time), most discussions about careers in digital humanities have centered around questions of how to convince more traditional colleagues to accept digital work as scholarship, to make it “count” for tenure and promotion, that is, to make it fit into traditional structures of academic employment. This has been a hard sell because, as Mills has pointed out, the kind of work done by digital humanists, no matter how useful, interesting, and important, often just can’t be made to fit the traditional definitions of scholarship that are used to determine eligibility for academic career advancement. No amount of bending and squeezing and prodding and poking is going to help the new square pegs of digital humanities fit the old round holes used to assess traditional textual scholarship.

Having seen their older colleagues struggle though stages of denial, anger, bargaining, and depression, a new generation of digital humanists (some of us) is coming to accept this situation. Rather than fighting to have its work credited within the existing structures of academic career advancement, it has instead decided to alter those structures or replace them with ones that judge digital work on its own merits. This new generation is hacking the academy to create new structures more natively accepting of digital work. These new structures—as imperfect and tenuous as newly forked code—can be seen in the job descriptions and contract arrangements of many in the alt-ac crowd.

Yet however much we have hacked academic employment to better accommodate digital work, at least one structure has remained stubbornly intact: the CV or curriculum vitae. For the most part our CV’s look the same as our analog colleagues’. Should this be? Isn’t this pouring new wine into old wineskins? Aren’t we setting ourselves up for failure if we persist in marketing our digital achievements using a format designed to highlight analog achievements? The standard categories of education, awards, publications, and so on (see this fairly representative guide from MIT [.pdf]) sets us up for failure. If we are going to market our work effectively we need to come up with a new vehicle for the construction of professional identity.

There is nothing immutable about the CV. As far as I can tell from a few hours research, the CV in its current form emerged in the late 19th century and early 20th century, right around the time our modern disciplines were consolidating the academy. The OED dates the first use of “curriculum vitae” to mean “a brief account of one’s career” to the turn of the last century (“Anciently biography was more of a mere curriculum vitæ than it is now,” New Internat. Encycl. III. 21/2, 1902). The British term, “vita,” appears just about the same time. A quick search of the “help wanted” pages of a few major American newspapers yields a similar result for the first use of the term. A December 3, 1908 advertisement in The Washington Post asks:

HELP WANTED—MALE: IN A PATENT OFFICE—YOUNG GERMAN, HAVING passed schools in Germany; salary $30 to start, gradually increasing. Send curriculum vitae to G. DITTMAR, 702 Ninth st. nw.

Considering its importance in shaping the modern academy and constructing the modern notion of the scholar, there is little (very little, in fact; I couldn’t find anything) written on the CV. Yet even from this very cursory bit of research we can say one thing definitively: the CV is a social and historical construct. It hasn’t always existed, and it is not an essential ingredient for the successful creation and dissemination of scholarship. Erasmus didn’t have one, for example.

I’m ready to accept that the successful operation of the academy requires a vehicle, even a standardized vehicle, for constructing and communicating scholarly identity. But it doesn’t have to be, and hasn’t always been, the CV—certainly not the one we were told to write in grad school. The CV is a platform for constructing and communicating professional achievement and identity, and like any platform, it’s hackable.

So, I say we need, and can build, a new CV, or whatever you want to call it. But what does this new CV look like? Here are at least some of the criteria a new vision for the professional identity document should meet (I use the word “document” here simply as a shorthand, not to suggest the format or material existence this new thing should take):

  1. Its primary presentation should be digital. A print version of the document may exist, but it should be born digital to make best use of the special qualities of digital media, which undoubtedly will do a better job of representing digital work than the analog technologies of print. We should look to discussions around the notion of e-portfolios in the educational technology community for ideas.
  2. It should eschew the visual hierarchies that privilege print scholarship in the traditional CV. Specifically, the vertical orientation that inevitably puts digital work below analog work should be eliminated.
  3. It should adequately represent collaborative work. You should be able to put a collaborative product (a website, a software project, an exhibit) on your CV without diminishing your colleague’s contributions but also without feeling guilty about listing it under your name. We need a better way to represent group work.
  4. It should credit processes as well as products. Put another way, we need to elevate activities previously relegated to the category of “service” in our career presentations. Much of the real work of digital humanities involves project management, organization, partnership building, network building, curation, and mentoring, and these processes need to be credited accordingly. The development and implementation of new ways of working constitute significant achievements in digital humanities. New methods should be credited equally with new modalities of scholarship.
  5. It should be used. If digital humanists create these new documents, but persist in using their old paper CV’s to apply for jobs, it will be doomed to fail.

There are surely other criteria this new document should meet. Let’s brainstorm in comments and start helping help ourselves.