Found History

by Tom Scheinfeldt

August 18, 2014
by Tom Scheinfeldt
1 Comment

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.”

May 29, 2014
by Tom Scheinfeldt
0 comments

Innovation, Use, and Sustainability

Revised notes for remarks I delivered on the topic of “Tools: Encouraging Innovation” at the Institute of Museum and Library Services (IMLS) National Digital Platform summit last month at the New York Public Library.

What do we mean when we talk about innovation? To me innovation implies not just the “new” but the “useful.” And not just the “useful” but the “implemented” and the “used.” Used, that is, by others.

If a tool stays in house, in just the one place where it was developed, it may be new and it may be interesting—let’s say “inventive”—but it is not “innovative.” Other terms we use in this context—”ground breaking” and “cutting edge,” for example—share this meaning. Ground is broken for others to build upon. The cutting edge preceeds the rest of the blade.

The IMLS program that has been charged and most generously endowed with encouraging innovation in the digital realm is the National Leadership Grants: Advancing Digital Resources program. The idea that innovation is tied to use is implicit in the title of the program: the word “leadership” implies a “following.” It implies that the digital resources that the program advances will be examples to the field to be followed widely, that the people who receive the grants will become leaders and gain followers, that the projects supported by the program will be implemented and used.

This is going to be difficult to say in present company, because I am a huge admirer of the NLG program and its staff of program officers. I am also an extremely grateful recipeint of its funds. Nevertheless, in my estimation as an observer of the program, a panelist, and an adwardee, the program has too often fallen short in this regard: it has supported a multitude of new and incredibly inventive work, but that work has too rarely been taken up by colleagues outside of the originating institution. The projects the NLG program has spawned have been creative, exciting, and new, but they have too rarely been truly innovative. This is to say that the ratio of “leaders” to “followers” is out of whack. A model that’s not taken up by others is no model at all.

I would suggest two related remedies for the Leadership Grants’ lack of followers:

  1. More emphasis on platforms. Surely the NLG program has produced some widely used digital library and museum platforms, including the ones I have worked on. But I think it bears emphasizing that the limited funds available for grants would generate better returns if they went to enabling technologies rather than end prodcuts, to platforms rather than projects. Funding platforms doesn’t just mean funding software—there are also be social and institutional platforms like standards and convening bodies—but IMLS should be funding tools that allow lots of people to do good work, not the good work itself of just a few.
  2. More emphasis on outreach. Big business doesn’t launch new products without a sale force. If we want people to use our products, we shouldn’t launch them without people on staff who are dedicated to encouraging their use. This should be refelected in our budgets, a much bigger chunk of which should go to outreach. That also means more flexibility in the guidelines and among panelists and program officers to support travel, advertizing, and other marketing costs.

Sustainability is a red herring

These are anecdotal impressions, but it is my belief that the NLG program could be usefully reformed by a more laser-like focus on these and other uptake and go-to-market strategies in the guidelines and evaluation criteria for proposals. In recent years, a higher and higher premium has been placed on sustainability in the guidelines. I believe the effort we require applicants to spend crafting sustainability plans and grantees to spend implementing them would be better spent on outreach—on sales. The greatest guarantor of sustainiability is use. When things are used they are sustained. When things become so widely implemented that the field can’t do without them, they are sustained. Like the banks, tools and platforms that become too big to fail are sustained. Sustainability is very simply a fuction of use, and we should recognize this in allocating scare energies and resources.

April 7, 2014
by Tom Scheinfeldt
7 Comments

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]

March 27, 2014
by Tom Scheinfeldt
1 Comment

Uber and Airbnb

I’m extremely uneasy about startups like Uber and Airbnb whose business models are grounded in sidestepping regulations that were originally intended as consumer- and labor-protection measures. People—both the service providers and their customers—love Uber and Airbnb because they offer greater flexibility and efficiency than traditional taxi and hotel services. Some of that flexibility is afforded by new communications technologies that offer a more direct connection between the service provider and the consumer. But a lot of that flexibility stems from the fact that these services are unregulated. Uber and Airbnb get closer to consumers not only by using information technology to ditch the middleman of the dispatcher (in Uber’s case) or travel agent and hotel chain (in Airbnb’s), but also by ditching the middleman of the government.

We can imagine lots of markets that could be streamlined by using information technology to sidestep middlemen to place service providers in more direct communication with consumers. But the middlemen are often the people who comply with government regulations that are intended to protect us from fraud and abuse. Middlemen often create friction and inefficiencies in the system. But sometimes a little friction is good.

December 9, 2013
by Tom Scheinfeldt
0 comments

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.]

August 22, 2013
by Tom Scheinfeldt
3 Comments

No Holds Barred

About six months ago, I was asked by the executive director of a prestigious but somewhat hidebound—I guess “venerable” would be the word—cultural heritage institution to join the next meeting of the board and provide an assessment of the organization’s digital programs. I was told not to pull any punches. This is what I said.

  1. You don’t have a mobile strategy. This is by far your most pressing need. According to the Pew Internet and American Life Project, already more than 45% of Americans own a smartphone. That number rises to 66% among 18-29 year olds and 68% among families with incomes of more than $75,000. These are people on the go. You are in the travel and tourism business. If you are only reaching these people when they’re at their desks at work—as opposed to in their cars, on their lunch breaks, while they’re chasing the kids around on Saturday morning—you aren’t reaching them in a way that will translate into visits. This isn’t something for the future. Unfortunately, it’s something for two years ago.
  2. You don’t have an integrated social strategy. I could critique your website, and of course it needs work. But a redesign is a relatively straightforward thing these days. The more important thing to realize is that you shouldn’t expect more than a fraction of your digital audience these to interact directly with your website. Rather, most potential audience members will want to interact with you and your content on their chosen turf, and these days that means Facebook, Twitter, Pinterest, Tumblr, and Wikipedia, depending on the demographic. You have to be ready to go all in with social media and dedicate at least as much thought and resources to your social media presence as to your web presence.
  3. Your current set of researcher tools and resources aren’t well-matched to what we know about researcher needs and expectations. Ithaka Research, a respected think tank that studies higher education and the humanities, recently released a report entitled “Supporting the Changing Research Practices of Historians” (I’d encourage everyone here to give it a good read; it has a ton of recommendations for organizations like this one grappling with the changing information landscape as it relates to history). One of its key findings is that Google is now firmly established as researchers’ first (and sometimes last) stop for research. Lament all you want, but it means that if you want to serve researchers better, your best bet isn’t to make your own online catalog better but instead to make sure your stuff shows up in Google. As the Library of Congress’s Trevor Owens puts it: “the next time someone tells you that they want to make a ‘gateway’ a ‘portal’ or a ‘registry’ of some set of historical materials you can probably stop reading. It already exists and it’s Google.” This speaks to a more general point, which is related closely to my previous point. Researchers come to your collection with a set of digital research practices and tools that they want to use, first and foremost among these being Google. Increasingly, researchers are looking to interact with your collections outside of your website. They are looking to pull collection items into personal reference management tools like Zotero. More sophisticated digital researchers are looking for ways to dump large data sets into an Excel spreadsheet for manipulation, analysis, and presentation. The most sophisticated digital historians are looking for direct connections to your database through open APIs. The lesson here is that whatever resources you have to dedicate to online research collections should go towards minimizing the time people spend on your website. We tend to evaluate the success of our web pages with metrics like numbers of page views, time spent per page, and bounce rate. But when it comes to search the metrics are reversed: We don’t want people looking at lots of pages or spending a lot of time on our websites. We want our research infrastructure to be essentially invisible, or at least to be visible for only a very short period of time. What we really want with search is to allow researchers to get in and get out as quickly as possible with just what they were looking for.
  4. You aren’t making good use of the organization’s most valuable—and I mean that in terms of its share of the annual budget—resource: its staff expertise. Few things are certain when it comes to Internet strategy. The Internet is an incredibly complex ecosystem, and it changes extremely quickly. What works for one project or organization may not work for another organization six months from now. However, one ironclad rule of the Internet is content drives traffic. Fresh, substantive content improves page rank, raises social media visibility, and brings people to the website. Your website should be changing and growing every day. The way to do that is to allow and encourage (even insist) that every staff member, down to the interns and docents, contribute something to the website. Everybody here should be blogging. Everyone should be experimenting. The web is the perfect platform for letting staff experiment: the web allows us to FAIL QUICKLY.
  5. You aren’t going to make any money. Digital is not a revenue center, it’s an operating cost like the reading room, or the permanent galleries, or the education department. You shouldn’t expect increased revenues from a website redesign any more than you should from a new coat of paint for the front door. But just like the reading room, the education programs, and the fresh coat of paint, digital media is vital to the organization’s mission in the 21st century. There are grants for special programs and possibly for initial capital expenditures (start-up costs), but on the whole, cultural organizations should consider digital as a cost of doing business. This means reconfiguring existing resources to meet the digital challenge. One important thing to remember about digital work is that its costs are almost entirely human (these days the necessary technology, software, equipment, bandwidth is cheap and getting cheaper). That means organizations should be able to afford a healthy digital strategy if they begin thinking about digital work as an integral part of the duties of existing staff in the ways I described earlier. You probably need a head of digital programs and possibly a technical assistant, but beyond that, you can achieve great success through rethinking/retraining existing human resources.

I’m happy to say that, aside from a few chilly looks (mainly from the staff members, rather than the board members, in the room), my no-holds-barred advice was graciously received. Time will tell if it was well received.

February 20, 2013
by Tom Scheinfeldt
4 Comments

Black, White, and Red

Steering partners and clients toward simpler web designs is one of the greatest services we can render. In consultations and collaborative projects, I often find myself advocating for less, less, less. This is especially true when it comes to color schemes—historians aren’t easily put off their beiges, navy blues, burgundies, and parchment textured backgrounds. I do not have any design training, so I have just as often been frustrated by my lack of appropriate and convincing language to explain that when it comes to color, less is often more. Until now.

airjordanLast week I met a design professor who gave me the words. “When we are teaching color to design students,” he said, “we always tell them to start with black, white, and red.” “You don’t have to stay there, but any time you stray from black, white, and red, you should have a good reason.” “It’s no accident Coca-Cola, Marlboro, and Santa Claus are the world’s most recognizable brands.”

To this list he added the highly stylized opening titles of the fashion setting television show, Mad Men. I immediately thought of Nike Air Jordans, and the covers of Time, Life, Newsweek, and The Economist. I’m sure there are many others. Black, white, and red just work. Please feel free to share additional examples in comments.

[Image credit: ididj0emama]

February 13, 2013
by Tom Scheinfeldt
2 Comments

The Hacker Way

On December 21, 2012, Blake Ross—the boy genius behind Firefox and currently Facebook’s Director of Product—posted this to his Facebook page:

Some friends and I built this new iPhone app over the last 12 days. Check it out and let us know what you think!

The new iPhone app was Facebook Poke. One of the friends was Mark Zuckerberg, Facebook’s founder and CEO. The story behind the app’s speedy development and Zuckerberg’s personal involvement holds lessons for the practice of digital humanities in colleges and universities.

Late last year, Facebook apparently entered negotiations with the developers of Snapchat, an app that lets users share pictures and messages that “self-destruct” shortly after opening. Feeding on user worries about Facebook’s privacy policies and use and retention of personal data, in little more than a matter of weeks, Snapchat had taken off among young people. By offering something Facebook didn’t—confidence that your sexts wouldn’t resurface in your job search—Snapchat exploded.

It is often said that Facebook doesn’t understand privacy. I disagree. Facebook understands privacy all too well, and it is willing to manipulate its users’ privacy tolerances for maximum gain. Facebook knows that every privacy setting is its own niche market, and if its privacy settings are complicated, it’s because the tolerances of its users are so varied. Facebook recognized that Snapchat had filled an unmet need in the privacy marketplace, and tried first to buy it. When that failed, it moved to fill the niche itself.

Crucially for our story, Facebook’s negotiations with Snapchat seem to have broken down just weeks before a scheduled holiday moratorium for submissions to Apple’s iTunes App Store. If Facebook wanted to compete over the holiday break (prime time for hooking up, on social media and otherwise) in the niche opened up by Snapchat, it had to move quickly. If Facebook couldn’t buy Snapchat, it had to build it. Less than two weeks later, Facebook Poke hit the iTunes App Store.

Facebook Poke quickly rose to the top of the app rankings, but has since fallen off dramatically in popularity. Snapchat remains among iTunes’ top 25 free apps. Snapchat continues adding users and has recently closed a substantial round of venture capital funding. To me Snapchat’s success in the face of such firepower suggests that Facebook’s users are becoming savvier players in the privacy marketplace. Surely there are lessons in this for those of us involved in digital asset management.

Yet there is another lesson digital humanists and digital librarians should draw from the Poke story. It is a lesson that depends very little on the ultimate outcome of the Poke/Snapchat horse race. It is a lesson about digital labor.

hackerMark Zuckerberg is CEO of one of the largest and most successful companies in the world. It would not be illegitimate if he decided to spend his time delivering keynote speeches to shareholders and entertaining politicians in Davos. Instead, Zuckerberg spent the weeks between Thanksgiving and Christmas writing code. Zuckerberg identified the Poke app as a strategic necessity for the service he created, and he was not too proud to roll up his sleeves and help build it. Zuckerberg explained the management philosophy behind his “do it yourself” impulse in the letter he wrote to shareholders prior to Facebook’s IPO. In a section of the letter entitled “The Hacker Way,” Zuckerberg wrote:

The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it – often in the face of people who say it’s impossible or are content with the status quo….

Hacking is also an inherently hands-on and active discipline. Instead of debating for days whether a new idea is possible or what the best way to build something is, hackers would rather just prototype something and see what works. There’s a hacker mantra that you’ll hear a lot around Facebook offices: “Code wins arguments.”

Hacker culture is also extremely open and meritocratic. Hackers believe that the best idea and implementation should always win – not the person who is best at lobbying for an idea or the person who manages the most people….

To make sure all our engineers share this approach, we require all new engineers – even managers whose primary job will not be to write code – to go through a program called Bootcamp where they learn our codebase, our tools and our approach. There are a lot of folks in the industry who manage engineers and don’t want to code themselves, but the type of hands-on people we’re looking for are willing and able to go through Bootcamp.

Now, listeners to Digital Campus will know that I am no fan of Facebook, which I abandoned years ago, and I’m not so naive as to swallow corporate boilerplate hook, line, and sinker. Nevertheless, it seems to me that in this case Zuckerberg was speaking from the heart and the not the wallet. As Business Insider’s Henry Blodget pointed out in the days of Facebook’s share price freefall immediately following its IPO, investors should have read Zuckerberg’s letter as a warning: he really believes this stuff. In the end, however, whether it’s heartfelt or not, or whether it actually reflects the reality of how Facebook operates, I share my colleague Audrey Watters’ sentiment that “as someone who thinks a lot about the necessity for more fearlessness, openness, speed, flexibility and real social value in education (technology) — and wow, I can’t believe I’m typing this — I find this part of Zuckerberg’s letter quite a compelling vision for shaking up a number of institutions (and not just “old media” or Wall Street).”

There is a widely held belief in the academy that the labor of those who think and talk is more valuable than the labor of those who build and do. Professorial contributions to knowledge are considered original research while librarians and educational technologists’ contributions to these endeavors are called service. These are not merely imagined prejudices. They are manifest in human resource classifications and in the terms of contracts that provide tenure to one group and, often, at will employment to the other.

Digital humanities is increasingly in the public eye. The New York Times, the Los Angeles Times, and the Economist all have published feature articles on the subject recently. Some of this coverage has been positive, some of it modestly skeptical, but almost all of it has focused on the kinds of research questions digital humanities can (or maybe cannot) answer. How digital media and methods have changed humanities knowledge is an important question. But practicing digital humanists understand that an equally important aspect of the digital shift is the extent to which digital media and methods have changed humanities work and the traditional labor and power structures of the university. Perhaps most important has been the calling into question of the traditional hierarchy of academic labor which placed librarians “in service” to scholars. Time and again, digital humanities projects have succeeded by flattening distinctions and divisions between faculty, librarians, technicians, managers, and students. Time and again, they have failed by maintaining these divisions, by honoring traditional academic labor hierarchies rather than practicing something like the hacker way.

Blowing up the inherited management structures of the university isn’t an easy business. Even projects that understand and appreciate the tensions between these structures and the hacker way find it difficult to accommodate them. A good example of an attempt at such an accommodation has been the “community source” model of software development advanced by some in the academic technology field. Community source’s successes and failures, and the reasons for them, illustrate just how important it is to make room for the hacker way in digital humanities and academic technology projects.

As Brad Wheeler wrote in EDUCAUSE Review in 2007, a community source project is distinguished from more generic open source models by the fact that “many of the investments of developers’ time, design, and project governance come from institutional contributions by colleges, universities, and some commercial firms rather than from individuals.” Funders of open source software in the academic and cultural heritage fields have often preferred the community source model assuming that, because of high level institutional commitments, the projects it generates will be more sustainable than projects that rely mainly on volunteer developers. In these community source projects, foundations and government funding agencies put up major start-up funding on the condition that recipients commit regular staff time—”FTEs”—to work on the project alongside grant funded staff.

The community source model has proven effective in many cases. Among its success stories are Sakai, an open source learning management system, and Kuali, an open source platform for university administration. Just as often, however, community source projects have failed. As I argued in a grant proposal to the Library of Congress for CHNM’s Omeka + Neatline collaboration with UVa’s Scholars’ Lab, community source projects have usually failed in one of two ways: either they become mired in meetings and disagreements between partner institutions and never really get off the ground in the first place, or they stall after the original source of foundation or government funding runs out. In both cases, community source failures lie in the failure to win the “hearts and minds” of the developers working on the project, in the failure to flatten traditional hierarchies of academic labor, in the failure to do it “the hacker way.”

In the first case—projects that never really get off the ground—developers aren’t engaged early enough in the process. Because they rely on administrative commitments of human resources, conversations about community source projects must begin with administrators rather than developers. These collaborations are born out of meetings between administrators located at institutions that are often geographically distant and culturally very different. The conversations that result can frequently end in disagreement. But even where consensus is reached, it can be a fragile basis for collaboration. We often tend to think of collaboration as shared decision making. But as I have said in this space before, shared work and shared accomplishment are more important. As Zuckerberg has it, digital projects are “inherently hands-on and active”; that “instead of debating for days whether a new idea is possible or what the best way to build something is, hackers would rather just prototype something and see what works”; that “the best idea and implementation should always win—not the person who is best at lobbying for an idea or the person who manages the most people.” That is, the most successful digital work occurs at the level of work, not at the level of discussion, and for this reason hierarchies must be flattened. Everyone has to participate in the building.

In the second case—projects that stall after funding runs out—decisions are made for developers (about platforms, programming languages, communication channels, deadlines) early on in the planning process that may deeply affect their work at the level of code sometimes several months down the road. These decisions can stifle developer creativity or make their work unnecessarily difficult, both of which can lead to developer disinterest. Yet experience both inside and outside of the academy shows us that what sustains an open source project after funding runs out is the personal interest and commitment of developers. In the absence of additional funding, the only thing that will get bugs fixed and forum posts answered are committed developers. Developer interest is often a project’s best sustainability strategy. As Zuckerberg says, “hackers believe that something can always be better, and that nothing is ever complete.” But they have to want to do so.

When decisions are made for developers (and other “doers” on digital humanities and academic technology projects such as librarians, educational technologists, outreach coordinators, and project managers), they don’t. When they are put in a position of “service,” they don’t. When traditional hierarchies of academic labor are grafted onto digital humanities and academic technology projects that owe their success as much to the culture of the digital age as they do to the culture of the humanities, they don’t.

Facebook understands that the hacker way works best in the digital age. Successful digital humanists and academic technologists do too.

[This post is based on notes for a talk I was scheduled to deliver at a NERCOMP event in Amherst, Massachusetts on Monday, February 11, 2013. The title of that talk was intended to be "'Not My Job': Digital Humanities and the Unhelpful Hierarchies of Academic Labor." Unfortunately, the great Blizzard of 2013 kept me away. Thankfully, I have this blog, so all is not lost.]

[Image credit: Thomas Hawk]

January 29, 2013
by Tom Scheinfeldt
0 comments

Take me to your leader: The importance of knowing who's in charge

You’ve probably been there. A new job, a new project team, a new client. A great first meeting. Everyone is invited to talk, to listen, to contribute. Everyone is assured that their voices will be heard, their concerns addressed, their ideas taken seriously.

Fast forward a week, a month, a year. One by one, those voices have been silenced, those concerns dismissed, those ideas undermined. What remains are the ideas and concerns of the person who (it has now become clear) is in charge.

To do their jobs effectively, members of a project team need to know who the decision maker is. We all like democracy, those of us in education and cultural heritage especially so. If it’s truly a democracy, great. But if it’s a dictatorship, people would rather know from the outset than be led down a rhetorical primrose path of “democracy,” “consensus,” and “collaboration” only to have the rug pulled out from under them when the decision maker finally decides to assert his or her will.

If you are the decision maker, let us know. Anything less treats team members like children and wastes everybody’s time. What’s worse, it makes for shortsighted, haphazard, second-rate work product.

March 23, 2012
by Tom Scheinfeldt
1 Comment

Ancient Religion, Modern Technology: Takeaways

[Last month, I posted notes from my keynote at Brown University's Ancient Religion, Modern Technology workshop. I was also fortunate to be invited to offer some concluding observations to the excellent group assembled there. Here they are, my very rough notes.]

1) The community of scholars interested in ancient religion has done some extraordinary digital work with extraordinarily little money. The work of Michael Penn, David Michelson, and other members of “Syraic Mafia” (as that small group of scholars working on ancient Syriac manuscripts was dubbed during the workshop) through projects such as the Syriac Reference Portal is a particularly striking example of this.

2) I was struck by the extent to which this community has identified real problems/questions and how incredibly successful it has been in answering them. It seems to me that integrity and availability of the texts is a much bigger problem in classics than in more modern history. But it is also a problem that lends itself to digital solutions: edge matching, name authority, calendar disambiguation, and handwriting recognition are clearly defined problems with clearly identifiable (if difficult) solutions. These are what we might call “instrumental” uses of technology, and they seem less current among the broader community of digital humanists. I think that broader community could benefit from a renewed focus on these kind of problems in our own domains, but I think this community could stand a broader discussion about the possibly “squishier” things that occupy much of the rest of digital humanities: new modes of scholarly communication, digital pedagogy, open access, public humanities and social media.

3) Digital humanities has too often gone searching for the elusive “one” database/tool/standard. To a large extent, this search has been driven by our funders, who are reluctant to fund multiple projects with the same ends, but we have been complicit as well. I caution this group to avoid this trap. The notion of the “one” doesn’t represent the way either technology or the humanities proceed. Technologies and ideas exist in dialog with one another. Put crudely, they compete in the marketplace. There isn’t one smartphone, and there isn’t one book about Alexander the Great, and we wouldn’t want there to be. In the same way, I don’t think there has to be or even should be one database/tool/standard for the things we want to accomplish. I don’t think we or our funders should be so concerned about duplication of effort or projects that “do the same thing.” We should strive for interoperability in our products, but we shouldn’t wish for just one. I understand where the impulse comes from. It is messy and unsatisfying to have overlapping and competing databases, standards, and tools. But what are the humanities if not messy and, ultimately, unsatisfying? These are the things that spur us on to new research.

css.php